JSTQB FLのまとめ 第一章 テストの基礎①

1.テストの基礎

この章でのキーワード

キーワード	意味
カバレッジ	テストスイートを使用して特定のカバレッジアイテムを判定または実行した度合い。パーセンテージで表す
デバッグ	ソフトウェアの故障の原因を見付けて、分析して、取り除くプロセス
欠陥	作業成果物に存在する、要件または使用を満たさない不備または欠点
エラー	間違った結果を生み出す人間の行為
故障	コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと
品質	コンポーネントまたはシステムが、さまざまな利害関係者の明示的および暗黙的なニーズを満たす度合い
品質保証	品質要件が満たされるという確信を提供することに焦点を当てた活動
根本原因	欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される
テスト分析	テストベースを分析してテスト条件を識別する活動
テストベース	テスト分析と設計のベースとして使用するあらゆる情報
テストケース	実行事前条件、入力値、アクション（適用可能な場合）、期待結果、および実行事後条件のセットであり、テスト条件に基づいて開発されたもの
テスト完了	テストウェアを後続のテストで使用できるようにし、テスト環境を十分に満足できる状態にし、テスト結果を関連するステークホルダーに伝える活動
テスト条件	テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分
テストコントロール	テストプロジェクトが計画から逸脱した場合に、軌道修正するための対策を考えて適用する活動
テストデータ	テスト実行に必要となるデータ
テスト設計	テスト条件から、テストケースを導出し明確化する活動
テスト実行	コンポーネントまたはシステム上でテストを実行し、実際の結果を提示する活動
テスト実行スケジュール	テストサイクル内でテストスイートを実行するためのスケジュール
テスト実装	テスト分析と設計に基づいてテスト実行に必要なテストウェアを準備する活動
テストモニタリング	テスト活動のステータスのチェック、計画済み、または予測されるステータスからの逸脱の識別、関係者へのステータスの報告を行う活動
テスト対象	テストすべき作業成果物
テスト目的	テストをする理由や目的
テストオラクル	テスト対象のシステムの実行結果と比較する期待結果のソース
テスト計画	テスト計画書を策定し、更新すること
テスト手順	複数のテストケースの実行順序。最初の事前条件や実行後の終了活動をセットアップするために必要な関連するアクションも含む
テストスイート	特定のテストランで実行されるテストスクリプト、またはテスト手順のセット
テスト	全てのライフサイクルを通じて静的および動的に実施するプロセス。成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、コンポーネントやシステムおよび関連作業成果物に対し、計画、準備、評価をすること
テストウェア	テストプロセスで生成される中間成果物。テストの計画、設計、実行、評価、報告を行うために使用する
トレーサビリティ	2つもしくは複数の成果物間に関係を確立できる度合い
妥当性確認	検査、および、特定の使用法や適用に対する要件が満たされていることを客観的な証拠で確認すること
検証	客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注：JIS Q 9000:2006より引用

1.1 テストとは何か？

・本番で使われる前に、期待通りの動作をするかを確認する行為
　↪︎動作しない場合＝故障→その故障が発生しなくなるまで見届けることで、本番環境で故障が発生する可能性を低くすることが出来る

テストをしないと……

• 経済的な損失
• 時間の浪費
• 信頼の失堕
• 傷害や死亡事故になることもある

【テストのプロセス】

• テスト実行前作業

  • テスト計画
  • テスト分析
  • テスト設計
  • テスト実装

• テスト実行時の作業

  • 実行結果のチェック
  • テスト終了基準の評価
  • テスト完了作業
  • テスト結果報告
  • テストウェアの整理

• 全体を通して行われる作業

  • モニタリングとコントロール

【実行するテストと実行しないテスト】

　テスト＝ソフトウェアを実行して結果を確認することだけではない
　実行するテストもあるが、実行しないテストもある

• 実行するテスト
  • 動的テスト
    • テスト対象のコンポーネントやシステムを実行する
• 実行しないテスト
  • 静的テスト
    • それらを実行しない→作業成果物のレビュー等が当てはまる 　

【テストは検証だけではない】

　ソフトウェアを実行した時に、期待結果と確認結果が一致しているためだけに行うわけではない
　妥当性確認も行う
妥当性確認では、ユーザーやその他のステークホルダーのニーズを運営環境でシステムが満たしていることを確認する

1.1.1 テストに共通する目的

【目的】

• 作業成果物の評価

  • 作業成果物をレビューする中で、正しく書かれていること以内についても確認する
  • 目的にする場合は、観点をあらかじめ洗い出し、評価対象の作業成果物が出来たダ段階で確認をする

• 検証

  • テスト対象となる作業成果物、コンポーネントやシステムが要件を満たしているか検証する必要がある
    • 最も共通的なテストの目的でもある

• 妥当性確認

  • 受け入れテストは、ユーザーやステークホルダーが期待していると思われる動作内容を確認する
    • ユーザー視点での確認等が該当？
  • 欠陥の検出を目的にしないで、ソフトウェアの品質確認を行うこともある
  • 所定の時期にリリースすればどんなリスクがあるのかをステークホルダーに提出するため

• テスト対象が所定のレベルにあることの確証

  • 明確化したすべての要件を満たしていることの検証
  • 故障や欠陥の発見
  • 妥当性確認

　上記を検証した結果は、開発担当者/PM/ユーザーに伝えることが可能な情報になる
　だが、テスト結果や欠陥修正の結果をメトリクスを使って確認する必要あり

• 欠陥の作り込みの防止

  • 改善活動の一環としてテストを使うことにある
  • 過去のテストで検出された故障と修正済の欠陥の原因分析を行う→その後の開発時に評価観点に分析結果を取り込むことで、同じ欠陥を作りこむことを防止する活動など

• 故障や欠陥の発見

  • 開発でのテストのメインの目的
  • なるべく多くの故障を発見して、ソフトウェアの欠陥を特定して修正する

• ステークホルダーが意思決定できる、特にテスト対象の品質レベルについての十分な情報の提供

  • テストの最も重要な目的でもある
  • テストを行った結果、品質が所定のレベルであることを確証できない部分についても適切に評価することも含まれる

• (以前に検出されなかった故障が運用環境で発生するなどの)不適切なソフトウェア品質のリスクレベルの低減

  • ここで必要となるのがリグレッションテストである

• 契約上/法律上/規制上の要件や標準を遵守する、そして(または)テスト対象がそのような要件や標準に準拠していることの検証

  • ソフトウェアシステムが使われる業界ごとに、業界独自の要件や標準がある
  • それらの要件や標準に従ったテストを行う必要があり、それを検証する

1.1.2 テストとデバッグ

【テストとデバッグの違い】

• テスト

  • ソフトウェアに存在する欠陥に起因する故障を発見すること
  • テスト担当者が責任を持つ

• デバッグ

  • 故障の基となる欠陥を見付けて、欠陥の原因を解析し、修正する、一連の開発活動
  • 開発担当者が責任を持つ

※但し、ソフトウェア開発ライフサイクルによって、役割が変わることもあるので注意

1.2 テストの必要性

1.2.1 成功に対するテストの貢献

テストを行うことで、コンポーネントやシステムの本番稼働時/市場で利用する際に問題が起きるリスクを軽減できる

それを怠ると…

• リリース後に致命的な故障が見つかり、全品回収になる可能性
• システムの性能の著しい低さが原因で、ユーザーや顧客の作業/業務への支障の可能性

品質向上の貢献、契約や法律上の要件/各業界の標準に合致していることが必要となる
そのためにも、ソフトウェア開発ライフサイクルの適切な時点で適切なテスト技法を適用したテストを行うことが重要になってくる

• 要求分析

  • テスト担当者が行う
  • ユーザー欲求やユーザーストーリーのレビュー
    • このタイミングで欠陥を取り除くことによって、正しくない機能や、どのようにテストすればいいのかわからない機能を開発してしまうリスクの低減につながる

• システム設計

  • テスト担当者とシステム設計担当者が連携する必要がある
  • 設計内容のレビュー
    • 設計の欠陥が混入するリスクの低減につながる
  • 設計内容に対してどうテストするかを理解することによって、早い段階でテストケースの設計が可能

• コード開発/コンポーネントテスト

  • テスト担当者と開発担当者が連携する必要がある
  • コードとそのテストケースのレビュー
    • コードに欠陥が混入するリスクの低減
    • コードのテストケースに欠陥が混入するリスクの低減
  • コンポーネントテストはコードを開発した開発担当者自身がテストを行うことが一般的

• 統合テスト/システムテスト/受け入れテスト

  • テスト担当者が行う
  • リリース前に行う
  • テストしなければ見逃してしまうかもしれない故障の検出につながる
  • 欠陥レポートの作成によって、デバックを行う開発担当者の作業の支援につながる

1.2.2 品質保証とテスト

【品質の分類】

• 当たり前品質

  • 機能そのものが意図した通りに動くこと

• 魅力的品質

  • その製品を使いたくなるような特徴
    • ユーザーにとって魅力的なユーザーインターフェースなど

但し、相反することもある

品質保証（QA）とテストは品質マネジメントの構成要素である
つまり、品質保証≠テスト

• 品質保証＝プロセスを守らせる活動
• テスト＝品質を向上させる活動

【品質保証】
品質が適切なレベルに到達するようプロセスを遵守させる活動
※テスト活動を含む開発プロセス全体が適切に進められるよう活動する

適切なプロセスとは…

• 開発ライフサイクルをお構成する活動とその実施順序
• 計測活動の手順
• 問題報告・是正の手順

プロセスを適切に遂行すると、これらのプロセスで作成される作業成果物は一般的に高い品質を持つ

【品質コントロール】

品質を適切なレベルに達成させる活動
※テスト活動は品質コントロールに含まれる

【品質マネジメント】

品質に関して組織の方針を示し、組織をコントロールする活動
※品質保証と品質コントロールは品質マネジメントの一部

テストは品質コントロール活動の一部
なおかつ品質保証のためのデータ提供を行うことで品質マネジメントに貢献する

1.2.3 エラー、欠陥、故障

言葉の定義は現場によって異なることもある
ここではISTQB(JSTQB)での定義を取り上げる

【エラー】

間違った結果を生み出す人間の行為

エラーが発生する理由
・納期のプレッシャー
・人間の誤りを犯しやすい性質
・プロジェクト参加者の経験/技術不足
・プロジェクト参加者間の誤ったコミュニケーション
・コード/設計/アーキテクチャー/解決すべき根本的な問題/使用する技術の複雑さ
・システム内/システム間のインターフェースに関する誤解
・新しく不慣れな技術

【欠陥】

作業成果物に存在する、要件or仕様を満たさない不備or欠点
→エラーによって作業成果物やプログラムに血管を埋め込んで実装してしまうと言ったイメージ

※バグ・欠陥・フォールとは同義であるとしている

【故障】

コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと

但し、欠陥に依存しない故障(設定ミスや実行環境の問題など)や、期待通りではないテストの結果がすべて故障であるとは限らない場合(欠陥の含まれたプログラムが実行されない/されたとしてもユーザーに影響がないなど)もある
また、すべての欠陥が故障となるわけではない

【エラー/欠陥/故障のイメージ】

• エラー：仕様書に書かれていた「年齢20歳以上」を「年齢20歳以下」と勘違いする
• 欠陥：プログラムで「入力＞＝20」と記載すべきところに「入力＜＝20」と記述
• 故障：「年齢」に「21」と入力するとしようと異なる結果が出力される

1.2.4 欠陥/根本原因/影響

【根本原因】

欠陥を埋め込んだ最初の行為or条件のこと
欠陥を分析して根本原因を識別し、類似の欠陥が今後発生しないようにしなければならない

【根本原因の影響】

影響も根本原因の結果である