なぜテストは「やり方」を学ぶだけではうまくいかないのか
～品質保証を体系として理解する必要性を解説～

受講者に渡されたテストケースには、商品の数量を1個から100個へ変更し、合計金額が正しく更新されることを確認する、と書かれていました。受講者が手順の通りに操作すると、最終的な合計金額は仕様書どおりになりました。ただし、合計金額の周辺で、レイアウトがわずかに崩れていました。受講者は少し気になったものの、期待値である「100個分の合計金額が表示される」ことは満たしているため、テスト結果を「OK」とし、そのまま次の項目へ進みました。
この受講者は手順を忘れていたわけでも画面を注意深く見ていなかったわけでもないようでした。演習振り返りの際にその場面を取り上げたところ、「レイアウトの崩れ自体はたしかにありました。ただ、期待値である金額は表示されていたので、テストとしては問題ないと判断したため、報告しませんでした」という答えが返ってきました。

この判断自体は、テストケースの合否判定としては間違いではありません。問題は、合否判定とは別に発見した違和感をどう扱うべきかについて、十分に理解されていないことにあります。
大事なのは、その違和感がすぐに報告されることです。報告さえ上がれば、テスト全体を設計・依頼している側が、状況に応じて次の一手を選べます。たとえば「表示が崩れている以上、金額の確認より先に表示の不具合を直すべきだ」と判断できる。逆に報告されなければ、その判断の機会そのものが失われ、崩れに気づかないまま先へ進んでしまいます。合否判定はできても、判定とは別で気づいたことを共有するかどうかで、品質保証の成果は大きく変わるのです。

この例から、個別のテスト技法や作業手順を伝えただけでは、品質保証という営みの一部しか捉えられないということがわかります。では品質保証全体はどのようにすれば捉えられるのでしょうか。
この記事では、品質保証全体を、簡単な4つの問いから捉え直します。手順を教えたはずなのに、なぜ現場では判断できないことがあるのか。個人の注意力や習熟度に見える問題を、組織の仕組みとしてどう捉え直せるのかを考えていきます。

品質保証という営みは、4つの問いでとらえると理解しやすくなります。

品質保証がなぜ必要で、何を目指すのかという原理・原則を理解することです。ここを飛ばして手順だけを学んでしまうと、その手順が通用する範囲でしか動けない人になります。研修では、あえてマニュアルにない状況を演習に混ぜることがあります。原則を理解している受講者はその場で応用の判断ができる一方、手順の理解のみにとどまる受講者は、そこで手が止まります。

 ISTQB/JSTQBでは「早期テスト」や「欠陥の偏在」などのテスト原則が整理されているのも、この考え方と重なります。これらは状況が変わっても通用する判断軸として整理されている点に価値があります。もちろん、原理・原則から教えれば必ず応用が利くようになる、というほど単純ではありません。これらはあくまでも抽象的なものであり、この後に出てくる具体的な作業を通じて理解が深まるものです。

原則を理解したうえで、具体的なテスト戦略やテスト設計に落とし込み、実行後に何を確認するのかを決めます。何を、どの順番で、どこまで確認するかを決める作業であり、ここが曖昧なままだと、後工程でどれだけ丁寧に確認しても抜け漏れが発生することになります。
例えば、テスト設計を書いてもらうときに「何をどこまで書けば十分なのか」がわからず手が止まることがあります。この原因は単なるテスト設計者の技術不足だけではなく、何のためにその設計を書くのかという目的が定まっていないことも多いです。
プロセスを整備し、事前にドキュメント化しておけば、都度プロセスを設計する負担は減ります。一例として、ソフトウェアテストの国際的な規格ISO/IEC/IEEE 29119では、どのようなテストプロセスが必要かを定義しています。

設計されたプロセスを、実際に手を動かして確認していく段階です。品質保証を行う人が最初に担うのはこの部分であることが多いですが、ここだけを切り出して学んでしまうと、単に言われたことを言われたままに行う人になってしまいます。もちろん、言われたことを言われたままに実行すること自体は簡単ではありませんが、それだけでは品質保証を本質的に理解しているとは言えません。

品質保証を、特定の担当者ではなく組織の習慣にしていく段階です。品質保証について理解を深めるほどに、この問いが難しいことに気づくこともあります。習慣は原則やプロセスと違って、目に見える成果物として残らないためです。マニュアルは作れても、習慣になっているかどうかは、担当者が異動したり退職したりしたときに初めてわかります。
実際、報告基準を明文化していたつもりのチームでも、基準を最初に作った担当者が異動した途端、新しく入った人には基準の存在自体が伝わっておらず、また同じ迷いが再発したという場面を何度も見てきました。基準を作った時点がゴールではありません。担当者が入れ替わっても同じように伝わる状態を作れたときにはじめてこの問いに答えたことになります。

冒頭の場面をもう一度見てみます。受講者は「どう実行するのか」はできていました。仕様書との照合はできていたし、違和感にも気づいていたのです。ただ、「なぜ行うのか」——違和感を報告することが品質保証にとってなぜ重要なのか、という理解が曖昧だったために、判断の手前で止まっていました。これが一度きりの出来事なら、個人の問題として片づけられます。しかし同じ迷いが複数の受講者から出てくるならば、それは「どう継承するのか」の設計不足です。

4つの問いは独立したものではありません。ひとつの問いへの答えが欠けていると、それは別の問いの不具合として表面化します。違和感に気づけないことと、気づいたことを報告する必要がないと考えたことは別の問題なのです。
この場面では「なぜ行うのか」の理解が十分でないことから「どう実行するのか」の不具合として現れましたが、他のケースも考えられます。例えばプロセス設計が細かすぎると、決められた確認項目をこなすことが目的化し、想定外の不具合に気づく余地そのものが失われます。どの問いが原因かを見誤ると、対策は的外れになります。

世の中には、品質保証に関わる標準や知識体系がいくつも存在します。SQuBOKはソフトウェア品質に関する知識を体系立てて整理した知識体系です。ISO9001は品質マネジメントシステムを構築・運用・改善するための要求事項を定める規格で、組織の状況把握から計画、運用、評価、改善までの一連の仕組みを整理しています。ISTQB/JSTQBは主にソフトウェアテストの知識・技能を扱う資格制度で、同値分割やデシジョンテーブルといった具体的な技法を標準化しています。

性格はそれぞれ違いますが、いずれも、何を確認すべきかや何を満たすべきかという共通言語を与えてくれる点では共通しています。ただし、共通言語を知っていることと、自社の現場でその通りに判断できることの間には大きな壁があります。業界標準や知識体系は、業界としての一般化された型を示してくれるありがたい存在ですが、一方で目の前の案件事情までをくみ取ってくれるわけではなく、「自社には合っていないかもしれない」と感じてしまうこともあるでしょう。

SHIFTでは、この4つの問いのうち「なぜ行うのか」「どうプロセスを設計するのか」を、SQF(SHIFT Quality Framework)という独自の標準が担っています。SQFは、世界的な品質保証標準と、SHIFTが積み重ねてきた支援経験から得たナレッジを組み合わせた独自標準で、テスト計画から実行・報告までのプロセスや手順、ドキュメントのひな型を定義しています。さらに、豊富なテスト知見を凝縮した標準テスト観点を用いることで、不具合の起こりやすい重点箇所を把握し、ソフトウェアテストを実施できる仕組みが整えられています。これらは現場からのフィードバックを継続的に取り込みながら更新されています。

「どう実行するのか」「どう継承するのか」については、入社時に職種を問わず全員が合同で受ける導入研修「トレセン」、SHIFT社内のキャリアアップ制度「トップガン」、そして日々のテスト実行・報告を同じ形式で残すテスト管理ツール「CAT」という3つの仕組みで支えています。
導入研修「トレセン」は、現場に出る前に判断の土台を揃える場であり、「トップガン」は、学びを実務でどこまで使えるようになったかを本人と組織の双方が確認する場になります。そして「CAT」は、担当者が変わっても同じ形式で記録と判断の跡が残る仕組みとして働きます。この3つの仕組みの前提にはSQFがあります。SQFはSHIFTが提供する品質保証の土台であり、より高品質な品質保証サービスを提供することを可能にする独自標準なのです。

SQFを通じて品質保証を体系化してきたからこそ、一部プロセスでAI活用をするという選択肢も生まれます。

SHIFTがSQFで抑えてきたのは、人によって判断がばらつくことでした。AIを活用してテスト設計を行う場合も、同じ仕様書を渡したからといって、常に同じ観点が返ってくるわけではありません。人であれAIであれ、向き合う問題は変わりません。ばらつきをどう抑えるかであり、そのためには整備された基準が必要になります。基準を持たないままAIを使った場合、もともとあったばらつきがそのまま増幅されるだけです
SQFと現場のテストエンジニアが積み上げてきた知見をAIが扱える形にしたのが、SHIFTのAIテストエージェント「ネムラナイ」です。過去のノウハウを活用したことで、SHIFTエンジニアがテスト設計やテスト実行をより短期間で効率的に実施できるようにしています。

冒頭の受講者は、その後の研修で、同じような違和感に気づいたときに迷わず報告欄に書き込むようになりました。変化が起きた理由は、品質保証というものへの理解が増したためです。本人にその後の様子を聞くと、「最初は目の前の作業をこなす、という理解でしたが、品質保証とは何かという理解を深めると、おのずとやるべきことがわかるようになった」と話していました。

自社の品質保証をさらに改善したいとお考えであれば、4つの問いのどこが手薄になっているかを考えてみるとよいかもしれません。原理・原則が浸透していないのか、プロセス設計が曖昧なのか、実行段階での判断基準が足りないのか、それとも継承の仕組みが手薄なのか。手薄な問いを特定できれば、それを改善することで組織として提供する品質保証の精度が上がります。
そして、この4つの問いは一度整理して終わりではありません。SQFが現場からのフィードバックを取り込みながら更新され続けているように、体系は変化を取り込み続けることで、はじめて活用され続けます。標準を学ぶことも、自社の体系を整えることも、どちらも一度作ったら安心していいものではないのです。
仕組みが不十分ではないのかを疑うこと、その仕組みを一度改善したら終わりではなく、改善し続けること。これが、品質保証を体系として理解するということの、実務的な意味なのです。