【JSTQB FL 】3. 静的テスト

はじめに : JSTQB FLの学習内容・解釈・気づきを共有

JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)

今回の内容 : 第3章.静的テスト

目次

静的テストの基本

静的テストで検査可能な成果物
静的テストの利点
静的テストと動的テストの違い

レビュープロセス

作業成果物のレビュープロセス
形式的レビューの役割と責務
レビュータイプ
レビュー技法の適用
レビューの成功要因

静的テストの基本

静的テストで検査可能な成果物

静的テストの対象は、ソフトウェアのあらゆる作業成果物

• レビューの対象 : 人が読んで理解できる作業成果物
  • 要件、設計仕様書、テストウェア、プロジェクト計画、スケジュール、予算など
• 静的解析の対象 : 形式的な構造をもった作業成果物
  • コード、モデルなど

静的テストの利点

• 動的テストよりも早い段階で実施できるため、欠陥の早期発見につながる
  • 手戻りの削減につながり、開発コスト全体のコストを削減できる
  • 動的テストを実施せずに欠陥を検出することで、テストのコストと時間の削減できる
• 動的テストでは検出しづらい欠陥を検出できる
  • 設計、コーディング段階での欠陥の混入を防止できる
  • 設計作業の改善、コードの保守性の向上にも貢献できる
• レビューにより、関係者どうしのコミュニケーションの改善につながる

静的テストと動的テストの違い

静的テストと動的テストでは、検出できる欠陥の種類が異なる。互いに補完しあうことで効果的に欠陥の検出ができる。

静的テストと動的テストの相違点↓

• 静的テストの得意な検出
  • 要件の欠陥
  • 設計の欠陥
  • コードの欠陥
  • 標準からの逸脱
  • インターフェース仕様
  • 設計やテストのトレーサビリティ、カバレッジ
  • ソフトウェア再利用時の欠陥の混入
  • 保守性 (モジュール化されていること)

目次へ戻る

レビュープロセス

作業成果物のレビュープロセス

• 形式的なレビュー：レビュープロセスに従う/レビュー結果を文書で記録
• 非形式的なレビュー：レビュープロセスには従わない/レビュー結果を文書で記録しない

レビュープロセス

形式的レビューの役割と責務

レビュータイプ

効果的にレビューを行うために↓の状況に応じて、最適なレビュータイプの選択が必要。

• ニーズ(プロジェクトの人数や体制など)
• 利用可能なリソース(関係者のスキル)
• ビジネスドメイン
• 企業文化など

レビュータイプ

• 非形式的レビュー
  • 種類
    • バディチェック：同僚に確認してもらう
    • ペアリング：隣で確認してもらいながら作成
    • ペアレビュー：スキルのある2人が作業成果物の確認
    • ピアデスクチェック:作成者と同僚が一緒に作業成果物のウォークスルー
  • 目的：潜在的な欠陥を検出する
  • 形式的なプロセスに従わなくてOK
  • 手軽に実施できる
    • メールや短時間の会話レベルでもいい
    • レビューミーティングも任意開催
    • 結果の文書化も任意
    • チェックリストの使用も任意
• ウォークスルー(@レビューミーティング)
  • 目的：欠陥の発見、プロダクトの改善、異なる実装方法の検討、標準や仕様への準拠の評価
  • 作成者が作業成果物の説明を行い、都度参加者の質疑に答えていく
  • 作成者自身がファシリテータも兼ねる場合もある
  • 非形式的にやる場合もあれば、高度に形式的にやる場合もある
  • シナリオ、ドライラン、シミュレーションを形態としてとる場合がある
• テクニカルレビュー
  • 目的：合意の獲得　欠陥の検出
  • レビュー対象のエキスパートが参加し、作業成果物の懸念事項を確認。代替え案の提示や検討を行うのが特徴
  • レビューアはエキスパートだったり別の専門家
• インスペクション
  • 最も厳格に形式に従うレビュー
    • 標準レビュープロセスの遵守、レビュー結果の文書化が確実に行う必要あり
    • レビューミーティング前に個々のレビューを済ませておく必要あり
    • 個々のレビューで事前に懸念事項の発見を完了させておく
    • レビューミーティングでは、懸念事項の共有と検討(ステータスやオーナーの割り当て)に注力
    • 作成者は、どの役割も担わない
  • レビューの関係者の訓練が必要
  • 正しい運用により、動的テストよりも前に欠陥を発見できる
  • レビューの効果の測定や結果からプロセス改善につなげる

レビュー技法の適用

レビュー技法は、レビュー対象の作業成果物から懸念事項を発見するための有効なテクニック
各レビュー技法は、レビュープロセスの「個々のレビュー」で適用でき、全てのレビュータイプに適用できる

• アドホック
  • レビューの進め方：特になし
  • 作業成果物を順番に読んで、懸念事項の識別と記録を行う
  • レビューアのスキルに大きく依存
• チェックリストベース
  • レビューの進め方：チェックリストに基づいてレビュー
  • 典型的な懸念事項を体系的にカバーできる
  • チェックリストは、定期的にメンテナンスが必要
    • リストの拡充、整理、過去の事例の掲載
    • チェックリストは完璧とは限らないので、発想を広げて確認する必要がる
• シナリオとドライラン
  • レビューのガイドライン：レビューのガイドライン(読み方)に基づいてレビュー
  • ユースケースのレビューに効果的
    • 作業成果物の期待する使い方に沿って、ドライランを行う。
      • 実際にシステムを動かすイメージでレビュー対象を見る
    • 全体の整合性や要求に対する妥当性の欠如を検出しやすい
• ロールベース
  • レビューの進め方：個々のステークホルダーの役割の観点から作業成果物をレビュー (なりきり)
  • レビューアごとに異なる観点からレビューをすることで、検出する懸念事項の重複が少なくなる
• パースペクティブ
  • レビューの進め方：ステークホルダーの観点で、作業成果物をもとに、その役割における作業成果物を作成しながらレビュー
  • ロールベースのレビュー技法の一種
    • テスト担当者の観点の例
      • 要件仕様書をレビューするときに、テスト条件やテストケースの作成をする中で、懸念事項がないかを確認する
      • この仕様書では、テストケースが作れないのでは？というときに、それを懸念事項としてフィードバッグする

レビューの成功要因

適切なレビュタイプの選択、適切なレビュー技法の適用に加えて↓が必要

• 組織的な要因
  • 計画時に、計測可能な目的を定義
  • チェックリストを最新状態に保つ
  • 欠陥に関するフィードバッグを早期・頻繁に行うために、ドキュメントは小さく分割
  • 参加者に十分な準備期間を与える（レビューミーティング中に議論するため）
  • レビューのスケジュールを適切に通知
  • マネージャーはレビュープロセスを支援する
• 個々の要因
  • レビュー目的に対して、適切な知識・レベルの保有者を関与させる
  • テスト担当者は、早期にテスト設計を開始する（テスト期間の短縮）
  • 参加者に適切な時間を割り当て、詳細にレビューしてもらう
  • 集中力を維持できるようにレビュー対象は小さく分割して実施
  • 見つかった欠陥は客観的な態度で確認、識別、対処する
  • レビューは信頼できる雰囲気で行う（レビュー結果を評価に使わない。）
  • 参加者は他の参加者に対して退屈感、憤り、敵意だと受け取られないように気を付ける
  • レビューに関するトレーニングの実施（特にインスペクションなど）
  • 学習とプロセス改善の文化を醸成する

目次へ戻る

以上　第3章.静的テスト

参考になれば幸いです。