読書メモ。2025年23冊目。
『Agile Testing Condensed』を読んでの感想となります。（2025/3/18記載）
本の概要
『Agile Testing Condensed』は、アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています。JanetとLisaは、読者が理解できるように、20年間のアジャイルテストの経験から知識を抽出して表現しました。
テストとQAの専門家がアジャイルチームでどのように貢献するか
アジャイルサイクルにテスト活動をフィットさせるにはどうすればよいか
いつ、誰の責任で、様々なテスト活動を完了させるのか
テストエンジニアがアジャイル開発チームの他のメンバーと関わるにはどうすればよいか
デリバリーチームの全員が継続的なテストに参加するにはどうすればよいか
視覚的なモデルを使ってテスト活動を計画するにはどうすればよいか
短いイテレーションや継続的なデリバリーに対してテストが「追いつく」にはどうすればよいか
テストの有効性を評価し、継続的に改善するにはどうすればよいか
テスト自動化で牽引していくにはどうすればよいか
本書は、テストエンジニア、ソフトウェアデリバリーチームのメンバー、プロダクトチームのメンバー、ビジネスの利害関係者、管理者、経営者にとって必携の一冊です。著者の最初の2冊である『Agile Testing』と『More Agile Testing』では、実際のアジャイルチームが直面しているテストの課題を詳細に例示し、それらがどのように解決されたかを説明しています。この『Agile Testing Condensed』は、多くの場合で有用であったアジャイルテストの実践の概要を紹介します。
引用：
動機
感想
アジャイル開発における品質の捉え方を学べる１冊でした。
ビジネスルールや品質特性は改めて利用方法の意識をすることができました。
具体例の使い方はチームの共通認識を醸成する上で効果的な印象を持ちました。
さっそく直近対応するPBIに対して、適応していきます。
実例マッピング使えるようになれば、チームの視座があがりそうな気がします。
また、探索的テストは利用できる状態まで学びたいと思いました。
できれば、いわゆるWFで登場する単体テスト、結合テストなどは自動化に回し、空いた分で探索的テストなどができるようになりたい。
詰んでる本に着手します。
本書全体を通じて、アジャイル開発におけるテスターの役割は単純にインクリメントに対するテストを行う人ではなく、チームが品質に向き合える状態を作ること人であると理解しました。イネーブリングしていきたいです。
ブロッコリーさんの他の翻訳書も読んでいきたいです。
直近、BDDも解像度上げて学びたいのでぽちってしまおう。
今月はQA月間になりそうです。
忘れたくないメモ
■アジャイルテストの核心
プロダクトの品質構築やテストにチーム全体で関与すること。
■チームでの開発プロセス全体を通した品質構築
チーム全体が、開発プロセス全体をテストし、バグの防止に注目し、機能性よりもはるかに多くのことをテストし、品質に責任を負う。
コーディングの完了後に欠陥を見つけるのではなく、欠陥の防止に焦点を当てる。テスト以外の開発タスクと並行して、テストタスクを完了させる。
アジャイル開発は、サイロを分解し、開発を継続的で反復的なプロセスに変える。
プロダクトを提供するために必要な人全員が協力し、プロセス全体を通して品質を構築する。
■サイロを取り除く
アジャイルテストの重要な成功要因のひとつは「広い視野をもつ」こと。
チームが他チームに依存している場合、スクラムチームまたはフィーチャーチームがサイロとなる。他チームと協力して依存関係を管理するか取り除く必要がある。
テストの主な目的のひとつは、ユーザーとビジネスに対するリスクを特定して軽減することであり、プロダクトおよびビジネスの専門家と協力することで、顧客の価値を構築する最適な方法を見つけることができる。
■全体像の理解
チームが全体像を理解した上で、ストーリーをイテレーションに持ち込むことが重要。
デリバリーされた各ストーリーが全体像にどのように影響するかを、チームが理解する必要がある。
プロダクトのリリースに向けて作業しているすべてのチームの対応を考慮したテストアプローチが重要となる。
チーム全体が開発に取り組むのと同様に、デリバリーの準備もチーム全体で取り組むべき。
■具体例（Example）
望ましいシステム動作と望ましくないシステム動作の具体例は、チームで各フィーチャーとストーリーについて共通の理解を構築するのに役立つ。
多様性は既成概念にとらわれない発想をするのに役立つ。チームは様々な視点からそれぞれの機能を見ることで、顧客が得る価値をより正確に把握できるようになる。
システムの動作に対する質問を各関係者から受けることで、チームはその具体例を調べることで矛盾点に気づきやすくなる。
デリバリーチームとビジネスチームが一丸となって具体例を収集することで、頻繁かつ持続可能なペースで顧客に価値を提供することが可能となり、実装前に重要となる共通の理解を構築することができる。
■ビジネスルール
ビジネスルールは、ストーリーの中でフィーチャーを分割するのに役立つだけでなく、フィーチャーが振る舞う方法を共有して理解できるため、フィーチャーを探索し始めるのに最適な方法となる。
主要な目標を念頭に置き、フィーチャーが顧客とエンドユーザーに提供する価値に注目する。
多くの場合、実際の例を使用することにより、チームはより多くのビジネスルールに気付く。
■探索的テスト
探索的テストの目標は、プロダクトのリスクを軽減し、信頼を獲得すること。
システムについて学ぶためのテストの設計と実行を同時に行い、最後の実験から得た洞察を次の作業に伝える。
ペルソナや役割を想定することで、チームメンバーは新鮮な視点でプロダクトをテストできる。結果、重要な問題の発見を妨げる可能性がある無意識のバイアスを相殺することで、チームの創造性を高めることができる。
また、誰かとペアリングすることで経験を最大限に活用することができる。探索後、他メンバーに報告することで、学習を共有することもできる。
■品質特性のテスト
品質特性は、すべてのフィーチャーやストーリーで考慮しなければならない制約として考えることができる。
顧客にとって重要な品質特性を検討することで、チームはプロダクトのリスクを話すことができる。
■アジャイルテストの四象限
象限を使用して、チームにとっての「Done」の意味を定義する。
最適なモデルが何であれ、それを目に見える状態に保ち、テストを継続的に改善する方法についての会話を刺激するために利用する。
■テスト自動化
テスト自動化ピラミッドは、「テストを低くする」方法を考え、アプリケーションの一部に分離される回帰テストを最大化し、システムの複数の部分を含むテストを最小化するのに役立つ。
完全に形成されたバグを見つけるために、チームは実稼働環境で動作するシステムのロギング、アラート、および監視が必要となる。
回帰テストの自動化により、探索的テストにより時間をかけられる状態を作れる。このことは、実稼働環境の障害を引き起こす可能性のある「無知の無知」を見つけるための最良の方法のひとつとなる。
■アジャイルテストにおけるテスター
品質の作り込みエンジニア、または、コンサルタント。
テスターの役割は、関係者との協力、テスト活動への専門知識の提供、開発者や他のテスターとのペアリング、プロダクトオーナーのサポート、全体的な品質戦略の整理と調整、優れたテストデータの取得、リスクの特定など、複数の活動で構成されている。
テスターが「チームの健全性」を品質特性に追加し、チーム全体のコミュニケーションとストレスのレベルが注目されている。
優れたアジャイルテスターは、他のチームメンバーとペアリングするのに時間を費やすことで、システムを構築する前に、チームの他のメンバーがシステムについてより多くのことを理解できるように支援する。
テスト戦略を定義、フォローアップ、および調整し、チーム内のテストに関する知識を共有し、伝道する。
■チームの持続可能な成功
チームの成功は、心理的な安全性、信頼、そして学ぶ時間に依存する。
テスターは、チームにテストスキルを譲渡することで、チームが品質を作り込む方法を学ぶことを支援できる。テスターはコンサルタントとして行動し、チーム全員がテストスキルを向上させ、品質に関する懸念をビジネスレベルで認識できるように支援する。
他のチームメンバーは、テスターがより多くの方法で貢献できるように、T字型スキルを向上させることを支援できる。
テストの問題を、テスターだけではなく、デリバリーチーム全体が対処する問題に変えることは、プロダクトに品質を作り込み、持続可能な成功を達成する方法を学ぶために不可欠となる。
これらの主要な成功要因と信頼醸成の実践は、チームが改善への道に沿って次のステップを決定するのを支援するフレームワークを提供する。
