はじめまして。小池です。アジャイル開発チームでQAをしています。
現在のチームはQAが参画してからまだ間もなく、一人目のQAが一生懸命畑を耕していたところに私がジョインしました。QA1人のときは手動や頭の中でどうにか管理できていたことが、2人になったことで改善していく必要がでてきました。
その改善活動に役立つ話やヒントがもらえるかもしれないと思い、3/9-10に開催された、JaSST’23Tokyoにオンライン参加しました。
JaSSTとは
JaSSTとは「ソフトウェアテストおよびソフトウェア品質に関心のある方が深い学びを得ることを目指して、 ソフトウェアテスト分野の幅広い情報と、参加者同士の交流や議論ができる場を提供」するため、特定非営利活動法人ソフトウェアテスト技術振興協会 (ASTER)が主催する日本最大級のソフトウェアテストのシンポジウムです。
JaSST’23 Tokyoのテーマは「相互理解で広がる世界」ということで、関連するセッションが多数催されました。
セッション「テストウェアのデータモデル」
このセッションでは、鈴木一裕さんと朱峰錦司さんが「テスト管理ツール」について利用者と開発者（提供者）の立場から、これまでの経験や世の中のツールの傾向をふまえてお話ししてくれました。
今のチームはテスト管理ツールは使わずスプレッドシートで管理をしています。
日々リリースがあり、テストケースのやり直しが発生すると「テスト管理業務で気づいたら半日終わっていた」なんてこともあります。
テスト管理を楽にするためにツールを導入しようとしているので、このセッションを視聴しました。
朱峰さん曰く「マニアックなテーマ」だそうですが、とても多くの方が視聴していました。
セッションの内容をご紹介する前に、テスト管理ツールについて説明します。
テスト管理ツールとは
テスト管理ツールの中心は「テストケース」です。
そのテストケース管理には大きく2つの流派があります。
- チケット型
テストケースの属性（フィールド）はツールが「こうあるべき」と縛ります。
テストケースのグルーピングは入れ子可能な自由なフォルダ構造であることが多いです。
- スプレッドシート型
基本的にテストケースの属性（列名）は任意で使いたいように使えます。そのため、今使っているスプレッドシートをそのまま使えます。
テストケースのグルーピングは「テストスイート」という一段階の縛りになります。
ちなみに朱峰さんが開発しているテスト管理ツールはスプレッドシート型だそうです。
利用者目線での課題
まずは鈴木さんが利用者目線で「Excel管理」とテスト管理ツールを比較して、何ができて何を課題と感じているかをお話ししてくれました。
※「Excel管理」とはExcelを使用していなくても、テストケースの手順から実行までを強力に結合した管理のことを表しています。
Excel管理ではテストケースが一覧化しているので全体感はわかりやすいですが、仕様とテストケースとのトレーサビリティは弱く、テストのモニタリングに使用するグラフ等も自分で作りこむ必要があります。
一方、テスト管理ツールでは、最新のテストケースを一元管理しやすく、仕様やインシデントとのトレーサビリティも取りやすいです。また、ビルトインで用意されたグラフ・表はリアルタイムで集計してくれるので、自分で作りこまなくてもモニタリングができます。
テスト管理ツールは、Excel管理の手間を省いてくれますが、もちろん万能ではありません。この後、鈴木さんが利用者として感じている課題をお話しします。
まずは解決策を見出したい課題を2点挙げていました。
課題A：一覧性や保守性の低下
一般的なテスト管理ツールの「チケット型」は1テストケースごとに管理することが多く、テストケースがバラバラになります。そのため、Excel管理と比較して一覧性が低下します。
チケット型ではツリー構造で管理できますが、階層が深くなると扱いづらくなります。
また、テスト管理ツールは、例えば「手順は共通でパラメータだけ違う」場合も別々のテストケースとして扱うため、共通の手順を修正する際も複数のテストケースに同じ修正を行う必要があり保守性が低下します。これについては「データ駆動」の機能サポートで解決するかもしれないとお話ししていました。
課題B：テスト管理ツール外で作成したテストモデルとの関連付けは難しい
デシジョンテーブルや状態遷移表等、記法が定義されたモデルは、専用ツールで作成しテストケースを抽出できます。しかしそれをテスト管理ツールにインポートするとトレーサビリティが断絶してしまいます。
ほかに、テスト対象に応じて独自の図表を作ることがありますが、そういう場合は汎用性の高いExcel管理が相性が良いです。
次に、ベストプラクティスを出したい課題を3点挙げられました。
課題C：テストケースの管理構造
「チケット型」の場合、Excel管理に比べて一覧性が低下するので、テストケースが増えるとカオスになりがちです。そこで、ある程度の構造化が必要になります。
テスト管理ツールでは各テストケースに名称を付けることが強制されます。チケット型のテスト管理ツールの場合は、どんなテストケースかわかる名称にすることが大切です。
課題D：テスト実行のステータス管理
ツール上ではシンプルで難しくありませんが、「計画したテストは完了したといえるのか」を判断しようとすると難しくなります。
例えば、「テスト実行はFailedになったが、当該バージョンでは直さない」となったときや「テスト環境の問題でまだテストケースが実行できない」等、「成功を期待できない」テストケースが増えると複雑になります。
課題E： トレーサビリティの使いどころ
テスト管理ツールの良いところに「トレーサビリティの取りやすさ」があります。トレーサビリティをどう役立てるか、自分たちにどの情報に価値があるかを考えて定義することが大切です。
今のチームでは課題Dの例であげられた「テスト実行のステータス管理が煩雑」になることが多いので、テスト実行のステータス管理は特に難しいと感じています。
課題Eについては、テスト管理ツールの課題というより利用者自身の課題と感じました。
提供者目線でのアプローチ
次は朱峰さんがテスト管理ツールの提供者側の目線で、鈴木さんが挙げた課題について考察をお話をしてくれました。
課題A：一覧性と保守性についての考察
まずは一覧性についてです。
一覧表示したいときは見た目の確認とメンテナンスのために全体を見たい場合が多いそうです。一覧表示についてはWebのUX/UIの工夫のしどころではありますが、こういうのを考えられる人を雇うことが難しいのが悩みだそうです。
スプレッドシート型はシートとテストケースが分断化されているので、一覧には一つ一つのテストケースは表示されません。チケット型は一覧に個々のテストケースも表示されます。「どういう目的で一覧化したいか」によりますが、一覧を参照するときに個々のテストケースまで見たいか？が議論のポイントだそうです。
次は保守性について。鈴木さんはお話のなかで「データ駆動」というアイデアを出していました。
抽象的なテストケースに対して具体的な値を複数用意する仕組みは実現できそうと思ったそうで、実際にこういうツールもいくつかあるようです。
課題B：テストモデルとのトレーサビリティの考察
前提として、テストモデルの作成自体はテスト管理ツールの外で扱うのがよさそうです。
上流を変更するとそのあとも勝手に変わるような一貫性を確保した「強いトレーサビリティ」は出来ないので、ここは潔くあきらめます。リンクを書いておくなど、少し作業したら追えるトレーサビリティを確保していくのが無難だそうです。
ただし、仕様→テストモデル→テストケースといった2段階になるとしんどくなるので、その場合はテストケースに対して仕様とテストモデルの両方からトレーサビリティをつけるのが良いそうです。
課題C：グルーピング（管理構造）、テストケースの名前の考察
テスト管理ツールのフォルダやスイートは機能分割の単位で活用されることが多く、テストの目的はタグで使われることが多いそうです。
スプレッドシート型ではテストケースの名前はつけませんが、名前をつけることによって、モデリングがきれいになるきっかけになるかもしれないのでスプレッドシート型でも明示的に「名前」列を導入してもいいかもしれないとおっしゃっていました。
課題D：テスト実行結果のステータスの考察
多くのテスト管理ツールは、テストケースと実行が1:Nで同じテストケースを繰り返し実行できます。少ないステータスで取りまわすのはスマートですが、意味のあるステータスは増やしたほうがいいと思ったそうです。
課題E：情報の活用の考察
鈴木さんの課題では「トレーサビリティ」となっていたところです。朱峰さんは、それは「手段」であるとして「情報の活用」と読み替えました。
提供側として、「今実施しているテストの進捗や品質の状況」のほか、次のテストに活かせる情報やテスト戦略に関する情報も提供したいそうです。
まとめ
利用者がテスト管理ツールの課題を話し、提供者がその解を話すというのは、まさにテーマの「相互理解」だと思いました。テスト管理ツールの利用者側の話は聞けることがあっても、提供者側の話を聞ける機会はないので、とても面白く視聴できました。
鈴木さんがトレーサビリティの課題について言っていた「自分たちにどの情報に価値があるかを考える」は意識から抜けがちな気がしたので、これを意識していくことが大事だと思いました。
また、朱峰さんの「強いトレサビは無理。2段階もしんどい。トレサビを2つつけるのがいい」というのはとても腹落ちしました。
実は今回、JaSST初参加でした。どのテーマも面白かったのですが、全体として印象に残っているのは、「開発とQAが良い関係を築いているところが多い」ということです。
私のチームでも、開発とQAで協力して全員で品質をあげていけるようになりたいなと思いました。
改善のヒントになる話や気持ちが上がる話が聞けますので、皆さんもぜひ来年は視聴してみてください。
最後までよんでいただきありがとうございます。
