D.Horiyama's output

JSTQB ch1 テストの基礎 (1/2)

JSTQBテスト技術者

出典: 

1.1 テストとは何か？

背景

ソフトウェアが期待通りに動かないと生じる4つの不都合

  • 経済的な損失
  • 時間の浪費
  • 信用の失墜
  • 傷害や死亡事故

テストとは

よくある誤解

ソフトウェアを実行し結果を確認するだけ
  • 一部ではあるが全部ではない
要件、ユーザストーリー、その他仕様にソフトウェアが準拠していることの検証がすべて

  • 要件等そのものの妥当性確認も行う

    • 例: 金額計算で小数円はどうすんの？

  • 動かしてみないと妥当かがわからない場合は、作ったものに対して妥当性確認を行うこともある

    • 例: GUIのルック&フィールとか

ソフトウェアテストを構成するプロセス

  • テスト実行前作業

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

  • テスト実行時の作業

    • 実行結果チェック
    • テスト終了基準の評価

  • テスト完了作業

    • テスト結果の報告
    • テストウェアの整理

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

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

1.1.1 テストの共通する目的

  • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価

    • 正しいことが書かれていること、以外にも…
    • 誤解を招きやすくないか
    • 同じことがあちこちに重複して書かれていないか
    • 一貫性を欠いており読みづらくないか

  • 明確にしたすべての要件を満たしていることを検証

    • コンポーネントやシステムが要件を満たすこと。一番馴染みのあるやつ
    • 欠陥の早期特定・修正のために多くの故障を見つけること
    • コードカバレッジを増やすこと

  • テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認 (受け入れテスト)

    • 指定期日にシステムをリリースすることのリスクについてステークホルダーに情報を提示する目的で行うこともある

  • テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証

    • テスト結果や欠陥修正の結果をメトリクスを使って確認
    • 【所感】不具合曲線とかかな
    • 開発担当者、PM、ユーザー等に伝えることのできる情報となる

  • 欠陥の作り込みの防止

    • 検出した故障と修正した欠陥の原因分析を行う
    • 「要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価」にフィードバックすることで、類似の欠陥を繰り返し作り込むことを防止する
    • 【補】後述の「品質保証」におけるプロセス改善にテスト結果を役立てる的な話

  • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減

    • 開発サイドでのテスト(コンポーネントテスト、統合テスト、システムテスト)の主目的

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

    • リスクの回避、転嫁、軽減、需要といった意志決定のため、品質が所定のレベルであることを確証できない部分についても適切に評価する

  • 不適切なソフトウェア品質のリスクレベルの低減

    • デグレのこと
    • リグレッションテスト

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

    • 例えば国際規格ISO26262に準拠していること、など
    • 【所感】Web界隈だとCookieの扱いとかかな

1.1.2 テストとデバッグ

ソフトウェアテストの概念・語彙に関する情報は ISO/IEC/IEEE 29119-1 に記載されているらしい

  • テスト

    • 故障を見つけるもの
    • テスト担当者の責任

  • デバッグ

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

開発プロセスによっては、テスト担当者がコンポーネントテスト(開発担当者守備範囲)のテスト設計をレビューしたり、デバッグのためにソースコードを調べたりすることも

1.2 テストの必要性

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

各工程においてテスト担当者が密に連携することで問題を含むリリースの頻度を低減できうる

要求分析

  • 正しくないフィーチャーが開発されるリスク低減
  • テストできないフィーチャーが開発されるリスク低減

システム設計

  • どうテストするか握れる
  • 基本的な設計の欠陥が混入するリスク低減
  • テストケースを早い段階で識別できる

コード開発、コンポーネントテスト

  • どうテストするか握れる
  • コードとテストケースに欠陥が混入するリスク低減

統合テスト、システムテスト、受け入れテスト

  • 故障を検出し、欠陥レポート作成

    • 環境
    • データ
    • 再現手順
  • 開発担当者のデバッグ(欠陥除去)を支援する
  • 結果、ソフトウェアがステークホルダーのニーズに合致し要件が満たされる可能性が高まる

1.2.2 品質保証とテスト

品質保証(QA: Quality Assurance)とテストとは異なる概念

品質とは

  • 当たり前品質

    • 「使わなきゃよかった」にならない

  • 魅力的品質

    • 「使ってよかった」になる

  • 当たり前品質/魅力的品質はトレードオフ

    • リリース間際に「魅力的品質」向上目的で有用な機能をブチ込むと？
    • それまで行ってきたテスト結果の信頼性は低下し、「当たり前品質」は低下する可能性がある

品質に関する活動

  • 品質マネジメント

    • 品質に関して組織の方式を示し組織をコントロールするためのすべての活動
    • 品質保証、品質コントロール等を包含する

  • 品質保証

    • 適切なプロセスの遵守・プロセス改善により成果物の品質を高める
    • テスト結果をプロセス改善に活用できるが、テストそのものは品質保証ではない

  • 品質コントロール

    • テスト活動は品質コントロールの一環

1.2.3 エラー、欠陥、および故障

エラー(error)

欠陥のもととなる人間の誤り

  • SWEBOKの定義と異なるので注意

発生要因

  • 納期のプレッシャー
  • 人間の誤りを犯しやすい性質
  • 経験不足・技術不足
  • コミュニケーションエラー
  • コード・設計・アーキテクチャ・問題領域・選定技術の複雑性
  • I/Fに関する誤解
  • 新しく不慣れな技術

故障からなぜなぜを掘っていって行き着く最初のものを根本原因(root cause)という

欠陥(defect, fault, bug)

  • 要件または仕様を満たさない不備または欠点

  • 故障のもととなりうる

    • ならないこともある

故障(failure)

  • 実行すべきこと(あるいはしてはならないこと)が期待通りではなく、コンポーネントやシステムの問題でもたらされた不正な結果
  • 欠陥により生じることがある(生じずにすむこともある)

  • エラーにより混入した欠陥以外に、環境因子により生じることもある

    • 放射線、磁場、電場、汚染等によるファームウェア誤動作
    • ハードウェア構成変更
  • 「テスト結果が期待通りでないこと」(不正: anomaly)で検出するが、検出能は100%でないことに注意する

  • 偽陽性(誤検出)

    • テスト実施者のエラー・テストの欠陥等により故障と判定されたが、デバッグしたところ欠陥ではなかったもの

  • 偽陰性(検出もれ)

    • 検出すべき欠陥を検出しない

1.2.4 欠陥、根本原因、および影響

JSTQBシラバスより引用 (2021-01-13現在)

例えば、1 行のコードの間違いが間違った利子の支払いを引き起こし、顧客の不満を招いたとする。
欠陥のあるコードは、プロダクトオーナーが利子の計算方法を誤解しており、ユーザーストーリーが曖昧となったために埋め込まれた。
多くの割合の欠陥が利子の計算に存在し、これらの欠陥の根本原因が類似の誤解により発生していた場合、
プロダクトオーナーが利子計算に関する知識を習得することで、そのような欠陥を埋め込まないようにできる。

  • 影響: 顧客の不満
  • 故障: 間違った利子の支払い
  • コードの欠陥: コードでの不適切な計算
  • 要件の欠陥: ユーザーストーリーの曖昧さ
  • 根本原因となったエラー: ユーザーストーリーを作成したプロダクトオーナーの知識不足

下のものが上のものの原因となっている

1.3 テストの7原則

1.3.1 ソフトウェアテストの原則

  1. テストは欠陥があることは示せるが、欠陥がないことは示せない

    • 【所感】悪魔の証明

  2. 全数テストは不可能

    • 全組み合わせは無理
    • 【所感】なのでxUnit Test PatternではOne Bad Attributeなどが提示されている

  3. 早期テストで時間とコストを節約 (シフトレフト)

    • 傷が浅いうちに
    • 担当者の記憶が新しいうちに

  4. 欠陥の偏在

    • 特定の少数モジュールに集中する

  5. 殺虫剤のパラドックスにご用心

    • 新しい不具合を見つけられなくなる

  6. テストは状況次第

    • ソフトウェアの種類によって内容は異なる (産業機械とECサイトなど)
    • ソフトウェア開発ライフサイクルによって実行方法は異なる

  7. 「バグゼロ」の落とし穴

    • 「可能なテストすべてを実行し、潜在的な欠陥すべてを検出する」ことは前述の原則1,2より不可能
    • 仮にできたとしても、ユーザのニーズや期待を満たす・競合に勝るソフトウェアができるとは限らない