天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Agile Testing Condensedを読んだ

最近読んだAgile Testing Condensedが良著だったので、読んだ感想を書いてみます。

本を読んだきっかけ

自分の現場では、テストに膨大な工数がかかるという課題を抱えています。*1
そのため、課題発見が得られる何かしらのヒントが見つかることを期待して、以下のイベントに参加しました。

devlove.doorkeeper.jp

ここでブロッコリーさんの話を聴いたのですが、目から鱗の話が多く、現場を良くするためのヒントをいただけたので、Agile Testing Condensedを買って読んでみることにしました。

leanpub.com

この本を読んで今後活かしてみたいと思ったこと

テストで欠陥を見つけるのではなく、テストで欠陥を防ぐ

これまでのチームでは、テストはどうしても最後にやるものだというイメージが強く、レビュアーの人に、「ソースコードがFIXするまではテストに関するレビューをしない」と大きめの開発だと言われてしまっています...(かく言う自分も半年位前までは全く同様の考え方を持っていました)
長年WFで開発してきたこともあるため、価値観を変えてもらうのは中々難しいと思うのですが、最後にテストしてバグが見つかり、慌てて直してさらにバグを埋め込む, 保守性の低い修正をする...課題が事実として散見されているので、テストを先にして早めに問題検知できた事例を積み重ねて、地道に成果をアピールしていきたいです。

例を用いる

自分たちのチームで例を話す時は、複雑な計算式や多数の仮定, 前提条件が必要となることがあり、抽象的な例で話す(隠れた前提は受け手に読み取ってもらう)が多くなってしまっています。
ただ、本書を読んで、具体的な例を用いてチームで会話することの効果(社内外で協調を促進したり、もっと良い価値を生み出すためのアイデア発見の手助けになる)を知り、実例マッピングの手法を活用するなどして、コミュニケーションコストを最小限に抑えつつも具体的な例で会話を進めたいと思いました。

ペルソナやロールを活用してテストする

新たな学びではないのですが、実際に自分がこれまでテスト時に無意識にやっていたことの効果が言語化されていて、なるほど!となった箇所です。
自分はこれまでテストする時、ユーザが触ることが想定される時間帯や、ユーザの心情(急ぎで操作する, 絶対に入力ミスしちゃいけないという気持ちで操作する...)を想像してテストしていたのですが、探索的テスト(システムに対しての理解を深めて次に繋げるテスト)での学習促進効果やユーザビリティ向上に役立つ旨が記載されていて、チームのメンバーや後輩に自分がテスト時に良く意識するペルソナやロールを是非シェアしようと思いました。

学びを得るためのテスト

直近のレトロスペクティブで、「プロトタイプを作って動かしたことで大量の学びを短期間で手に入れた」という話をしていたのですが、学びを得るためのテストができていたからなのかな、と思いました。
テストを欠陥を発見するためのプロセスとして捉えている限り、プロトタイプを作って動かすという行為はやりにくいと思うので、前述した「テストで欠陥を見つけるのではなく、テストで欠陥を防ぐ」と考える重要性を再認知しました。

アジャイルテストの四象

プロダクトに必要なテストを考えるのに役立つというモデルです。
本書の冒頭で、「テストにベストプラクティスはない。なぜなら常にプラクティスは進化し続けるからだ」という印象的な主張があるのですが、本書に書いてあるプラクティスを現場で実践して進化させるために、このアジャイルテストの四象限モデルが役立つのだと理解しました。
チームの状況や開発案件の仕様を観測した上で、プロダクトを良くするためにはどんなテストが必要なのか、現場でこのモデルを使って考えていきたいです。

この本を読んで得た知識

まだ現場で実践するまでに至っていないものの、引き出しとして持っておきたいと感じた知識をまとめます。

  • チームのコンテキスト(チーム、プロダクト、システムの詳細レベルの3観点)から考えるテスト計画
  • テスト時にペアリングすることの有用性
  • 品質特性のメタモデル
  • 継続的デリバリ(デプロイ)のパイプライン例
  • 学習リリースからフィードバックを得るという考え方
  • 監視と可観測性(異常発生時に迅速に対応するための1プラクティス)
  • 視覚モデル(従来のテスト自動化ピラミッドとSeb Rose ピラミッド)
  • テスターの役割とテスト成功のための材料(必要なメンタルモデルやスキル)

感想

テストに対する考え方を160度位見直しさせられる本でした。
この本を読むまではテストという仕事が一番嫌いだったのですが、テストの奥深さに気が付かされました。(人から影響を受けやすい自分は、今はテストがやりたくて仕方がない状態になっていますw)
たくさんの人に伝えたいという想いからかなりコンパクトなサイズになっていますが、考えさせられることが多く、抽象的でそのまま現場に適用できない内容も幾つかあるので、何回か定期的に読み返して消化していきたいと思っています。

現場への実践

今は、チームの課題にフィットしていて、実践することで効果が得られそうなものをまずは個人で実践してみる⇒ある程度有用性が担保できたものをチームにも広げる、という流れで本書に書いてある内容を適用していこうと考えています。(これはまさにTesting Manifestoの考え方なんですかね?笑)
チームにも徐々に広げようとはしていて、今日は実例マッピングをチームメンバーと初めてペアでやってみました。
本当は今日の記事でやってみた感想を書く予定で記事を書き始めましたが、実例マッピングを通してプロダクトの仕様について徹底的に考えたこともあり、今日はへとへとで、記事の文字数も長めになりそうなので、また明日すっきりした頭で整理して書きたいと思います!
試したいことはまだまだたくさんありますし、今日初めてチームで実施した実例マッピングも練度を上げる余地は大いにあると考えているので、何か新しい気付きがあれば、またこのブログで書いていきます。

*1:半年前の時点で、開発期間の内、4~5割はテスト(しかもその内殆どが手打鍵&Excelにキャプチャ貼り付けするテスト)に費やしていました