はじめに

良いテストケースを書くためにはテスト設計が必要であることは、2021年となった現在では多くの人が認知しているようになりました。私は2003年頃から多くの現場でテスト設計をコンサルティングしていました。その後、テストマネージャーをやったり、現在はQAエンジニアをしていたりしますが、テスト設計がうまくできていないことによって大事なテストが抜けてしまったり、無駄に多いテストをひたすらこなしていると言った現場があることは今も昔も変わりません。

これは、テストの経験が浅い人たちだけの話ではありません。それなりに経験を積んでいるテスト技術者が多くいる組織でさえ、テスト設計がうまくいっていないケースがあります。そのような現場の方たちは経験は豊かなので、どこに欠陥が潜んでいるかを探り出す感覚はしっかりしたものを持っています。しかし、各自が自分のやり方を貫いてると、複数の技術者でテスト設計していったときにお互いの作ったテストの内容を確認しあうことが難しくなります。そして、各人のテストを合わせて全体を見渡した時に必要なテストが全部揃っているか、無駄な重複していないかといったことがわからなくなっていきます。

そのような状況は、ちょっとの手間と工夫を惜しまなければ解決できるものです。

このちょっとの手間と工夫を手法にしたものがゆもつよメソッドです。ゆもつよメソッドについては、「ソフトウェアテストの上流設計」という記事を、ソフトウェアテストPress Vol.10（技術評論社）の特集で執筆したのが2010年でした。それから10年以上たった今でも、基本的な考え方は変わっていません。ただし、その頃のコンサルティングの経験だけでなく、さまざまな現場で経験を積む中で、現場に適用するポイントとしてわかったことが多々あります。また、2013年から2018年までの間に大学院に通い行ったテスト設計の研究により、考え方をアップデートしたところもあります。

このnoteでは、「ソフトウェアテストの上流設計」の記事をベースにしながらも、それらの経験も踏まえてアップデートしたことも加味した内容でゆもつよメソッドについて書いていきたいと思います。

テストが注目される背景

まず、（これは2010年に書いた話ですが）テストが注目される背景としてはどういうことがあるのか再考するところから始めて見たいと思います。背景は、大きく言えば2つに分けて考えることができます。

ひとつは、「ソフトウェアの大規模化や複雑化に伴うテスト量の増大」であり、もうひとつは、「開発期間の短縮化によるテスト工数不足」です。

これらの背景によって、どのような問題がもたらされるのでしょうか。

ソフトウェアの大規模化や複雑化に伴うテスト量の増大
テスト量の増大による影響としては、テスト期間が長くなりすぎるために、適切なタイミングで製品を市場に送り出すための大きな障壁になっていることが考えられます。開発コストにかかるテストの割合が多くなりすぎてしまうという問題も同時に考えられます。

開発期間の短縮化によるテスト工数不足
もうひとつの背景であるテスト工数不足では、結果として充分に品質の確認ができないまま製品をリリースせざるを得ないという事態が考えられます。こうなると市場でトラブルが発生するかもしれないというリスクを抱えてしまいます。仮に市場クレームとなり、トラブル対応により手戻り作業が発生してしまうと、今度は次の製品の開発ライフサイクルにさえ悪影響が出てしまいます。このため、開発ライフサイクルを繰り返すごとに、前の出荷と比べて更にテストが充分に行えなくなってしまう可能性でてしまいます。

こういった現実を乗り越えるためにも、テストを効率よく実施することと、品質を確保することがソフトウェア開発の現場では大きな課題となります。

直面している問題の原因

テストを効率よく実施したうえで、品質を確保しなければならないという課題があることは説明せずともこのnoteを読んでる皆さんは分かっていることかもしれません。その課題に向き合うために、何かしら行動を起こすべきなのですが、そのためには、まずはなんでこうなるのかを理解しないといけません。原因としては大きく四つに分類出来ると思います。

以下、原因として考えられる問題をひとつづつ見てみたいと思います。

システム/ソフトウェア構造の問題

まず最初に、テスト対象となるシステム/ソフトウェアそのものがテスト困難な【作り】になっていることが原因として考えられます。例えば、IF文の入れ子が何階層にも及ぶ複雑なソースコードや、データを保存している領域にアクセスする方法が数百あるようなモジュールなどの事を指します。複雑であるということは、テストケースの数がそれだけ増えるということです。

また、アーキテクチャーの責務に一貫性がない場合もテストが難しくなります。例えば、排他制御のロジックをフロントとサーバーサイドのどちらで実装するかが曖昧になってしまっていて、フロントの変更でどこまでテストするのかが決めきれないと言った場合もテストが増えてしまいます。

いまどきはこういうのを技術的負債と呼んだりします。これらは、技術的負債によりテストしやすさが損なわれているために起こる問題です。 

 仕様の考慮漏れに関する問題

別の原因として、要件や仕様がドキュメントに十分に記述されていないことが考えられます。よくあるドキュメントの傾向として、正しいことしか書かれていなく、正しくないときはどうなるかということや、その処理がどの処理へ影響するかといったことがわからないといったことがあります。また、性能や信頼性などの非機能要件がドキュメントに一切かかれていないケースや、書かれていたとしても非機能要件の定義が定量的でなかったり、その実現方法が明記されていないためにどこをテストすべきかが分からないと言ったこともよくあります。

システム／ソフトウェアはバージョンアップし続けているのに仕様書などのドキュメント類はそれに合わせてバージョンアップされないため、記述内容と実際の動作がちがうということが起きているケースもあります。こうなると、テストケースを設計するときに拠り所になるものが無くなってしまうので、テスト設計の効率が非常に悪くなります。
これらは、システム／ソフトウェア開発に沢山の人が関与することを考えていなく、そこにいる人だけがわかっていれば良いという、目先の効率だけを重視しているために起こる問題です。

ここまでは2010年の執筆時に書いたことですが、今では私の考え方も少し変わってきました。

ドキュメントに書くというのが、「完璧な仕様書を作ってないとテストができない」となるとちょっと話が変わります。仕様を決めてない／言語化してないために実は曖昧だというのが本質的な問題です。また、今どきの開発は特にトライアル＆エラーしながら仕様を決めていくこともあるので、完璧な仕様書ありきのテストは現実的ではないです。タスクチケットやテストケースで仕様がわかるようになっていれば大丈夫ですし、テスト結果を元に仕様を明確にしていくというのもありだと思います。

 開発プロセスの問題

いまどきの開発プロセス（ex.反復型、派生開発、プロダクトライン、サービスの利用）では開発量は減ってもテスト量は（単純には）減らせません。なぜなら、最終的にシステム／ソフトウェアをユーザが使う時に既存の部分が問題ないことは結局テストしないと確認できないからです。そうなると、ほとんど不具合 は起きないだろうと思われる場合でも、過去に行ったものと同じテストを何度も行わなければならなくなります。

これは、ある程度仕方が無いことですが、テストは単純には減らないということを認識したうえでどうテストを進めていくかを計画することで解決策は見いだせてきます。例えば、単純になんども同じテストを繰り返さずに、もっとも効果的なタイミングを考えて日程を組むことや、リグレッションテストの自動化などが考えられるでしょう。

 テストケースの問題

テストをする際に、「とにかく全部テストしろ」と言われたことはありませんか？品質が大事であることはみんな分かっているのですが、とにかく全部といってもできるわけありません。全数テストができないということはあらゆる書籍でかかれています。2021年になった今でもこの傾向は変わらないため、自分のnoteでも「ちゃんと網羅して！って頼まれた時の返答方法あれこれ」っていうのを最近書きました。

 
全数テストは無理だと言うことはわかっていても、品質が心配だと言うことで、システムテストなのに単体・統合テストで行うことと同じようなテストを沢山やろうとするためにテスト量が膨大になってしまっている状況は良く見かけます。また、テストケースを作る時間を節約したいがあまり、思いついた条件を吟味せず全部組み合わせてテストケースとしていたり、組み合わせる値の同値分割が無意味に細かいテストケースを機械的に作っていったりしている状況も見かけることがあります。そのようなテストケースは意図が不明瞭であるため、後で見直すとなぜそのテストをするのかがわからなくなります。ただし、いままでやっていたテストであるからやっておかないと不安だと思うあまり、意味はわからずともとりあえずテストは続けてしまいます。それによって、疲弊するほど沢山テストしているのに大事なところをテストし忘れるといった問題が起きる可能性があります。

テスト技術で解決できることはテストケースの問題

テストの現場では、これらの問題がからみ合って、非効率的な状況を作り出し、テストを困難にしています。

あるべき姿としては全ての問題が解決された世界を作り上げることかも知れませんが、何もかも一度に解決すると言うのはなかなか難しいものです。まずテストをする人たちが最も先に手を付けるべきことは、自分たちのスキルをあげることで解決出来る問題だと思います。四つの問題で言えば、それはテストケースの問題になります。

テストの全体像 

テストの全体像を考えたとき、そこにはどういうプロセスがあると考えられるでしょうか？

まず、システム／ソフトウェアを実際に動かしてみる、いわばテスト実行が真っ先に思いつくと思います。なぜならテストを実施するさいにテスト実行は誰でも必ず行っているからです。では、テスト実行の前にはどのようなプロセスがあると考えますか？これはいろいろな意見があるのではないでしょうか？「テスト準備」と一括りにする人、「テストケース作成」という人、「テスト計画」と「テスト設計」という人など、いろいろなくくりで説明ができるからです。

テストは、開発プロセスと同じように、最初から用意周到に計画、設計をしていくことが成功の秘訣です。開発プロセスの最終工程で行っていることはテストプロセスで言えば「テスト実行」にすぎません。テストを実行としてしか捉えていないと、テスト実施以外の活動を「準備」としか考えられなくなります。用意周到にすることで効率的にテストを行うためには、「準備」と一括りにするのではなく、テスト実行の前に何をやるべきかを理解した上で行動出来ることが重要です。準備では、目的を明らかにし、具体的にしていき、テスト実行がうまくできるように仕掛けを入れ込んでいきます。具体的にはどのようなことをするべきかを以下に示します。

このテストの全体像の中で、特にテストケースを作るためのアクティビティはテスト計画の一部からテスト実装までの中で行われます。これがこの記事のターゲットです。

次回は、テストケースを作るためのアクティビティの概要を説明します。

おまけ　この連載はどこまでやるか？

2010年にこの内容を最初に雑誌に掲載したときは、その流れで本を書こうと思ってました。しかし、直後に転職をして仕事の内容が変わってしまったために継続して書いていくパワーが失せてしまい、実現できませんでした。

これをリライトしようと思ったのはJaSST東北2021でのゆもつよメソッドワークショップを盛り上げようと思ったのがきっかけです。流行り廃りのファッション雑誌のような内容でもないので、今でも有用なことが書いてあるとは思いますが、それでも10年以上前の内容でもあるので補足が必要ですし、そのままテストPressに書いたことを載せるのはなんか違うので、いろいろアップデートして載せようと思いました。そして、この際、Twitterなどでよく聞かれることも書ける範囲で書いてこうと思いました。ただ、まだ構想中であることとか、事例が足りなくて本当にそうなのか自分でも自信がないことも多くあります。そう言うことも含めて書いていくためには、継続性が必要です。

継続してくためには、さらっと読むのではなく、ちゃんと読んでもらい、フィードバックがもらいたいと思いました。お金を払ってでも真剣に読んでくださる方がいたほうがこちらも気合いが入ります。なので、この連載はJaSST東北が終わったらnoteのマガジンにまとめて有料マガジンにします。

2021年6月26日追記：有料マガジンにすでにしています。noteの仕様で、単品購入してもらえれば有料マガジンを購入しなくても読めますが、マガジンで購入してもらった方がお得になるようになっています。今後も不定期に記事を追加していく予定です。今考えているのはテストケースの設計まで書いた後に、これまで使っていた「飛行機予約システム」の仕様を題材にした具体例の掲載です。お楽しみしてください。

この内容が面白かった！今後の内容も期待しちゃうよ！という方は、購入お願いします！