JSTQBシラバスに出てくる「ヒューリスティック」とは何ぞや

JSTQBのテストアナリストやアジャイルテスターのシラバスで、「ヒューリスティック」という言葉を見かけて意味が分かりにくかったので、自分なりにまとめてみます。しっくりくる日本語がないので、英語のままにした方がよさそうな単語ですが、いきなり出てくると意味がとらえがたい単語ですね。

ヒューリスティック(heuristic)の辞書的な意味

Google先生に聞いてみたところ、以下の意味になります。

enabling a person to discover or learn something for themselves.
(人が自分で何かを発見または学習できるようにします。)

()内は私の訳なので、間違っていたらすみません。
語源は何だろうと調べてみたところ、ギリシャ語由来らしいです。これまたGoogle先生情報です。

early 19th century: formed irregularly from Greek heuriskein ‘find’.
(19世紀初頭:ギリシャで「見つける」を意味するheuriskeinから不規則活用された)

ちなみにアルキメデスの「エウレカ!」と同じ語源のようです。
f:id:yuki_shiro:20200301175842p:plain
こういう豆知識が好きなので個人的にテンションがあがりますw
雰囲気としては、経験などから発見して学習する、みたいな意味合いになるでしょうか。

ヒューリスティックという言葉が出てくる分野

ざっとググってみた感じ、心理学、教育分野、IT、証券などで出てくるようです。人の心の動きに関わるものなので、人間のかかわる活動全般に出てくるということかと思います。「経験から学ぶ」といういい意味でも使われるし、「経験に縛られる」という悪い意味でも使われるようです。

JSTQBテストアナリストで出てくるヒューリスティック評価法とは何か

テストアナリストのシラバスでは、使用性テストの文脈で出てきます。該当箇所はこちら。

ヒューリスティック評価(使用性に関するユーザインターフェース設計の体系的なインスペクション)は、設計における使用性の問題を発見するのに使用できるので、イテレーティブな設計プロセスの一部として使用できる。
(4.2.4.2 使用性テストの詳細 p44)

ユーザビリティの専門家が対象となるシステムを見て、経験則に基づいてUI上の問題点を発見する手法だそうです。専門家ではなくても、あらかじめ用意されている観点があるので、それに沿って評価できます。あらかじめ用意されている観点としては、ヤコブ・ニールセンのユーザビリティ10原則が有名です。原題は「10 Usability Heuristics for User Interface Design」です。ヒューリスティックという言葉が出てきてますね。
詳しい内容はこちらのサイトで確認できます。
www.nngroup.com

JSTQBアジャイルテスターで出てくるヒューリスティックとは何か

アジャイルテスターのシラバスでは、探索的テストの文脈で出てきます。該当箇所はこちら。

テスト時には、一連のヒューリスティックを適用できる。ヒューリスティックは、テストの実行方法と結果の評価方法についてテスト担当者をガイドする [Hendrickson]。たとえば、次のようなものがある。
A set of heuristics can be applied when testing. A heuristic can guide the tester in how to perform the testing and to evaluate the results [Hendrickson]. Examples include

  • 境界
  • CRUD(作成(Create)、読み取り(Read)、更新(Update)、削除(Delete))
  • 構成のバリエーション
  • 中断(ログオフ、シャットダウン、再起動など)

(3.3.4 探索的テストとアジャイルテスト p44)

最初の説明部分の文章は、分かりやすくするために英語版を併記しました。「A set of heuristics」と書かれているので、ここでは「経験則一式」くらいの意味で書かれているのだと思います。

以上、JSTQBの文脈で出てくる「ヒューリスティック」についてまとめてみました。何かの参考になれば幸いです。

参考

こちらのサイトや書籍を参考にいたしました。
ヒューリスティック評価
https://u-site.jp/usability/evaluation/heuristic-evaluation/
・ユーザーエクスペリエンスの測定

テスト手順、詳しく書くかざっくり書くか

こんなことをつぶやいたら、色々ご意見をいただいたので自分なりにまとめてみます。


具体的テストケースと論理的テストケース

JSTQBのテストアナリストのシラバスには、具体的テストケースと論理的テストケースについて言及があり、ざっとまとめてみると次の通りになります。

具体的テストケース 論理的テストケース
概要 テスト担当者がテストケース(すべてのデータ要件を含む)を実行し結果を検証するために必要な特定の情報と手順のすべてを提供する テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする
メリット テスト担当者の経験が少なくてもテストケースを見れば、テスト実行可能。再現性が高い。監査にも使用可能。 テスト実行時の変更を許容するため、具体的テストケースよりカバレッジが高い場合がある。
デメリット メンテナンスに労力がかかる。テスト実行者の想像力を阻害する場合がある 再現性が低い場合がある。

(Advanced Level シラバス日本語版 テストアナリスト 「1.5.1 具体的テストケースと論理的テストケース」 p13)
上記の概要は、シラバスからの引用ですが、具体的テストケースの方は、テスト実行の主語が「テスト担当者」となっているのに対し、論理的テストケースの方は、主語が「テストアナリスト」となっています。テスト実行するのが誰かによって、テスト手順や期待結果の粒度をどの程度書くかが意識されてるように思います。

具体的テストケースと論理的テストケースをどう使い分けるか

自分の使い分けについて考えると、テスト実行するメンバとの物理的距離と熟練度が大きく影響しています。

テスト実行するメンバが同じ場所にいる場合

使用するテストケース

論理的テストケースです。「××欄に任意の値を入れる」などの表現をよく使っています。

前提

テスト実行に入る前に、テスト実行してもらうメンバに、テスト対象の目的の説明やテスト対象を一緒に動かしてみるなどを行います。物理的距離が近いと、実行メンバの理解度の確認やなにかあったときのフォローが容易にできます。
ある程度複雑な手順が必要だったり、使用するコマンドなどを具体的に指定した方が良い場合は、テストケースとは別途、確認手順書を書いて具体的な内容はそこに寄せるようにしています。メンテナンスは必要ですが、テストケース一つ一つに手順を書くことに比べると、共通化できている分楽です。

良い点

テスト対象の目的、それで実現したいことを共有しておくと、こちらが想定していなかった問題を見つけてもらえることもあります。(逆に、うまく共有できていない時には、細かすぎるバグを大量に報告してしまったこともありました)
テストケースを書く量が少なくて済むので、メンテナンスが楽です。詳細にテストケースを記載する時間が浮くので、教育とかバグを見つけるための活動に時間を使うことができます。Twitterでもこのようにアドバイスをいただきました。

テスト実行するメンバが離れた場所にいる場合

使用するテストケース

具体的テストケースの方が多いです。特にあまりフォローができない場合は、テスト実行に迷わないように具体的に書きます。

良い点

テストケースの記載通りに進められる場合は、経験の少ないメンバでもスムーズに進められます。

悪い点

ちょっとしたUI変更で、テストケース通りに進められない場合は質問の嵐になることがあります。テストケースを修正するにも時間がかかります。物理的距離が離れていたり、さらに時差がある場合はフォローがしにくいので、自分の中には、この問題への対処策はこれといったものがありません。ある程度実行メンバを教育して、修正案を出してもらい、自分はそれを判断するだけにする、とかでしょうか。。

まとめ

テスト実行メンバが同じ場所にいる場合は、論理的テストケースを作成して、メンバへの教育を手厚くするのが良いと思います。離れた場所にいる場合は、よい対応策を募集中です。
最後に、ふとしたつぶやきにアドバイスをくださった皆様、ありがとうございました!

JaSST'20 RejectConに行ってきた

ピースオブケイクさんで、JaSST Tokyoに残念ながら落ちてしまったプロポーザルを供養するイベントがあったので、供養に参加してきました。イベント概要はこちら。
connpass.com

noteでのテスト自動化に関する取り組み(ピースオブケイク・増原さん)

※ちょっと遅れて到着したので、講演途中からのメモです。

  • MagicPod使ってる
    • クラウドシミュレータでシナリオが作れる
    • サポートが速い

 

  • 分かったこと
    • エンジニアを巻き込むの大事→はまりどころに二人で立ち向かえる
    • PR単位のFBになると実行時間長め
    • リリース前のテストで変更箇所に集中できる

Flow理論に学ぶレベルアップの鍵(Mark Wardさん)

リベラル・アーツの世界

リベラル・アーツはRIPPAなものを作るのに必要
フローはレベルアップの鍵。
強い状態(フロー)

  • 楽しさ、幸福感
  • 集中
  • 複雑さ:込み入った問題を解くこと

→フロー状態は能力と挑戦が釣り合っている状態。釣り合ってないと不安だったり退屈だったりする。

  • メンタルステート図
    • 挑戦と能力の度合いによって、心理状態にどう変化があるか
    • 挑戦ルート:不安→覚醒→フロー。フローに至るまでの速さは、理解の速さやスタート地点の差による
    • 能力ルート:くつろぎ→幸福→フロー。コントール感があるが、時間がかかる

→頑張れないなら、頑張り方を変える必要がある。それには組織の理解と協力が必要

WebアプリケーションE2Eテスト自動化の3つの壁(末村さん)

自動化の現実

自動化は進んだものの

  • バグを検知できない
  • 思ったより高頻度で実行できない
  • どうでもいいところでコケまくる

バグ検出できないことへのアプローチ

  • 網羅性が低い
    • スナップショットテスト:HTMLの差分を比較(Jestとか)
    • ビジュアルリグレッションテスト:スクショを比較(CodeceptJSとか)
    • 実行時エラーを検知

実行速度問題へのアプローチ

  • テストデータをAPIやコマンドで作る
  • 通信部分だけ実行する
  • 状態をキャッシュする:ログインを毎回やるのはつらい
  • 並列実行(Zalenium、Selenoidなど)
    • 注意点:何度実行しても同じ結果になるようシナリオを作っておく必要あり

安定性へのアプローチ

  • 失敗したステップをリトライする
  • シナリオをリトライする
  • 不安定性を可視化する(Allure Reporterがいい)

まずはE2Eは難しいことを理解する

  • E2Eでしかできないことに注力しよう

おまけ

プロダクト開発におけるアジャイルQA活動(生井さん)

不採択の理由を踏まえる

  • 品質は健康診断*アジャイル開発→最近QAとお医者さんの話題も上がってるし着眼点は悪くなかった
  • 査読コメント
    • チームに展開した結果はどうだったかの事例がききたい(説得力)

伝えたかった事

  • 開発に終わりはない:プロダクトは成長・複雑化していくが、テストリソースは同じ勢いでは増加しない
  • 広さ*深さに加えて時間
    • 広さ:品質特性を軸にどこを見るか
    • 深さ:どこまで見るか
    • 時間:適切に発見できるか
    • 時間*深さ 素早く検査できるか、頻度を意識する必要がある
  • ソフトウェアテストの海はとても広い
    • 物量が膨大になった中でどう理想に近づくかが腕の見せ所

当たり前のことを当たり前にやる

テスト?自動化?それよりもQA/QCの業務とは(仮)(gremitoさん)

プロダクトに最もあう品質チェック作業を模索または最適化

QA/QCのリーダーシップ
QA:品質保証
QC:品質管理

終盤にいくら頑張ってもバグをつぶせない

  • 開発メンバとのコミュニケーションはとっていたか
  • テスト計画は開発の序盤あたりから始められていたか
  • 開発のMTGに参加して状況を把握しているか

開発チームの中にQAメンバがいる
QAは初めの方から参画する
品質チェックに入る前にテスト計画とテストケース作りを終わらせる
→開発チームの一員

ウォーターフォール(V字)開発でモブ設計してみた(t_isekiさん)

問題点

  • 開発者が特定のモジュールを設計、開発する
  • システムテストフェースで後戻りが大きすぎる

実現したかった事

  • やり直しを減らしたい

なぜモブか?

  • ファシリテーションが難しい(めくら承認、設計した人が悪者に)
  • 作業管理が面倒
  • 問題 vs 私たちの構図にしたい

モブ設計

  • 準備
    • 主担当が章立てを容易
    • 章立てに対して気になることや注意点などを参加者がメモ
  • 実施結果

<Good>

  • 要件や設計思想の統一認識
  • ドキュメント整備
  • テスト設計のシフトレフト
  • 当事者意識が芽生えた

Improve

  • 長時間やるとだれる

感想

テストに対して、リベラルアーツや自動化やチームのお話など、色々な切り口からの発表があって、どの発表も楽しめました! 本当にこれRejectなのかと思うほど、素敵な内容でした。企画、登壇者、スタッフの皆様ありがとうございますー!

「テストの宿泊型ワークショップWACATE2019冬参加報告」で参加報告してきました

先日WACATEの参加報告会が、ビズリーチさんのD3で行われ、私もそこでLTをさせていただきました!
イベントの詳細はこちらからどうぞ。
d-cube.connpass.com
当日の様子はTogetterにまとめられてるので、雰囲気を知りたい方はこちらもどうぞ!
togetter.com
WACATEのテーマの一つに「加速」があるのですが、どの方のプレゼンも加速感あふれてて素敵でした。

K氏「開発者からQAになった話 とWACATEに行ってきた」

概要
  • 知識量は土台、思考力がより良い結果を導ける
  • テスト技法とかの土台があって、思考力によってより良い結果を導く。知識と思考のバランスが大事。
  • プロセス改善もQAの業務。リリース後の問い合わせのパンクを防げたりした。
  • 業務フローを把握していればシナリオテストに流用できる
感想

開発、QA、PM的な立場を経験されている方なので、それぞれで得た見方を、役割を変えても生かしてるところが素敵です。QAから改善のボールを開発に渡して、開発者が続けてくれてるのがすごいなと思います。

たおかさん「WACATEにより爆発的に加速したQA歴3か月の新卒の話」

なんと初LTとのこと!

概要
  • 新卒3か月目「QAだったらどうする?」開発者の質問に答えられず。→自分に自信がない。QAとして情けない。
  • そんなとき、上司から「WACATEってイベントがあるよ!」
  • お気に入りのセッションソフトウェアテストの7原則
  • 参加後、自分で考えて動けること
    • 目の前のことではなく、その背景や理由を念頭に対応する
    • 言語化して誰かに表現することにより、真に自分の理解が深まる
感想

新人でWACATEに参加して、さらにLTまで立候補する加速感が素晴らしすぎる! (自分が新人のころをふりかえると、日々の業務でアップアップでそこまでのチャレンジ精神はなかったと思います)
素敵なのは、自分で「テスト完了することがゴールになっていた」と気づいたことだと思います。内容も素敵だったし、初LTとは思えないくらいに堂々と発表されてました!

かなさん「WACATEに参加すると・・・?」

概要
  • WACATE参加前「なんとなくテストケースを書いて、なんとなく実施する人」
  • 参加した後
    • 言語化大事と気づいた!
    • なぜを常に考えるようになった
    • 社外に相談できる人ができた!
  • WACATEではワークはうまくいかなかった。プロダクトの特性を考えずにテストしようとしてた。
    • しかしWACATEは業務でないので失敗できる。失敗をもとに加速できる!
  • 自分のプロダクトで大事なものはなんだ?を考えて社内の同じチームの人に話せるようになった
感想

スライドをご覧になっていない方は、ぜひスライド見てください! かなさんのイラストや図がとてもかわいいくて引き込まれます! 
WACATEの説明や、雰囲気などが伝わってきて、とても素敵なプレゼンでした! WACATEについてやセッションの説明もとても丁寧で、WACATE未経験者にはすごく伝わりやすいプレゼンだったのではないかと思います。

02さん「WACATEとテストと開発エンジニア」

概要
  • 参加の動機:品質悪いと上司に言われて夜泣いた→自分で品質を良くするために勉強したい
  • 品質やテストについて一緒に勉強する仲間が欲しかった
    • とにかく手を動かして勉強したい
  • セッション中の学び:ただ覚えるだけでは得られない経験・知識を得た
  • 自分一人では理解できなかった分野を理解できた
  • WACATEは一つのコミュニティ
  • WACATE後
    • テストやテストコードをテーマに登壇するようになった!
    • 知識:ある程度実践した見たものばかりに!
    • アウトプット:たまにテストのテーマで登壇するように
    • テスト仲間:Twitterフォロワーの1/3!
感想

WACATEで得た仲間のことを「社外の同期」や「WACATEは一つのコミュニティ」と言っていたのがとても印象に残りました! 私の感覚としても、すごく実態に合ってる素敵なワードチョイス。「同期」という言葉が、気軽に相談できて、一緒に切磋琢磨できる感じを表してて本当に素敵です。
プレゼンの進め方も、ゴールの提示がはっきりしていてわかりやすかったです。

信頼貯金さん「WACATE参加報告 ~WACATEに参加した前後で何が変わるのか~」

概要
  • WACATEとは
    • テスト活動の基礎からアドバンスドまで扱う
    • 分野の知見を豊富に持つ人から話を聞ける
  • ワークや分科会で一気通貫で理解が深まる
  • WACATE 2019夏
  • テスト計画の誤った理解をアンラーニング
    • 「計画は守るために作るものだ」から、計画は手段、プロジェクトの狙いを反映していい、に変わった
  • テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題
  • WACATE冬、テーマが多い。すごいポテンシャル
  • 自分一人では到達できないできないところに到達できる!
感想

テスト計画に触れたところで「テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題」と話されてたのが印象に残りました。「アンラーニング」がキーワードなのかなと思いますが、こう思えるようになった学びが素敵です。

shiromoto「WACATEで得たものとその活かし方」

発表の感想

WACATEの参加動機、駆動方法は色々ありますが、その一つに「カープ優勝駆動」というものがございますw 勢いでも何でもいいので、飛び込んでみると世界が開けるよ、という話だったのですが、もし誰かの背中を押せてたら嬉しいな、と思います。WACATE参加で仲間が増えるのは、本当に参加のメリットなので、迷ってる人がいたらぜひ一度参加をお勧めします。

きんぢさん

概要

WACATE実行委員の宣伝のセッションでした。
WACATE実行委員をやると、次の力が身に付くそうです。

  • アウトプット
  • プレゼン構成力(少しずつ解像度を上げていく)
  • 合宿の企画力
  • 仕組化・自己組織化
  • 実行委員はいいぞ!
感想

WACATEで参加者が解散した後、片付けや次の予約、次の次の仮予約まで済ませてくださってるという実行委員の方々には、感謝しかないです。毎回ありがとうございます!
WACATEで得たものを日々の業務で活かしたり、悩んでるテストエンジニアにWACATEを進めたりで、恩返しや業界への貢献をしていきます。

「数学ガールの秘密ノート/学ぶための対話」は、学生時代に数学をパターン暗記で乗り切ってしまった人にお勧め

昨年参加したソフトウェアテストの合宿形式の勉強会・WACATEのお楽しみ抽選的なイベントで『数学ガールの秘密ノート/学ぶための対話』をいただきました。

色々とぐさりと来るところがあったので、ちょっと感想などを書いてみます。なお、数学ガールはシリーズものですが、私はこれ一冊しかまだ読んだことがありません。

この本をお勧めしたい人

数学が苦手で、パターン暗記で乗り切った人にお勧めします。私はほぼパターン暗記で学校の数学を乗り切ったタイプです。

なぜお勧めできるか

私は数学が苦手です。苦手な理由は、恐らくですが中学・高校時代に数学を理解せずにパターン暗記で対処していたからではないか、とこの本を読んで思いました。

本の中で何度か主人公で数学の得意な「僕」は、数学を教わりに来てる「ノナちゃん」から「暗記しますか?」と聞かれます。暗記ではなく理解するよう主人公は諭すのですが、まさに暗記してたのが昔の私です。たぶん今もその傾向は続いていると思います。

パターン暗記の問題点

自分の場合ですが、パターン暗記のやっかいなところは、パターン暗記で教科書の理解確認問題や中間テストは対処できるので、理解できてないことに気づきにくい点でした。そして、単に覚えているだけなので、当然忘れていきます。

範囲の広い実力テストなどになると、中間テストに比べると正答率が劣るので、うっすら「実は分かってないかも?」と疑います。その時に理解するよう動けばよかったんだと思いますが、今思うと、自分の対処は「暗記するパターンを増やす」と「反復練習して記憶から抜ける量を減らす」でした。受験対策としては間違ってないんですが、理解が進んだかといえば、ちょっと怪しいです。

この本のお勧めなところ

この本では、言及されている数学の範囲は、一次関数とグラフのみです。それだけなので、パターン暗記で覚えてしまおうとするとすぐ済む内容なんですが、暗記ではなく理解を促すように話が進みます。ちょうどパターン暗記してしまいそうになるあたりで、ノナちゃんが「暗記しますか?」と聞いてくれます。自分も暗記に走りそうになっていたことに気付けるので、ノナちゃんと一緒に意味を考えながら読めるようになっています。

数学をパターン暗記で乗り切った人が、意味を理解するってなんだろうと思いながら読むと、ちょうど良い本だと思います。

WACATE2019冬「あなたの番です」参加レポート2日目!

2日目レポートも行ってみまーす。

f:id:yuki_shiro:20191215130639j:plain
三浦海岸の朝焼け

モーニングセッション:Agile Testing Days 2019 参加レポート

ブロッコリーさん)
資料はこちら!
speakerdeck.com
Agile Testing Days:ドイツのポツダムで11月に毎年開催、全日程6日間、参加費は約30万円。
800人くらいが参加する。キーノートだけで14個!本会議のセッションは9レーン。
セッションには認知科学や健康がテーマのものもある。
「人間てのは壊れた櫛だよ。人それぞれ得意不得意がある。だからチームとして動くといいよねー」みたいなこと主張してるセッションがあったり、ホームズとワトソンになりきってるセッションがあったり、着ぐるみで発表しようとしたけど暑くて開始3分で脱いだり、とか多様すぎる。ドイツと南アフリカにすむ二人が学習パートナーシップを組んだ結果、毎日カンファレンスに参加している気分になった!→距離について言い訳するのはやめようぜ!

感想

国際カンファレンス楽しそう!特にAgile Testig Daysはフリーダム度が高くて面白そうなのが伝わってきました。資金面は何とかするにしても一度行ってみたいですね。なお、手軽に国際カンファレンスを楽しむ手立てとしては、OnlineTestConf Japanもございますので、よろしくお願いします(宣伝)!

アジャイルとテスト

(つのださん)
資料はこちら!
speakerdeck.com

アジャイルについて

世の中の流れが速い、ニーズをそもそも完璧に確定するのが難しい

  • アジャイル向きなシステム:外部要因に大きく影響を受ける
  • アジャイル向きでないシステム:不確実性があまりないシステム。ミッションクリティカルとか
  • アジャイルソフトウェア宣言→ソフトウェアをよりよく作るための考え方

アジャイルのテストについて

アジャイルのテスト→フィードバックを得るため

  • 頻繁なコミュニケーション
  • 手戻りを減らすための複数人同時作業
感想

アジャイルに向くもの、向かないものの説明も含めて、短いけど丁寧にアジャイルとテストをまとめてもらえたセッションでした。アジャイルのテストは「フィードバックを得るため」は、確かにそうだなーと思います。自分の現場でも、フィードバックを早めるための施策は試行錯誤してるので、レビューでのフィードバックなど地道にやっていきます。

ソフトウェアテスト業界でのステップアップを考えよう

(きんぢさん)
資料はこちら。

www.slideshare.net
メモも貼っておきます。
f:id:yuki_shiro:20191215130719j:plain

感想

「品質 is 何」や「3年後どうなっていたいか」のような問いかけで、班のメンバーから本当に現場に応じたいろいろな意見が出てきて面白かったです。自分にとっての品質は、「ユーザがシステムで解決したいことを解決できている」とか「やりたいことをより簡単に、楽にできるようになっている」とかだと考えています。これが医療機器とか自動車とかに携わる方になると、「人が死なないこと」とかが出てくるのだなーと自分にない視点が出てきて面白かったです。
テストの分け方はテストレベルやテストタイプ、自動化などいくつか種類があるので、この後のキャリアのために自分がどの位置で仕事しているのかを把握するのは重要だと思いました。キャリアマップを作りたいなーと思っているので、このセッションからヒントをいくつかもらえた気がします!

WACATE流勉強会の作り方

(えっちゅーさん)

  • 勉強会をやるとよいところ
    • プロジェクト運営の疑似体験ができる
    • アウトプットすることで思考の整理、分かるところ分からないところの明確化ができる
  • 勉強会をやるのに考えること

時間

  • 必要な時間は?
  • 会場、準備にかかる工数

会場

  • 人数と会場の広さ
  • 必要な設備が整っているか
  • 開催希望日に利用ができるか

事前準備

  • 参加者に事前にやってきてもらうと嬉しいことは?
  • 持ってきてもらいたいものはある?

開催回数

  • 今回限り? 何度も開催する? 定期/不定期?

対象者

  • どういった人に参加してもらいたい?

運営にかかるお金

  • お金をかけずに開催できる? かかる場合、何にどれくらいおかねがかかる?
  • 必要な金額はどうやって集めるか?

登壇者

  • 自分たちが話すか、講演者を呼んで話してもらうのか?
感想

WACATEに限らず応用できる話ですが、WACATEの実行委員の方々がすごくこだわって勉強会を作られてるのが伝わってきました。ここまで考えてくださってるの、本当にありがたいです。
自分が主催した勉強会で、テーマ設定と参加者のレベル感を上手く合わせられず、ちゃんと勉強会の設計しておけば良かったと後悔したことがあるので、次に活かします。

招待講演:テスト設計をより良くするモデリングと観点分析

資料はこちら!
speakerdeck.com

感想

講義のために簡略化されたとはいえ複雑なテスト対象をモデリングして、リスクまでクリアに見えてく様子がすごく綺麗でした!あれを自分でできるようになりたい。
モデリングはわりと難しくとらえてたところがあるのですが、比較的簡単なものはテスト技法ですでに使ってるというところで、ちょっと勇気が出ましたw にしさんの「絵(図だったかも?)を描け」に通じるところがあって、本質はたぶん同じことを言ってるのではないかと思いました。
モデリングで知識の部分はごく一部で、目的に応じて使い分けるところが難しいと感じます。テスト技法自体は知っていても、現実のどの場合にどの技法を当てはめればいいのか、すぐには判断つくようになりませんでした。要件レベルになると経験があまりないので挑戦になりますが、ここができるようになるとビジネスに貢献できる幅が広がるので、自分としては今後の挑戦のしどころです!

2日間を通じての感想

テストに情熱を持つ方々とワークしたり、お話したりできて楽しかったです!場を作ってくださった実行委員の方々、話してくださった参加者の方々ありがとうございます!
今後やりたいことへのヒントがもらえました。息切れしないようにちょっとずつ加速しますw Twitterアイコンとご本人が一致した方が増えたのも嬉しかったです。またどこかの勉強会でお会いすると思うので、よろしくお願いします。

WACATE2019冬「あなたの番です」参加レポート1日目!

ソフトウェアテスト業界にはお馴染みのWACATEにやってまいりました!
f:id:yuki_shiro:20191214231734j:plain
若手(若手じゃなくても)が手を動かして学ぶ2日間合宿形式のワークショップです!さあ、加速できるかな?

BPPセッション

(はるにゃんさん)
何も言わない。これを見てくれ。
f:id:yuki_shiro:20191214231620j:plain
石油王に敬意を表して、私にしてはグラフィックなグラレコになりました。
BPPをとるために戦略的に考えて、インパクトに残るポジションペーパーにしているのかの過程を説明してくれて、すごく分かりやすかったです。人生初の登壇だったそうですが、間の取り方もうまくて何度も爆笑が巻き起こったセッションでしたw
テストラジオでもBPPセッションの裏話が紹介されているので、ぜひこちらも聞いてください!
testradio.fm

業務でも活用できるソフトウェアテストの7原則

(ブロッコリーさん)
資料やセッションの経緯は、ブロッコリーさんがブログで公開してますので、ぜひこちらでどうぞ。
nihonbuson.hatenadiary.jp

感想

ワークは、実際にテストの現場でありそうな会話から、テストの7原則に反してそうなものを見つけるという内容でした。ワークのまとめで言及されていたのですが、テストの7原則を理解した上で、「7原則があるからと言って、正義を振りかざすべきタイミングを見極める。原則に沿えない場合もあるので話を聞いて障壁を取り除く」ことができるのが重要だと感じました。次のワークでも感じましたが、相手を詰めても前に進めないので、7原則は、背景などを話した上で「じゃあどうするか」を考えるための材料にするべきものですね。

物語を想像して問いを立ててみよう

(かおりっとさん)
資料はこちら!
speakerdeck.com
「問い」をうまく活用して、相手の考えていることを紐解いていくセッションでした。
ワークで実施した内容は次の通りです。

  • 相手に何かを思い浮かべてもらう
  • 相手が思い浮かべたものを当てるために、「問い」をしていく。ただし「問い」で使えるのは、Yes/Noでこたえられる質問のみ。
  • ワークでは時間が限られるため、実行委員が用意してくれたテストに関するキーワードの中から「答え」になるものを選ぶ
  • 質問は5個まで

実際にやってみると、色々な想定外が発生し、思った以上に難しかったです。

  • 「問い」を立てるって難しい
  • 自分が「問い」で使った言葉で相手が同じものをイメージしているとは限らない
    • 「イベント」という言葉でWACATEやJaSSTを想定していたけど、相手は「レビュー」などの粒度で想定していた、という例があった
  • キーワードの中から答えを選ぶ形式で、選んだものが同じ事態が発生。同じものを選ばないだろうというバイアスが働き、答えを当てられなかった
感想

問いって本当に難しいなーと感じました。問いはうまく使わないと、相手を詰めてしまう凶器になりかねないとは思ってます。ワークの短い間でも、背景のずれやバイアスがかかったりとかを、ちゃんと意識できる状態で体感して、「ここまでずれるものなのか!」という実感が持てたのは大きいな、と思います。
「自分たちのシステムを使う人はどういう人だろう?」と考えるときとか、何かの認識ずれでバグが発生してしまった時のふりかえりとかで「問い」が使えそうな気がしています。

形式手法ってなんだろう?

(べにさん)
speakerdeck.com
形式手法は数論理学に基づいた手法。

  • 仕様を厳密に書ける、明確に意味を一つに絞れる
  • プログラミング言語そのまま? いいえ、実装ではなく仕様を記述することが可能です

形式手法のいいところ

  • 仕様を厳密に書ける
  • 実装ではなく仕様を記述できる
  • 実装前に検証が可能
  • 何が複雑なのかを把握できる
感想

形式手法は、基礎知識がないと難しいと感じました。例を真似すれば書けはするのだけど、自分が何を書いてるのかわからなくて同じチームの方に解説してもらいました。チームメンバに助けてもらえるの良かったです。ただ、すみません、形式手法は私には早かった。。。あまり理解できてないので要復習です。。

ディナーセッション、夜の分科会

美味しいごはんを食べたり、飲む人はお酒をいただきながら夜23時までテストについて語り合う変わり者たちの宴です! 夜の分科会では、よしたけさんのテスト観点共有会のセッションに参加しました。電話番号に関する観点を出し合ったのですが、みんなで観点を出し合うと、自分にはない観点をもらえたり、相手の出した案に乗ってそれをより深められたりというのが面白かったです。
成果物はこちら。
f:id:yuki_shiro:20191217204142j:plain
テスト観点共有会の詳しいやり方は、よしたけさんのブログをどうぞ!
yoshitake-1201.hatenablog.com

おまけ

WACATEはご飯も美味しいですよ!
f:id:yuki_shiro:20191217204108j:plain
f:id:yuki_shiro:20191217204122j:plain
三浦半島の海の幸を堪能する意味でもぜひWACATEへ!