先日あきぴーさんが ETWest で講演されたスライドを読んでふと疑問がわいた。
あきぴーさんの資料では TestLink で発見されたバグはすべて Redmine のチケットとして登録し、TestLink 側にそのチケット番号を登録することでバグとチケットを追跡可能にしている。
今回、自分が TestLink を結合テストの段階で使った時は、テストケースが 200 個くらいで失敗数が 20 個くらい（またはそれ以上）。他にもブロックされたテストが結構あったので BTS と関連付ける手間がかかり断念した。
他の人がどういった運用をしているか知らないので、このあたりの話（バグが多いと関連付けが多くてたいへんじゃないですか？）を質問したところ、またアドバイスをもらいながらいくつかの気付きを得ることができた。
数の問題の原因
失敗の数が多かった原因は以下のとおり
- １日のテスト（消化が１００件くらい？）でだいたい１０個くらいの不具合が発生（全体で７００件ほど）
- ブロックの概念を知らなかったため、ブロックとなるべきテストも失敗とカウントし、失敗数が増えた
- 単体テストを厳密にやっていないので、TestLink でのテストに入る前の品質が悪い
こんな感じの結果になったため、トータルの不具合の割合（失敗率）は１０％を
超える。
失敗率がこの割合でも母数となるテストケースが多ければその分だけ失敗の数も多くなる。それを回避するために、テスト計画に入れるテストケース数を減らすなど調整することで対応する。
その上、本来ブロックとして失敗予備軍（失敗ではない）ものも失敗とカウントしたため、いたずらに失敗率を上げる原因となった。
また、TestLink でのテストで品質を上げようとしていたが、その前の段階でそれなりの品質を確保しておいたほうがよさそう。
気づき１・TestLink を使ったテストを行う前に品質を確保する
矛盾していることだけど、今の TestLink の機能を考えるとこれが一つの解になると思う。
現状の TestLink が一番力を発揮するのはテストの中でも統合や受け入れテストなど、失敗が少ないことが前提で、ひとつの失敗が致命傷になるようなケースだと考えた。
ここでのテストは成功することが前提で、失敗したテストは設計や要求からくる不具合であり、システム（またはソフト）に重大な問題があるようなケースをテストする。
失敗が多くなるようであれば、その前段階のテストからやりなおしたほうが良さそう。
気づき２・｢テスト｣という技術の幅広さ
これは前々から感じていたけれど｢テスト｣という言葉の持つあまりの広い意味を限定しないと、そもそも話がかみ合わない。
テストに入る前の工程（製造）では｢要求｣、｢設計｣、｢実装｣と呼び方が変わるのに、｢実装｣に対する｢単体テスト｣も、｢設計｣に対する｢統合（結合）テスト｣も、｢要求｣に対する｢受け入れテスト｣もひとくくりに｢テスト｣とされているため、どの工程に対するテストかを前提として決めておかないと、そもそも議論にならない＾＾；
気づき３・TestLink 導入の敷居を下げるために
Web 上や ML での TestLink の感想は「難しい」が結構多い。
実際、自分も今回の運用が軌道に乗るまでは難しくて何度も挫折した。
この「難しさ」の原因は先の「テスト」という言葉のもつ意味の広さから来ている気がする。
で、ひとつの導入方法として TestLink を単体テストから導入するのはどうか、ということ。
これは自分目線だけど、プログラマからすれば一番身近なテストは単体テストで、そこから TestLink を導入することでなじみやすいのかなぁと。
前回の TestLink Adapter もその一環で、.NET 環境に限られるけど、TestLink を単体テストに適用するいいツールだと思う。
