WARAI冬の陣2022_組織的テストプロセスとテスト計画を学ぶ

WARAI冬の陣 2022 ~組織的テストプロセスとテスト計画を学ぶ 2022.11.2６

What’s “WARAI” ? ◼ WARAI(ワライ)は、「関西ソフトウェアテスト勉強会」の略称で、 関西在住のメンバーが中心で実施しているソフトウェアテスト／QAの勉強会です。 これまで有志のメンバーにより10年以上の活動を継続してきており、 現在は、JaSST(ソフトウェアテストシンポジウム)関西の実行委員が中心で企画・運営しています。 ◼ 活動ペースは2022年より年2回、夏と冬に実施する予定です。 告知はconnpass、Twitterで約2か月前に告知・募集を行います。 ◼ WARAIは原則無償による活動です。 参加者に参加費／教材費など費用を求めることは基本的にありません。 但し、大規模でのイベントなど、運営メンバーの負担が非常に大きくなる際には、 参加者に無理させない範囲でご負担をお願いするケースもあるかもしれません。 その際はご協力頂けると幸いです。 ◼ WARAIでは企画・運営メンバーを募集しています。 経験・年齢等の条件はありません。興味ある方はぜひメンバーにお声がけ下さい。 2022 WARAI(関西ソフトウェアテスト勉強会) 2

諸注意 ◼ 発表者が公開NGとした資料や発言は、SNSなどで拡散しないようお願いいたします。 それ以外では、SNSによるつぶやき、感想の投稿はOKです。 勉強会で使用した資料については、基本的に後日公開いたします。 ◼ イベント内ではビジネスの勧誘にあたる行為は禁止しています。 また、参加者全員が楽しむイベントである主旨を理解した発言・行動をお願いします。 (誹謗中傷、マウンティング、一方的な発言、場を悪くする行動など) 主旨に反する言動を繰り返す参加者に対しては、強制退場・出禁といった処置を取ります。 ◼ 勉強会中は基本的に発言は自由です。 また質問やコメントはDiscordに記載してもOKです。 URLは『参加者への情報』欄を確認ください。 2022 WARAI(関西ソフトウェアテスト勉強会) 3

企画・運営メンバー morinaga まゆぼーん 2022 WARAI(関西ソフトウェアテスト勉強会) ※画像はイメージです HOLLY 4

今回の勉強会のきっかけ テストのキャリアをそれなりに重ねてきて、 ある時、とあるプロジェクトでテスト計画を作成することになった。 最初にしたことは何か。 ・・・それは、テスト計画のテンプレートを探すことだった。 テスト計画が、テスト計画を作る、という目的のタスクになっているように思えた。 キャリアを重ね、テスト計画をいくつも書いてきているのに、 本質が見えていないのではないか。 いわゆる、これは”思考停止”である。 本来のテスト計画とは何なのか、 勉強会を通じて考えてみようと思い立った。 ２０２２年某日 Copyright Association of Software Test Engineering All rights reserved. V3.1.1 5

Timetable 10:00～11:00 11:00～12:00 Sect.1 テスト計画を学ぶ Sect.2 組織的テストプロセスの理想と現実 12:00～13:00 休憩 13:00～14:00 14:00～15:00 15:30 Sect.3 アジャイル開発におけるテスト計画 Free ディスカッション&情報交換会 オンサイト会場撤収 ※Sectionの合間に小休憩を取ります。また、勉強会中の中座も常識の範囲でOKです。 2022 WARAI(関西ソフトウェアテスト勉強会) 6

Section.1 テスト計画を学ぶ 2022 WARAI(関西ソフトウェアテスト勉強会) 7

Agenda ➢ テスト計画の定義～『ASTERセミナー標準テキスト』より ➢ ソフトウェアテストの国際標準からテスト計画を学ぶ • プロセスの全体像 • 各プロセスの説明 ➢ まとめと考察 Copyright Association of Software Test Engineering All rights reserved. V3.1.1 8

テスト計画の定義 『ASTERセミナー標準テキスト』より テスト計画 • テストの使命を明らかにし、目的を定義する。 → テストの目的は、開発ゴールと直結していることが重要である。 • 使命、目的に合致するようテスト活動を構築する。 → 状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。 → 開発ゴールを満たすためのテストプロセスやそのルールを規程する。 （適切なテスト技法とタスクを指定し、適切なテストスケジュールを作成するなど。） • テスト計画書は、モニタリングとコントロールのフィードバックに応じて更新する。 出典： ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018.J03 複雑かつ大規模なものほど最初の計画が しっかりしていないとプロジェクトは破綻する！ これは複雑なソフトウェアやテストでも同じ。 Copyright Association of Software Test Engineering All rights reserved. V3.1.1 9

テスト計画の定義 『ASTERセミナー標準テキスト』より 使命・・・なぜ我々は”いる”のか、 目的・・・我々のミッションは何ぞや？ テスト計画 テストプロセス、ルールを決めないといけない • テストの使命を明らかにし、目的を定義する。 → テストの目的は、開発ゴールと直結していることが重要である。 状況・・・何が今後起こりえるだろうか？ 制約・・・テストがどうやりにくくなるだろうか？ • 使命、目的に合致するようテスト活動を構築する。 → 状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。 → 開発ゴールを満たすためのテストプロセスやそのルールを規程する。 （適切なテスト技法とタスクを指定し、適切なテストスケジュールを作成するなど。） • テスト計画書は、モニタリングとコントロールのフィードバックに応じて更新する。 更新・・・計画の見直しのタイミングはいつが良いか？ （書いて終わりではないんだな） • 計画とは、これからの道筋を作ること • 計画とは、道筋に至る疑問や障害を解決し明示していくこと ⇒ 結果、安心感と自信を持ってプロジェクトに臨める！ Copyright Association of Software Test Engineering All rights reserved. V3.1.1 10

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) ２９１１９においてテスト活動は、3つに分類される多層構造のテストプロセス(マルチレイヤーモデル)を提唱している。 組織的テストプロセス ➡ Sect.2 汎用的で、プロジェクトに依存しない テスト戦略・仕様・管理 テストマネジメントプロセス テスト戦略・計画プロセス テスト監視・制御プロセス テスト完了プロセス 動的テストプロセス テスト完了基準が達成されるまで、 設計と実行を反復的に行う 2022 WARAI(関西ソフトウェアテスト勉強会) 11

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) ２９１１９における『テスト戦略と計画プロセス』の全体像は以下の通り。 プロセス Test strategy and planning process TP9にてテスト計画が公開/利用可能となるが、ここで終了ではない。 公開/利用可能となることで、ドラフトな部分が精緻化されていく。 TP3～６は反復的に実行し、完全を目指していく。 概要 TP1 コンテキストの理解 TP2 テスト計画作成の準備 TP3 リスクの特定と分析 TP4 リスク低減のアプローチの特定 TP5 テスト戦略の設計 TP6 人員配置とスケジュールの決定 TP7 テスト計画の文書化 TP8 テスト計画の合意形成 TP9 テスト計画の通知及び利用の開始 2022 WARAI(関西ソフトウェアテスト勉強会) 12

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) テスト戦略及びテスト計画プロセス① プロセス 概要 TP1 コンテキストの理解 説明 • • • テスト計画の作成のため、コンテキスト(背景・状況)及びテスト要求を理解する テスト要求の理解は、ステークホルダの特定と対話によって得ること コミュニケーション計画を開始する ▲ 組織のテスト方針・テスト仕様をインプットする。 ※計画プロセスは初頭から対話で始まる テスト計画とは、計画書を埋めるプロセスではないことがわかる TP2 テスト計画作成の準備 • • • • テスト活動を特定し、スケジュール化する テスト活動に関わるステークホルダを特定する 活動内容、スケジュール、メンバーについて、ステークホルダの承認を得る ステークホルダの関与を組織的に行うよう取り決める ※PMにテスト戦略のレビューに参画してもらう、など 2022 WARAI(関西ソフトウェアテスト勉強会) 13

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) テスト戦略及びテスト計画プロセス② プロセス 概要 TP3 リスクの特定と 分析 説明 リスクアセスメントの実施 • ソフトウェアテストに関係するリスクを特定する • ソフトウェアテストに関係しないリスクは、ステークホルダに共有する • リスクは分類スキームを用いて、プロジェクトリスクとプロダクトリスクに区別する - プロジェクトリスク ・・・ テストが止まる要因、など - プロダクトリスク ・・・ バグの事象レベルで書いてしまうと影響度が小さくなる。 システム/サービスの不具合として書くことをお奨めする。 • リスクは影響度や可能性でレベル付けする • 上記のリスクアセスメントをステークホルダと合意する ▲ プロジェクトリスクレジスタ（既存リスク）から、関連するものを取り出す (組織的なリスクマネジメントが前提) TP4 リスク低減のア プローチの特定 リスクの種類、分類、リスクレベルに基づいて、リスクに対するアプローチを決定する。 • テストレベル ： 単体テスト、結合テスト、システムテストなど • テストタイプ ： 負荷テスト、ユーザビリティテストなど、品質特性の視点で捉える • テスト設計技法 • テストの完了基準 上記は、TP5：テスト戦略のインプットとなる 2022 WARAI(関西ソフトウェアテスト勉強会) 14

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) テスト戦略及びテスト計画プロセス③ プロセス 概要 TP5 テスト戦略の設計 説明 • • • • • • • TP6 人員配置とスケジュール の決定 • • • テスト基盤、リスク、組織、プロジェクト、製品の制約を考慮したテスト戦略を策 定しなければならない - 前プロセス：TP3～4で実施したリスクアセスメント結果がインプットになる テスト戦略を実施するために必要な活動を特定する テストのモニタリング及び管理に使用するメトリクスを策定する テストデータの要求事項を策定する テスト環境要件およびテストツール要件を特定すること テスト成果物を特定し、その形式度合いや伝達頻度を把握すること。 テスト戦略を実施するための必要なリソースの初期見積りを作成する テスト戦略を実行するために必要なメンバーの役割とスキルの特定 ※採用及び研修の必要性が考慮されていること テスト戦略におけるテスト活動は、見積もり、依存関係、メンバーの稼働率に基 づいてスケジューリングする 人員配置やスケジュールについてステークホルダの了解を得る 2022 WARAI(関西ソフトウェアテスト勉強会) 15

ソフトウェアテストの国際標準からテスト計画を学ぶ (ISO/IEC/IEEE 29119-2:2021) テスト戦略及びテスト計画プロセス④ プロセス 概要 TP7 テスト計画の 文書化 説明 テストの見積もりは、テスト戦略の設計（TP5）で設計されたテスト戦略と、 人員配置・スケジュールの決定（TP6）で合意した内容に基づいて算出する。 その値が、以前の初期見積もりと異なる場合は、TP5～6の活動を再検討する。 ▲ 比較対象のデータは、組織的テストプロセスの中で管理しているものを使用する (見積もりデータが管理されている前提) TP8 テスト計画の 合意形成 • • • • ステークホルダの意見を収集する ステークホルダの見解の矛盾を解決する ステークホルダからのフィードバックを考慮して更新する ステークホルダの承認を得る ▲ 過去のテスト計画に対するフィードバックを活用する (振り返りがなされている前提) TP9 テスト計画の通知 及び利用の開始 ステークホルダにテスト計画を通知し、公開する。 ※この時点ではドラフトな箇所があるため、以降TP３～６を反復的に実行する 2022 WARAI(関西ソフトウェアテスト勉強会) 16

まとめと考察 ◼ テスト計画について テスト計画は、段階的な策定プロセスの中で、様々なステークホルダと合意形成しながら進める。 公開/利用可能後は、リスクマネジメントを中心に、反復的に実行しながら、完全を目指していく。 テスト計画はテストチームのためだけにあるものではないし、 テンプレのテスト計画書を作りきって終わりというものでもない。  組織的テストプロセスとの関わり(考察) 計画の合意事項においては、過去の結果・データを参照する場面が多い。 組織的なテストプロセスによって得られるテストに関するデータを、 新たな計画に対して用いることで、テスト計画が誤った方向に行かないよう是正する。 to be continued "Section.2“… 2022 WARAI(関西ソフトウェアテスト勉強会) 17