書評 『Agile Testing Condensed Japanese Edition』 〜アジャイルテストの一冊目として最適〜

hgsgtk

『Agile Testing Condensed Japanese Edition』、以前から原著を積ん読していたのですがなかなか読み進めれていなかったのですが、すでに読み進めて翻訳されている方がいらっしゃると知って速攻で買った一冊。

購入リンクはこちらとなっている。

Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています！

Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる

本書は訳者まえがきにあるが、著者たちの3冊の本（『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』）の中でまず最初に読み始めることをおすすめしている。これまでの2冊が少しテストに興味を持っていたりする開発者・経営者には、ページ数の多さなどでハードルが高かった一方で、本書はCondensedとあるとおり「凝縮された」一冊となっている。

「凝縮している」ためプラクティス・テスト技術などについてはそこまで紙面が割かれていないが、この書籍を起点に特定プラクティス・テスト技術に対して戦略を持って取り組める期待感があった。

実際に読み進めると、これはテスト戦略を考えたい現在の私にとっては最も最適な一冊だった。様々品質特性についての書籍や具体的なテスト手法・テスト自動化に焦点を当てたもの等を読んでいったのだが、なかなかテスト戦略を体系的に整理して現場でどういうふうに実践していこうか、という考察を前にすすめるための道標は見つけれていなかったのだが、この本はすべての領域に対して横断的に触れており、その詳細を『More Agile Testing』等別冊に預けることで、横断的かつ体系的に網羅しいわゆる書籍のターゲットとなっている「リーダー層」が読み切れるように仕向けることに成功していると感じた。

このnoteでは、個人的に関心がより高かった「アジャイルテストとは」というそもそも論と、その中におけるテスト戦略とテスト自動化戦略に焦点を当てて、これまで色々見回ってきた関連情報なども踏まえて、個人的な備忘録を書いています。

継続的テストモデル

Ellen氏とMary氏の『Discover to Delivery』（日本語訳：『発見から納品へ:アジャイルなプロダクトの計画策定と分析』）で使用している Discovery to Delivery という開発プロセス

このプロセス図はどこかで見た気がするな〜とおもったのですがDiscoveryとDeliveryが2つの円で連なっていく概念モデルは、市川氏の『正しいものを正しくつくる』で述べられていた仮説検証型アジャイルの概念図に近いものがあるなと感じた。

DevOpsにおける継続テストのループの重要性についても次のブログを紹介している。

画像1

あらゆるフェーズにおいてTestingは存在しており、さらにその源泉となるアイデア（Idea）をテストすることの重要性も述べていました。

画像2

著者の中でのAgile Testingの定義は以下のブログにてあるとおり、様々な会話の末、次のように定義しているようだ。

Collaborative testing practices that occur continuously, from inception to delivery and beyond, supporting frequent delivery of value for our customers. Testing activities focus on building quality into the product, using fast feedback loops to validate our understanding. The practices strengthen and support the idea of whole team responsibility for quality.

ATDDやBDD、SBEといった開発プラクティスはこの中で行なう一つの開発のガイディングツールとして紹介されている。

Guiding development with concrete examples, means using practices like ATDD (acceptance test driven development, BDD (behaviour driven development) or SBE (specification by example)

チーム全体のマインドセット

チーム全体のマインドセットについても幾つか述べられているが、品質に注目するというマインドセットにおいて、「DoD: Definition of Done: 価値のある完成の定義」について議論し同意する必要がある点を述べている。『Clean Agile 基本に立ち戻れ』でも品質について述べられており「完成の定義」について述べられていた。

「完了の定義」ではないことは訳者の中ではすでに当たり前のコンセンサスになっていることを密かに感じた。

欠陥許容度ゼロ（Zero Defect Tolerance）

多くのチームが導入しているらしい概念「欠陥許容度ゼロ（Zero Defect Tolerance）」。これは、既知の欠陥がイテレーションやストーリーの完成から逃れることがないという意味なようだ。1week/2week程度のイテレーションでこれを実現するには、チームアプローチ自体から手を入れて何からの手法を採用する必要がある。

チームでのテスト計画

ここでテストの詳細度に合わせてそれぞれの解説をしていることに大局観が得られて良い。

画像3

上の図は個人的に詳細度と一部のプラクティスを関連付けてテストピラミッドの概念とマッピングしたものだが、詳細にプログラマだけだと思考が寄ってしまいタスクレベルでとどまってしまいがちなテスト戦略が俯瞰となっていい。

チームでのリリーステスト計画の際にTest Matrix・Test Mindmapはツールとして便利だなと感じたので活用していきたい。

ATDD: Acceptance test-driven development

ATDDについて実は具体的な定義を説明しているのはそこまで多くない。本書では次のように説明していた。

受け入れテスト駆動開発（Acceptance test-driven development, ATDD）も同様です。これ は、厳密な言語やルールのない例を使用して開発を導く、より一般的な形式です。機能テストに ATDD を使用する人が多いですが、セキュリティやアクセシビリティなどの他の品質特性の要件 を含めることができます。私たちが使用した ATDD のアプローチの 1 つは、チームがストーリー を計画するときに、望ましいまたは「ハッピーパス」の振る舞いの少なくとも 1 つの抽象的な例 と、おかしな振る舞いの種類ごとに少なくとも 1 つの例を捉えることです。

「ハッピーパス」という言葉はAgileにおけるテストを語る際他の書籍でも出てきていて、Robおじさんの『Clean Agile』でも同様の言葉を使用している。

機能テストのみに限らず、セキュリティ・アクセシビリティ等の品質特性の要件も含めることが出来るとしている。本書では機能のみをテストすることがアジャイルテストでやることなんだという誤解があることについて度々言及しているが、ATDDにおいてもストーリー受け入れテストによって開発を駆動する中で機能のみがそのDoneではないことを示していたりする。

Power of Three(Three Amigos)

ユーザーストーリーを開発していく戦略として Three Amigos戦略というものを George Dinwiddle氏が提唱している。

Summaryを抜粋すると次のように語っている。

Developing software correctly is a detail-oriented business. George Dinwiddie writes on how using the Three Amigos strategy can help you develop great user stories. Remember, the goal is to have the work done just in time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale.

詳細が陳腐化するほど先には進んでいはいけないよという話は、やはりAgileのユーザーストーリ定義における一つの誘惑と鍛錬で、『Clean Agile』でも詳細化を避ける鍛錬が必要であることについて言及していた。

Three Amigos Meeting自体は、User Storyが期待するふるまいがなにかを開発者が手にとった際によくわからないという開発体験に対して、ストーリーを完全理解するためにスプリントまで待つのではなく、次のスプリントにむ向けて準備されるストーリーをビジネス（POやアナリスト）、プログラマ、テストが3者で、一緒に議論する時間をとるというものだった。この3者である理由は、彼らが相互に直交する視点を提供することで必要な詳細が明らかになることが期待される点にある。

実例マッピング

ルールの多さ・実例の多さでユーザーストーリが分割したほうがいい可能性が明らかになる。

この手法は、ストーリー受け入れテストを作成する際の議論方法にも使えると本書では説明している。初めて知ったのだが活用していきたい手法だった。

継続的探索テスト

このテーマは一番「どういうふうにやってるの？」と個人的に気になっていたところだった。

これについては探索的テストについて解説している様々な書籍・資料で述べられているが、アドホックテスト・モンキーテストや、ランダムにさまよったテストとの違いについて、具体的なテクニックを通じて教えている。

探索的テストには様々な定義がある事自体は、下の書評を書いてる際に「JaSST'20 Tokyo で探索的テストを解説した資料」にて探索的テスト自体とその定義についてわかりやすく説明してあった。

本書では、『Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing』の著者であるElisabeth氏の次の定義を参照していた。

システムについて学ぶ ためのテストの設計と実行を同時に行い、最後の実験から得た洞察を次に伝える

具体的なテクニックとして、まずペルソナや役割を想定することで新鮮な視点でプロダクトをテストできる点を説明しています。このテクニックによって「不注意による盲目」・「確証バイアス」などの認知バイアスを克服できる。

「不注意による盲目」ってなんのことかな〜っておもって見たら「あぁあのゴリラが通るやつね！」となった。

「確証バイアス」は、自分にとって都合のいい情報ばかりを無意識的に集めてしまい、反証する情報を無視したり集めようとしなかったりする傾向のことを言う。

リスクと価値を明らかにする問い

顧客にとってのリスクと価値を明らかにする問いとして、「起こりうる最悪の事態はなんですか？」というものがあるとしていた。これはとても便利な問いなので引き出しの中に入れておこう。

品質特性のテスト

品質特性に開発と運用があるよという整理区分はソフトウェア品質体系化の文脈でもあまり聞き覚えがなかったのですが直感的でわかりやすいかもしれない。

考慮する必要がある品質特性の主な 2 つのタイプは、開発の特性と運用の特性です。開発の特 性には、コードの保守性、コードの再利用、およびテスト容易性（コードをどのように開発する か）が含まれます。それは内部または技術に面した品質であり、ソフトウェアのデリバリーチーム が所有しています。 人々が品質特性について話すときは通常、運用の特性を意味します。Ellen Gottesdiener と Mary Gorman は「図：品質特性のメタモデル」にて、品質特性の一部を運用特性または開発特性 として分類しています。

「どっちの話ししてるの？」という会話の整理になりそう。

DevOps Testing

継続的デプロイにおけるパイプラインを次のように例示していた（図は再現して自作。緑は自動、黄色は手動）

画像4

継続的デリバリ(Continuous Delivery, CD)、継続的デプロイ(Continous Deployment, CD)の両方について説明していますが、上の図は継続的デプロイです。継続的デプロイについて筆者が強調しているのはテストの非同期な実行が可能となった点です。Martin Fowler氏がブログにて示している"Feature Toggles"等の手法によって、必要なテストがすべて完了するまで、変更を顧客から隠すことを可能となった。

継続的デリバリまたはデプロイは、パイプライン内の各要素スキルと、高速なパイプラインを構築するためのインフラの必要性等、様々なスキルが存在するため、各チームメンバーがT字型（T-shaped Skill)のスキルを持ち協力することになる。

このへんの開発組織・メンバーに求められるスキルは、Agileな文化をもった自己組織化した開発者組織のそれとかなり一致しているため、アジャイルテストについて解説する本書でDevOpsに紙面をしっかり取られるのはとても納得感があった。

可観測性(o11y)についての言及

本書ではo11y(observability)についての言及も含めています。つまり、監視と可観測性についてです。実稼働環境で起こるすべてのエラーを予測してテストすることは不可能であるという前提のもと、可観測性を高め記録された情報から異常なパターンについて気が付きリスク特定・価値提供するという点において、運用と切り離された組織であればもしや距離が遠く感じてしまうかも知れない可観測性・監視の領域はむしろテスターとしての本領発揮の絶好の場であることを言及していました。

書籍の注釈の中で紹介されていたAbby氏の以下の記事が、Deploy, Release, Post-Releaseの3 phaseごとのテストについて語ってる。o11yとかchaos engineeringやA/B Testとかそれらの具体的なプラクティスを大局的に整理されててとてもいい。

アジャイルテストの四象限

この四象限はちょっとTDDとかテストとかに興味があった場合におそらく目に触れているはずの内容で、テストの概念整理としてはかなりわかりやすい四象限整理ですよね。本書を読んで Brian Marick 氏という方が提唱したことを知りました。

アジャイルテストの四象限は、さまざまな種類のテストの分類法です。必要とする可能性のあ るテスト活動をチームが議論し、それらを実行するための適切な人材、リソース、および環境があ ることをチームが確認するための思考ツールとして使用します。

テストの分類手段としてのこの4象限は強力だと思っていて、なおかつテスト自動化戦略の前段にしっかりこのテスト観の認識が先立っていることがとても重要だと個人的に感じている。

画像8

開発を導くテストはコーディング前・進行中に作成されるもので欠陥の防止に役立つ一方、プロダクトを批評するテストはコーディング完了後に行われ欠陥の発見及び欠落したフィーチャの特定に役立つ。

ビジネス側のテストはビジネス関係者が読み取り可能なテストにフォーカスを当てており、技術側のテストは技術チームによって作成されビジネス側はその最終結果は気にしない。ある意味ビジネス側の多くは外部品質に関したもので、技術側は内部コード等内部品質やインフラの正確性と行った一部外部品質に関したものとなる。

TDDの実践をしている場合には、小さなユニットテストを作成しそれに合格するためのコードを作成するという自動テストが導入されていることでしょう。これは第一象限内の議論であると解釈できる。

開発を導くビジネス向けのテストは、実例マッピング等によって各ストーリのビジネスルールおよびその実例を引き出し。さらにBDDやATDD・SBEを実践するチームの場合は、実行可能なテストとしてシナリオ化し、コード記述によって自動化することになる。

この象限整理によってもう一つ得られる視点は完成したというDoneの定義にどのテストを含めるべきかということが議論可能な点にあるとしている。さらに本書ではDoneをより具体的に「ストーリー完了」と「フィーチャ完了」と呼び分けることを推奨していた。つまり、ストーリー完了に含める事ができるのはQ1・Q2・Q3の一部となり、「フィーチャ完了」ではユーザー受け入れテスト（UAT）や探索的テストなどもこれらに含まれるという整理となる。ストーリーレベルのテストでカバーできなかった品質特性を、フィーチャレベルで実行するという実践例を示していた。『More Agile Testing: Learning Journeys for the Whole Team』の第8章ではこの象限内のバリエーションを様々示しているらしい。この本を読み進めるほど『More Agile Testing』を今すぐ読みたくなってくるところが素晴らしいところ。

Test Automation Pyramid

Mike Cohn氏のテスト自動化ピラミッドは有名すぎるほどのものだ。Martin Fowler氏のブログでも彼のテスト自動化ピラミッドが紹介されている。

画像6

ビジネスロジックとデータベースや外部サービスなど、アーキテクチャの異なるレイヤ間にまたがり相互作用を必要とする場合は、サービスレベルおよびAPIレベルで行なうという「Service Tests」が一般的に用いられている方法となる。

UI Testはもっとも速度が遅く変更に対して脆弱でありメンテナンス頻度が高くなるため、最小限に抑えることを推奨されています（この辺はもう常識的な観念になりましたね）。

更に本書では「Seb Rose ピラミッドバージョン」というモデルの構想を紹介していました。

上記のブログの中でテストの実行するコード量について着目していることがわかります。

What this tells us is that most tests should exercise as little of the application as they can. These tests should document the behaviour and validate the correctness of small amounts of code.

本書でも、テストをより効果にするのが、実行が必要な層の数であることを言及していました。

画像7

また、ちょっと現実的な解釈を示しているのはとおもったのは、おなじみの「アイスクリームコーン」となっているテスト状況に対して、必ずしも間違っているわけではないことを示している点でした。

画像8

チームのニーズを満たしていない場合は変更が必要になり、そのためにテストピラミッドは視覚化している、というスタンスを取っています。

たとえば、レガシーシステムでテストピラミッドの下の層が薄いがそれでも影響範囲が大きいシステム変更をしなければいけない場合、意図的にカバレッジを荒く広く取るためのコンポーネントテストを優先する戦術がありえます。そういった場合にテストピラミッドの図を教義的に出すのは生産的な議論とは思えません。もちろん時が経過するにつれてより正三角の形へ持っていくことが望ましいとなるので、その際に「理想的な姿の視覚化」としてのテストピラミッドの引用は非常に有用となるでしょう。これは個人的な見解を唐突に述べましたが本書でも次のように示しています。

視覚化モデルに関する会話は、自動化の取り組みを始めたばかりのチームが最終的な目標と最初の優先順位を決定するのに役立ちます。

テストピラミッドを「should」の理由付けと使う理論付は非常に多く自身もそれをやりがちですが、そもそも論としてチームのニーズはどこにありそのために求められる形はなにか？という論点が抜け落ちないように気をつけないといけない。あくまでこれらは視覚化のツールであることを理解した上で頭を使わないといけないですね。

更に『A Practical Guide to Testing in DevOps』にてDevOpsのバグフィクターについて解説しており、単体テストレベル・統合レベル・エンドツーエンドレベルと段階的なバグ検出のモデルを視覚化していると紹介されていました。こちらもいずれ手に取りたい（とにかく本書はたくさんの関連書籍を示してくれるのですごく好きです）。

アジャイルテスター

Agile Testing: A Practical Guide for Testers and Agile Teams』（日本語訳：『テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト』）では、「アジャイルテスターのための10の原則」を示している。

• 継続的なフィードバックを提供します。 
• 顧客に価値を提供します。
• 対面でのコミュニケーションを可能にします。
• 勇気を持って。
• シンプルさを保ちます。
• 継続的な改善を実践します。
• 変更に対応します。
• 自己組織化する。
• 人に注目します。
• 楽しんで！

おわりに

本書は、コレまで紹介してきた概念に限らず特に終盤にはテスターにとってのチーム内での振る舞いの指針やその始め方について語っています。アジャイルテストをいかに成功させるかという指針も幾つか語っており、全体像を見ることといった詳細に目が囚われてしまいがちな開発者に対して良き指針を与えてくれています。

本書以外も『Agile Testing: A Practical Guide for Testers and Agile Teams』や『More Agile Testing: Learning Journeys for the Whole Team』といった書籍も実践例が含まれていると紹介されており、続けて読んでいきたい。

とくに、『More Agile Testing: Learning Journeys for the Whole Team』ではコーディング完了後ではなく欠陥自体を防止することに焦点を当てる考え方を説明しているらしい。さらに第 23 章では、テスト環境のセットアップ、テスト自動化フレームワー クの実装、テストデータの生成など、運用スペシャリストがデリバリーチームの品質向上を支援する方法について説明しているらしくこの次にすぐに読んでいきたい。

こちらの本を翻訳してくださった@nihonbusonさんには感謝してもしきれない。こちらの書籍によって脳内でぼんやりとして浮かんでいたものがくっきりと言語化され、確実にアジャイル開発における品質に立ち向かう大きな一歩目が踏み出せそうです。本当にありがとうございます。



この記事が気に入ったらサポートをしてみませんか？