Agile Testing Condensed 読んでみた感想

こんにちは。Azukaritai の村穂です。
Azukaritai の中では Communication ロールといって、Azukaritai と外部の人をつなぐ役割として活動しています。そんな活動の一環として note を初めてみたわけですが、さて、何を書きましょう。アイデアはあるのですが、どのアイデアを最初の投稿に持ってくるか悩ましいものです。結局、Azukaritai の主な活動領域であるソフトウェアの品質向上に関するネタがいいかなと思いまして、かといって立ち上がったばかりのチームなため独自のノウハウがまだなく、そこで過去に教材にさせていただいた本の紹介を今回行いたいと思います。どうぞお付き合いをお願いします。

Agile Testing Condensed は、アジャイル開発におけるテストの考え方が書かれた本です。UNIBA という会社で QA 専門のチームを作りたいというモチベーションからスタートした Azukaritai にとっていい教材になるのではないかと思い、Azukaritai 活動の初期のほうでチームメンバー同士、この本の輪読会を行ったりしました。
今回の記事では私がこの本の中で特に印象に残ったテーマや具体的なアクションに昇華できた事例を紹介し、本書をすでに読み終えている方も多少面白がってもらえるようなそんな記事が書けるといいなと考えています。

本の概要

全91ページ。サクッと読める量ですが、重要な示唆を与えてくれる素敵な本でした。Lisa Crispin と Janet Gregory による共著で、2021年にブロッコリーさんという方が邦訳を公開されました。

邦訳された電子書籍は以下のリンク先から購入できます。
https://leanpub.com/agiletesting-condensed-japanese-edition

この本に書かれていること

・テストと QA の専門家がアジャイルチームでどのように貢献するか
・アジャイルサイクルにテスト活動をフィットされるにはどうすればよいか
・いつ、誰の責任で、様々なテスト活動を完了させるのか
・テストエンジニアがアジャイル開発チームの他のメンバーと関わるにはどうすればよいか
・デリバリーチームの全員が継続的なテストに参加するにはどうすればよいか
・視覚的なモデルを使ってテスト活動を計画するにはどうすればよいか
・短いイテレーションや継続的デリバリーに対してテストが「追いつく」にはどうすればよいか
・テストの有効性を評価し、継続的に改善するにはどうすればよいか
・テスト自動化で牽引していくにはどうすればよいか

※ https://leanpub.com/agiletesting-condensed-japanese-edition より引用

QAに取り組まれている方にとって非常に気になってしまう話題がいくつかあるのではないでしょうか。

印象に残った3つの話

書籍で取り上げられている内容はどれも重要に感じたのですが、特に印象に残っている3つの話を取り上げようと思います。

その1.テストマニフェスト(p15)
テストマニフェストは Karen Greaves と Samantha Laing によって作成されたものです。マニフェストには以下のことが記されています。

私たちは以下を大切にします。
・最後にテストするよりもずっとテストし続ける
・バグの発見よりもバグの防止
・機能性をチェックするよりもチームが理解している価値をテストする
・システムを破壊するよりも最高のシステムを構築する
・テスターの責任より品質に対するチームの責任

この本を読むまでは、基本的にテストは最後の門番のようなイメージを持っていました。実際にそのようなテストの仕方を私はしていました。この門番的なテストが上手くいっているように感じる時もあります。リリース前に多くのバグを見つけて、多くのバグが修正されリリースされた時はやりがいもあります。しかし一方で、リリース間際に多くのバグが見つかることに対して不安を覚えることもあります。これらのバグを修正するのにどれだけ時間がかかるのか？リリースに間に合うのか？それらの不安に対して本書で書かれているアジャイルテストは有効だと感じています（言うは易く行うは難しという感じもします）。アジャイルテストのマインドセットをすぐ思い返せるこのテストマニフェストは机の上にでも貼っておくとよさそうだなと思いました。

その2.質問する (p37)
“第5章：協調を可能にする”内のトピックで”質問する”というのがありました。そこには QA とは Question Asker の略だ。というジョークが書かれていました。プロダクトのフィーチャーを議論するときテスターは誰も質問しないと思う質問を定期的に出しましょうと。これはいい取り組みだと思いました。テスターはプロダクトの仕様を細かく把握していないと網羅的なテストを行うことができません。なので仕様に関しての質問を多く行うことはもちろん重要なのですが、仕様が決まる前の質問も重要なのだと、この”質問する”というトピックで気づかされました。仕様が決まる前の質問を多くすることで、プロダクトオーナーや開発メンバーのプロダクトに対してのイメージを加速させ、より議論を深めることができます。さらに仕様についての議論が充実することで、仕様の漏れを防ぐことができ開発の手戻りなども防ぐことができます。テスターは質問をすることで、不具合を検出する以外の方法でプロダクト開発に貢献できるのだなと、印象に残った話でした。

その3.テスターの新たな役割 (p75)
この章では、これまでテスターとはテストを行う役割を持つものと考えていた人からすると少々驚いてしまう可能性があるほどテスターが持つべき”テスト以外の役割”について書かれていました。しかし、テスターの目標が品質を向上するというものであるならば、たしかにそうだと思えるような内容だと思いました。おおよそ、以下のようなことがテスターの役割の中にあるそうです。
・テストの成果を上げるため（テストの容易性や可観測性の確保）に各関係者の協力を得ること
・質問を通してシステムがどのように利用されているか探索すること
・開発プロセス全体に対して品質戦略を立てること
・品質向上に繋がる技術をチームメンバーに教育すること
またテスターは「チームの健全性」も品質特性に含み注目するだろうと書かれた一文もあり、これは面白いなと思いました。
上記に挙げた一覧を見ると、テスターはテスト実施だけではなく、リーダーシップを発揮しながら開発チームを品質向上の取り組みに引っ張っていくことが求められていると感じました。

読了後の変化

まだほとんど本で書かれていたような取り組みはできていません。その理由はいくつかあるのですが、一つはこれまでのやり方に自分が慣れきっていることが挙げられます。動くプロダクトが出来て初めてテストを行い、見つかったバグをリリース日に間に合うように修正するというやり方。すでに書きましたが、このやり方が悪いとは思いません。しかし開発のスタイルによっては上手く機能しない、むしろ良くないと感じることがあります。例えばリリースに間に合うように不具合修正をしている時、新たな機能を開発する必要が発生した場合、作業の優先順位付けやタスクの管理コストが一気に膨大になるような感覚があります。そんな現状に対しても「そういうものだ」と頑張ることで乗り越えようとしていたのですが、本を読んでからは仕様が頻繁に変わる可能性があるアジャイル開発に置いて、まとめてバグ修正を行うのは危険な行為なんだと、現状のやり方に対してより課題を感じるようになりました。そこから仕様を決める段階でテストアプローチを取るやり方に挑戦などしました。その際に参考にしたのは本で書かれていたマインドやノウハウだけでなくW字モデルという開発手法のドキュメントなども参考にしました。
上流工程からテストに取り組むのは簡単ではありません。アジャイルテストはこれまでのやり方と比べると高い能力が求められます。会得するには道のりが長いですが、テスターがプロダクト開発の重要ポジションとして活躍できるよう、色々チャレンジしていきたいと思っています。