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