品質保証の"お作法" 〜テストプロセス解体新書〜

「語り得ぬものについては、沈黙せねばならない」

Ludwig Josef Johann Wittgenstein：論理哲学論考 より

はじめに

どうも！
ユニファ株式会社でQA（品質保証）エンジニアをしています、高田です！

最近、Kindle Unlimitedに入会して本を読んでまして。

そのなかで、「QA・テストがモヤモヤしたら読むITスタートアップのためのQAの考え方 （内製化失敗編）*1いうのを読みまして。

読み終えて、私の頭の中を去来する色々な何もかもをすっ飛ばして、一つ感想を申し上げますと。
「……それな〜っ！！！」と（笑）

これ以上言うと、本稿の筋から外れてしまいますので、これくらいにしておきます！

さて、今回は前回の投稿*2から打って変わって、技術ブログらしく「品質保証の活動」について書きたいと思います。

品質保証の活動には、系統だった知識体系や技法、そして人間の心理からくる「品質の形」というものが存在します。

今回は、それについて書いていこうと思います。

とはいえ、テスト技法とかテスト設計の組み方といったものをガッツリ解説するものではなく、「品質保証活動の全体像」を高田なりに解説する回になります。

いきなり、「テスト技法は〜」とか「テスト設計において〜」とか、理路整然とあるべき論を述べるより、「そもそも、QA活動（品質保証の活動）って何するの？」という根本的な問いについて、品質保証の外観を眺めながら解説します！

詳細な技法や設計の組み方などは、後の投稿で解説していく予定です！（そう、できればいいなぁ…）

---

おことわり

卒爾ながら生意気にも、最初に申し上げたいことが一つあります。

それは、「品質を担保する = テスト実行（testing）だけして、Passしたら担保される」という考えは間違っているということです。

これは、「検査重点主義」*3 という考えがバイアスとして根付いているために起こっている、「勘違い、思い込みからくる誤り」であると、高田は考えます。

と同時に、このバイアスというものは厄介なことに「人間が持っている、潜在的な不具合（バグ）」です。

代表的なものでいうと、

• 利用可能性ヒューリスティック
• 代表性ヒューリスティック
• 認知バイアス
• 確証バイアス
• 遅延割引
• 損失回避
• 錯視 etc......　
  
  

と、色々とあります。

要は、「バイアスは、完全に取り除くことが不可能である」ということです。

もし、この投稿をお読みになられている方で「品質を担保する = テスト実行（testing）だけして、Passしたら担保される」と考えている、もしくは考えていたのでしたら、この投稿によって、"そのバイアスから、解放する手立てになってくれる"ことを、切に願っています。

バイアスを完全に取り去ることは無理でも、「見方を変えること」によって、そのバイアスによる影響を最小限に抑えることは、可能であると信じています。

そのために、本投稿「品質保証の"お作法"　〜テストプロセス解体新書〜」を掲載するに至りました。

前フリが長々となりましたが、最後までお読みいただけたら幸甚です。

では、本編です。

---

（再掲）品質を語るには、「◯◯◯」が大事である

前回の投稿「ユニファと共に進む、品質保証の旅　〜ユニファQAの姿を考察してみた〜」にて言及した内容を、再度掲載します。
それは、

です。

「品質」というものは「目に見えないもの」です。

それは実体を伴わず、「誰かにとっての価値」*4という主観的な基準によって存在するもの。

そして、その「実体のない、誰かにとっての価値をエンジニアリングする」のが、QAエンジニアの役割。

もとい、「"品質"という抽象的な概念から生じる問題や課題に対して正対し、命題である"誰かにとっての価値"を一つ一つ証明し、具体化しながら語るストーリーテラー」がQAエンジニアである。

と、高田は考えます。

仰々しく申しましたが、つまりは「品質を語るストーリーテラーが、QAエンジニアの役目である」ということを言いたいのです。

そして、それらを語る上で必要なのが、以下のElement（要素）です。

これらの要素を組み合わせて、品質のContext（文脈）を紡ぎ、清濁併せ呑む形で（良いも悪いも関係なく）品質を語っていきます。

「〜のテスト、Passしました！」という報告だけでなく、

• 「この案件は、◯◯◯をテストスコープとして定義します」とか、
  
• 「△△のテスト観点は、★★★の技法を用いて〜〜〜のように仕様を整理し、□□というパターンを導出しました」とか、
  
• 「〜〜〜のテストを実行したところ、△△という条件下で不具合が発生し、代替となる手順が存在せずシステムの影響が多大なため、最優先に修正する必要があると考えます」
  
  

といったことも、各ステークホルダーに報連相していきます。

では、「品質のContext（文脈）を紡ぎ、清濁併せ呑む形で（良いも悪いも関係なく）品質を語るためには、何をするのか？」

ここで出てくるのが、「テストプロセス」です。

テストプロセスって何？

もう、ここまでお読みになられたのでしたら、大体お察しになられているかもしれませんが、敢えて言います。

テストプロセスとは、

を、言います。

上記の作業の流れは、ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02をベースに、ユニファQA内や開発定例のLTで話した内容です。

では、順を追って各プロセスを外観しながら、高田なりに解説していこうと思います。

テスト計画って？

最初のプロセスは、「テスト計画」になります。

シラバスを見てみるとテスト計画とは、「テスト目的を定義することと、その後に全体のコンテキストにより課せられた制約下において目的を最も効果的に達成するアプローチを選択することから構成される。」*5とあります。

要は、

を、言います。

その方向性は、以下の内容を定義して「品質保証活動のアウトライン」を決定します。

感覚でいうと、「彫刻」や「絵画」で彫ったり描いたりする際の「あたりをつける」といったところでしょうか。

更に、5W1Hでいうところの

を主に定義していくものになります。*6

では、どのように「あたりをつける」のか。具体的に、以下に掲載します。

1. テストマイルストーン：計画、分析・設計、実装、実行、完了までの作業のだいだいのスケジュール（規模）感を導出。

   • これにより、おおよその品質保証活動の工数を算出します。

2. テスト方針（戦略ベース）：「テストタイプ」や「テストレベル」、範囲・目的・環境（テスト環境）・技法の有無・ステークホルダー一覧を導出。

   • テスト戦略をここで定義します。要は、「どういう座組、枠組みで品質保証活動するのか」をここで方向づけるものになります。
   • 厳密には、「テスト計画」と「テスト戦略」はそれぞれ別のドキュメントとして扱うべきですが、アジャイル開発手法がが定着した今では、「計画」と「戦略」を一緒に決めることが多いです。

3. インプット：要件定義書・仕様書といったドキュメントの格納先、開発チケットのリンク、Slackなどのコミュニケーションログを掲載し整理します。

   • ここで掲載するものは、「大元になっている資料」を掲載するようにします。じゃないと、際限無く掲載出来ちゃうので。
   • インプット資料となるものを掲載することで、「どのインプット資料を参照しているのか、を整理する」ことと「その資料へ簡単にアクセスする」ことが出来るようにしています。

4. リスク分析：プロダクトリスク、プロジェクトリスクを分析したものを掲載します。

   • プロダクトリスク：「プロダクトの品質特性（例えば、ISO 25010 品質モデルに記述がある）に関連するものである。」*7
   • プロジェクトリスク：「プロジェクトのマネジメントや統制に関連するものである。*8
   • プロダクトリスクは、8つの品質特性*9が担保できない場合に、「Biz側・Dev側・ユーザー側」の各領域へ、どれだけ影響があるかを表形式でマッピングしたり、明文化したりします。
   • プロジェクトリスクは、品質活動の目的達成において「各リソース（プロジェクトのスケジュール、予算、スコープ、人員）が足りなくなった」「他の要因によって、品質保証活動に支障をきたす」ことになった際に、どれくらい影響があるか、もしくは影響が「ありそう」かを明文化したりします。
   • このリスク分析を通して、「これから設計・分析に入った時の、”このテスト観点を導出した理由付け”や"説明責任の強化"」といったことを実現します。
   • 「このリスクが想定されるので、〜のテスト観点が必要」、あるいは、「〜もテストスコープ（範囲）とする」といったようなものに対して、テスト観点導出の確度を強化できるものと考えています。

5. テストスコープ：テスト対象の「範囲内」と「範囲外」を決めます。

   • 機能ベース（新規登録、情報変更、追加、削除 etc.....）や、非機能ベース（大量にデータを入力してもシステムが破綻せずに動く、データの受け渡しに遅延が起きない etc.....）で記載していくことで、「機能（or 非機能）を、どこまでテストする」「ここからは、テストしない」といったことを決めることによって「品質保証活動の境界線」を引いていきます。
   • 高田個人の考えとして、「テストしない範囲」を最初に決めると、「本当にテストすべき範囲が決まりやすい」と考えています。
     
     

これらを、テスト計画書としてドキュメントに書き起こして品質保証の全体像を掴んでいきます。

また、テスト戦略（と、後述するテスト分析・設計）といったところでは「狩野モデル」*10を参考にして、方向性を考えることもあります。

ユニファQAでは現在、上記の項目をコンフルに明記して作成していく運用を、試しています。

ここで引かれた「あたり」。
もとい、「品質保証活動のアウトライン」を用いて、次のプロセスに移ります。

テスト分析・設計って？

さぁ、QAエンジニアの醍醐味（と、高田は思っています）である、「テスト分析・設計」に入っていきます。

何を隠そう（隠すまでもないですが）テストプロセスの中で、テスト分析・設計は「高田が大好きであり、得意である」工程です。

シラバス上では、

• テスト分析：「テストベースを分析して、テスト可能なフィーチャーを識別し、関連するテスト条件を定義して優先順位を付けるとともに、関連するリスクとリスクレベルを分析することを含む。（中略）計測可能なカバレッジ基準から見て「何をテストするか？」という問いに答えている。」*11

• テスト設計：「テスト条件をテストケースやその他のテストウェア（テストチャーターなど）に落とし込む作業を含む。この活動には、多くの場合、テストケースの入力を指定するためのガイドとして機能するカバレッジアイテムの識別が含まれる。（中略）テスト設計では、「どのようにテストするか?」という問いに答えている。」*12

と、それぞれ定義しています。

いわば、

を、指してます。

そして、

を、もう少し解像度を高めて定義していくのが、「テスト分析・設計」の工程になります。

ここで、疑問に思った方、鋭いですね。

「おいおい、テスト分析・設計で"一番大事なもの"が、抜けてるじゃないかっ！」

、と。

世のQAエンジニアの方々から、総ツッコミを頂戴しそうな勢いですが（笑）。

諸先輩（と、同期・後輩）の方々。まぁまぁ、そう焦らずとも、解説しますから〜！。

何でしたら、この解説のために、わ ざ わ ざ 上記のシラバスからの引用で「（中略）」と書いたのですからっ！

気になりますよね？「（中略）」に、何が書いてあるのか。

ね？

ということで、勿体つけずに「ささっ」と解説します。

それは、「テスト技法」です。

最初に、「テスト技法については、解説しない」と書きましたが、ここに書くのは「テスト技法の外観」について掲載します。

内容の詳細な解説については、今後の投稿や他の良書に任せるとして、「テスト技法は、どれくらいのものがあって、どんなタイプのものがあるのか？」といったことを掲載していこうと思います！

テスト技法は、大きくわけて以下の3つに分類されます。*13

1. ブラックボックステスト技法

   • 同値分割法
   • 境界値分析
   • デシジョンテーブルテスト
   • 状態遷移図

2. ホワイトボックステスト技法

   • ステートメントテスト
   • ブランチテスト

3. 経験ベースの技法

   • エラー推測
   • 探索的テスト
   • チェックリストベーステスト

番外編として、以下のようなアプローチによるものも、テスト分析・設計で使うことがあります。

• その他のアプローチによる技法
  • ユーザーストーリー（マップ）
  • 受け入れ基準
  • 受け入れテスト駆動開発（ATDD：Acceptance Test Driven Development）
    
    

他にも、CFD(Cause Flow Diagram)といった"原因流れ図"や、HAYST(Highly Accelerated and Yield Software Testing)法を使った組み合わせテスト技法などを用いて、テスト分析・設計することもあります。

それらのテスト技法を駆使しながら情報を整理し、「テスト設計書」にまとめることで、情報整理を行っていきます。

また、仕様書もインプットとして、このプロセスを実行するのですが、「仕様に書かれていないこと」も導出してテストの要否を見ます。
これについても、後の投稿で解説したいと思います！（できるかしら？）

さて、テスト設計書が出来上がったら、いよいよ「テスト実装」のプロセスに入っていきます。

テスト実装って？

テスト分析・設計で「情報を整理した後」に、次に行うのは、「テスト実装」です。

ここでは、

を、実行していきます。

いわば、「テストケース（もしくは、テスト項目書）に落とし込んでいく」プロセスになります。

に加えて、

• 「手順」と「詳細的な期待値」

を入れてテストケースとして落とし込んでいきます。

「テストケースを書くのは、”テスト設計の段階（プロセス）”でしょ？」と思われるかと思いますが、はっきり言ってそれは違います。

というのも、「テスト設計書」と「テストケース（テスト項目書）」は、"別物"だからです。

書いている項目は重複していても、

• 「内容の粒度」や「項目の数が違う（手順は、テスト設計書にはない）」
• 「各ドキュメントの構成が違う」こと
  
  

から、ドキュメントとして別物として考えるべきであり、同時にプロセスも、テスト設計と実装と分けるべきです。

まぁ、どんな領域のシステム・プロダクトのテストケースを一筆書きで書ける「銀の弾丸」や「天賦の才」があればそう出来るのでしょうが、高田から見るとそれは「設計図なしで、ランボルギーニ（Lamborghini）を作る」ようなもののように、思えてならないです。

いうなれば、「それは、無理」ってことです。

そしてその無理は、「無謀」に変貌し、最後には「機能不全」に陥ります。

そんな無理をするぐらいなら、愚直に「テスト分析・設計で”情報を整理”して、テスト実装で"文脈を紡ぐ"」ほうを選んで、事に臨みたいです。

おっと、なんか説教臭くなってきましたね。
なんか結構なことを申し上げて来ましたが、そんな高説を説くほど、大層な人間ではないのですよ（汗）

では、仕切り直して、次のプロセス「テスト実行」のほうに参りたいと思います！

テスト実行って？

テスト実行は、主に、

を、言います。

平たく「テスト実行 = テストケースに書かれている項目を実行して、その通りにシステムが動くかどうか（期待値がとれるか、どうか）」と言うのもつまらないので、 今までのことを踏襲していくと、

• 「証左を示す = 実際に動かして、品質のストーリーを語るための事柄や文脈の通りに品質が担保されるという事実、または真実の拠り所となる裏付けとなる証拠・証跡といったエビデンスを提示する（時には、集めて提示する）」
  
  

ということを行うプロセスが「テスト実行」と定義します。

そして、その証左を示したあとに、最後に「テスト完了」というプロセスを経ていきます。

テスト完了って？

テスト完了は、

のことを指します。

ハッピーエンドで結ぶのか、バッドエンドで結ぶのか。

それは、テスト計画・テスト分析や設計・テスト実装・テスト実行の一連のプロセスの結果から、導き出すものとなっています。

「テストケースの実行が”OK”だったので、リリースします！」といったことだけでは、不十分です。

テストケースの実行結果だけではなく、「テスト計画書、テスト設計書、テストケース、実行結果付きのテストケース」を「テスト完了書」にまとめ、それらを各ステークホルダーに提出すること。

それらをもとに、「品質基準（品質メトリクス）に照らし合わせて、合否を決する」ことであると、高田は思います。

実際に、現在小さい単位ですが、高田が関わっているプロジェクトにて、このようにテスト完了を施しています。

余談ですが、最近では、テスト計画書を他のQAメンバーが書くようになってきて、高田自身は嬉しく思っています。

実際に、手を動かしてやってみる。願わくば、それを継続できるように、環境整備をしていこうと、生意気ながら高田はそのように、思いました。

ということで、ここまで、

かと思いきや、「もう一つ」あります！

ただ実行しっぱなしでは、「何も成長しません」。というより、「何も報告や調整がなければ、何も成し遂げられません」

ここで出てくるのが、「テストのモニタリングとコントロール」です。

テストのモニタリングとコントロールって？

テストのモニタリングとコントロールとは、

です。

テストの目的を達成するため、各プロセスを継続的にチェックし、進捗の遅延や方向性の逸脱に対して調整を行うことを指します。

またテスト後の分析*14として、以下のことも行います。

• 不具合分析
  • QAテストフェーズでてきた不具合は、QAテストフェーズ前にキャッチアップできないか？、をステークホルダーと共に考える
• 不具合の検知タイミング
  • クリティカルな不具合を、テストの初手に出せてるか？など
• ゾーン分析
  • バグ密度とテスト密度を算出し、テスト内容の質・開発工程の質を振り返る
• テストの予実差分の要因とその対策
  • テスト時の質問やり取りが多かった場合、QAが元となる資料のブラッシュアップできるところあるんでは？、QAも事前に気づけるにはどうしたらよかったか、など。
• テスト観点の見直し
  • レビュアーとレビューイで振り返る。ステークホルダーからもらったコメントも含めて振り返る
    

このように、批判的思考と共に上記の振り返りと分析を行い、各テストプロセスをブラッシュアップしていきます。

この「テストのモニタリングとコントロール」については、今後のユニファQAでの課題となっているので、ゆくゆく導入してその実践知をどこかで発表できたらと思います。

おわりに

いかがでしたでしょうか？品質保証の活動ひとつとっても、色んなプロセスを踏んでいるとおわかりいただけたかと思います。

いや〜、書いた書いた（笑）

ここまでのテストプロセスとその成果物について、PFD*15というもので以下にまとめてみました！
※現在、テストプロセス改善の一環でPFDを使って可視化し、現状のユニファQAでの活動を見直そうとしています。その際に、作成したものを掲載します。まだ、手直しは必要ですが。

さて、ここで、「ここまで読んできたけど、一番大事なことが抜けているような気がする」かと思います。

そう、「テストの目的」です。

高田個人で考えていることではありますが、

ことが、その目的であると考えます。

とはいえ、事業会社なのでそこには「ビジネス」が絡んできますし、「開発サイクル」も関わって来ます。

そのストーリーを語るときには、「もう時すでに遅し」とはしたくないですし、そんな悠長なことは言ってられません。

そこは、各事業会社のQAエンジニアが工夫し、実践し、改善行動していく必要があると考えます。

ユニファQA内でも、そこはご多分に漏れず、同じように行動していくことが必要です。

「LeanとDevOpsの品質保証活動」も同時に考えて、行動していくことも今後のユニファQAの課題であるとも考えています。

また、自動テストに関しても今後、AIが更に発展して新しいツールや既存のツールのアップデートといったこともあるでしょう。

そんな時に、このテストプロセスを思い出して、どのように「守破離するか」といったことも考え、工夫し、実践してナレッジをためつつ、「品質という、「誰かにとっての価値」のストーリーを語る」ことができるようにしたいと思います！

「自分を批判する人々が正しい知識を身につけ、かつ公正であると信じられるなら、そして自分の下す決定が結果だけで判断されるのではなく、決断に至る過程も含めて判断されると信じられるなら、意思決定者はよりよい選択をするようになるだろう」

Daniel Kahneman：ファスト＆スロー　あなたの意思はどのように決まるか？　下巻 より

QAエンジニアとして、「バイアスとの闘い」があります。

このことを肝に銘じて、事に臨みたいと思います。

今回も、ここまで読んでいただき、ありがとうございます！

では、また！

---

ユニファでは家族の幸せを生み出すあたらしい社会インフラを一緒につくっていく仲間を大募集しています！
気になる方はぜひこちらのサイトもチェックしてみてください！！

jobs.unifa-e.com

*1:私が（一方的に）敬愛するQAエンジニア、tettanさんが書いた書籍。

*2:2025/02/24投稿 ユニファと共に進む、品質保証の旅　〜ユニファQAの姿を考察してみた〜

*3:昨年の12月ナレッジワークさんにて開催された、QAエンジニア向けにイネーブルメント（"できるようになる"）の機会を提供するイベント「Enablement Workshop for QA Engineers #3」にて出たキーワード。このワークショップは、本当に参加してよかったと、心から思います。

*4:Gerald Marvin Weinberg：ソフトウェア文化を創る1 ワインバーグのシステム思考法 より

*5:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 20ページ

*6:とはいえ、テスト計画では一部、「What?」「Where?」「How?」の内容が含まれます。

*7:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 53ページ

*8:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 53ページ

*9:JISX25010:2013　「システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル」

*10:1980年代に東京理科大学教授であった狩野紀昭 教授によって提唱されたモデル。顧客満足度に影響を与える製品やサービスの品質要素・特徴を分類したモデルのこと

*11:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 20ページ

*12:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 20ページ

*13:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2023V4.0.J02 38~45ページ

*14:現ユニファQAメンバーからいただいた、ナレッジを掲載しています。とても有用と思い、せっかくなので載せました。

*15:Process Flow Diagram：プロセスフローダイアグラム