【翻訳】「アジャイルテスト」、わたしたちの定義

　『実践アジャイルテスト』の著者である、Janet Gregory、Lisa Crispinの両氏による『Our Definition of “Agile Testing”』という記事を、許可をいただいて翻訳してみました。

agiletester.ca

　この本、勢いで買って店晒しにしておったのですが、最近やっと読み始めまして、とても気に入っています。あらゆる経験、知識、エピソードをとにかくぶっこんでみた！という勢いと厚さが好きです。つまみ食いでも得られるものがあると思いますので、未読の方はぜひ。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

　では、以下が翻訳です。

「アジャイルテスト」、わたしたちの定義

　Janetの講義で、学生の一人がアジャイルテストの定義を尋ねてきた。彼が求めていたようなわかりやすくきれいな定義は、3日間の講義の中では得られなかったのだ。
　Janetは自著である『Agile Testing』と『More Agile Testing』を調べてみたが、簡潔な定義はどちらにも載っていなかった。ブログポストにあるものが、最も答えに近いものだった。

　そこで、LinkedInのアジャイルテストのグループと、長く続いているアジャイルテストのYahooグループで質問してみることにした。
　「アジャイルテストの定義はどんなものだと思いますか？」

　多くの人が、アジャイルを定義しようとしたり、定義の中で「アジャイル」という言葉を使ったりしていた。この言葉を使うことにまったく同意しない人もいるが、「アジャイル」という言葉自体は形容詞であり、「アジャイルテスト」という言葉は間違ってはいないだろう。また、テスターのロールではなく、テストという活動自体にフォーカスしたかった。

　すべてのやり取りと、わたしたち自身の考えを踏まえた結果、考えついたのが以下の定義だ。

アジャイルテストの定義（Lisa Crispin、Janet Gregory）
　開発の始めからデリバリーまでに行われる協働的なテストのプラクティスで、顧客にビジネス価値をもたらす高品質なプロダクトの、高頻度なデリバリーを支える。テストの活動は、欠陥を見つけることではなく抑えることにフォーカスするものであり、「品質に対するチーム全体の責任」という考え方を強め、支えるためにある。

　アジャイルテストは、以下のようなテストの活動を含む（が、これに限られない）。
　具体的な例を挙げて開発を導く。アイデアや仮定をテストするために質問を投げかける。テストを自動化する。探索的テストを行う。性能、信頼性、セキュリティといった品質特性のためにテストする。

　この定義があなたにも響いてくれればいいが、そうでなければコメントを残すか、メールしてほしい。この定義はまだ初めのもの、ドラフトであり、変更したり適応させたりすることに、わたしたちはやぶさかでない。

　すでに寄与してくれた人に感謝したい。有用なアイデアもあればそうでないものもあったが、すべてがわたしたちの検討の役に立った。
　以下は、グループメンバーからもらったコメントや定義の一部である。上述のグループを訪れて、やり取り全体を読むこともできる。

• 重要なプロダクトを欠陥なしかつ迅速にリリースできるようにする、協働的かつ継続的な活動
• アジャイルのコンテキストでは、高速なイテレーションと継続的な改善という環境におけるテストであり、変化とプレッシャーに対応するものである。
• Elisabeth Hendricksonの『Agile Testing Overview』(pdf)を教えてくれた人もいた。これはみなさんにぜひ読んでもらいたいものではあるが・・・、21ページもあり、簡潔な定義とは言えない。
• イテレーションベースの成果物を支える迅速なフィードバックをもたらすために、短い時間で結果が得られる効果的なテスティング
• アジャイルテスティングとは、最初の1日目から、プロダクションに提供されるまでの間ずっと取り組むものである。
• アジャイルテスティングは、ビジネス価値と、顧客が求める品質に直接フォーカスする。アジャイルテスティングにおいてテスターは、品質に対して一丸となって責任を持つ、アジャイル開発チームの一員である。
• 顧客の視点からテストし、ビジネス価値を高めること。それはプロダクトのゴールなのだから、とても重要だ。Gojko Adzicの「ソフトウェア品質のピラミッド」の言葉を借りると、「使うことができる」（usable）、「役に立つ」（useful）、「成功である」（successful）というのは時に、テストの話だとは考えられていないが、わたしにとって「アジャイルテスター」は、これらすべてのレベルを意識しているべきであり、少なくともどのようにテストすればいいのかをチームに知らせるべきだ。
• 品質に対するチームの責任感を強める。
• Karen Greaves and Samantha Laingのテストマニフェストに言及する人もいた。

わたしたちは、以下のことに価値をおく。
「最後に行うテスト」よりも「ずっと行うテスト」に、
バグを見つけるよりもバグを防ぐことに、
機能をチェックすることよりも自分の理解をテストすることに、
システムを壊すことよりも最高のシステムを作ることに、
テスターの責任よりも品質に対するチームの責任に。

• アジャイルテストは、アジャイルソフトウェア開発において切り離された活動ではなく、切り離せない部分である。
• アジャイルテストは、バグが起こるのを待っているのではなく、未然に防ぐものである。
• 協働/アジャイルは、プロジェクトの最後だけ（あるいは最初の少しと最後だけ）でなく、プロジェクト全体を通じてテスターは一緒にいるのだという事実を教えてくれる。
• ユーザストーリーに対して質問を投げかけたり、受け入れ基準を作り上げるのを手伝ったりすることで、プロジェクトは良くなっていく。バグを見つけるのが遅くなるほど、プロジェクトにとって高くついてしまう。
• アジャイルテスティングは、サイクルの短い開発でペースを保つためのテストである。
• 価値とアジャイルマニフェストのプラクティスを支える、テストのプラクティス

　わたしたちが提起した問題に取り組み、探究を助けようとしてくれた、以下の方々に感謝する。誰かを漏らしていたら申し訳ありません。
　Augusto Evangelisti, Tim Western, Gaurangi (Surve) Rawat, Richard Cowling, Vivek Sharma, Wim Heemskerk, Eddy Bruin, Steven Gordon, Lionel Champalaune, George Dinwiddie, Adrian Howard。