ソフトテストウェア技法ドリルがJSTQBより親しみやすく実務的だったので、内容をまとめておきます。
点に注意を向ける
数字一つをとってみても整数、小数、自然数、負の数、数字以外といったように、
「間」「対称」「類推」「外側」を考える癖をつけることで怪しい箇所を推測する。
意地悪条件
ソフトウェアの入力可能範囲を超えた異常な値など、
絶対入力しないような値を考える。
人間の習性
ソフトウェアのバグ発生メカニズムは、「人間の習性」によるものが大半である。
→言語学、認知心理学、哲学などの力を借りる必要がある。
過去の経験
多くのバグ票を読みながら「どうしてそのようなバグを作り込んでしまったのだろう」と考えることでトレーニングする。
ただ、経験があるがゆえに見逃す場合もあるので注意。
線を意識する
同値分割と境界値分析
入力可能性がある値をグループ分けして代表値だけをテストすることで「網羅」するテストができる。
境界値付近に関係するバグは非常に多いため、必ず線で視覚的に分かるように図示することが重要。
異常値は他の異常値を隠す
プログラムの処理順番の関係上、正常値は複数組み合わせを同時に検証できるが、
異常値は一つずつしか検証できない。
面で逃さない
ドメイン分析テスト
下記の概念をもとに図に起こすことが重要。
マトリクスを作成し、着目した変数以外はinにしておけば着目した変数を確実に評価できる。
on 着目している境界値
off onポイントに隣接している境界値
in ドメインの内側の値（on/off以外）
out ドメインの外側の値（on/off以外）
デシジョンテーブル
if文やswitch文は全てデシジョンテーブルにできる。
デシジョンテーブルを圧縮する場合には処理順が重要になるため、注意が必要。
原因結果グラフ
論理関係を目に見える形で表現したもの。
CEGTestにて原因結果グラフをデシジョンテーブルに変換することができる。
立体で捉える
直行表
機能と機能の間に関連がないことを「直交している」と言う。
時間を網羅する
状態遷移テスト
多次元の品質
シナリオテスト
線・面・立体・時空全てを組み合わせ、人の行動に基づいてシナリオを作成する。
狭く深くシナリオを書くことが重要。
参考書籍：「ソフトウェアテスト技法ドリル テスト設計の考え方と実際」秋山 浩一 (著) 日科技連出版社
https://www.qbook.jp/book/20200619_937.html