上記のイベントに参加してきたので、会の様子と感想を書いていこうと思います。
最近参加するコミュニティに偏りが出てきていた(別に悪いことではないと思っています)のですが、久々に初めて参加するコミュニティということで楽しみにしていました！
イベントの概要
テスト設計のチュートリアルということで、
イベントで使用した資料
http://aster.or.jp/business/contest/doc/2021_tescon_V1.0.0.pdf
イベントであった学び
学びが多数あって、自分にとって非常に有意義な内容だったのですが、印象的だったものを幾つか抜粋していこうと思います。
エンジニア的テスト要求とマネジメント的テスト要求
テスト要求には、エンジニアリング的テスト要求*1とマネジメント的テスト要求*22種類の要求があるというお話でした。(マネジメント的テスト要求は品質リスクとして管理する)
自分は現場だと、エンジニアリング的テスト要求に強く主眼を置いてテストケースの設計を行っていたので、マネジメント的テスト要求も意識して今後はテスト設計を行いたいと思いました。
テスト観点の羅列ではリファインが難しい
テスト観点は羅列されていると妥当性や十分性が(特に第三者にとって)担保しにくいので、マインドマップ等でテスト要求を図示したり、テスト観点を考えた過程を残しておくことで、リファインしやすいようなテスト観点を作るという話がありました。
リファインしやすいようにテスト観点を作るという発想は自分は現場で全然持てておらず、今回の解説で悪い例とされていたような、表形式で観点を羅列したようなテスト観点を作ってしまうことが多かったので、参考になりました。
テストの意図を明確にする時の観点例
テストの意図というと、「バグを見つけたい」くらいしか正直思いつかなかったのですが、「網羅したい」「エビデンスを残したい」「テスト対象の学習をしたい」「要求や仕様の詳細化をしたい」...多数の意図があり得ることを知りました。
案件ごとに、どういう意図でテストをしていくのかチームで話し合い、意識を揃えながらテストについて議論していくことができると、テストに対するイメージがチームで統一できるうえに、テスト活動の重要性が自然と浸透しそうなので、今度テスト設計をしていく時に是非話し合ってみようと思いました。
テスト設計を考える上での多数の切り口
テスト設計を考える上での切り口として、今まで知らなかった多数の切り口を知ることができました。*3
テスト設計実施時のコンテキストに合わせて、今回知った切り口の中で活用できるものはどんどん現場で活用していこうと思います！
Q＆A
テスト要求モデルの子要素としてテスト観点モデルが位置づけられるイメージで合っているか？
子要素と言う言葉でもニュアンス的には合っている。町田さんのイメージ的には、テスト要求モデルを考える中で、テスト観点モデルも自然とやる(包含関係になっている)イメージ。
テスト設計のフレームワークでテスト設計コンテストに合っているもの/合っていないものがあれば知りたい
テスト設計コンテストで高い点を取りたいという目的であれば、審査基準に沿いやすいという点から、今回説明したフレームワークを使うと良い。
現場で使うという意味だと、JSTQBのやり方でも今回のやり方でもいいので、自身や現場と親和性が高いものを選ぶべきだと思う。
テスト要求分析とテスト分析の関係をもう少し詳しく知りたいのだが、テスト要求分析にテスト分析は含まれると理解してよいか？
それほど大きな違いはないが、一番の違いとしてはあくまでもテスト要求に対する分析であるという風に定義を明確にした印象を町田さんは持っている。
全体を通した感想
自分の現場ではQAチームがいないため、テスト設計についてプロの人から話を受ける今回のイベントは非常に貴重な機会で楽しかったです。
丁寧に解説がなされている資料に加え、町田さんの分かりやすい解説(各スライドごとに簡単にポイントをまとめてくださっていました)&ゆっくりとした聞きやすい声に助けられ、テスト設計に対して誤った考え方を是正することができて良かったです。
スライドに書いてある内容の解説は勿論ですが、現実解として現場ではどのように適用していくことになるのか、という話が随所で織り交ぜられていた点が、学びが多かったです。
今日聞くことができた解説を踏まえて、改めてスライドの方も読み返してみようと思います。
