2009年12月23日

はたして、TDDを前提として障害収束曲線が描けるのか?

前のアーティクルで自分で言及してなんだけど、ものすごーく気になったので、思考実験。
規模は数人3ヶ月を想定してみた。

従来の障害収束曲線



障害収束曲線は色々呼び方があって、最も短い呼び方ではバグ曲線とか呼んだり、Wikipediaでは信頼度成長曲線という名前で出ていたりする。
基本は「テストを重ねていけば、自然と障害検出数が低くなっていくよね。」という「現象」を取り扱ったもの。
図としてはこんな感じかな。

image001.gif

図は、製造フェーズ後にテストフェーズが「単体テスト」・「結合テスト」・「受入テスト」と分かれている事を想定している。
(テストフェーズも、現場や企業の慣習によって大きく扱いが違うので、この程度にした)

「恣意的だ」とツッコミが入るだろう部分を先に解説。

  • 件数多くね? … 過去3ヶ月もテストフェーズがある場合、これぐらいじゃなかったかな?という経験則。(件数に厳密な意味などない)
  • ブレがないね … わかりやすくするため。
  • 各テストフェーズを分けるべきだ … 自分が経験した殆どの現場では、テストフェーズ全体で障害収束曲線を測るのが一般的だったので、それに習った。
  • なんで横軸が日付なの? … 自分が経験した(以下略)。


この図で「わかる」のは、単体テストから受入テストまでしだいに曲線がなだらかになっていき、受入テストが完了するころにはほぼフラットになっている(障害検出がされなくなっている)という事だ。

CI結果を障害収束曲線に!



同じようにして、次の条件でグラフを描いてみた。

  • チーム全体がTDDを前提に開発を進めている。
  • 指標に使用したのは、CIでビルド&テストが失敗した場合に、その失敗件数を障害件数と同等として使用した。
  • CIでの自動ビルドは、簡略化のために日に1回とした。


image003.gif

描いてみてわかったこと



この縦軸に出る「件数」って、「障害」の数じゃなくて「メンバの作業ミス」の数だよね



TDDを前提とすると、少なくともCIで実行するテストは常に「すべて通るハズのもの」であり、基本的にはデグレードしないことをチェックしている側面が強くなる。
そのため、ここでなんらかのエラーが起きるのは、たいていは単純な作業ミスに帰結することが多い。だから件数も少ないし、当然、日数とともに作業に慣れてくるので、ミスも少なくなる。
作業ミスとして現れるのは、だいたいこんなところかな。

  • ビルドエラー … マージのさいのコンフリクト解消を失敗する等で、コードが一時的にコンパイル不能な状態に陥る。
  • テストエラー … 原因はいくつかからなる。

    1. テストを実行せずにコミットした。(TDDに慣れない、切羽詰っててそれどころじゃなかった等)
    2. マージのさいのコンフリクト解消を失敗した。
    3. ローカルでのテスト環境とサーバでのテスト環境とに差異があった。




また、テストエラーも、Mockをあまり使わずにテストコードを書いていた場合、共有されやすいクラスを修正するとエラー範囲が爆発的に増える傾向があり、Mockを適度に使用するとそれが収束する傾向がある。

うん、まあ、なんていうか。
障害収束曲線という代物は、TDDを前提とした開発の場合、あまりにも合わない、というところが明らかになった感じかな。

※ もちろん、元請企業が「単体テストによる障害数」を求めているときに、これらの数字を使う/使わないは政治判断だと思う。その場合でも、「この件数とは何なのか」を自分できちんと把握しておくことは大事だ。

ただし



この障害収束曲線も、「カスタマテスト」および「QAテスト」で"(有効な)チケットを切られた数"に対して行う分には、十分計測する意義はある。
その場合、よりウォーターフォールに近いか、Agile/インクリメンタル開発に近いかが、件数の大小に現れてくるだろう。

おまけ:従来型ウォーターフォール開発で本当に障害収束曲線を描くと



最後のヘビの足。

障害収束曲線って、ホントに全テストフェーズを通してこんなキレイな曲線になるの?という点。
結論を言ってしまうと、障害収束曲線があのようにキレイな線になるのは、1つのテストフェーズに閉じた場合だけで、何段階もあるテストフェーズを通してあんなキレイな線になるはずがない。

image002.gif

こんな感じに。


  • テストを律儀に実施した/適当に省いた に関係なく、各テストフェーズ内でテストを繰り返す間は、曲線は次第になだらかになる。
  • だが、次のテストフェーズに以降した段階で、今までのフェーズになかったファクターが"当然"加わるため、また曲線は急勾配を描く。
  • とくにウォーターフォールでは、顧客受入れ時の要件変更のかなりの部分が「障害」として計上されるため、その傾向に拍車がかかる。


この特徴をしっかり理解しておこう。
現場ではよく「前のフェーズでテストしたのに、なぜ今フェーズでまた障害が発生しているのか」が技術者の問題として槍玉に挙げられる。(そして障害票でしっかり「反省」させられる)
だがそれは、テストのスコープも違うし、ファクターも違うのだから、発生するべくして発生した障害でしかないのだ。

タグ:テスト TDD
posted by 未知夢 at 13:55| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.seesaa.jp/tb/136362342
※ブログオーナーが承認したトラックバックのみ表示されます。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。