QA@IT

xUnitを利用した際の品質指標について

3986 PV

私は、xUnitを単体テストに利用した際の品質評価方法が分かりません。

xUnit利用前は、ExcelやWordにてテスト項目を作成して単体テストを実施してきました。

テストを実施する中で、不具合が発覚し、不具合票を発行して
設計書またはソースの修正を行い、該当の不具合を解決していく中で品質担保を行ってきました。
(テスト方法はホワイトボックステストで行っています)

単体テスト工程終了後、不具合の内容や件数を分析して
品質評価を行っています。

xUnitを利用して単体テストを実施する際、
プログラマーとテスターが同一人物の場合、
テストを通しながら開発を進めると
ただカバレッジ率を高める結果しか得られず、
発生した不具合の管理ができません。

Jenkinsを利用することで回帰的にテストを実施し、
品質担保を行う仕組みにはすごく感銘を受けているのですが、
不具合管理も必要と思っています。

xUnitを利用した際の品質評価や不具合管理はみなさんどのようにされていますか?

回答

質問を整理させていただくと、これはxUnitの話ではなくて、テストプロセスの話をしているのだと思います。
xUnitはあくまで手段であって、それをどのようなプロセスにのせるかはプロジェクトの進め方の話です。

おそらくはここで言っているxUnitで云々というのは、いわゆる「開発者テストを自動化した」ということであり、それが「ドキュメント管理駆動のテスト」とどうやって住み分けるか?もしくは移行で気をつけるポイントは何かという事だと思います。

以下では、「ドキュメント管理駆動のテスト」から「自動化された開発者テスト」とのテストケースの差分による比較について述べます。もともとのテスト設計力がどうこうというのは範囲外にします。また、この回答はkyon-mm個人による意見です。

1.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が同じ場合。
例えばですが、「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」は同じテストケースを実装することが担保されているでしょうか?
そこに変化がないのであれば、プロセス中に発生した失敗したテストケース(バグの登録)を手動から自動に変更すればいいだけの話の気もします。(別に失敗するごとに手動で登録してもよいけど)

2.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が異なる場合。
同じテストケースでないならば、異なる品質を担保していることになります。その場合はやるべきテストの住み分けを行ったという事であり、例えば「自動化された開発者テスト」ではバグ管理を行わないという選択もできます。ただし、住み分けをおこなった部分(おそらくは減った分のテスト)に関してどのように管理しているのかはまた別の問題です。これを管理していないのであればそれを放棄したということになります。ですが、それで十分というプロジェクトも存在するのもまた事実です。

3.「自動化された開発者テスト」がTDDである場合。
自動化された開発者テストというのがTDDである場合に、「先にテストケースを考慮しているからバグがテストケースが通るまでが実装であって、通らなくなることはほとんどない。」という場合もありますが、それもまた「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」は同じテストケースを実装することが担保されているのか?という問いの答えによってわかれます。
これが同一であるならば、「単体テストのバグゼロを目指した」ということとと同一視しても僕はいいと考えていますが、同一でないならば、先の2.「ドキュメント管理駆動のテスト」と「自動化された開発者テスト」が異なる場合。と同じ答えになりそうです。

最後に。
自動化された開発者テストなどによる偉大な習慣によって多くのバグが減ることは明白ですが、差分を考えたい場合は、プロセス、手段、目的を整理してから考えるといいと思います。
xUnitはあくまでツールの手段の話であり、それを計画駆動のテストとして使うことも、開発者がリファレンスとして残すこともできますし、ゆるいTDDのツールとしても、厳しいTDDのツールとしても使うことができます。

Have a Good Test!

編集 履歴 (0)

大局観的な回答はもうされていますので、ここではホワイトボックスよりのいわゆる「単体試験」をxUnitによって自動化した時に品質というものをどう捉えればいいか、という回答をしたいと思います。

もともと品質指標のようなメトリクスは条件をある程度揃えた時に比較の軸として機能しますから、ユニットテストによる自動化テストを導入した時に「バグが少なすぎる」「テストケースが多すぎる」という食い違いが起きるのは、よく起きる話です。

そもそもいわゆるコーディングを終わった後の単体試験において発生したバグを管理するのは、自動化されていないテストの環境では修正した後の回帰テストにコストがかかること、また少なからずリグレッション(デグレード)のリスクがあるため、品質指標を管理する必要があるからです。ですので、障害が何件発生して、何件残っていて、残障害がどれくらいありそうかという管理をするわけです。

もちろん、テストを自動化する場合も基本的な考えは変わりませんが、回帰テストのコストが大きく下がる、という点が大きく異なります。(テスト件数が積み上がってくると、テストケースの管理コストの問題が出てきますが、それは別の話です)なので、製造の早い段階から自動化されたテストを実行して、品質をモニタリングすることができます。

つまり、障害の数を管理するのではなく、障害を早い段階に少ないコストでつぶすことができるように、アーキテクチャーをコントロールすること(例えば、全てのコンポーネントが揃わないとxUnitによるテストが実行できないような状況を避ける)、プロジェクトをマネジメントすることが、品質管理の主眼となってきます。

なので、Jenkins等のCI(継続インテグレーション)において、テストの件数の増減、リグレッションの発生頻度、カバレッジ等をモニタリングするのが効果的でしょう。

また、テスト対象(実装)にあわせてテストを実装してしまうという点を心配しているのであれば、テストファーストのアプローチが有効でしょう。xUnitに開発者が不慣れだというのであれば、テストコードのコードレビューも必要になってくるかもしれません。

編集 履歴 (3)
  • 回答ありがとうございます。
    回答いただいたどちらの内容も私のモヤモヤを晴らしてくれる内容で
    とても参考になりました。

    TDDやテストコードレビュー、ソースレビューも交えてテストプロセスを考えてみたいと思います。

    まだテスト自動化の知識が乏しいので、勉強して有意義なテストを行うスキルを身に着けないといけませんね。
    -
ウォッチ

この質問への回答やコメントをメールでお知らせします。