開発知見共有のためのEnablersの会に参加してきたので、会で学んだことと感想を書いていきます。
会の概要
佐々木さんからテストベースの理解戦略について話を伺った後に、参加者(Zoomの参加者を見たら、名前を知っているテストエキスパートの方ばかりで驚きました...！)で議論をしていきました。
佐々木さんがお話した内容については、Connpassからの引用を以下にします。
開発担当者のチームから独立した組織横断の品質保証部門やテストベンダーでは知見のない状態でテストベースの理解を深める必要がある。主なテスト活動が受け入れテストやシステムテストのエキスパート達が知見が乏しい状況下で如何に理解を深めていくのか、その過程は明らかになっていない。開発担当者とは異なるマインドセットや豊富なテスト知識を持ったエキスパートがテストベースを理解していくアプローチを調査した内容をもとにテストベース理解戦略を紹介する。
なお、今回の話のベースとなっている話は、以下の論文を踏まえているとのことです。
オープニング～Enablersの会の目的～
主催者の森崎先生から、Enablersの会の目的や発足した背景について説明がありました。
「コミュニティに依存して欲しくない、コミュニティが拠り所になって欲しくない」というお話でした。
自分は以前の製造業アジャイルで、今回よりも熱い森崎先生から、「コミュニティに依存して欲しくない、コミュニティが拠り所になって欲しくない」という想いに至った背景を聴いていたのですが、その時から継続して、森崎先生の志や想いの強さに敬服しました。
会の学び
後日、森崎先生が会であった議論のメモを展開してくださるということだったので、詳細な記述は省き、自分が特に学びを得た内容を書いていこうと思います。
未知のテストベースに対してはまず用語定義する
テストエキスパートの方々が未知のテストに出会った時に取る戦略として、皆さん共通して用語理解(用語の正確な定義)から入るというお話がありました。
その後、理解した用語*1について技術要素やシステムと裏付けをして、テストベースの全体構成を掴んでいくということでした。
未知のシステムでなくても(ドメイン知識がある程度あるテストベースでも)大まかには同じプロセスを取っているという結果もあり、これもまた興味深かったです。
テストベースをプロダクトとして捉える
テストベースをプロダクトとして捉えて、テストベースを品質特性の観点で考えてみるという話がとても面白かったです。
具体的には、理解が難しいテストベースは品質特性で言うと使用性が低いのではないかというお話があり、適切度認識性や習得性という観点で理解が難しい理由を深堀していました。(確かに読んでいて使い方しか分からないテストベースよりも、どういうユーザーストーリーがあるのかの記載がある方が良いテストベースだと言えそうです)
自分自身も、現場で使っているテストベースをプロダクトとして捉えて、品質特性で言うとどの部分が弱いのかを考えてみようと思いました。
自分がどうやってテストベースのリスクを洗い出しているか？
テスト仕様書を書く時に気を付けているかの議論に参加したのですが、その時に森崎先生から「テストベースに潜むリスクが分かっている前提で話をしているけど、テストベースにあるリスクはどうやって探しているのか？」という意図の質問をいただき、自分がどうやってテストベースのリスクを洗い出しているか言語化することになりました。
言語化の過程で、まだ考えが浅い部分や論理的におかしい部分、ここ2ヶ月テストの勉強をしていく中で意識するようになった部分が整理されたので、学びになりました。言語化した結果、現時点ではどのような考えなのかは、以下に脚注として記載しておきます。(まだテストの勉強を本格的に始めてから日が浅いこともあり、皆さんがあんまり興味がないと思われるので)*2
テスト仕様書の読み方
テストエキスパートの方々から、テスト仕様書の読み方を伺えて、大変参考になりました。
上からテスト仕様書を読んでいくのではなく、重要な情報を抽出して論理的につなぎ合わせる、「どう動くか」ではなくて「どんなサービスを提供してくれるのか」に注目する、仕様書の論理構造を意識して読む、目線や視点を変えて読む、抽象度を整理して読む、ラルフチャート(あるいはラルフチャートの考え方)の活用...様々な意見を伺えました。
また、西先生からは最後に、仕様書の読み方を意図的に分けている話も伺えて、これも面白かったです。
全体を通した感想
佐々木さんの話は勿論ですが、他のテストエキスパートの方々からも沢山の話を聴くことができて満足しました。
参加者の面々を見て発言することを大分躊躇しましたが、思い切って議論に参加してみた結果、自身が何をテストで意識していて何を意識できていないのかが分かった&フィードバックがもらえて良かったです。
森崎先生の深堀の上手さもあって、現場で実際に使えるレベルまでブレイクダウンされたような内容の知識が多く、かなり実践的なイベントだなあと感じました。(エキスパートの方々がテストをする時の感覚が、森崎さんの質問によって言語化されていました)
和気あいあいと皆で話をするイベントではないものの、いい意味で緊張感があって、議論に参加する時を中心に、頭をかなり使う楽しいイベントでした。
コミュニティで普段学べないような内容を持ち帰って欲しい一方で、会社から現実逃避する場(コミュニティへの依存度が強くなるような場)にしたくないという森崎先生の意向が綺麗に反映されている、素晴らしい会だなと思いました。
*1:用語を理解したかにも基準を持っているということでした
*2:リスクを洗い出す時ですが、主に以下のアプローチをやっています(順番にやるのではなく、並行してやるイメージです)
① システム理解を深める
今日の佐々木さんの話と近いですが、用語定義とか、システムの使われ方、ユーザは何を求めているのか、システムがビジネス的にどういうインパクトを与えるか...を考えます。
② 品質特性の活用
データ量/故障が発生した時のインパクト/操作性...など、調べたり人に聞けば直ぐに分かる情報を抽象度高めでもいいので集めて、主に品質特性で言うとどこが弱いかを考えます。
③ 不具合分析
もしあればですが、過去にシステムで起きた不具合を分析して、傾向がないかを考えます。性能課題が多いのかとか、複数因子の組み合わせで発生する不具合が多いのか...
④ ステークホルダーを集めてヒアリング
開発者や(可能であれば)顧客を集めて、何を特に不安に思っているのか、という所を聴きます。例えばリリース日が伸びて市場で試すまでに時間がかかることが不安なのか, どのような故障が発生するのが不安なのか...ただ、どのステークホルダーも何らかのバイアスがかかっているので、そこは注意して聴くようにしています。
