テストが嫌いである。小学生の頃、大嫌いだったししゃもを食べたくないが故に給食時間が終わり昼休みが終わり「5限目が始まるからもう返してきなさい」と言われるまで食べず、先生と根比べをしていたのと同程度、あるいはそれ以上にテストをやるのは（ここではテストケースの作成→テストの実施までの一連の流れを含む）億劫で手がつかないものである。
今回は親の仇のようにテストを嫌う新卒2年目のひよっ子開発者が、テストの意義を無理やり頭に叩き込み自己説得に自己説得を重ね、やっとのことで手がつけられるようになるまでに辿った軌跡と、テストをやりたくがないが故に「より少ないテストケースでより多くのバグを検出するにはどうすればいいのか」を吐き気を催しながら出した結論を書き記すものである。
※この記事はFringe81 Advent Calendar 5日目の記事です。
モチベーション
テスト技法に習熟することでテスト作成→実施に割く時間を減らし開発へ集中したい。
結論
まず効率の良いテストを作る手順として今の自分が結論した手順を記す。
- 仕様書を読む
- コードを読む
- テストコードを読む
- 影響範囲の決定
- 必要なテストの種類を決定
- ブラックボックステストを意識してテスト項目を作る
- ホワイトボックステストを意識してテスト項目を作る
- レビューを受ける
- (テスト作成者と実装者が同じならテスト項目を減らせるようユニットテストを書く)
項目数や各テストの棲み分けはテストに割けるリソースで判断。詳細は後ほど説明。
まず読むべき資料
次に前提知識の整理。
テスト技法を全く知らなかったのでたくさんの記事を読み漁った。その中でとりわけテストに入門しようという人が最低限これは読んでおくべきだと感じた資料をインプットすべき順番に列挙してみる。
ソフトウェアテスト類型
[連載] 第1回 ソフトウェアテストを分類する | 技術評論社
まずどういったテストがなぜ存在しているのかを知る。
システムテストの次に実際の状況を模したシナリオテストを行うこともよくある。
同値分割 / 境界値分析
同値分割・境界値分析の解説 | ソフトウェアテスト・テスト技法に関する情報サイト
同値分割の代表値を境界値にすることでテストケースを減らすことができる。
正常系 / 準正常系 / 異常系 言葉の定義
事例とツールで学ぶHAYST法 -正常系と異常系- | ソフトウェアテスト・テスト技法に関する情報サイト
専門的で言葉が難しいが、この記事が一番意味のある言葉の定義をしていると感じた。
準正常系として無効同値を分割しつつ削り、残った有効同値を分割しつつ正常系とする。コードで担保できない例外を異常系としてそれぞれテストを行う。
「正常系」・「準正常系」・「異常系」テストについて、まとめてみました。 | ヒャッハー！ふっくら太郎です。
言葉の定義入門として分かりやすさ重視するならこっち。
テストの7原則
原則 1：テストは欠陥があることしか示せない
テストにより、欠陥があることはわかるが、欠陥がないことは示せない。テストにより、ソフトウェアに残る未摘出欠陥の数を減らせるが、欠陥が摘出できない状態でも、正しさの証明とはならない。
原則 2：全数テストは不可能
全てをテストすること(入力条件の全組み合わせ)は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスクや優先順位によりテストの焦点を絞る。
原則 3：初期テスト
早く欠陥を見つけるために、テストはソフトウェア開発もしくはシステム開発のライフサイクルのなるべく早い時期に開始し、あらかじめ定義した目的に集中すべきである。
原則 4：欠陥の偏在
テストは、モジュールごとの欠陥密度の予測や直近の観察結果に比例してテストの焦点を絞らなければならない。リリース前のテストで見つかる欠陥や運用時の故障の大部分は、ある特定の少数モジュールに集中する。
原則 5：殺虫剤のパラドックス
同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この「殺虫剤のパラドックス」を回避するため、テストケースを定期的に見直して、改定する必要がある。ソフトウェアやシステムのいろいろな部分に対しテストを実行して多数の欠陥を摘出するには、これまでと違うテストケースが必要となる。
原則 6：テストは条件次第
条件が異なれば、テストの方法も変わる。例えば、高信頼性が必要な 24 時間稼動するシステムのテストは、e コマースのテストとは異なる。
原則 7：「バグゼロ」の落とし穴
欠陥を見つけて修正しても、構築したシステムが使えなかったり、ユーザの要件や期待を満足したりしなければ役に立たない。
特に2と4を知っておくとテストケースを大きく減らせる。全てをテストすることは不可能なのでバグが偏在するであろう箇所に絞って重点的にテストケースを作成する。
元々は以下からの引用
テスト技術者資格制度 Foundation Levelシラバス 日本語版
ブラックボックステスト / ホワイトボックステスト
[連載] 第3回 ホワイトボックステスト | 技術評論社
[連載] 第4回 ブラックボックステスト | 技術評論社
ブラックボックステストで仕様通りの振る舞いをすることを確認し、ホワイトボックステストでカバレッジを担保。
手順再掲と詳細
前提知識を押さえた上で最後に結論を補足。
- 仕様書を読む
- コードを読む
- テストコードを読む
- 影響範囲の決定
- 必要なテストの種類を決定
- ブラックボックステストを意識してテスト項目を作る
- ホワイトボックステストを意識してテスト項目を作る
- レビューを受ける
- (テスト作成者と実装者が同じならテスト項目を減らせるようユニットテストを書く)
完全新規開発の場合は2、3、4が存在しない。早い段階でテスト項目を作ることで使用の漏れをなくしつつ、バグの作り込み（間違った仕様で作り込んだ実装をしてしまうこと）を防ぐ。
完全新規開発以外の場合は、現行の仕様に倣うなど都合の良い言葉が使われがちで仕様書に完全な仕様があることはまずないので既存のコードとテストコードを読んで仕様の全体像を把握する。
5~7ではそれぞれのテスト（例えば、単体テストと結合テスト）で発見できるであろうバグの重複がないように必要十分な量のテストケースを意識する。
9ではなるべく自動テストで担保することでテストにかかるリソースを減らす努力をする。
appendix 具体的なプラクティス
テスト項目作成時とテスト実施時ともに、マトリックスなどを書きつつ、経時的、共時的に漏れがないように代表値を決定、テストしていくのが手戻りなどが減って便利。
自分はNotionやマインドマップツールを使っている。
以上。