はじめに
人間だれしもミスをする。コーディングに明確な正解はない、それゆえに複雑なコードをミスせずに書くことは不可能だ。ミスをしない開発者がいたとしたらそれは難しい作業をこなしていないだけで何の自慢にもならない。
でも納品したプログラムで致命的なバグが発見されると大変だ。評判が下がるし、追加作業が発生したり、損害賠償を請求されたりする。ミスは発生するものだが、納品までには取り除いておきたい。だから被害防止のためにどこの会社でもテストをやっている。
私がいた現場ではホワイトボックステストとブラックボックステストを区別せずに適当に実施していた。まず行っていたのがブラックボックステストを後でまとめて行なうやり方、これをテストコードを書かずに手動で行っていた。そのうち「テスト駆動開発が流行っている」という意見が出てきたのでブラックボックステスト風のテストコードを書きながら開発を行なうという方法になった。
しばらくなんとなくテストコードを書いている状態で開発は続けられた。しかし、ある簡単なプロジェクトで開発者が書いたテストコードのみでテストを済ませ納品したのだが、いろいろとバグが発生して問題となった。当前のことだが開発者が書いたテストコードでは開発者が予想できるバグしか発見できなかった。
では一体どうすれば良かったのか。ようはホワイトボックステストとブラックボックステストのバランスを大切にしてテストを進めて行こうということだ。
基本方針
ホワイトボックステストとブラックボックステストのバランスを意識するためにテスト設計の前にチーム内で基本方針を定める。これによってテスト工程全体の短縮を行いたい。
品質
- 品質の担保はブラックボックステストの際にテスト内容をダブルチェックすることで行なう。
工程順序
- ホワイトボックステスト → ブラックボックステスト(自動) → ブラックボックステスト(手動)
ブラックボックステストの設計には時間が必要なのでホワイトボックステストの後の実施になる予定(前後することもあり)。
手動テストはテスト実施に時間がかかるため、工程の後ろの方に持っていく。これはテスト観点以外でエラーが発生し、無駄な手戻りを防ぐため。
テストコードの扱い
- ホワイトボックステスト、ブラックボックステストのテストコードはそれぞれ分離して区別できるように管理する。
ホワイトボックステスト
定義
- 開発者が開発のために書くテストコードを用いる
目的
- 開発者の意図通りの動作をすることを確認するため行なう
- 開発者がコードを書いた際の変更範囲、コードが動作するかのフィードバックを得ることで開発をスムーズにする
手法
- テストコードのロジックの正確性についてのレビューは行わない(もちろん通常のコードと同様に保守性は考慮する)
- 開発とテストコード記述は同時に行われる
- 全パターン網羅しなくとも良い
- 境界値テストのようにブラックボックステストで行なうテストは行わない
ブラックボックステスト
定義
- 開発者以外が作成するテスト
- 開発者の意思が入るとホワイトボックステストになってしまうので開発者の意思とテスト内容を分離すること
- テストコードだけとは限らず手動テストも含む
目的
- 品質を確保するために行なう
手法
- テストコードについては、ダブルチェックを行いロジック間違いを防ぐこと
さいごに
具体的にどのようなテスト設計にすればいいかは今後勉強していく予定。