#book #r2020 ![image](https://gyazo.com/80107242721fc06df25cbc0c797d8e49/thumb/1000) [https://leanpub.com/agiletesting-condensed-japanese-edition](https://leanpub.com/agiletesting-condensed-japanese-edition) # 概要 - アジャイルプロセスの中にテスト(テスターを含む)をいかに組み込むかの話 - テスターに品質保証を丸投げするのではなく、チームが血管を防ぐことを学ぶというマインドセットの話 > 始まりからデリバリーまで、そしてそれ以降も継続的に実施される協調的なテストの実践により、お客様への価値の頻繁なサポートをします。テスト活動は、高速なフィードバックループを用いて、プロダクトの品質を築くことに重点を置いています。このプラクティスは、品質に対するチーム全体の責任という考え方を強化し、サポートします。 上記だけで理解するのはちょっと難しいので画像も一緒に紹介 ![image](https://gyazo.com/1900b14c346f754854500dbefea4b997/thumb/1000) Agile Testing Condensed Japanese Edition より引用 つまり要約すると、アジャイルテストにおけるテストとはやってしまいがちな品質を保証する最後のフェーズではなく継続的に品質をチーム全員の責任おいて考えていくというプロセスのこと。 # 振る舞い駆動開発 (BDD、Behavior Driven Development) - Daniel Terhorst-Northによって提唱された自然なドメイン言語で実例のシナリオによって振る舞い (テストシナリオ) を定義するもの - よく使われるのは、「Given / When / Test」構文で、前提条件、トリガー、結果を記述する - 具体例 - ストーリー : カナダ人の買い物客として、私はレジ係に現金を渡したいと思っています。正しいお釣りをもらえることを期待して、食料品を買って正しい学の支払いをします。レジは、買い物客に渡すべきお釣りの金額を正しく報告します。 - シナリオ：買い物客が食料品の価格以上の金額を支払った時に、正しいお釣りを受け取る正常系 - Given : 私はカナダの買い物客であり、4.97ドル相当の食料品を購入した - When：レジに5.00ドル渡す - Then：0.05ドルのお釣りをもらえると期待する これが振る舞いとして定義され、テストパスの1つとしてチーム全体で理解され、新たな振る舞いやエッジケースなどを理解する助けとなる。 # 受け入れテスト駆動開発 (ATDD、Acceptance Test Driven Development) - BDDで定義される振る舞いをテストケースとしてこれらを満たすように開発を進めていく - 新たに見つけた振る舞いでテストケースを増やしていくというプロセスのことを指す - 本書で紹介されてるATDDのアプローチとして - チームがストーリーを計画するときに、望ましいまたは『ハッピーパス』の振る舞いの少なくとも1つの高レベルの例を出す - 不正行為の種類ごとに少なくとも1つの例をキャプチャする - テスターや他のチームメンバーは、ストーリーのコーディングが進むにつれて、より詳細な例を引き出す - わかりやすい比較としてTDDはコードでテストケースを記述する一方でATDDは、自然言語で振る舞いを定義して新たなことを学んでいくというプロセス # 探索的テスト - Exprlore It!の中で、Elisabeth Hendricksonは、探索テストのことを「システムについて学ぶためんテストと設計と実行を同時に行い、最後の実験から得た洞察を次に伝える」と定義している。 - テスターだけではなく、開発チームやその他のメンバーでオープンに期待するものを検証するテストを行う - この過程で新たな振る舞いや期待と異なる点を洗い出し新たな要件を見つけ出す - 探索的テストはフィーチャー単位で行われることもあり、ペアやモブで取り組むアプローチも紹介されている # 品質特性のテスト - 非機能要件をあとから検証しようとすることが多いがこれはバッドプラクティスの1つである - 品質の特性はほとんどの場合、設計が原因であり最初に行った工程をやり直すことなってしまうから - デリバリーをする開発チームはこれに積極的に対応する必要があり、早期にこれを検証するためにスパイクタスクを行うことが推奨される ## テストの四象限 ![image](https://gyazo.com/12a4ebac370f6c17546dea252ef968c1/thumb/1000) - 第 1 象限（Q1）：開発を導く技術に面したテスト - 第 2 象限（Q2）：開発を導くビジネス向けのテスト - 第 3 象限（Q3）：プロダクトを批判するビジネス向けのテスト - 第 4 象限（Q4）：プロダクトを批判する技術に面したテスト # 感想 - テストはフェーズではなく活動である - テスターもプロダクトを学習するための貢献が可能である - 品質はテスターが保証するのではなく、チーム全体で品質を考える ちなみに本書で紹介されてる参考文献がかなり充実している