徹底攻略 JSTQB Foundation教科書&問題集 シラバス2018対応を勉強しているので、自分のメモとしてまとめています。
ソフトウェアテストとは
ソフトウェア品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する一つの手段。
欠陥を見つける事がテストの直接の目的だが、あくまでも「手段」であるという理解が大切。
ウォーターフォール開発モデルにおけるテスト
ウォーターフォール開発は、古くからあるソフトウェア開発手法の一つ。滝が上流から下流へ流れていくように、決められた工程を順番に進めて開発していくこと。
プロセス
1. 要件定義
どのようなソフトウェアを作るのか方針を定めること。
どのような開発手法やシステム基盤などを使うか、どのような業務フローで目的を実現するかなどを決める。
2. 設計
要件定義で作成する要件定義署に基づいて行う。
3. 開発
設計で作成する設計書の通りにプログラミングする。
プログラミングされたものがソースコードと呼ばれるもので、コンピュータはこのソースコードに書かれている通りに処理を行う。
4. テスト
設計書通りに動くかなどを確認する
5. リリース
テストレポートをもとに、テスト結果や他の準備がきちんと完了しているかを確認する本稼働判定を行い、リスクが低いと判定された場合にリリースされる。
テストがクリアする項目
テストでは、ソースコードが以下の項目をクリアするかを確認する。
- 設計書通りに正しく動作すること
- 指定されている要件を満たすこと
- ユーザーのニーズを運用環境で満たしていること
もしテストが不十分でバグをたくさん残したままソフトウェアがリリースされてしまえば、運用中に故障が発生して大きな損失となる可能性がある。
テストは、本番運用前の品質ゲートの役割を果たす。
品質ゲート（クオリティゲートともいう）は、ウォーターフォール開発モデルで上流から下流に工程が移動する際に行われる品質チェック作業になる。
ゲートは最後だけとは限らない。
要件定義署や設計書などを人の目で評価して欠陥を見つけることも立派なテストだ。
テストは、どのフェーズでも行うものである。
テストの目的
主な目的は以下の6つ。
①作業成果物の評価 : 設計書はソースコードなどの作業成果物を評価することで欠陥の発生を防ぐ。
②要件の充足の検証 : 指定された全ての要件を満たしていることを検証する。（3秒以内にレスポンスが返ってくる、セキュリティホールがないなど）
③妥当性の確認 : システムが完成して、期待通りに動作すること（妥当性）を確認する。
④欠陥や故障の発見 : 欠陥や故障を発見し、品質が不適切になるリスクを軽減する。
⑤品質情報の提供 : ステークホルダーに対して、品質レベルに関する情報を提供する。（テストサマリーレポートを提出し、どのように品質確認したかを示すなど）
⑥契約や法律準拠の検証 : 契約上、法律上の要件や標準に準拠していることを検証する。
テストレベルによる目的の違い
テストレベルとは
テストレベルには、コンポーネントテスト、統合テスト、システムテスト、受け入れテストの4つのこと。
コンポーネントテスト
コンポーネントとは、部品や構成要素という意味。ソフトウェアにおいては、独立してるテストできる最小単位を指す。
単体テスト、ユニットテスト、モジュールテストとも呼ばれる。
統合テスト（結合テスト）
複数のコンポーネントを組み合わせて連携部分をテストするもの。
システムテスト（総合テスト）
システム全体としてきちんと動作するかの確認を行う。
受け入れテスト（運用テスト）
システムを運用環境で動作させて問題ないかを確認する。
テスト方法による目的の違い
スクリプトテスト（記述式テスト）
目的
仕様通りに動作することを網羅的に確認し、一定の品質を保障する。
説明
設計書に書かれた内容をもとにテストケースを作成し、その内容に沿ってテストする方法。
テストケースとは、ソフトウェアテストを行う際に用意する条件やテストデータ、期待される結果などの組み合わせのこと。
ここでいうスクリプトは「脚本」という意味が近い。プログラミングのスクリプト言語とは別物。
多くの開発現場で最も一般的に行われているテスト手法である。
とにかく仕様通りに漏れなく確認する事が大事。
探索的テスト（アドホックテスト）
目的
効率よくテストを行い、たとえ設計書に不備があっても大切な動作を確認する。
説明
テストケースを作成せずに手探りでテストする方法。テストしながら次のテストの内容を決めていく。
テスト中にエラーが起きた時に、どのような欠陥がどのあたりに多そうかを推測して、そこを重点的にテストすることをエラー推測といい、探索的テストで使われる技だ。
予測しながら進めなければならないため、テスターにも相応のスキルが求められる。
テストの網羅性は低いが、短時間で効率よくテストが行える。
設計書に不備があっても、大切な動作を確認できるメリットがある。
モンキーテスト（ゲリラテスト）
目的
設計担当者や開発担当者の意図を考慮していない操作をすることにより、想定していなかった思わぬ欠陥を見つけ出す。
説明
テストケースを作成しないテスト方法。
探索的テストと違い、仕様書を理解していない担当者が思いつきで操作することによって、想定していなかった欠陥を見つけ出す。
（開発者をギャフンと言わせる事ができるぜ）
カバレッジテスト
目的
ソースコードを網羅的にテストすることによって欠陥を減少させる。
説明
カバレッジ（網羅率）とは、テストすべき要件のうちどれくらいテストが完了したかを表す指標である。
テストによって全てのコードをなぞっていれば、100%のカバレッジとなる。
絶対に100%じゃないとダメというわけではなく、目標数値は時々によって変わる。90%のカバレッジの場合は、残りの10%はテストをしていないことにある。
カバレッジはコード以外にも対象がある。要件定義の場合、全ての要件のうち、テストによってどのくらい検証できたかがカバレッジになる。
受け入れテスト
目的
システムが期待通りに動作し、要件を満たすことを確認する。
説明
開発されたシステムが、期待通りに動作するかをステークホルダー側で確認するテスト。
開発側は機能面を中心にテストするが、いけ入れテストはユーザー側が運用面を重視してテストを行う。
本稼働テスト
目的
システムを本稼働させた場合のリスクをステークホルダーに示して判断してもらう。
説明
指定期日にリリースしても問題ないか、リスクを判定すること。
カットオーバークライテリア（稼働判定基準、リリース判定基準）が使われる。
チェックリストなどを用いて、準備が完了しているか、判定基準を満たしているかどうかをステークホルダーに示す。
テストとデバッグ何が違うの？
デバッグ(debug)とは、プログラムの中の欠陥(bug)を取り除く(de)作業のこと。
ウォーターフォール開発モデルにおいて、テストとデバッグを比較すると以下のようになる。
| テスト | デバッグ | |
|---|---|---|
| フェーズ | テスト | 開発 |
| 担当者 | テスト担当者 | 開発担当者 |
| 作業範囲 | 欠陥に起因する故障を示す。修正作業は含まない。 | 正常に動作するよう修正する開発作業 |
アジャイル開発モデル（要件定義からテストまでの工程を細かい単位に分けて繰り返す）では、テスト担当者がデバッグに関与することもある。
デバッグとコンポーネントテストの違い
通常、デバッグは開発担当者自身が欠陥を見つけ修正する作業を行う。
一方、コンポーネントテストをテスト担当者が行う場合は、欠陥を見つけるまでが作業範囲となる。
コンポーネントテストは開発担当者が行う事が多いため、この二つの違いは曖昧。分けずにイコールで捉えることもある。
次回