『Agile testing condensed Japanese Edition』を読んで

はじめに

Agile testing condensed Japanese Editionを読んで個人的に共感したところとあまり共感できなかったところをまとめてみました。
原著を読んでいることを前提に細かい説明は割愛してます。

購入リンク

Agile Testing Condensed Japanese Edition

他の方のNote（とても良くまとめられていると思います）

https://note.com/hgsgtk/n/nf8d0ffc8a605

共感したところ

第3章の「アジャイルにおけるテスト計画」のところで、

テストの主な目的の1つは、ユーザーとビジネスに対するリスクを特定して軽減することです。明らかに、このリスクはテスト計画のやり方に大きな影響を与えます。

というところです。引用した部分以外も含めて本当にそのとおりだと思いました。

第4章の「例を用いて開発を導く」のところで、

各関係者からシステムの動作の具体的な例を要求される時に、チームはその例を見ることで矛盾点に気づきやすくなります。また、顧客が必要とする最低限の具体的な価値を掘り下げやすくなり、チームは「十分な」正しいものをデリバリーできるようになります。

というところです。具体例を出すことによって矛盾点に気づきやすくなるというのはよくあることだと思います。

第5章の「協調を可能にする」というところで、

QAは「Question Asker」の略です（Pete Walenから得たアイデアです）。テスターは、誰も質問しないと思う質問を定期的に出します。

もちろんQAはソフトウェアテストの文脈ではQuality Assuranceの略ですが、フィーチャー開発の話し合いで「これによって、ビジネス、顧客、またはエンドユーザーにとってどのような問題が解決されますか？」というような質問だけではなく、「このフィーチャーを使用する前にユーザーは何をしますか？」というような種類の質問をテスターがすることはとても大切なことだと思います。

あまり共感できなかったところ

第2章の「チームが欠陥に対処する方法」のところで、

多くのチームが欠陥許容度ゼロ（Zero Defect Tolerance）を実践しています。ここでのゼロは、既知の欠陥がイテレーションやストーリーの完成から逃れることがないという意味です。

と書かれていますが、少なくとも私の所属するチームでは既知の欠陥が重要でなければより重要な新機能の開発を優先します。重要度の低い欠陥の修正は別途時間がとれるイテレーションの際に修正します。特にスタートアップな企業では重要な新機能の開発は優先度の低い欠陥の修正より優先されるべきだと思うので、私はそれが正しいと今も信じています。

第6章の「継続的な探索」というところで、

顧客にとってのリスクと価値というテーマで探索的テストのアプローチについて説明していますが、リスクは顧客にとってのリスク（顧客データの盗難）だけではなく、もっと広く様々なステイクホルダーにとってリスク（マネーロンダリングに利用される等）となりうることを探索的テストの観点に入れていかないといかないのかなと思いました。

第9章の「アジャイルテストの四象限」というところで、

フィーチャー開発の場合、ほとんどのチームはおそらく第2象限から開始します。プロトタイプを紙に描いて、潜在的な顧客に見せることがあります。

第2象限の例としてストーリー受け入れテストやUX（ユーザー体験）テストが挙げられていますが、私の経験上フィーチャー開発でも第1象限（単体テスト）から開始して、第3象限（ユーザー受け入れテスト等）をしてから、実際のアプリケーションを使って第2象限のテスト（ドッグフーディングやユーザーインタビュー）をしています。紙に書いたプロトタイプからそれほど多くのフィードバックを得られるとも思いにくいのでそれで良いと私は思っています。