こちらの記事ではJSTQBのシラバスのうち、第3章静的テスト分野における以下の分野の学習内容及び学習してみて私が思ったことについて記載します。
【JSTQB(FL)対策】第3章静的テスト
1. 静的テストの基本
静的テストはテスト対象となるソフトウェアで実際にプログラムを実行して実行する動的テストと違い、プログラムを実行せずにレビューや静的解析で実行する。
1-1. 静的テストで検査可能な作業成果物
レビューは設計仕様書、ソフトウェア、予算などといった人が読んで理解できるような作業成果物をほかの人と一緒に見てもらい、おかしな点がないかを検証する。
静的解析はコードやモデルなどといった形式的な構造を持った様々な作業成果物をコード実行せずに品質やセキュリティの検証する。
1-2. 静的テストの利点
ソフトウェア開発ライフサイクルの初期段階に適用すると、自動テストを実行する前に欠陥を早期検出でき、ライフサイクルの終盤に検出した欠陥よりもはるかに安価に除去することが可能である。
その他に開発やテストにかかるコストや時間を削減できたり、動的テストでは容易に識別できない欠陥の識別、さらにはレビューによりチームメンバー間のコミュニケーションの改善ができたりするなどの利点もある。
1-3. 静的テストと動的テストの違い
静的テストは作業成果物の整合性と内部品質の向上、動的テストは外部のふるまいにそれぞれ焦点を置くといった違いがある。
両者はそれぞれ異なる種類の欠陥を検出するため、相互に補完しあう関係であるが、静的テストは動的テストで検出が難しい欠陥をはるかに少ない工程で検出できる。
また要件、設計、コードの欠陥などを早期安価に検出して修正が可能である。
2. レビュープロセス
2-1. 作業成果物のレビュープロセス
1.計画
2.レビューの開始
3.個々のレビュー
4.懸念事項の共有と分析
5.修正と報告
1.計画
・レビューの範囲を定義する。・工数および時間を見積もる。
・レビュー参加者を選出し、役割の割り当てを実施する。
・レビュー特性を識別する。
・開始と終了の基準を定義する。
・開始基準が満たされていることのチェックを行う。
2.レビューの開始
・作業成果物またはチェックリストや問題記録フォームなどといったほかの資料を配布する。・レビューにおける範囲、目的、プロセス、役割、作業成果物を参加者に説明をする。
・参加者からの質問に応答する。
3.個々のレビュー
・作業成果物のすべてもしくは一部をレビューする。・潜在的な欠陥、提案、質問の書き出しを行う。
・レビュー方法は後程記載のレビュー技法の適用にて詳細に記す。
4.懸念事項の共有と分析
・潜在的な欠陥についてレビューミーティングなどで議論する。・潜在的な欠陥を分析し、それらにオーナーやステータスの割り当てを行う。
・品質特性を評価し、文書化する。
・欠陥を終了基準に対して評価し、レビュー判定を行う。
5.修正と報告
・欠陥レポートを作成する。・作業成果物で発見された欠陥を修正する。
・適切な人もしくはチームと欠陥について議論する。
・欠陥ステータスの更新を行う。
・メトリクスを収集する。
・終了基準が満たされているかをチェックする。
・終了基準到達時に作業成果物を受け入れる。
2-2. 形式レビューでの役割と責務
形式的レビューに含まれる役割は以下のとおりである。
1.作成者
2.マネージャー
3.ファシリテーター
4.レビューリーダー
5.レビューア
6.書記
1.作成者
・レビュー対象の作業成果物を作成し、必要に応じて欠陥を修正する。
2.マネージャー
・レビューの計画を責任もって行う。
・レビューの実行を決定する。
・担当者、予算、時間の割り当てを行う。
・費用対効果のモニタリングを継続的に行う。
・不適切な結果が発生した状況に対し、コントロールを行う。
3.ファシリテーター(モデレーター)
・レビュー成功を左右する重要な役割を果たし、効果的なレビューミーティングを運営する。
・必要に応じて意見の調整を行う。
4.レビューリーダー
・レビューに対して全体的な責任を持ち、参加者の人選やレビューを実施する期間と場所を決定する。
5.レビューア
・特定分野の専門家やプロジェクトの従事者などが行う。
・レビュー対象の作業成果物の欠陥を識別する。
・専門分野ごとにそれぞれ異なる観点(テスト担当者やユーザー、オペレーターなど)でレビューを行う。
6.書記(記録係)
・個々のレビュー活動期間に発見された欠陥を照合する。
・レビューミーティングで発見された欠陥や未決事項、決定事項を記録する。
2-3. レビュータイプ
レビューには以下のようにもっとも一般的な4つのタイプがある。
1.非形式的レビュー
2.ウォークスルー
3.テクニカルレビュー
4.インスペクション
1.非形式的レビュー
・主な目的は潜在的な欠陥の検出
・形式的なプロセスに基づかない作成者の同僚やその他の人により実施が可能なため、容易にできる
・バディチェック、ペアリング、ペアレビューなどがある
2.ウォークスルー
・主な目的は欠陥の発見やソフトウェアプロダクトの改善、異なる実装方法の検討、標準や仕様への準拠の評価である。
・作業成果物の作成者がレビューミーティングを主導し、レビュー対象物を説明し、関係者が質問やコメントをする形式である。
・秘書は必須である。
3.テクニカルレビュー
・主な目的は合意の獲得や潜在的な欠陥の検出である。
・専門家がファシリテーターとなり、作業成果物の懸念事項を確認していく。
・理想は経験を積んだファシリテーターが主導することである。
・秘書は必須である。
4.インスペクション
・主な目的は欠陥の検出、作業成果物の品質の評価と信頼の積み上げ、作成者の学習と根本的分析による将来の類似欠陥の防止である。
・進行役のモデレーターがコーディネートを行い、参加者の役割を明確にして、ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成する。
・メトリクスを収集し、ソフトウェア開発プロセス全体の改善に使用される。
2-4. レビュー技法の適用
レビュー技法には以下のような様々なタイプがある。
1.アドホック
2.チェックリストベース
3.シナリオとドライラン
4.パースペクティブベース
5.ロールベース
1.アドホック
・レビューアに順番に作業成果物を読んでもらい、懸念事項などを指摘してもらう技法である。
・レビューアのスキルに依存し、複数のレビューアから重複した懸念事項が多数指摘されることがある。
2.チェックリストベース
・レビューアがレビュー開始時に配布されたチェックリストを使用して懸念事項を検出する技法である。
・典型的な懸念事項の種類を体系的にカバーできるという利点がある。
3.シナリオとドライラン
・レビューアはシナリオベースドレビューを使用して、作業成果物に対してドライランを実施する。
4.パースペクティブベース
・レビューアがそれぞれの異なるステークホルダーの役割の観点から作業成果物を評価する技法で、最も効果的であることが判明している。
5.ロールベース
・レビューアが個々のステークホルダーの役割の観点から作業成果物を評価する。
2-5. レビューの成功要因
レビューを成功させるには適切な種類のレビュー及び手法の適用が必要であるがこれ以外にも様々な要因がある。
組織的な要因と人的な要因に分けて以下の通りに上げる。
→組織的な要因
→レビュー計画時に計測可能な終了基準として使用できる明確な目的を計画する。
→達成する目的およびソフトウェア成果物と参加者の種類とレベルにふさわしいレビュータイプを選択する。
→作業成果物の欠陥を効果的に識別するために適切なレビュー方法を一つ以上使用する。
→チェックリストは最新の状態に保てるようにする。
→大きなドキュメントは小さく分割して記述およびレビューする。
→参加者に十分な準備期間を与える。
→レビュースケジュールは適切に通知する。
・人的要因
→適切な参加者を選出する。
→参加者には適切な時間を割り当て、細心の注意を払って作用際にレビューしてもらう。
→欠陥はきゃかん的な態度で確認、識別、対処する。
→ミーティングは参加者にとって有意義な時間となるように適切にマネジメントする。
→レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。
→参加者は自分の言動がほかの参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける
→学習とプロセス改善の文化を醸成する。
3. エピローグ
第3章静的テストを学習してみて、私はテストレビューに対する知識が一段階身についた気がしました。
私は今までの案件でテストレビューを実施した経験がなかったため、今回の学習でどのようなことを考えてどのような手段でレビューを実施すればよいかを学ぶことができたと思います。