読んだ本
マンガでわかるソフトウェアテスト入門 テスターちゃん Vol.1
ソフトウェアテストとは
ソフトウェアテスト（以下、テスト）はソフトウェアやシステムが仕様どおりに動作することを確認し、品質を保証するための活動。
テストでは主に以下の3つの観点を確認する。
- バグの確認
- 性能の確認
- ユーザー視点での確認
バグの確認
仕様書に記載された内容どおり動作するか、意図しない動作が発生しないかを確認する。
この際、主に以下の4つのふるまいを検証する。
- 入力
- 処理
- 出力
- データ保存
性能の確認
例えば機能的な不具合がなくても、動作が極端に遅いシステムは価値が低い。そのため、処理速度やレスポンス性能、負荷時の挙動などを確認する必要がある。
ユーザー視点での確認
ユーザーの立場からシステムやアプリケーションが使いやすいかを確認する。
例えば、
- 操作方法が分かりやすいか
- 必要な機能にたどり着きやすいか
- ストレスなく利用できるか
といった観点を検証する。
テストケースの典型例：三角形問題
あるプログラムが3つの整数を入力として受け取り、それらを三角形の3辺の長さとみなして以下を判定し表示する。
- 不等辺三角形
- 二等辺三角形
- 正三角形
考えられるテストケース
正常系
- すべて1以上の整数を入力した場合
- 不等辺三角形となる値を入力した場合
- 二等辺三角形となる値を入力した場合
- 正三角形となる値を入力した場合
異常系
- 入力値の一部が0の場合
- すべての入力値が0の場合
- すべてまたは一部の入力欄が空の場合
- すべてまたは一部、整数以外の値を入力した場合
- すべてまたは一部、負の数を入力した場合
- 三角形の成立条件を満たさない場合
- 三角形の成立条件は「任意の2辺の長さの和が、残りの1辺の長さより大きいこと」
例えば「1,2,3」はこの条件を満たさないため、三角形として成立しない。
テストケースの作成
テストケースには主に以下の内容を記載する。
- 前提条件
- 入力値
- 実行手順
- 期待結果
テストケースが曖昧であると、実施者によって解釈が変わり、テスト結果にばらつきが生じる可能性がある。
そのため、新人であってもベテランであっても同じ結果を得られるよう、具体的かつ明確に記載する必要がある。
バグ票の書き方
バグ票とは発見した不具合の内容を開発者へ正確に伝えるための資料。
簡単に言えば
「どこで、何をしたら、どうなったのか」
を記録するもの。
最低限、以下の項目を記載する必要がある。
- 発生環境（OS、ブラウザの種類など）
- 再現手順
- 実際の結果
- 期待結果
再現手順が不足していると、開発者が不具合を再現できず、原因調査や修正が困難になる。
探索的テスト
探索的テストとは、目的に沿って考えながら実施するテスト手法である。必ずしもテストケースが必要とはされない。
探索的テストは以下のサイクルを繰り返しながら進める。
学習
↓
テスト設計
↓
テスト実行
↓
分析
↓
学習
学習
ソフトウェアやアプリケーションを実際に操作しながら挙動を理解する。
例えばSNSアプリであれば、
- 会員登録
- ログイン
- 投稿
- いいね
- シェア
- フォロー
- 各種設定
などを確認する。
テスト設計
学習した内容をもとに、どのような観点でテストを行うべきかを検討する。
テスト実行
設計した内容に基づいてテストを実施する。
分析
テスト結果を分析し、不具合が発生しそうな箇所や追加で調査すべき内容を洗い出す。
探索的テストの種類
探索的テストには主に以下の3種類がある。
- フリータイプ
- テストチャータ使用タイプ
- セッションベースドタイプ
フリータイプ
テスト実施者の判断に委ねて自由に実施する方法。
テストチャータ使用タイプ
あらかじめテスト方針を定めて実施する方法。
例えば、
- 仕様書に記載された機能が実装されているか確認する
といった方針を設定する。
探索的テストを行うための「道しるべ」となる資料をテストチャータと呼ぶ（仕様書、抽象度の高いテストケース、機能リストなど）。
- 参考
セッションベースドタイプ
テストチャータを用いた探索的テストに時間制限を設ける手法。1セッション終了ごとに結果を振り返り、新たなテスト方針や観点を追加しながら進める。
バグを発見しやすい観点
不具合は特定の条件下で発生しやすい傾向がある。
代表的なものは以下のとおり。
- 処理の繰り返し
- 処理中の別操作
- 境界値
- 入力値の種類
- 処理順序の変更
- 外部制御の影響
- 特殊状態の発生
例えば境界値テストでは、入力可能文字数が1〜100文字の場合、
- 0文字
- 1文字
- 100文字
- 101文字
を確認する。
また、特殊状態の例としては、
- 通信遮断
- サーバーダウン
- 回線速度低下
などが挙げられる。
テスト7原則
- 参考：
1. テストでは欠陥があることは示せるが欠陥がないことは示せない
テストによって欠陥が存在することは示せるが、欠陥が存在しないことを証明することはできない。
2. 全数テストは不可能
すべての入力や操作パターンを網羅的に検証することは現実的でない。そのため、リスク分析や優先順位付けが重要となる。
3. 早期テストで時間とコストを節約できる
開発初期に問題を発見するほど修正コストは低くなる。
4. 欠陥は偏在
不具合は特定の機能やモジュールに集中する傾向がある。
5. テストの弱化
同じテストばかり繰り返していると、新たな不具合の発見が難しくなる（弱化）。ただし、回帰テストやデグレチェックには繰り返し（自動化）も有効である。
6. テストは状況次第である
すべてのシステムに適用できる万能なテスト手法は存在しない。対象や開発体制に応じて柔軟に選択する必要がある。
7. 欠陥ゼロの落とし穴
仕様どおりに動作し不具合がなかったとしても、それがユーザーにとって価値のあるシステムであるとは限らない。
仕様の把握
テスト担当者は、実システムが完成していない段階でも仕様書を読み込み、システムの全体像を理解する場合がある。
把握すべき内容は以下のとおり。
- 何をするシステムなのか
- システムの特徴は何か
- どのような機能があるのか
- 各機能はどのような役割を持つのか
マインドマップの活用
仕様理解にはマインドマップが有効である。
まず主要機能を表すメインブランチを作成し、そこから関連する機能や仕様を枝分かれさせて整理する。
これにより機能間の関係性を可視化でき、テスト観点の洗い出しにも役立つ。