「ソフトウェアテスト教科書 JSTQB Foundation」をざっとまとめた

ソフトウェアテスト教科書JSTQB Foundation第3版

10年前くらいに資格は取ったけど、ほぼほぼ内容を忘れていた
所属する組織のテストの品質向上の取り組みの一貫として、この本の内容を要約して共有した

個人的には第一章に書いてあることが重要と思っている。
なんとなくわかっていた当たり前のことが文章でまとまっていることをチームメンバーで認識を合わせたかった
だいぶ端折っているので、メンバーには本を読んでほしいということで

全部をまとめるのは大変なので重要と判断したものを抜粋

テストの不足...テストの工数の不足、テストの対象の不足、テストの技術力の不足

第1章 テストの必要性

テストの基礎

• ソフトウェアが期待通り動かないことによる不都合
  • 経済的損失
  • 時間の浪費
  • 信用の失墜
  • 傷害や死亡事故
• ソフトウェアの欠陥に関連する用語4つ
  • エラー(誤り)...間違った結果を生み出す人間の行為
    • 人間の勘違い、思い込みなどがソースコード、ソフトウェア、ドキュメントの欠陥となる
  • フォールト(fault)...要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの不備
  • 故障(failure)...あるプログラムを実行した際に、実行すべきこと(あるいは実行してはならないこと)が正しく実行できず、故障がおきること。期待した機能、サービス、結果を提供できないこと
  • インシデント...ソフトウェアシステムを実際に使うユーザやテスト担当者が期待する動きと、実際の動きが一致しない事象のこと
    • 環境要因だったり、テスト担当者の勘違いということもあるので、「インシデント」≠「故障」
    • 日本では「不具合」、「障害」をインシデントと呼ぶことがあるので注意
• ソフトウェアの開発、保守、運用におけるテストの役割
  • ソフトウェアが期待どおりに動かない事による不都合(経済的損失、時間の浪費、信用の失墜、傷害や死亡事故)へつながる確率を下げためにテストをする
  • 使い勝手、非機能要件にかかる課題をテストで発見し、製品の魅力を高める
• ソフトウェアの品質
  • ソフトウェアの品質は「顧客満足度」につながる
  • 顧客が喜ばなければ品質が高いとは言えない
    • 当たり前品質...意図した通りに機能する
    • 魅力的品質...製品を使いたくなるような特徴
  • 品質の確保...リリースする前に結果を減らし、品質を確保する
  • 品質の計測...要件ごとのテストカバレッジ、故障発生件数などから品質の計測をしたり
  • プロセス改善のための情報提供...他の(過去の)プロジェクトで見つかった欠陥の根本原因を品質保証活動に活かす
• テストの十分性(どこまでテストをすべきか)
  • 以下をもとにテストの終了基準を決める
    • 技術面、安全面、ビジネス面からみたプロダクトリスクの度合い(カバレッジ、故障率)
    • プロジェクトリスク(テストを含む開発全体の進捗状況など)
    • 開発期間や納期
  • 利害関係者への情報提供
    • 次の開発ステップや次のリリース戦略を決められるように

テストとはなにか

ソフトウェアを実行して動きを確認することだけが「テスト」ではない。

• テスト実行前作業
  • 計画(いつまでにどのような作業を実施するのか)
  • テスト条件の選択(何をテストするのか)
  • テストケースの設計
• テスト実行時の作業
  • 実行結果の確認、テスト終了基準の検証、テスト結果の報告
• テスト実行後
  • テストウェアの整理...自動化など。資産化する。次回以降のテストに活かす
• テストの目的
  • 4つの目的
    • 欠陥の検出
    • 対象ソフトウェアの品質レベルが十分であることの確認
    • 意思決定のための情報の開示
    • 欠陥の作り込みの防止
  • 静的テストと動的テストは方法は違えど目的は同じ
  • 製品がリリースされるまでのテスト
    • 開発でのテスト(コンポーネントテスト、統合テスト、システムテスト)...なるべく多くの故障を発見してソフトウェアの欠陥を特定して修正する
    • 受け入れテスト...システムが期待通りに動作し、要件に合致することの確認を行なう。ステークホルダに提供するために行われることも
    • 保守テスト...ソフトウェアの変更時(機能追加、不具合対応)に、新たな欠陥が潜んでいないか確認する
    • 運用テスト
• デバッグとテストは別の意味です
  • 欠陥から発生する故障を発見することが「テスト」
  • 故障の原因を突き止め、解析し、取り除く一連の開発の活動が「デバッグ」
    • デバッガなどのツールを利用して修正するのがデバッグ

テストの7原則

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

• 1. テストは「欠陥がある」ことしか示せない
  • 「故障しない＝欠陥がない」ことは示すことができない
• 2. 全数テストは不可能
  • 「全数テスト(ソフトウェアに入力する可能性のある、全てパターンをテストすること)」
  • 有限の時間でテストするのは難しい。そのため、テストする場所を絞ったり、優先順位を決める
• 3. 初期テストの大事さ
  • 欠陥を見つけるのが、欠陥を作り込んでしまった時期から離れてしまうほど、修正のコストが指数関数的に大きくなる
    • コーディングしたときのことを忘れる
    • 再テストの範囲が増える
• 4. 欠陥の偏在
  • ソフトウェアの品質は均質なものではなく、欠陥が見つかるのはある部分に集中していることがよくある
    • ソフトウェアがいろいろな要素から構成されているから(UIとか、データ変換とか、データを格納するデータベースとか)
• 5. 殺虫剤のパラドックス
  • 害虫を退治するのに、同じ殺虫剤がだんだん効かなくなってくるのと同じく、新しい成分(欠陥を見つけるため新しいテスト)を加えないと効果がない
• 6. テストは条件次第
  • 全てのソフトウェアに共通するテストは存在しない
    • eコマースだったらセキュリティや正確性を重点的に「どんな入力があっても間違った結果を表示しない」「元のデータを壊さない」「情報が他へ漏れない」等
    • パソコンで動作する汎用ソフトウェアなら「どんな使い方をしてもマニュアル通りに動くか」「インストールが正しく行えるか」等
• 7. 「バグゼロ」の落とし穴
  • バグゼロを目標に、インシデントの内容を踏まえ改修を行なったら、また別のインシデントが発生したり
    • 入力値に4桁の数値しか入らない → 5桁も100桁も入るようにした → 動作が遅くなって使い物にならない
    • 機能、性能、システム全体への影響を確認してインシデントへの対処を

基本的なテストプロセス

効率的で合理的なテストを実施するためにはテスト計画が欠かせません

• 計画とコントロール
• 分析と設計
• 実装と実行
• 終了基準の評価とレポート
• 終了作業

テスト計画作業とコントロール

• テストの目的を明確にする。どんなテストを「なんのために」行なうか
  • テスト
• テスト計画
  • スコープとリスクを特定し、テストの目的を定義する
    • テストの対象範囲(機能、サービス、サブシステム...)
    • テストの目的(欠陥の検出なのか、外部システムとの疎通確認なのか)
    • テストの終了基準
      • インシデントは全て解決済か
      • テストの実施率、合格率
  • リソースの割当
  • テストの分析と設計の活動をスケジューリングする
    • 材料は要件定義、設計書他各種成果物
  • テストの実装と実行、テスト結果の評価にかかる活動をスケジューリングする
• テストのコントロール
  • テストの結果の計測と分析
    • 各ケースのテスト結果の合否判定だけでなく、パフォーマンス測定やリソース利用率の評価も
  • 進捗、テストカバレッジ、終了基準のモニタリングと文書化
    • テストの進捗状況の確認頻度は開発規模や、納期によって異なる
    • 終了基準を満たす方向でテストが進んでいるか見極め、コントロール
  • 欠陥修正の開始
    • 順次報告されていくインシデント
      • 修正をいつ反映するか
      • インシデントがなくなった確認をいつやるか
  • 意思決定
    • テストの進捗状況をみつつ、テストの中断、再開、終了を判断する
    • ときにはユーザにも入ってもらう
• テストの分析と設計
  • テストの分析と設計は、テストの実装とは別のアクティビティ
    • 分析は、テスト対象の情報を収集して理解する
    • 設計は、どのようなテストをどのような手順で実施すべきか検討する
  • テスト分析と設計の7つのタスク
    • テスト設計の入力となるテストベースをレビューする
      • テストベース...要件、RFPなどのユーザ起点のものから、要件定義や設計書、I/Fドキュメント、はたまた会議の議事録やメモ書きも含む
    • テストベースやテスト対象のテスト容易性を評価する
      • ユーザビリティ評価で「見えやすい」「聞こえやすい」「使いやすい」等の基準がテスト担当の主観にならないよう、基準を具体的にする
    • テストアイテム、仕様、動作、ソフトウェアの構造の分析に基づいてテスト条件を識別し優先順位を付ける
      • ちょっとよくわからなかった...
    • 高度なテストケースを設計し、優先順位を付ける
      • 高度なテストケース...いきなりテスト手順や期待結果などの詳細なところから検討するのではなく、テスト条件/テスト要件を網羅するように作っていく
        • 抜け漏れも減りそう
      • 利用する側の視点「ユーザ指向」、欠陥を見つけるための「フォールト指向」、要件の妥当性を見る「要件指向」、設計通りにテスト対象が動作するかを見る「設計指向」等、どの視点を優先してテストするか決める ← ！ここ重要！
    • テスト条件やテストケースをサポートする上で必要なテストデータを識別する
    • テスト環境を設計し、必要となるインフラストラクチャやツール類を識別する
      • 開発環境とテスト環境を分けるとか
      • 使っているミドルウェアのパラメータ設定とか
      • テストツールの設定とか
    • テストベースとテストケースの間で双方向のトレーサビリティを作成する
      • トレーサビリティを確保しておいて、要求仕様が変更されたらどこのテストケースを修正すればいいかすぐわかるように
        • 具体的にイメージわかず...
  • テストの実装と実行
    • テスト環境の構築もここで
    • 実装...テストケースの作成と同義、テストコードの実装も含む
    • ソフトウェアテストドキュメントの国際標準であるIEEE829-2008
  • 終了基準の評価とレポート
    • テスト実施結果、進捗状況、欠陥の検出、修正状況が基準を満たしているか評価する
      • テスト結果の記録をテスト計画段階の終了基準を比較する
  • 終了作業
    • 成果物がリリースされたか
    • インシデントレポートを終了させる
    • システムを受け入れるための文書作成

テストの心理学

テストの目的は「欠陥を見つける」だけではなく「正しく動作している」確認、「欠陥の作り込みを防ぐ」ことも含んでいる

• 独立性を確保したテスト
  • 開発者＝テスト担当者...コードから多くのバグを見つけることができる反面、時間的な猶予があまりない場合や先入観によって抜けや漏れが発生することもある
  • 開発者≠テスト担当者...テスト対象の理解に時間がかかる
  • テストの目的の違いにより効果が異なる
    • 総合テストレベルだったら開発者≠テスト担当者のほうが効果が高い？
• 独立性の度合い
  • 開発者＝テスト設計者...独立性最低
  • 開発者≠(同じ開発チームの)テスト設計者...独立性低
  • 開発者≠(別の部署のQAチームなど)テスト設計者...独立性高
  • 開発者≠(別の会社のQAチームなど)テスト設計者...独立性最高
• テストの目的の明確さ
  • 「欠陥を見つけること」を目的とせず、「ソフトウェアが目的を果たしていること」を確認したほうがいい
    • そうすることでいろいろなことに気づける
• 欠陥のフィードバックとコミュニケーション
  • 開発者とテスト担当者の立場の優位性に差はない
  • テスト担当者から指摘されても開発者は怒ってはだめ！
• テスト担当者と開発担当者の心理の違い
  • ソフトウェアの開発に従事する全ての人は「ユーザに求められる品質を満たすこと」をゴールにすべき
  • 敵対せず良好な関係を築く
  • インシデントの報告はソフトウェア開発者への中傷ではない
    • 開発担当者に適切な情報を提供すること

行動規範

テスト結果は製品の品質を判断する最も重要な材料である

• テスト中に重大な不具合を見つけた際に、修正によるプロジェクトの納期遅延や予算超過を意識するよりも、公共の利益(＝ソフトウェアに関与することになる多くの人達にとって最適な対応)を第一に考えた行動が求められる
• テスト担当者による成果物はプロフェッショナルとして高いレベルのものでなければならない
  • 品質は目に見えない
  • 品質に関するアウトプットが読みづらいと、品質の説明ができず、適切な情報提供ができているとは言えない
  • 「テストレポートが読みづらかったら恥ずかしい」という自覚が必要

第2章 ソフトウェアサイクルを通じてのテスト

ソフトウェア開発モデル

• V字モデル
  • 後工程で発覚した不具合を改修する際の追加工数
• イテレーティブ-インクリメンタル開発モデル
  • プロトタイピングとかXPとかスクラムでテストコードを先に書いたりとか
• ライフサイクルモデルの中でのテスト
  • どんなモデルを用いようが、良いテストは以下を満たしている
    • 各開発活動に対してテスト活動がある。各工程とテスト活動がしっかり対応している
    • 各テストレベルにはそのレベル特有の目的がある
      • 各テスト工程でテスト対象がちゃんと定義されている
    • テストレベルのテスト分析や設計は、対応する開発活動を実施している間に実施すべきである
      • ドラフト版でもいいのでなるべく早い時期に行なっていたほうがいい
      • あまりできていない印象
    • テストベース(要件定義書、各種設計書などのテストを作成の材料)は早期にレビューを行なう

テストレベル

• 各テストレベルで押さえておくべき事柄は以下
  • 一般的な目的
  • テストベース(テストケースを導き出す際に参考にする開発成果物)
  • テスト対象(なにをテストするか)
  • テストで見つかる典型的な欠陥や故障
  • ツールによる環境
  • 特定のアプローチ
  • 責任割当

ｐ.88からの図を共有したい

テストタイプ(テストの種類)

• 機能テスト
  • 機能が仕様どおりに動作するのか
• 非機能テスト
  • コンポーネントやシステムで、機能に関係しない特性を検証する
  • 非機能テストは機能以外がすべてが対象になる
    • 性能テスト
    • ロードテスト(負荷を増加させたり)
    • ストレステスト(要件で定義した限界またはそれを超える条件で評価する)
    • ユーザビリティテスト(ユーザにとって魅力的かどうか)
    • 相互運用性テスト
    • 保守性テスト
    • 信頼性テスト(任意の運用回数、期間、条件下で必要な機能を果たせるか)
    • 移植性テスト(別のハードウェア環境やソフトウェア環境に対して容易に移植できるか)
  • 非機能テストの適用対象
    • 受け入れテストなどテスト工程の後半で実施すると思われがちだが、コンポーネントテストや統合テスト(結合テスト)でもやる
  • 非機能テストのモデル
    • パフォーマンスとかユーザビリティとかセキュリティ脅威とか
  • 使用できる技法
    • ブラックボックステストのテスト技法使ったり
  • 品質特性(ISO/IEC9126)) http://etc9.hatenablog.com/entry/20121129/1356526435
• 構造テスト
  • カバレッジテストとほぼ同義か。どこまで網羅したか
• 回帰テスト

保守テスト

• 保守テスト...リリース後のソフトウェアに対する修正を行なった場合に行なうテスト
• 回帰テスト
• 影響度分析
  • 改修対象が他のどのモジュールや機能と関連があるか確認する

第3章 静的技法

静的技法の特徴

• コードを実行したり、テスト対象を動作させてなくても実施できる
• ソフトウェアの内部構造を意識して実施されることが多い
• 静的技法と動的技法がお互いに不足している点を補っている
• 静的技法は内部構造の欠陥を容易に検出できる。ソフトウェアの構造上の欠陥を検出することが目的
  • インスペクション等のレビュー
  • 構造分析、複雑度分析
  • モジュール、オブジェクト分析
• レビュー
  • 各種の成果物を人力で
  • 生産性の向上、開発期間の短縮、システムのライフサイクルを通じたコストの削減、欠陥の数を減らす
  • コミュニケーションを良くする

レビュープロセス

レビューの効果は高い

• 担当者のみに属人化していると、思い込みによって明らかな間違いにも気づかないことがある
• 計画して役割を明確にしてやる公式レビュー
• レビューの種類
  • 非公式レビュー
  • ウォークスルー
    • 作成者がレビューを主催
  • テクニカルレビュー
    • 技術のエキスパートが参加する
    • チェックリストを作ったり
  • インスペクション
    • モデレータが主導
    • チェックリストを使う
• レビューを成功させるために
  • 開始前に目的を明確に
  • ふさわしい人に参加してもらう
  • 欠陥がみつかることは歓迎すべきこと
  • 人の問題や心理も重要な要素
    • 非難しないように
  • レビュー結果と評価は関係ない
  • 欠陥を効率よく見つけるためにチェックリストを作ったり各人の役割(どういうところを重点的に見るのか)を決める

ツールによる静的解析

ソースコード解析ツールで、コーディング規約とか論理上のミスがないか、欠陥につながる記述がないか確認する

• 静的解析と動的解析の違い
  • 動的テストは欠陥によって引き起こされる現象(＝故障)を見つけるが、新の原因=欠陥にたどり着くまでに時間やテクニックが必要。そのための時間もかかる
• 引数の矛盾とか、不到達コード、脆弱性、書式、使われていないメソッドほかいろいろを検出

第4章 テスト設計技法

テスト開発プロセス

• テストの標準文書のドキュメント体系「IEEE829」
  • テストプロセス全般の全体像がわかる
• テストではまず、何を検証して評価すべきか、すなわち「テストの目的」を明らかにする
• その後...
  • 1. テスト条件を決定し、テストを設計する
  • 2. テストケースを定義する
  • 3. テスト手順仕様を定義する
• 1. テスト条件を決定し、テストを設計する
  • 用語「テスト条件」はテストの目的に応じてどのようにテストを割り付けるのか決めるもの
  • ！制約条件や事前条件ではない！
  • 例...機能、構造的要素(←静的解析で見るのかも？)、トランザクション、品質特性、等
  • テストの設計
    • テスト条件にどのテスト設計を適用するのか選択、決定していく
      • 境界値分析だったり、デジションテーブルとかいろいろ
• 2. テストケースを定義する
  • ＝ テストケースを書く
• 3. テスト手順仕様を定義する
  • テストケースに手順を記載しないで済ませるために(←これってテストケースによっては難しい気がする2と3は同時にやることも多い？)
  • テストを実施する手順、テストケース間で共有する手順、テストケースごとにユニークな手順。

テストの設計技法のカテゴリ

• 代表的な分けはブラックボックステストとホワイトボックステスト
  • ブラックボックステストは外から見える振る舞いに着目する
  • ホワイトボックステストは内側での動作に着目する
• JSTQBではブラックボックステスト/ホワイトボックステストの2つの分けではなく、経験ベース/仕様ベース/構造ベースの3つに分類する
  • 仕様ベース...テスト対象やテスト条件に対する要件、仕様を元に作る(みんなよく作っているやつ)
  • 経験ベース...過去に遭遇したインシデントや既知の類似した結果等、開発者のスキル、経験、知識をもとにして作る
  • 構造ベース...設計、実装を関する情報をもとに作る。カバレッジ見たりする

仕様ベース、ブラックボックスのテスト技法

• 同値分割法
  • 全てのデータでテストしない
  • 有効なデータ、無効なデータのグループを作る
• 境界値分析
  • 境界値は、同値分割した領域の端の値
• デジションテーブルテスト
  • どの条件の組合せがどの処理や動作に対応するのかわかりやすく
• 状態遷移テスト
  • 状態によって出力結果が変わる場合にやる
• ユースケーステスト
  • ビジネスシナリオやシステムの使い方に沿ってテストする
    • ユースケース名
    • 目的
    • アクター
    • 事前条件
    • 事後条件
    • 基本フロー
    • 代替フロー
    • 例外フロー
    • 備考 ### 構造ベース、ホワイトボックステスト技法
• ステートメントカバレッジ
  • 実行可能なステートメントが何％実行されたか
• デジションカバレッジ
  • テスト対象のコード中の全ての判定の結果のうち、テストによって何％実行されたか
  • 分岐をどこ程度網羅したか ### 経験ベースのテスト技法
• フォールト攻撃...過去に発生した故障、欠陥及び有識者の経験をもとに一般知識をリスト化
• 探索的テスト

第5章 テストのマネジメント

自分で作ったものの間違いは見つけづらい → JSTQBでは独立したテストチームがテストを実施することを推奨している

※組織の例(一部)↓

• 同じ開発プロジェクト内の独立したテストチーム
  • プロダクトの内部構造には詳しいが、独立性低い。品質以外の要求の圧力を受けるため
• 同じ会社内にある独立したテストチーム。上管理者の直属組織
  • 品質保証部とか。プロジェクトの圧力がかかりにくい

独立したテストのメリット/デメリット

• メリット
  • 先入観がないため開発担当とは異なる視点で欠陥を見つけられる
  • 仕様策定中や実装中に想定通りか検証できる
• デメリット
  • 開発チームから隔絶されている
  • 開発担当者の品質に対する責任感が薄れる
    • テストの責任の全てをテストチームにまかせてはいけない
  • テストチームが開発のボトルネックと見られたり、リリース遅延のために非難されがち

テスト計画

• テスト計画書の概要(IEEE Std 829-1998)参照のこと
• テスト計画とか、テスト進捗管理とか、テストレポートとかあるけど割愛
• インシデント管理もIEEE Std 829-1998のインシデントレポートの例を見てもらう

第6章 テスト支援ツール

いろんなツールの紹介。割愛