More Agile Testing 第一章の非公式翻訳

実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。

More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition)

作者: Janet Gregory,Lisa Crispin
出版社/メーカー: Addison-Wesley Professional
発売日: 2014/09/30
メディア: Kindle版
この商品を含むブログを見る

第一章アジャイルテスティングはどのように進化してきたのか

私たちは、それぞれ、エクストリームプログラミング（XP）チームの中のソロのテスターとして「アジャイル」なキャリアをスタートしました。当時、XPに関する出版物のどれも、チームにテスターがいることについて言及していませんでした。プログラマーと顧客の2つの役割がありました。顧客がすべての受入テストを指定し、プログラマーがそれらを自動化することで、これで完了です。 XPカンファレンスに行くときはいつも、自分たちをテスターと認識しているだけの、ソロの参加者でした。でも、テスターには多くの付加価値があることがわかっていました。私たちは実験し、XPのパイオニアたちとテストについて話し合い、お互いにアイデアを交換しました。それぞれのチームの他のメンバーとも話し合いました。

アジャイル開発は進化し、それに伴って、アジャイルテストも進化しました。チームは、単体レベル以上のテスト自動化のためのテストライブラリとフレームワークの開発を開始しました。アジャイルテストの本を書く頃には、多くのアジャイル実践者が、エリザベス・ヘンドリクソンやマイケル・ボルトンなどの経験豊富なテスターの貢献を認めていました。ブライアン・マリックやジョシュア・ケリエフスキーなどの実務家は、開発を導くために具体例とストーリーテストを使用するというアイデアを開拓してきました。

ウォード・カニンガムは、具体例を定義することを手助けするFit（結合テストのフレームワーク）を作成し、ダン・ノースはビヘイビア駆動開発（BDD）を導入し（North, 2006）その後の人気ツールへの道を開きました。アジャイルチームは、探索的テストの価値を理解しはじめていました。アジャイルチームでのテストは、ブライアン・マリックのアジャイルテストの四象限（Marick, 2003）で示されているように、機能だけでなく多くの種類のテストを採用しました。

もちろん、アジャイルテストの成功を妨げる課題がまだありました。私たちテスターは、プログラマーが使う統合開発環境（IDE）に単体テストが組み込まれているように、あらゆる支援を熱望していたのです。同じような手軽さを、テスターがテストを定義するときにも欲しかった。ジョージ・ディンウィディーがいう「Power of Three」または「Three Amigos」を適用することには大きな利点があります（Dinwiddie, 2010）。顧客・プログラマー・テスターは、機能がどのように振る舞うべきかについての質問があればいつでも協力します。しかし、設計・ユーザビリティ・データ・その他の品質属性など、顧客の要件には多くの側面があり、それらを把握することは依然として困難であることがわかりました。本書では、それらの課題の一部を扱います。

いくつかの手法の実践者たちはこれまで、アジャイルテストの実践における溝を埋めてきました。私たちは幸運なことに、さまざまな異なるコンテキストでのアジャイルテストで成功した、他の実務家たちのストーリーを共有することができます。

重要なアイデアの1つは、すでに私たちの日常的な思考の一部になっています。アジャイルチームでのテストとは、フェーズではなく、活動です。この概念をエリザベス・ヘンドリクソン（Hendrickson, 2006）から学び、本の全体を通して、テストとはソフトウェア開発中にすべての分野で考慮する必要があるものだということを強調しています。

アジャイルでテストするためのより優れたテクニックを継続的に学び、スキルセットの深さと幅の両方を備えたゼネラリスト・スペシャリスト(訳注: 幅広い複数の領域に専門性をもつ人)がいると、チームがテストにまつわる困難に取り組むのに役立つことを発見しました。実践者たちは、さまざまな分野のチームメンバーが協力して、お互いの専門分野を「ちょうど十分に」学ぶのに役立つプラクティスとパターンを作成しました。

アジャイルアライアンス機能テストツール（AA-FTT）グループのメンバーなどの実務家は、テストのためのより優れたツールへの道を主導してきました。今日では、テストコードの作成は本番コードの作成と同等のものです。どういったフレームワーク、テストライブラリ、ドライバーがチームのニーズに適しているかを特定するためのより優れた方法を学びました。

ビジネスアナリストは、顧客の要件を発見するための専門スキルをアジャイル開発に取り入れます。テストとビジネス分析は、チームが適切なビジネス価値を提供するのに役立つ補完的なスキルをもたらします。同様に、ユーザーエクスペリエンス（UX）の専門家は、新しい機能が設計されたときに顧客の意見を得る、シンプルで優れた方法を示します。DevOpsの実践者は、開発・運用・テストのスキルを組み合わせて、デリバリーやデプロイなど、新しい次元で品質を向上させ、リリースサイクルを短縮してリスクと顧客への影響を軽減します。

数年前に比べ、探索的テストの価値を理解しているアジャイルチームにたくさん出会うようになりました。私たちの一冊目の本では探索的テストを扱っていますが、そうしたチームがもっと様々なやり方で探索的テストのパワーを活用できるであろうことは明らかです。幸運なことに本書では、アジャイルな文脈で探索的テストを実践している人々が専門知識を共有してくれています。

私たちは、テスト計画とコラボレーションに関する新しく、創造的なアプローチにも出会ってきました。今日のチームは、品質を可視化する、より多くの方法を見つけています。アジャイルテストの四象限やテスト自動化ピラミッドは、より多くの次元を表すように適応・拡張されています。

今日、より多くのチームが、ますます拡大するデバイスとプラットフォームで、モバイルアプリと組み込みソフトウェアのテストに直面しています。データを保存・管理・分析・検索・可視化する、新しいテクノロジーを備えた大規模で複雑なデータセットは、新しいカテゴリであるビッグデータとなりました。テストも引き続き進化しなければなりません。

アジャイル開発は、同じ場所にいる小さなチームのために生まれました。現在、一部の小規模なアジャイル企業だけでなく、大企業の分散チームでも利用が始まっています。大企業の組織全体でソフトウェアソリューションを使用している場合、テストは重厚な組織の制約など、さまざまな障害に直面します。同時に、組織は、高速フィードバックループと検証による学習を備えた反復的なリリースを使用して、最小実行可能製品（MVP）を開発する新しい方法を見つけています。

一冊目の本を書いた2008年に、本番環境でテストを行っていた企業はほんの一部だったため、その技術を知ることができたのは後になってからでした。今日、ログファイルのエラーを監視しながら、少ない割合の本番ユーザーに更新プログラムをリリースすることや、本番ユーザーから迅速なフィードバックを得る手法は、適切なコンテキストで行う限り、有効かつ必要な戦略です。

これらの変化とイノベーションによって、私たちや他の実践者たちが学んだことを共有するようになりました。アジャイルは絶えず改善されています。みなさんの多くはアジャイルの採用に数年かかるかもしれません。学習するにつれてプロセスを変えるかもしれません。現在直面しているテスト関連の問題は、以前のアジャイル移行の際とは大きく異なる可能性があります。この本で共有された経験が、プロダクトの品質を可視化し、プロセスを検査・適応する際に、試すべき実験のアイデアを提供してくれることを願っています。

まとめ

アジャイルソフトウェア開発の進化に伴い、ペースを維持するためにアジャイルテストを継続的に検査・適応しています。この章では、アジャイルテストの変遷を概観しました。

テストは、プロダクトの成功に不可欠な活動であり、ステークホルダーから運用やサポートに至るまでプロダクトチームのすべてのメンバーが関心を持つ活動であることを認識しています。
アジャイルチームは、ビジネス分析・ユーザーエクスペリエンスデザイン・DevOpsなど他の分野の実践者たちの手法が、チームが顧客の望む品質を構築する能力を伸ばしてくれることを、ますます認識するようになっています。
アジャイルテスト用のツールは大きな前進を続けており、アジャイルチームは学習と迅速なフィードバックをサポートするために必要なインフラストラクチャを実装できます。
アジャイルチームは、顧客や開発チームに不可欠な情報を提供するのに役立つ探索的テストやその他のプラクティスの価値を学んでいます。
アジャイルテストは、急速に変化するテクノロジーとアジャイル開発の新しいコンテキストに対応する必要があります。この本を通してこれらのアイデアを探求します。