経緯
実践アジャイルテスト テスターとアジャイルチームのための実践ガイドを読んで学んだ内容を書いていきます。
筆者は、プロジェクトでテストに関することに携わったことがないですが、そのような役割に着く可能性があり、テスターの役割や仕事内容について知りたくてこの本を読みました。
かなり読み応えのある本ですが、アジャイルテストの考え方、アジャイルテスターの役割、取り組みの内容など、網羅的に学ぶことができ、いい本でした。（翻訳が悪い部分も少々ありましたが。。）
この記事ではこれからテスターの仕事をする人でどこから手をつけていいかわからない人向けて、アジャイルテストの取り組みの導入部分を説明します。
なぜテストをするのか？
なぜテストをするのか？それは、コードが正しく書かれていることを確かめるためです。
では、正しいコードとは何か？それは、顧客が求める価値を提供しているコードです。
顧客が求めるものは要件としてまとめられます。
開発終了時にコードが顧客へ提出されますが、それが要件を満たしていることはテストを通して、検証されます。
そのため、テストが必要になります。
これは、アジャイルでもウォーターフォールの開発体制でも変わりません。
アジャイルテストとは？
では、アジャイルテストは、ウォーターフォールでのテストと何が異なるのでしょうか？
ウォーターフォールの体制では、コードの開発が終わってからテストを行うので開発に追われ、テスト期間が削られてしまうということがありました。
これでは、満足にコードをテストできないことになり、バグを含んだ品質の低いコードになる可能性が高くなります。
アジャイルでは、ウォーターフォールのように一つの工程を終わらせて次の工程へいくのではなく、スプリントなどで期間を設定し、その期間内で達成できる要求単位で開発を進めていきます。
要求とは？
要求 = ストーリー + 例 + 会話
ストーリーとは？
ストーリー（ユーザーストーリー）とは、ユーザーや顧客にとって価値があるユーザー視点で書かれた機能に関する短い記述のことです。ストーリーは、顧客のコンテキストの言葉で記述されます。
ストーリーは、例えば次のような形式で記録されます。
（役割）として：私は（機能）を希望します。それにより（ビジネス価値）が可能です。
例えば、ECサイトを作っているとして、
ECサイトの買い物客として：私は、ショッピングカート機能を希望します。それにより、一括で商品を買うことができ、ユーザーの手間を減らすことができます。
例とは？
例とは、提供された機能がどのように動くべきかの例です。
ショッピングカートの例では、商品Aをカートに入れて、商品Bのページへいき、商品Bもカートに入れ、決算画面へうつると、商品A、Bが表示されて、支払い金額の合計が見える。など
この例は、一例ですが、境界の条件や極端なケースなど含めるとより多くのテストが必要になります。
会話とは？
要求を導くための会話となりますが、これは顧客とテスターだけでなく、プログラマも含まれます。
この三者が緊密に作業することで、正しい価値を提供することを目指します。
要求をテストケースへ
アジャイルテスターは、要求をコーディング可能なテストケースに変換します。
テストケースは、要求とコードの橋渡しとなります。
ストーリーからテストを作るまでのユースケース図
アジャイルテストの進め方
アジャイルでは、テストが書かれるのはスプリントの最後ではなく、要求が出た後、つまりスプリント開始初期になります。
この点が従来のウォーターフォール型と異なります。
スプリントで要求単位で開発を進めながらも、テストがそのスプリントの最後にきているなら、それはアジャイルではなく、ミニウォーターフォールというバッドプラクティスであると、書籍の中では警告されています。
つまり、アジャイルテストの進め方は、
- スプリントが開始されます。
- 顧客がストーリーを出します。
- 顧客、プログラマ、テスターで会話し、ストーリーから例を引き出します。
- ストーリー、例、会話により、要求が作られます。
- テスターは要求からテストケースを作成します。
- テストケースは、プログラマと共有され、設計に役立たれます。
- また、テスターはテストケースからテストをコーディングします。単体テストなどの一部のテストはプログラマにより作成されます。
- テストと機能のコーディングは同時に進みます。この時、テスターとプログラマは、それぞれ孤立するのではなく、よくコミュニケーションをとり、認識の齟齬がないようにします。
- 完成したテストはプログラマに渡され、機能のテストに用いられます。
- 最終的にテストとテストされた機能が顧客へ提供されます。
これにより、要求 → テストケース → テストと変換されたものが開発に使われることで、品質を基準とした開発をすることができるようになります。
このような開発体制を書籍の中では、テスト駆動開発（TDD）と呼んでいますが、TDDには、上のような開発体制としての意味と開発手法としての意味があるようです。
最後に
今回は、アジャイルテストの始まりとして、顧客、テスター、プログラマがそれぞれ連携して、要求を作っていく様子をまとめました。
ただ、そもそもアジャイルは、顧客に対して価値を提供するために、問題に対してチームで取り組むことをマニュフェストとして掲げているので、役割は分かれていますが、価値を提供するということに対しては、何人も平等です。
自分の役割に囚われず、価値を提供するということを第一にしていきましょう。