JSTQBFL3章 まとめ

ぬJSTQB FL3章を読みました。
シラバスの文章が長いので引用して大事だと思うところ、テス友で出題された部分を太字にしてまとめてみます。

🐰JSTQBFL1章 まとめ
🐱JSTQBFL2章 まとめ
🦊JSTQBFL3章 まとめ
🐶JSTQBFL4章 まとめ
🐧JSTQBFL5章 まとめ
🐷JSTQBFL6章 まとめ

■シラバス内容抽出/解釈

✔ 静的テストの基本

静的テスト技法では、
・作業成果物を人手で調査（すなわち、レビュー）
・コードや他の作業成果物をツール主導で評価（すなわち、静的解析）
したりする。

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

ほとんどの作業成果物は静的テスト（レビュー、静的解析、または両方）を使用して調査できる。例は以下。

• 仕様（ビジネス要件、機能要件、セキュリティ要件など）

• エピック、ユーザーストーリー、受け入れ基準

• アーキテクチャーおよび設計仕様

• コード

• テストウェア（テスト計画書、テストケース、テスト手順、自動化テストスクリプトなど） 

• ユーザーガイド 

• Web ページ 

• 契約、プロジェクト計画、スケジュール、予算計画

• 構成のセットアップとインフラストラクチャーのセットアップ

• モデルベースドテストで使用するアクティビティ図などのモデル

レビューは、読んで理解できるあらゆる作業成果物に適用できる。

✔ 静的テストの利点

• 静的テストは、ソフトウェア開発ライフサイクルの初期に適用すると動的テストを実行する前に欠陥を早期に検出できる（例えば、要件/設計仕様レビュー、バック ログを洗練させる作業など）。

• 早期に検出した欠陥は、本番稼動後のようなライフサイクルの終盤に検 出した欠陥よりも、はるかに安価に除去できる。

• 欠陥の検出と修正をより効率的に、しかも動的テストを実行する前に行うことができる。

• 動的テストでは容易に検出できない欠陥を識別できる。

• 要件の不整合、曖昧性、矛盾、欠落、不正確性、冗長性を明らかにして、設計時またはコーディング時に欠陥が混入するのを防止できる。

• 開発の生産性を向上できる（設計の改善、保守性の高いコードなど） 。

• 開発にかかるコストと時間を削減できる。

• テストにかかるコストと時間を削減できる。

• ライフサイクルの終盤または本番リリース後に検出される欠陥数が減少し、ソフトウェアの存続期間にわたる全体的な品質コストを削減できる。

• レビューへの参加過程でチームメンバー間のコミュニケーションを改善できる。

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

【静的テストの主な特徴】
ソフトウェア実行時に欠陥により引き起こされた故障を識別するのではなく、作業成果物の欠陥を直接検出すること

欠陥は、故障を引き起こすことなくきわめて長期間にわたって作業成果物に潜んでいることがある。この欠陥が潜んでいるパスはほとんど実行される ことがないか、到達することが難しいので、このような欠陥を偶然検出できる動的テストを構築および 実行することは容易ではない。
静的テストでは、はるかに少ない工数で検出できる。

静的テストは動的テストに比べて、以下の欠陥を早期かつ安価に検出して修正できる。

• 要件の欠陥
  ex) 不整合、曖昧性、矛盾、欠落、不正確性、冗長性

• 設計の欠陥
  ex) 非効率なアルゴリズムやデータベース構造、高い結合度、低い凝集度）

• コードの欠陥
  ex) 値が定義されていない変数、宣言されているが使用されることのない変 数、到達不能コード、重複したコード

• 標準からの逸脱
  ex) コーディング標準を遵守していない

• 正しくないインターフェース仕様
  ex) 呼び出し側のシステムと呼び出される側のシステム で異なる単位の使用）

• セキュリティの脆弱性
  ex) バッファオーバーフローが発生する可能性

• テストベースのトレーサビリティもしくはカバレッジが不十分もしくは不正確
  ex) 受け入れ基準に対するテストケースが欠落している

※保守性欠陥のほとんどは、静的テストでのみ検出できる
ex) 不適切なモジュール化、低いコンポーネント再利用性、分析が困難で新しい欠陥の混入なしに修正することが困難なコード

✔ レビュープロセス

レビューには、非形式的なものから、形式的なものまでさまざまな種類がある。

• 非形式的レビュー：
  定義したプロセスに従わず、レビュー結果を形式的に文書化しないことが特徴である。

• 形式的レビュー：
  チームで参加し、レビューの結果とレビューを行う際の手順を文書化することが特徴である。

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

レビュープロセスは、以下の主要活動で構成する。

■ 計画

• レビューの範囲を定義する。
  ※これには、レビューの目的、レビュー対象のドキュメント（またはその部分）、評価すべき品質特性を含む。

• 工数と時間を見積る。

• レビュー特性を識別する。
  ※これには、レビュータイプ、役割、活動、チェックリストなどを含 む。

• レビューの参加者を選び、役割を割り当てる。

• 開始基準と終了基準を定義する（インスペクションなど、形式的なレビュータイプほど必要とな る）。

• 開始基準が満たされていることをチェックする（形式的なレビュータイプほど必要となる）。

■ レビューの開始

• 作業成果物もしくは他の資料（例えば、問題記録フォーム、チェックリスト、関連する作業成果物）を配布する。

• レビューの範囲、目的、プロセス、役割、作業成果物を参加者に説明する。

• レビューについての参加者からの質問に答える。

■ 個々のレビュー（すなわち、個々の準備）

• 作業成果物のすべてまたは一部をレビューする。 

• 潜在的な欠陥、提案、質問を書き出す。

■ 懸念事項の共有と分析

• 識別した潜在的な欠陥について、レビューミーティングなどで議論する。

• 潜在的な欠陥を分析し、それらにオーナーとステータスを割り当てる

• 品質特性を評価し、文書化する。

• レビューで見つけた欠陥を終了基準に対して評価し、レビュー判定（却下、大規模な変更が必要、受け入れ可能、小規模な変更が必要など）を行う。

■ 修正と報告

• レビューで見つけた欠陥で作業成果物に変更が必要なものについて欠陥レポートを作成する。

• レビュー対象の作業成果物で見つかった欠陥を修正する（典型的には作成者が修正する）。

• 適切な人またはチームと、欠陥について議論する（レビュー対象の作業成果物に関連する作業成 果物で見つかった場合）。 

• 欠陥のステータスを更新する（形式的なレビューの場合）。コメント作成者の合意を含むこともある。

• メトリクスを収集する（形式的なレビュータイプほど必要となる）。

• 終了基準が満たされていることをチェックする（形式的なレビュータイプほど必要となる）。

• 終了基準に到達したときに作業成果物を受け入れる。

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

■ 作成者

• レビュー対象の作業成果物を作成する。

• レビュー対象の作業成果物の欠陥を修正する（必要な場合）。

■ マネージャー

• 責任を持ってレビューの計画を行う。

•  レビューの実行を決定する。

• 担当者、予算、時間を割り当てる。

• 費用対効果を継続的にモニタリングする。

• 不適切な結果が発生した状況に対してコントロールをする。

■ ファシリテーター（モデレーターと一般的に呼ばれる）

• 効果的なレビューミーティングを運営する（開催時）。

• さまざまな意見の調整を行う（必要な場合）。

• レビューの成功を左右する重要な役割を果たす。

■ レビューリーダー

• レビューに関して全体的な責任を持つ。 

• 参加者を人選し、レビューを実施する期間と場所を決定する。

■ レビューア

• 特定分野の専門家、プロジェクトの従事者、作業成果物に関心のあるステークホルダー、そして /または特定の技術や業務のバックグラウンドを持つ個人などが行う。

• レビュー対象の作業成果物の欠陥を識別する。

• それぞれに異なる観点（例えば、テスト担当者、開発者、ユーザー、オペレーター、ビジネスア ナリスト、使用性の専門家など）でレビューを行う。

■ 書記（記録係）

• 個々のレビュー活動の期間に見つかった潜在的な欠陥を照合する。 

• （開催時に）レビューミーティングで見つかった新しい潜在的な欠陥、未決事項、決定事項を記録する。
  

ファシリテーター（モデレーター）とレビューリーダーの違いは ❔

ズバリ！『責任を持つか、持たないか』
リーダーは、規定に反する意見などについては責任を持って正す必要があり、決定された事柄についても、その決定に責任を持たなければいけない。

ファシリテーターは、会議の結果に責任を持つことはない。結論は会議の参加者が出すものであり、ファシリテーターはあくまでも中立的な立場から、参加者の意見を引き出してまとめていく役割のみを担う。

※レビュータイプによっては、1人で複数の役割を担当することがある。

それぞれの役割とお仕事↓

✔ レビュータイプ

レビューはさまざまな用途で使用するが、主となる目的の 1つは欠陥を検出することである。

■ 非形式的レビュー（例えば、バディチェック、ペアリング、ペアレビュー）

主な目的：
潜在的な欠陥の検出。
その他の目的：
新しいアイデアや解決策の創出、影響度の小さい問題の迅速な解決。

【特徴】

• 形式的な（文書化した）プロセスに基づかない。

• レビューミーティングを行わないことがある。

• 作成者の同僚（バディチェック）やその他の人により実施。

• 結果を文書化することもある。

• レビューアにより、効果はさまざまである。

• チェックリストの使用は任意である。

• アジャイル開発では一般的に行われる。

■ ウォークスルー

主な目的：
欠陥の発見、ソフトウェアプロダクトの改善、異なる実装方法の検討、標準や仕様への準拠の評価。
その他の目的：
さまざまな技法やスタイルに関するアイデアの交換、参加者のトレーニング、合意の形成。

【特徴】

• レビューミーティング前の個々のレビューアによる準備は任意である。

• 典型的には作業成果物の作成者がレビューミーティングを主導する。

• 書記は必須である。

• チェックリストの使用は任意である。

• シナリオ、ドライラン、シミュレーションの形態を取る場合がある。

• 潜在的な欠陥のログ、およびレビューレポートを作成する。

• 運営により、きわめて非形式的のものから、高度に形式的なものまである。

■ テクニカルレビュー

主な目的：
合意の獲得、潜在的な欠陥の検出。
その他の目的：
作業成果物の品質の評価と信頼の積み上げ、新しいアイデアの創出、作成者のモ チベーション向上と将来の作業成果物の改善、異なる実装方法の検討。

【特徴】

• レビューアは、作成者の技術領域の同僚、および技術分野が同じ、または別の専門家である。

• レビューミーティング前に個々のレビューアが準備する。

• レビューミーティングの開催は任意である。

• 開催する場合、経験を積んだファシリテーター（作成者ではない）が主導するのが理想である。

• 書記は必須である（作成者でないのが理想）。

• チェックリストの使用は状況による。

• 潜在的な欠陥の記録やレビューレポートを作成する。

■ インスペクション

主な目的：
潜在的な欠陥の検出、作業成果物の品質の評価と信頼の積み上げ、作成者の学習と根本原因分析による将来の類似欠陥の防止。
その他の目的：
作成者のモチベーション向上と、将来の作業成果物およびソフトウェア開発プロ セスの改善、合意の形成。

【特徴】

• ルールやチェックリストに基づいたプロセスで進行し、形式に沿ったドキュメントを作成する。

• 役割が明確に決まっている。

• レビューミーティングで作業成果物を読みあげる人を専任で加えたりすることもある。

• レビューミーティング前に個々のレビューアが準備する。

• レビューアは作成者の同僚か、作業成果物に関連する別の分野の専門家である。

• 開始基準と終了基準が指定されている。

• 書記は必須である。

• レビューミーティングは、経験を積んだ進行役（作成者ではなく）が主導する。

• 作成者は、レビューリーダー、ドキュメントを読みあげる担当、書記のどの役割も担わない。

• 潜在的な欠陥の記録やレビューレポートを作成する。

• メトリクスを収集し、ソフトウェア開発プロセス全体（インスペクションプロセスを含む）の改善に使用する。

公式レビューのアクティビティ↓

✔ レビュー技法の適用

個々のレビュー（個々の準備）活動で欠陥を見つけるために適用できるさまざまなレビュー技法があ る。

■ アドホック

• レビューアは、このレビューに関するタスクのガイダンスをほとんどまたはまったく提供されない。

• レビューアは作業成果物を順番に読んで懸念事項を識別するごとに記録に残す。

• 準備を必要としない場合によく行う。

• レビューアのスキルに大きく依存し、複数のレビューアから重複した懸念事項が多く報告されてしまう場合がある。

■ チェックリストベース

• チェックリストベースドレビュー技法は体系的に行われ、レビューアはレビューの開始時に（例えばフ ァシリテーターにより）配布されるチェックリストを使用して懸念事項を検出する。

• レビューチェック リストは、経験から導出した起こりえる欠陥に基づく一連の質問を列挙したものである。

• レビュー対象の作業成果物ごとにチェックリストを用意し、以前のレビューで見逃された懸念事項の種類をカバーするために定期的にメンテナンスすべきである。

• 主な利点は、典型的な懸念事項の種類を体系的にカバーできることである。

• レビューを行う際には、チェックリストに単純に従うだけでなく、チェックリスト外の欠陥も検出する努力をすることが重要である。

■ シナリオとドライラン

• 作業成果物を読むための構造化されたガイドラインをレビューアに提供する。

• レビューアはシナリオベースドレビューを使用して、作業成果物の期待する使い方に基づいて、作業成果物に対して「ドライラン」を行う。

📝ドライラン
予行演習、空運転、リハーサルなどの意味を持つ
本番に備えて同じ内容を実際に行ってみることを指す

• 単純なチェックリスト項目よりも、特定の種類の欠陥を検出するためのよいガイドラインとなる。

• 他の種類の欠陥（例えば、機能の欠落）を見逃さないようにするためには、チェックリストベースドレビュー技法と同様に文書化されたシナリオだけにとらわれないようにしなければならない。

■ パースペクティブベース

• ロールベースのレビュー技法と同じく、レビューアはそれぞれに異なるステークホルダーの観点でレビュー活動を行う。

• 典型的なステークホルダーの観点とし ては、エンドユーザー、マーケティング担当者、設計者、テスト担当者、運用担当者などがある。

• レビューアごとに異なる観点を持つことで、より深く掘り下げたレビューが可能になり、検出される問題の レビューア間における重複が少なくなる。

• レビュー対象の作業成果物から各レビューアの役割で導出する成果物を作成してみる必要がある。
  ex) 要件仕様についてパースペクティブベース ドリーディングを行っているテスト担当者は、暫定的な受け入れテストを作成して必要な情報がすべて 含まれていることを確認する。さらに、チェックリストも使用することが前提である。

• 現場の調査から、要件や技術的な作業成果物のレビューの場合、パースペクティブベースドリーディングが最も効果的な技法であることが判明している。

• レビュー成功のためには、想定されるリスクに応じ て、さまざまなステークホルダーの観点を適切に含めることである。

■ ロールベース

• レビューアは個々のステークホルダーの役割の観点から作業成果物を評価する。

• 典型的な役割には、特定のエンドユーザーの種類（熟練者、初心者、年配者、子供など） や組織内の特定の役割（ユーザーアドミニストレーター、システムアドミニストレーター、性能テスト担当者など）がある。
  

違いが分かりにくかったので…超要約するとこんな感じでしょうか…↓

✔ レビューの成功要因

レビューを成功させるための組織的な要因を次に示す。

• レビュー計画時に、計測可能な終了基準として使用できる明確な目的を定義する。

• 達成する目的、およびソフトウェア成果物と参加者の種類とレベルに応じてレビュータイプを選択する。

• レビュー対象の作業成果物で欠陥を効果的に識別するために適切なレビュー技法（チェックリストベース技法やロールベース技法など）を1つ以上使用する。

• チェックリストは、主要なリスクに言及できるよう最新の状態に保つ。

• 欠陥に関するフィードバックを早期および頻繁に作成者に提供して品質をコントロールするため に、大きなドキュメントは小さく分割して記述およびレビューする。

• 参加者に十分な準備時間を与える。

• レビューのスケジュールは適切に通知する。

• マネージャーがレビュープロセスを支援する（例えば、プロジェクトスケジュールでレビューに十分な時間が割り当てられるようにする）。

• レビューは、社内の品質、および/またはテストのポリシーに統合する。

レビューを成功させるための人的な要因を次に示す。

• レビューの目的に対して適切な人たちに関与させる（例えば、さまざまスキルセットまたはパー スペクティブを持ち、対象のドキュメントを使うことがある人たち）。

• テスト担当者は、レビューに貢献するだけでなく、レビュー対象の作業成果物の内容を把握して、有効なテストを早期に準備できると、レビューアとして価値がでる。

• 参加者には適切な時間を割り当て、細心の注意を払って詳細にレビューしてもらう。

• レビューアが個人でのレビュー時、および/またはレビューミーティング時に集中力を維持できるよう、レビューは対象を小さく分割して実施する。

• 見つかった欠陥は客観的な態度で確認、識別、対処をする。

• ミーティングは参加者にとって有意義な時間となるよう適切にマネジメントする。

• レビューは信頼できる雰囲気で行い、レビュー結果を参加者の評価に使用しない。

• 参加者は、自分の言動が他の参加者に対する退屈感、憤り、敵意だと受け取られないように気を付ける。

• 特にインスペクションなど高度に形式的なレビュータイプには、十分なトレーニングを提供する。

• 学習とプロセス改善の文化を醸成する。