JaSST Online Fennel 参加レポート
はじめに
今回のFennelのテーマは「テスト設計の暗黙知」です。
テスト設計の実践的な技術は、同じ組織内であっても言語化が難しく、暗黙的になりがちです。例えば、業務で他者が設計したテスト成果物を見ることはあっても、その成果物ができるまでの「過程」を見ることは多くないのではないでしょうか。
本会では、テスト設計の有識者が実際にテスト分析・テスト設計を行っている様子を録画したものを参加者全員で観ながらご本人に解説して頂きます。
気になったポイントがあれば深堀りを行い、そのとき何を考えていたのか、どうしてその手法を選択したのかなどを明らかにしていきます。成果物を見るだけでは感じられない、言語化されにくいところを持ち帰っていただけることを期待しています。
今回のテーマ「テスト設計の暗黙知」の通り、「暗黙知の把握」→「暗黙知を言語化」→「再現（再利用）可能にする」という思いをもって、本会に参加しました。
本記事は、おーだんさんが解説や質問に答えてくださっていた内容を元に、筆者が理解／解釈したものを言語化し、書き記しております。
そのため、「おーだんさんの講演内容そのものを紹介する記事ではないこと」「筆者の個人的な理解／解釈が多分に含まれていること」をご承知おきいただければと思います。
PFD
テスト分析
成果物
機能一覧：プロダクトの機能をざっくり理解する
QA表：記載されていないことや不明なことを明確にする
画面・状態遷移図：画面/状態の流れを確認する
起きたら困るプロダクトリスク一覧：どんな不具合が致命的か考える
テストすべき仕様一覧：どこをテストすべきか考える
テストベース分析
考えるべきこと
プロダクトに対して確認すべきこと
機能、非機能、UI/UXデザイン、ユーザー操作、過去流出バグ
機能に対して確認すべきこと
入力、処理、出力、例外
曖昧な仕様、不完全な仕様の抽出（要件レビュー）
機能一覧
機能の全体構成を書き出し、階層構造を整理する
まずは全体像をざっくり把握してから、画面や機能単位の詳細を確認していく
テストベースは何度も繰り返し確認し、理解度を向上させていく
テストスコープの記載、テスト詳細度の記載などを追加し、テスト計画書の概形に再利用する
QA表
記載内容について
曖昧な仕様、不完全な仕様に対する質問事項
テストスコープに対して合意したい事項
非機能など合否判定基準について確認したい事項
（円滑なやり取りができるように）必要に応じて質問の意図も記載
画面・状態遷移図
テスト分析時のモデリングについて
「モデリング＝自分が世界をどう見ているか」
自分の得意なモデリング手法で分析すればいい
どこまでモデリングするか（深さ、広さ）は目的やリスク次第
書き出しすぎると大量になりがちなので注意
必要になった時に必要な分だけ分析すればい
プロダクトリスク一覧／テストすべき仕様一覧
プロダクトリスクの抽出について
主に経験則によるもの（過去のやらかしなどから学ぶ）
欠陥データベースなどあればそこから抽出するのがよい
ドメイン単位でナレッジ化とし、共有できるといい（と思う）
エンドユーザー視点に立って、「こんなプロダクトは嫌だ」という考えで抽出するのもよさそう
テストすべきことの抽出について
機能として確認すべきこと（要求／仕様の確認）
リスクを軽減するために確認すべきこと
ネガティブテスト
テスト設計
成果物
優先度付き起きたら困るプロダクトリスク一覧：テストの順番を決める
優先度付きテストすべき仕様一覧：テストの順番を決める
テストタイプ：どんなテストを用意すべきかざっくり確認する
テスト実行アーキテクチャ
テスト計画書の概形：どんなテストをすべきかをざっくり決めたもの
テストアーキテクチャ設計
テストでやりたいことをどうやったら実現できるか、実現できないリスクを考える
【優先度付き】プロダクトリスク一覧／テストすべき仕様一覧
優先度付の基準
高：基本機能が動作しない（影響度が高い）
低：万が一発生しても受け入れ可能なもの（影響度が低い）
中：高、低ではないもの
優先度ベースでステークホルダーとテストスコープの調整をしたりする
テストタイプ
テストをどういうかたまりで実施するかを定義したもの
テストスイートをさらに大きなカテゴリで分類したようなイメージ
ソフトウェア品質特定などで考えるのもよいが難易度が高そうなので、独自に定義したほうが簡単で使いやすそう
テストタイプにプロダクトリスクを割り付ける
テストタイプでカバーできていないリスクはないか
カバーすべきリスクの数を元に概算工数を算出する
テスト実行アーキテクチャ（スケジュール）
テストタイプ単位でのリスクの高／低を元に、順番を検討する
欠陥の修正期間等も考慮して検討する
テスト実行時におけるリスク（ボトルネックなど）も抽出する
テスト計画書の概形
テスト分析、テスト設計時の成果物を整形して、テスト計画書としてまとめる
まとめ
プロダクト仕様からより一歩先の自分に目線を向けてみる
（≒テストをしていて失敗しそうなことはないか）
感想
他の方のテスト成果物を見たり、レビューをすることはあると思いますが、テスト設計の過程そのものに着目したことはなかったので、とても貴重な体験ができました。
テスト成果物を作成する際の思考を解説いただくことで、「何を目的に」「何を考え」「何をアウトプット（成果物）」しているのかを深く理解することができました。
また、Discordでの質問もたくさん拾っていただき、疑問を解消できたのもよかったです。
今回気づいたこと、学んだことをこれからの業務に活かしつつ、テスト設計の過程をそのまま見せるというコーチングも試してみようと思いました。
この記事が気に入ったらサポートをしてみませんか？