プログラマの思索

テスト管理ツールに必要とされる機能要件は欧米と日本で異なるのではないかという記事を見つけたのでメモ。

【参考】
欧米のテスト管理ツールとCATにおける、要求の違いについて - CAT Tech Blog

TestLink利用に際して参考になるブログ - misc.log

テスト工程の管理をするツール、TestLinkについて - Qiita

脱Excel！ TestLinkでアジャイルにテストをする (1/6)：エンジニアがお薦めする 現場で使えるツール10選（5） - ＠IT

テストを育てるためにテスト管理ツール「TestRail」を使ってみた | 「世界」旅と子育てを愛するアジャイルコーチのブログ

ちょっと今、テスト管理ツールをもう一度調べている。
10年前はTestLinkを使っていて、それなりにテスト管理の技法は研究していた。
しかし、TestLinkそのものに不満が色々あって、結局使わなくなってしまった。

とはいえ、テスト管理をExcelでやるのは時代遅れ。
テスト管理のように、数千～数万のテストケースの予実管理を行う管理作業こそ、ツールで自動化すべきだ。
なのに、なぜ、特に日本では、テスト管理の重要性は知っているにも関わらず、テスト管理ツールが普及しないのか？

上記の記事では、欧米と日本では、品質に関するリスク管理の観点が異なるからではないか、と指摘している。
欧米では、シェア確保と先行者優位を優先するので、品質よりも市場投入のタイミングを重視する。
よって、品質よりリリースタイミングを優先し、バグがあれば機能制限を設けたりする。

一方、日本では、リリースタイミングよりも、予定されていた機能の品質が担保できていることを重視している。
なぜなら、いくら機能が良くても品質が悪ければ、クレームの嵐になり、ブランド価値が毀損されるからだ。
つまり、日本では、製品の機能と品質は表裏一体とみなす。

この違いから生じる、テスト管理ツールへの要件は何か？
欧米では、重要な利用シーン（ストーリー）をベースに品質を評価する。
よって、ストーリー（シナリオ）を分割し、テストケースのタイトルにStep1、Step2の順に確認項目を記載し、テストを実行していくGUIになる。

一方、日本では、機能テストをベースに品質を評価し、全項目で一定の品質を確保する必要がある。
よって、全ての機能を網羅したテスト仕様書がまず準備されて、各テスト項目はかなり詳細に手順や確認項目を書き込み、1つずつ潰していく。

上記記事にあるTestLinkのテストケース編集画面と、CATのテストケース編集画面の違いが面白い。
TestLinkでは、テストケースのタイトルがツリー構造で表示され、その一つを選ぶとポップアップされ、テストケースを編集する。
一方、CATでは、テストケース編集画面はExcelの表形式と全く同じ。

確かに、TestLink、あるいはTestRailsでも、テストケースのタイトルが一覧表示されていて、その詳細はポップアップで編集するイメージだ。
なぜなら、ストーリーベースなので、テストケースの詳細を見なくても、業務のストーリーを元に、その手順を踏めばいい。
テストケースをグルーピングする機能の方が重要だ。
つまり、欧米のテスト管理ツールでは、テストケースの粒度は荒い。

一方、日本のテスト管理では、機能ベースで全てのテストケースを網羅すべきというプレッシャーがあるので、テストケースの粒度はかなり細かい。
テストケースをテスト観点のカテゴリで分ける方が大事だ。
ゆえに、テスト管理ツールでテストを実行する場合、テストケースの詳細をじっくり読み込まないと、テスターはテストできないだろう。

おそらく、日本のテスト管理では、テストケースをグルーピングする機能よりも、テストケースにハッシュタグを付ける、とか、ツリー構造で階層化する機能の方が重要なように思える。
なぜなら、機能ベースのテストケースでは、グルーピング機能を強化しても、ツリー構造が深くなるので、肝心のテストケースを表示させるためのUIの導線が複雑になりやすいからだ。

TestLinkは個人的には好きだったが、テストケースの元ネタとなるテスト仕様書はExcelで作りこんでTestLinkにインポートしたり、テストケースを一括編集する時はTestLinkからExcel出力した後でExcel上で一括編集して再度TestLinkに取り込む、などの作業をしていたのを思い出した。
つまり、TestLinkというテスト管理ツール上でそういう作業はやりにくかったのだ。
すなわち、日本では品質を担保するためのテスト管理の概念が違う点が、根本原因にあったのだろう。

テスト管理ツールの利用、という古くて新しい問題については今後も色々考える。