TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理

TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。
TestLinkでテストしていきながら感じたことをメモ。

【1】ウォーターフォール型開発では、下流工程にテストが来る。
単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？

テストは基本的に、V字モデルの左側の工程の検証作業になる。
単体テストは開発工程の検証だが、結合テストの違いは何だろうか？

単体テストは、最低限動作することを保証すること。
Exceptionが発生するようでは話にならない。
ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。
だから、コードカバレッジが非常に重要になる。

結合テストは、複数のモジュール同士を結合して動作するのを検証する。
普通のプロジェクトでは、結合テストで火を噴くことが多い。
理由は、結合テストになって初めて、顧客だけでなく開発者も、実際にシステムが動くのを見れるからだ。
システムは、いくら設計をやったとしても、動かさないとイメージが湧きにくい。
そこで初めて、設計漏れ、要件漏れに気づくことも多い。

【2】Webシステムならば、結合ストで、複数の画面の間で遷移するテストになる。
結合テストでは、単に画面遷移するだけでなく、画面の状態のパターンに対してテストする。
つまり、システムの状態遷移図に従って、正しく遷移するか、おかしな遷移はしないか、を確認することになる。

結合テストで火を噴きやすい理由は、システムの状態遷移図に設計漏れがあったことに初めて気付く工程だからだと思う。
状態の数がわずか数個でも、その状態遷移のパターン数はすぐに爆発する。
全ての状態遷移を設計し尽くすのは、かなりの労力がかかるし、高度なモデリング力を必要とする。

例えば、Amazonのような小売系Webシステムの結合テストを考えてみよう。
商品は、会員によって商品検索で発見され、カート画面に入って、注文フローを通って注文完了されて、ようやく終わる。
その間の商品のステータスは、「カート」「注文中」「注文完了」が最低限あり、それらのステータスを結ぶと、状態遷移図が出来上がる。

この状態遷移図から結合テストのテストケースを作る時、「カート→注文中→注文完了」だけでなく、「カート→注文中→カート→注文中」「カート→注文中→カートから削除」など、フローを逆に戻るようなケースも必要だ。
この時に、実装漏れ、設計漏れが判明しやすい。

更に、注文完了後に、商品の配送前に注文取消ができる要件があったとしよう。
すると、「商品の配送前に注文取消できる」「商品の配送後は注文取消できない」というケースも出てくる。
この2個のケースに上記のケースも組み合わせると、テストケースは指数関数的に増えていく。

結合テストでは、他のステータスも考慮するから、画面に出てくるオブジェクトのステータスが多いほど、テストケースは爆発的に増えるから、納期までにテストを終えるのは高度なプロジェクト管理能力が必要になってくる。

【3】そして、システムテストでは、時間軸に沿って、業務シナリオに従ってテストする。
販売期間中の商品を注文した場合、商品をカートに入れたまま放置して販売終了になった場合、など、色んなフローを時間軸と絡めてテストケースを作る。

システムテストでは、システム間同士の結合テストも含まれる時がある。
特に、フロントのWebシステムと、バックエンドで動くバッチあるいはメインフレームのインターフェイスを確認する時が多い。
ここでも、初めて稼動するのを開発者も見るから、初めて仕様の本来の意味が分かる時も多い。

そして最後は、顧客が実際に使えるかどうか、受入テストを実施する。
このテストケースは今までのテストケースがほぼ流用されるが、顧客はこの工程で初めて触れるから、本来の要件がずれているのを初めて気付いたり、やっぱり使いやすくして欲しい等と言った仕様変更が大量に押し寄せる時がある。
特に、新規顧客で、第1次開発案件で最初のリリースでは、開発チームと顧客の距離感が分からないため、要件の認識相違が非常に多い。

【4】それぞれのテスト工程では、テストの目的は大きく異なる。
だが、一番注意すべき工程は、僕の経験では、結合テストだ。
その結合テストで一番の肝は、システムの状態遷移図を漏れなく、整合性を取りながら書ききれるかどうかにかかっている。

そして、その結合テストでもう一つ重要なのは、要件カバレッジだ。
実際は、仕様を全てテストで検証されているか、仕様のカバレッジを考慮しているか、ということ。
実際の現場では、そもそも要件や仕様にIDが振られておらず、テストケースはどんな背景から作られたのか、という作成理由が曖昧なまま作る時が多い。
すると、必ずテストされていない仕様や要件が出てきて、そこが潜在バグになる。

TestLinkを運用して使いこなしていくと、テストケースそのものの品質が重要になってくる。
テストケースがシステムの状態遷移を全て網羅していないならば、テストされない遷移からバグが出る。
テストケースが全ての要件や仕様を網羅していないならば、テストされない要件からバグが出る。

TestLinkでは、要件管理の機能があり、テストケースと要件を紐付ける機能がある。
この機能を使い要件解析すると、テストされていない要件を簡単に探すことができる。

また、TestLinkのテストケースは階層構造にできるため、状態遷移図のステータスやフローの種類でグループ化することができる。
これによって、テストケースを管理しやすくなる。

運用保守では、リアルタイムに保守されない仕様書よりも、過去に使われたテストケースの方がはるかに重要だ。
テストケースこそが、仕様そのものだからだ。
そのテストケースを再利用して回帰テストを行えば、デグレ防止にもなる。

【5】現場リーダーも開発者も、要件定義から開発までの上流工程のプロジェクト管理に関心が行きがちだが、実は、下流工程に当たるテスト工程のプロジェクト管理の方がはるかに難易度が高い。

TestLinkを運用してから、テストの進捗管理やバグ修正＆検証フローが非常に管理しやすくなり、テスト工程のプロジェクト管理がものすごく見える化できるようになった。
他にも考えてみたい。