単体テストではxUnitを利用して実施することが多い。
昔の自分はxUnitを利用するよりも、手動でデバッグを繰り返しながら行うほうが
品質は担保できるのではと考えていた。
下記の記事に明確な答えがあった。
xUnitを利用した際の品質指標について
http://qa.atmarkit.co.jp/q/3273
私は、xUnitを単体テストに利用した際の品質評価方法が分かりません。
xUnit利用前は、ExcelやWordにてテスト項目を作成して単体テストを実施してきました。
(テスト方法はホワイトボックステストで行っています)単体テスト工程終了後、不具合の内容や件数を分析して品質評価を行っています。
xUnitを利用して単体テストを実施する際、プログラマーとテスターが同一人物の場合、
テストを通しながら開発を進めると、ただカバレッジ率を高める結果しか得られず、
発生した不具合の管理ができません。xUnitを利用した際の品質評価や不具合管理はみなさんどのようにされていますか?
上記の質問に対する答え。
質問を整理させていただくと、これはxUnitの話ではなくて、テストプロセスの話をしているのだと思います。
xUnitはあくまで手段であって、それをどのようなプロセスにのせるかはプロジェクトの進め方の話です。「開発者テストを自動化した」を「ドキュメント管理駆動のテスト」とどうやって住み分けるか
1.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が同じ場合。
変化がないのであれば、プロセス中に発生した失敗したテストケース(バグの登録)を
手動から自動に変更すればいいだけの話の気もします。(別に失敗するごとに手動で登録してもよいけど)2.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が異なる場合。
同じテストケースでないならば、異なる品質を担保していることになります。
例えば「自動化された開発者テスト」ではバグ管理を行わないという選択もできます。3.「自動化された開発者テスト」がTDDである場合。
自動化された開発者テストというのがTDDである場合に、
「先にテストケースを考慮しているからバグがテストケースが通るまでが実装であって、通らなくなることはほとんどない。」
という場合もあります
「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」は同じテストケースを実装することが担保されているのか?担保されているならば、「単体テストのバグゼロを目指した」ということとと同一視。
担保されていないならば、先の2.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が異なる場合と同じ答え。