📚
”フルスタックテスティング”で掴む 現場で活かす多層テスト設計のヒント イベントレポート
ソフトウェアが複雑化の一途をたどる現代、多くの開発チームがこうした「テストのサイロ化」という壁に突き当たっています。個別のテスト手法を断片的に学んでも、プロダクト全体の品質を保証することはできない。では、どうすればいいのか。
2025年7月22日、その答えのヒントを探るべく、近著『フルスタックテスティング』の翻訳を手がけた3名の専門家が集結しました。彼らがパネルディスカッションで語ったのは、10のテスト手法を戦略的に組み合わせ、あらゆる角度から品質を「面」で捉えるという、新しい品質保証の世界観でした。
本レポートでは、その白熱した議論の模様をお届けします。これは単なるテスト技法の解説ではありません。品質という終わりのない旅路を歩む、すべての開発者、QAエンジニア、そしてプロダクトマネージャーに贈る、新たな航海図です。
「フルスタック」とは何か？ 10の手法と、それを貫く3つの層
イベントは、モデレーターも務める翻訳者の一人、Autifyの末村氏による書籍の紹介から始まりました。本書が扱うのは、以下の10種類のテスト手法です。
手動探索的テスト、自動テスト、継続的テスト、データテスト、ビジュアルテスト、パフォーマンステスト、セキュリティテスト、アクセシビリティテスト、モバイルテスト、機能横断要件テスト
しかし、本書の神髄は、これらの手法を単に羅列することにはありません。翻訳者の一人、Autifyの松浦氏が解説した、第1章で提示される**「フルスタックテスティングの全体像」**こそが、本書を貫く最も重要な思想です。
「この本の面白いところは、10の手法を語る前に、まず『UI層』『サービス層』『データ層』という3つの層を提示することです。そして、どのテスト手法を実践する上でも、この3つの層を意識することが重要だと説いています」 —— 松浦 隼人氏
「フルスタック」とは、フロントエンドからバックエンドまでという技術スタックの広さだけを指すのではありません。あらゆるテスト活動において、UI、サービス、データの各層にどのような影響があるかを常に意識するという、思考の広さを意味するのです。
例えば、モバイルテストを考える時も、単に画面（UI層）を操作するだけでなく、その裏で動くAPI（サービス層）や、デバイス固有のデータ（データ層）までを考慮する。この多層的な視点こそが、品質を面で捉えるための第一歩となります。
全てをやるのは不可能。テストスタックの優先順位はどう決める？
10種類ものテスト手法を前にして、誰もが抱くであろう疑問。それは「これ、全部やるの？」という問いです。この点について、PagerDutyの堀氏は、自らの経験を基に、テストの優先順位付けが**「コンテキストに依存する」**と語ります。
「大規模なパフォーマンステストは、例えば新リージョンへの進出など、大きな投資判断が必要なタイミングで行うことが多いです。一方で、日々の開発サイクルの中では、CIに組み込めるような小さなアクセシビリティチェックなど、継続的にできることから始めるのが現実的です」 —— 堀 明子氏
フルスタックテスティングは、全てのテストを一度に実施することを求めるものではありません。プロダクトのフェーズ、ビジネスの優先順位、そしてユーザーからのフィードバックといった**「対話」**を通じて、今、どの品質特性に注力すべきかを判断し、適切なテストを選択していく。そのための「共通言語」として、本書の10の手法が機能するのです。
「この本では、手動探索的テストが自動テストの前に置かれています。これは、まず人間がシステムを探索し、理解を深める中で、自動化すべき重要なテストケースを見つけ出す、というシフトレフトの思想が反映されているからです」 —— 末村 拓也氏
闇雲にテストを増やすのではなく、まず探索し、理解し、最も価値の高いテストから自動化・継続化していく。その戦略的な順序付けこそが、現場で活かすための知恵なのです。
現場からの問い：『テストしやすいシステム』とは？
パネルディスカッションは、参加者からのリアルな質問によって、さらに熱を帯びていきました。その中でも特に示唆に富んでいたのが、「テストしやすいシステムと、しづらいシステムの違いは何か？」という問いでした。
これに対し、末村氏は一刀両断します。
「身も蓋もないことを言いますが、作る前にテストのことを考えていないシステムは、テストしづらいです。アジャイル開発でよく使われるINVESTというユーザーストーリーの原則がありますが、その最後にある『T』は『Testable（テスト可能）』。要件定義の段階から、どうテストするかを考える文化が不可欠です」 —— 末村 拓也氏
テストは、開発の後工程で行われる「検査」ではありません。品質は、設計段階から作り込まれるべきもの。この当たり前でありながら、実践が難しい原則を、登壇者たちは改めて強調しました。
さらに、「ドメイン知識を得るために、新人に手動探索的テストをやらせるべきか？」という質問に対しては、こんな答えが返ってきました。
「新人『には』ではなく、『全員が』やるべきです。長年関わっていると、逆にバグを見つける勘所が鈍ってしまうことがある。以前、開発者がボタンを連打していたらバグが出た、なんてこともありました。多様な視点からシステムを触ることで、思わぬ欠陥が見つかるのです」
テストは、特定の誰かの仕事ではない。開発者も、QAエンジニアも、時にはPMやCSも巻き込み、チーム全体で品質に向き合う。その文化を醸成するための共通言語として、「フルスタックテスティング」の考え方は、強力な武器となるでしょう。
品質は、誰かの仕事ではない
この日の議論を通じて見えてきたのは、『フルスタックテスティング』という一冊が、単なるテスト手法のカタログではなく、**品質に対する向き合い方そのものを変革するための「思想書」**であるという事実でした。
自動テスト、インシデント管理、SREと、それぞれ異なる専門領域を持つ3名の翻訳者たちが、奇しくも同じ結論にたどり着いたこと。それは、**「品質は、チーム全員の責任である」**という、シンプルで力強いメッセージです。
品質を「面」で捉えるとは、テスト手法を増やすことだけではありません。それは、職能の壁を越え、開発ライフサイクルのあらゆる段階で、チーム全員が品質について対話し、意思決定を行なっていく文化そのものを指すのでしょう。
この本は、そのための地図であり、共通言語です。この地図を手に、あなたのチームは、品質という果てしない冒険の、どこへ向かいますか？そんな問いを、深く、そして静かに投げかけられた、実り多き昼休みの1時間でした。”フルスタックテスティング”で掴む 現場で活かす多層テスト設計のヒント”フルスタックテスティング”で掴む 現場で活かす多層テスト設計のヒント
Yardでは、AI・テック領域に特化したスポットコンサル サービスを提供しています。
興味がある方は、初回の無料スポットコンサルをお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...