【内製開発Summit 2025】システムテスト活動を手の内化するためのテスト資産管理のススメ

大アジャイル時代で発生したテストの課題

株式会社ベリサーブに所属している朱峰と申します。

ベリサーブは40年以上にわたり、ソフトウェア開発全般での品質向上を支援している会社です。企業のテスト活動を支えるべくBtoBのテスト支援プロダクトも開発しており、私はプロダクトマネージャーとして、それらの全体戦略策定と個別製品開発に従事しています。

本日は下記のようなお品書きでお話しいたします。



まずは「アジャイル時代のテストの課題」についてお話します。

現代は“大アジャイル時代”であり、プロダクトは1回作って終わり、ではなく継続的にアップデートすることが主流となっています。また、プロダクトないしサービスが世に出てからユーザーが5,000万人に至るまでにかかる時間は、どんどん短くなっています。



例えば、飛行機や車のようなものが一般社会に浸透するまでには、60年ほどの時間がかかっていました。しかし、2016年にリリースされた「ポケモン GO」は、1ヵ月もかからずに5,000万ユーザーを達成しています。最近のものだと「ChatGPT」は2ヵ月で1億人を突破したといわれていますね。

プロダクトの成長スピードはどんどん早くなっていますし、いつ何時、競合が出てくるのかは分かりません。どれほどいいアイデアを持っていたとしても、世に出すまでに3年も5年もかかっていたら、開発が完了する頃にはより良いサービスが世に出ている可能性もあります。そうなると、自分たちのプロダクトの価値は、当初の想定よりも大きく下がってしまうかもしれません。

ではどうすれば良いのかというと、アジリティを上げるしかないと。小さくとも早く世に出して、短いスパンで変化に追随することで、価値はどんどん向上していきます。つまり、企業はアジリティを上げざるを得ない時代に突入している。アジャイル開発とは、不確実な時代においてITビジネスリスクを低減させるシステム開発のスタイルであり、その本質はビジネスそのものなのです。

そんな“大アジャイル時代で、必然的に発生するのが、継続的なテスト活動です。テストをせずにリリースするのも一つの方法かもしれませんが、あまりベストな選択とは言えません。

しかし、リリース頻度の増加に伴いテストの頻度も増えるとなると、テスト活動の負担はどんどん大きくなってしまいます。1回のテストにかけられるリードタイムもどんどん短くなっていきます。

「開発のサイズが小さくなっているのだから負担は変わらないのでは？」と思う方もいらっしゃるかもしれませんが、開発におけるテストとは、リグレッションテスト（回帰テスト）なのです。変化したところだけを確認するのではなく、変化していない部分にも影響がないかテストする必要があります。そのため、変更量に対して指数関数的にテストの量が増えていくわけです。

また、アジャイル開発ではドキュメントが減少する傾向にあります。ドキュメントがあれば、それをベースに網羅するというアプローチでテストケースの品質を担保できますが、アジャイル開発ではそれが難しいこともあります。



一方で「動くプロダクトに触れられる機会の増加」「動くプロダクトに触れられるタイミングが前倒しになっている」という変化については、捉え方によってはテストエンジニアにとって良い傾向だとも言えるのではないかと考えております。この点は、後半でお話します。

テスト課題へのアプローチ①「テスト資産管理の効率化」

テスト資産とは？

「テスト資産の効率化」の話に移る前に、テスト資産について定義させてください。



これは標準的なテストプロセスを図にしたものです。

テストをするには、テスト計画を立てる必要があります。次に、対象の範囲を定めるためにテストの分析をし、そこで立てた方針に従いコスパ良くパターンを抽出できるテストを設計します。その後、テストをするためのデータ準備や実装を経て、やっとテストが実行できるわけです。またテストは必ずと言ってもいいほど、遅れます。必ずバグが出てしまうため、途中でリプランニングする必要があるのです。複数の段階を経てテストを完了した後は、次の開発に向けての振り返りをして、やっと全ての工程が完了します。一口にテストと言っても、これだけたくさんの工程を必要とします。

この中で、テスト資産に当てはまるものとして最初に思い浮かぶのが、テストケースです。現場によって粒度は異なると思いますが、どのようなものであっても「何をテストするか」「なぜテストをするのか」といった情報を書き下したものは、間違いなく資産と言えます。

また繰り返しテストが発生する大アジャイル時代においては、テスト結果も資産として扱えるのではないでしょうか。例えば、機能A、機能B、機能Cとそれぞれに10回のテストがあったとします。機能Aはバグがたくさん出てしまったけれど、機能Cは1回もバグが出ず安定している。そうであれば、テストの工数を下げないといけない場合に「機能Cのテストを薄くすることでリスクを最小限に抑えられるだろう」といった判断ができます。要は、自分たちのテストの優先順位を決める、もしくはテストのアプローチを最適化する際には、過去に積み重ねてきたテスト結果が資産として活用できるのです。

テストケースだけではなく、テスト結果も含めて資産として扱うというのは、テストを最適化するのに非常に良いアプローチなのではないかと考えています。

なぜテスト資産管理に着目するのか？

続けて、なぜテスト資産管理に着目するのかについてもお話しします。

テストケースについては、テストの度に仕様が変わっていくのだから、その都度新しく作るのではなく、アップデートする形で管理するのが一般的だと思います。テストケースを管理する際は、Excelもしくはスプレッドシートが使われていることが多いでしょう。Excelであればファイルをコピーしてファイル名を「_v◯」とし、◯の数字を開発のバージョンに合わせるなどして、仕様とのトレーサビリティを確保した状態で管理することが求められます。

またテスト分析でテストを減らす判断をするのは、非常に負担が大きいことでもありますよね。テストリーダーからすると、自分がやらないと判断したテストによって何か擦り抜けてトラブルが発生してしまうかもしれないのは不安でしょう。とはいえ、テストは有限だからどこかで厚みを減らさないといけません。そういった場合でも、過去のテスト結果を適切に管理していれば、先ほど例に出したようにテストリーダーの判断材料を少しでも増やすことができます。そのためには、機能や観点ごとの相対的な比較ができるような形でテスト結果を管理する必要があります。



つまり、テストの負担を減らすためにはテスト資産を適切に管理する必要があり、そのためにはテスト資産を効率よく管理することが重要なポイントとなるのです。

テスト資産を効率よく管理するツール選びのポイント

ある程度の規模までであれば、テスト資産はExcelで管理できます。しかし、テストの結果をExcelで管理するのは難しい部分もありますし、どこかで限界が来てしまうでしょう。世の中には、それらの管理をより高度にするためのサービスとして、テスト管理ツールというものがあります。

一昔前までは、プロジェクト管理やタスク管理もWBSを書く、もしくはExcelで管理するということが多かったのですが、最近はJIRAやRedmineといったタスク管理機能を持ったツールを導入するケースが増えてきていますね。それと同じように、テスト管理についても専用のツールを使用するのが当たり前になっていくのではないかと考えています。



上図は現在提供されているテスト管理ツールの一部をまとめたものです。ちなみに、左側の一番上にある「QualityForward」は弊社が提供しているサービスです。これ以外にもさまざまなサービスが出ていますし、それぞれに使い勝手が異なりますので、ぜひお好みのものを選んでいただければと思います。

ツール選びをする際は、カタログスペックで比較するのはもちろん、プリセールスがしっかりしているところに絞って選ぶのもお勧めです。後はトライアルなどを利用して、しっかり試してみてください。

なお、テスト管理ツールのトライアルで大事なのは、下記の二点だと思います。

1. 1プロジェクト内での繰り返し
2. プロジェクトn回目以降での繰り返し

要は、いかに上手に繰り返せるか、というのがテスト管理ツールの肝だと言えます。先ほどもお話しした通り、テストは必ずどこかでバグが出てきます。Failしたテストの2回目以降、それでも通らなかったものの3回目、他に影響が出ることも考えるとPassしたテストのリグレッションテストも必要になってくるでしょう。それをいかに直感的に繰り返せるか、というのがポイントです。

またプロダクトはどんどん進化していきますので、2プロジェクト目、3プロジェクト目で、テストを使い回していくのも重要なポイントです。仕様が変わったところはメンテナンスしなくてはいけませんし、変化のない部分はそのまま流用します。毎回全ての範囲をテストするわけにはいきませんので、優先順位を付けて対応していかなくてはいけません。そういった判断する際に、直感的に触れられるツールを選んでいただくと良いのかなと思います。

テスト課題へのアプローチ②「全体最適なテストプロセス」

ここからは「全体最適なテストプロセス」と題して、標準的なテストプロセスに従う時代ではなくなってきているよね、というお話をしたいと思います。

先ほど、JSTQBのシラバスから拝借したテストプロセスの図をご紹介したと思います。あの図では、ドキュメントベースでテスト分析をして、その後パターンを設計して実装するという流れでした。しかし、最近の傾向として、そもそも仕様書などのドキュメントが陳腐化しているケースが多くなっています。



それにより、テストケースを作り直す、手戻りが発生してしまうリスクが増えています。

一方で、プロダクトに触れる機会は増えている時代でもあります。前半で「動くプロダクトに触れられる機会が増加しているのはテストエンジニアにとって良い傾向だ」とお話していた部分ですね。

プロダクトに触れられる機会が増えている今、ご提案したいのが「探索型」のテスト実行の導入＋自動化です。



まずは触ってみて、プロダクトへの理解を深めます。そこでテスト観点・テスト条件を学習して、次につなげていく。変化したところはアドホックテストで済ませて、次のスプリントのためにリグレッションテストは後で作る、といった大胆なことをしてもよいのではないでしょうか。

ドキュメントベースに固執せず、プロダクトを触るという体験を大事にした上でテストケースを作る、というのが大アジャイル時代に求められていることだと思います。

ちなみに「探索型のテスト」とは、JSTQBにて定義されている「探索的テスト」とは異なります。探索的テストとは、テスト担当者がテストアイテムや以前のテストの結果などを活用して動的にテストを設計、および実行する超絶テクニックのことを意味しています。これは熟練のテスターにしかできないテクニックであり、取得するのに3～5年ほどの修練を要します。

そこでお勧めなのが、探索型のテストというわけです。熟練のテスターがいないのであれば、みんなで知恵を出し合いましょうと。エンジニアやプロダクトオーナー、デザイナーなど、チームのみんなでプロダクトを触ってみる。PassやFailの概念を取っ払いつつ「ここがもっさりしたかも？」などの些細な「気になる」を逃さないように、テスト観点を育てていく。こんな活動がチームでできたら、よりアジリティの高いテスト活動の一助になるのではなかろうか、と考えております。

ツールを活用して、テスト活動を手の内化

前半でもお話しした通り、ITビジネスのリスクを下げるには、アジャイルを取り入れるしかない時代だと思っています。内製化は開発の上流からやってきますが、どこかのタイミングでテストの手の内化も迫られるでしょう。自動化は内製化の最たるものですが、プラスアルファで「テストケースをしっかりマネジメントする」「テスト結果をしっかり生かす」「チームみんなで探索型のテストをしてテスト観点を育てていく」という知識を持っていれば、皆様の一助になるのではないかと思っております。

最後にベリサーブのツールについても、少しご紹介させてください。

テストの課題について、本日お話ししたもの以外に「目の前のテストの状況をうまく可視化できていない」というものもあると思います。テストがどこまで進んでいるのか、バグが何件発生しているのか、優先順位はどうなのか、それらを把握できていない場合は、そこからメスを入れる必要があると思います。それに加えて、本日お話ししたテストの課題を解決できるのが、テスト管理ツール「QualityForward」です。



メンバーの誰かがWeb上でテストを実行すれば、それが即座にレポートに反映されます。進捗の遅れやレビュー依頼時にテスト結果の不備を通知する機能もあります。テストケースのバージョン管理や検索機能、タグ付け機能もあり、テストケース作成の効率化にも貢献します。

まだまだ課題を完璧に解決できるわけではありませんが「レポートを出す」「テストのバージョンや変化差分を可視化する」「自分たちのテストの弱み・強みを可視化する」といったことがしっかりできるツールを目指して開発しております。もしご興味のある方がいらっしゃいましたら、ぜひお問い合わせいただければと思います。

アーカイブ動画も公開中

https://findy-tools.io/events/85b9689fd7ccb74c327a