システムにおける「テスト」とは何かを改めて考える

はじめに

ソフトウェア開発において、「テスト」とは何か。

コードを書いていると、つい「とりあえず動いたし、テストもしたし、もう大丈夫かな」と思ってしまいがちです。また、最近は自動テストツールも大変に充実しており、開発者自らが手を動かして検証するという場面は減少してきていると思います。

一方で、テストをどのように設計するべきかについて語ったり、チーム開発においてテストに対する認識を合わせたりする機会も同じように減ってきているという印象があります。

でも、それで本当に十分テストしていると言えるのでしょうか。

あらためまして、私は「入居者管理くん」と「内装工事くん」というプロダクトでエンジニアリングマネージャーをしている、 兼田（かねだ）と申します。

先日社内のLT会でテストに対する考え方の話を共有する機会があったのですが、その時整理した考え方をもう少し深掘りしてアウトプットしておきたいなと思ったので、今回は、システム開発における「テスト」とは何かを改めて整理してみたいと思います。

開発者はテストが下手である

最初にお伝えしたいのは、開発者はテストが下手であるということです。

これはスキルや経験の話ではなく、認知バイアスの問題です。

バイアスというのは恐ろしいもので、自分の作ったものを正しい(バグがない、など)と信じ込んでしまい「テストをしたつもり」になったり「ここはテストをしなくても大丈夫」と無意識に思い込んでしまうことがあります。

まずは、自分はバイアスにかかっているということを認識することが大切です。

バイアスとは？

こちらの記事によると、バイアスには認知バイアスと確証バイアスというものがあるということです。

• 認知バイアス

認識が偏ることを意味し、自身の経験、先入観、固定概念、思い込みなどにより合理的な思考ができない心理現象を意味します。

• 確証バイアス

自身の信じる事や願いについて裏付けとなる情報を重視し、一方で反する情報については軽視し排除する心理的状態を言います。

確証バイアスは、認知バイアスのひとつです。

他にもバイアスといってもいろんな種類のバイアスがあるようですが、 「認知バイアス」というと一般に広義のバイアスを指すことが多いようですね。

認知バイアスの恐ろしさ

こちらの記事は、ある情報システム開発プロジェクトの裁判における証人尋問の一場面を引用したものですが、「開発者は自分の作ったものを正しいと信じ込んでしまう」ということ、そしてその恐ろしさがよく表現されています。

開発者は、自分で設計し、コードを書き、思い描いた動作を「その通りに」実現しようとします。その結果、テストにおいても「こうすれば動くはずだ」という視点で確認してしまいがちです。

つまり、失敗する可能性のある操作や例外的な状況を見落としやすくなるのです。

これは責められるべきことではありません。人間の認知の仕組み上、むしろ自然なことです。

バイアスを取り払うには？

ではバイアスに立ち向かう方法はないのでしょうか？

いくつか取れ得る対策を紹介します。

六色ハット思考法

思考の手法の一つに「水平思考」というものがありその中に 六色ハット思考法という思考法があります。

これは思考を6つの視点に分けて考える手法なのですが、私は自分の作ったものを共有する前に「黒色の帽子をかぶって改めて見てみよう」と疑って確認・修正した上で共有するように心がけています。

一晩置いてみる

社内のLT会で意見交換した際に出た方法ですが自分の作ったPull Requestを一晩置いて翌朝まっさらな頭で見てみる、といった原始的な方法も有効ではないかという意見が上がりました。

自分の作ったものを一晩置いてから見ることでバイアスが薄れ、客観的に見ることができるかもしれません。いずれにしろ自分の作ったものをいろんな視点で客観的に見ることが大切ですね。

AIに協力を仰ぐ

つい先日正式リリースされたGitHub Copilotコードレビューに代表される、AIによるフィードバックも客観的な意見をもらうための有効な手段となり得ます。

こちらは、とある機能開発時にGitHub Copilotにレビューを依頼した結果です。ツールチップに表示しようとしている説明文が正しいかどうかをGithub Copilotレビューが指摘してくれました。

画面表示する文言が正しいかどうかはユーザー体験に直結するものの、タイポがないかの確認なども含めるとテスト観点がいくつかあることが多いです。

こういったフィードバックがあると「この文言でわかるはずだ」といった潜在しているバイアスを取り除いてくれます。

誰がやっても同じ結果が得られるテスト

ようやくここから今回の本題「テスト」に入ります。

ここまでの整理で、誰でもバイアスにかかって本来行うべき検証が行われないことがある、ということがよくわかったと思います。

テストは、開発者のバイアスを取り払って必要な検証を行い品質の高いプロダクトを提供することで利用価値を顧客に届けるための手段です。 そのため、「理想的なテストとは何か？」を整理することはシステム開発をスムーズに進める上で非常に重要になってきます。

私の考える理想的なテストとは、誰が実行しても同じ手順で同じ結果が得られるものです。

極端な話、たまたま通りかかった見知らぬ人にやってもらっても、開発者が実行しても、システムによる自動テストであっても、同じ操作で同じ結果になることが望ましいです。

つまり、前提知識がなくても、手順通りに操作すれば正しい結果が得られるということ、これが担保できて初めて、そのテストには曖昧さがなく「再現性」と「客観性」を持っていると言えます。

逆に、暗黙の前提や開発者の感覚に依存したテストは、人によって結果が変わる可能性があり、品質の保証という意味ではとても不安定です。

具体的なテストの設計

では曖昧なテストとはどういうものか、具体的なテストケースで考えてみましょう。(テストケースフォーマットは私のチームで実際に使用しているフォーマットで表現しています)

前提条件

• とあるサービスの顧客一覧画面に、顧客ステータスの絞り込み検索機能をリリースした
• 顧客ステータスは「未契約」「契約中」「解約済み」の3つ
• 顧客ステータスは同時に複数選択して顧客を絞り込むことができる
• 顧客ステータスを一つも選択せず検索して全ての顧客を表示することもできる

曖昧なテストケースの例

No	大項目	小項目	操作	期待動作	結果	備考
1	顧客一覧画面	顧客ステータスでの検索機能	ステータスをいずれか一つ選択して検索	正しい顧客が表示される	○
2	顧客一覧画面	顧客ステータスでの検索機能	複数ステータスを選択して検索	顧客が正しく絞り込まれる	○
3	顧客一覧画面	検索機能の退行テスト(デグレードテスト)	ステータスを何も選択せずに検索	全顧客が表示される	○

問題点

• 「どのステータスを選んだか」が記載されていない
• 期待動作が曖昧（何をもって「正しい」表示か？）
• 結果の確認が主観的になる（人によって判断がブレる）

明確に改善されたテストケースの例

No	大項目	小項目	操作	期待動作	結果	備考
1	顧客一覧画面	顧客ステータスでの検索機能	ステータス「未契約」を選択して検索ボタンを押下	ステータス「未契約」の顧客のみが表示される	○	田中一郎のみ
2	顧客一覧画面	顧客ステータスでの検索機能	ステータス「契約中」「解約済み」を選択して検索ボタンを押下	ステータスが「契約中」「解約済み」の顧客のみが表示される	○	佐藤花子、鈴木次郎
3	顧客一覧画面	検索機能の退行テスト(デグレードテスト)	ステータスを選択せずに検索ボタンを押下	全ての顧客（未契約、契約中、解約済み）が表示される	○	全3件が表示される

改善点

• 選択するステータスが明記されている
• 表示される顧客の条件や名前が具体的に書かれている
• 結果の正当性を誰でも確認できる（再現性と客観性あり）

テストケースの積み上げではなく「保証内容」から出発する

「テスト」と聞くと、つい機能ごとに「この入力でこの出力が得られる」といったテストケースを積み上げていくイメージを持ちがちです。ですが、このアプローチでは、「個々の機能は正しく動いているのに、業務全体としてはうまくいかない」という状態が起きてしまうことがあります。

弊社は企業にシステムを提供するBtoBのサービスを多く展開しているためBtoBのプロダクトを前提とした場合、「この業務シナリオを保証する必要がある」という保証内容を定義することが非常に重要です。

大切なのは、本当に保証すべきなのは機能ではなく業務そのものだという視点です。

まずは「ユーザーがどのような順番で操作し、どの情報を入力し、どのような結果を得たいか」というシナリオを定義します。そのうえで、「そのシナリオが成立するために必要な条件」を逆算し、必要なテストケースにブレークダウンすることで抜け漏れをなくすことができます(下図上段のブレークダウン型テストを目指す)。

※「どのように業務シナリオを構築するべきか」というトピックに関しては奥が深いので、またどこかで別の記事を書こうと思います！

おわりに

テストは、単にバグを見つけるためのものではありません。どんな状況でも、誰が使っても、期待される業務が正しく遂行できる、その信頼性を保証するための行為です。

だからこそ、テストは「使う人の視点」「業務の流れ」という現場起点で設計し、誰がやっても同じ結果になるような仕組みにしていく必要があります。

今後のみなさまのテストライフにこの記事が役立てば幸いです！！