この記事はJustin Rohrmanによるゲスト投稿です。
ここ10年間に私が働いた会社は、どこも程度の差はあれアジャイルを掲げていました。いずれもスクラムを実践し、スプリントを採用し、各スプリントの後にはレトロスペクティブを行って、どんな教訓を得たか、どんな改善が可能かを話し合っていました。アジャイルの特徴や形式をしっかり備えていました。
にもかかわらず、テスターにはいつも長い待機時間がありました――スプリントがあと数日という時点になるまで、スプリントに関連した作業がなにもないのが普通でした。開発チームは変化に対応できても、テスターは暗黒時代に取り残されていたのです。
いったいどうすれば、テスターもソフトウェア開発で起こる変化にもっとすばやく対応できるでしょうか？
もっと開発の近くへ
開発チームで役割が完全に分断されているとき、受け渡しが発生します。ビジネスアナリストが顧客と話をし、プロダクト オーナーがその情報から要件を作成し、開発者が要件をソフトウェアに変え、そしてテスターがエラーの起きる可能性がある箇所を発見します。
退屈なコンピューターサイエンスの書籍には、そんなことが書いてあります。受け渡しのポイントごとにプロセスに必要な時間が加算されます――そして受け渡しポイントは変化への対応を難しくする箇所でもあります。
私の経験では、開発者と密に連携することで、事態を大幅に改善できます。
何週間か前、私は開発者と協力して製品のキーとなる構成を変更しようとしていました。製品はファイルをスキャンして取り込み、スキャン時にラベルを付けてカテゴリに分類します。ラベルの中には、アクティブなラベルとアクティブではないラベルがあり、私たちのタスクは、アクティブではないラベルをなくすことでした。私たちがとった方法は、結局、あまりよくないものだとわかりました。変更の途中で他の開発者と相談し、まったく別のやりかたを選択しました。
私は開発者とペアで変更にあたっており、別の設計をコードに採用する際の話し合いにも参加していたので、開発者の作業と同時に自分のテストアプローチを修正することができました。新しいテスト戦略は別の単体テスト、ブラウザー自動化シナリオ、および微妙に異なる探索テストを必要としました。
開発者と連携していなければ、方向性の大幅な変更を何日も後になって知り、又聞きの情報に基づいてテストアプローチを補正しなければなりませんでした。
変更が発生したときにその場にいたことで、私はより柔軟に変更に対応できたのです。これがアジャイルの核心です。
技術的問題への恐れを克服する
アジャイルプロセスでテスターの存在が重要だというような記述を見ると、たいていはテストのアイデアに関する話です。テスターが設計の議論に参加し、顧客がどのように製品を使用するかについて重要なシナリオを洗い出すのを支援するとか、コードレビューに同席してコードのカバレッジについて質問したり、特定の使用シナリオが発生したとき何が起きるかを訊ねたりとか、あるいはもっと漠然と、他の人たちと会話し、会話を通じてソフトウェアの問題を発見しようとするといった話です。
会話も重要ですが、どこかの時点で実際に製品を動かす必要があります。アジャイルで働くテスターにとっての問題は、アイデアや会話ではなく、ソフトウェアをテストできるようになるのが、最速でいつの時点かということです。ツールを不安なく使えたり、ちょっとしたコードを組み立てられる能力がなければ、プロセスの初期の段階で関与するのは不可能でしょう。
ユーザーインターフェイスの下に何らかの API を置くというのは、ソフトウェア開発では一般的なやりかたです。APIによってデータを操作 （CRUD）でき、ユーザーインターフェイスがまだ存在しないときから本格的なテスト作業を始められるだけでなく、UIが利用できるようになったときにも、より多くのデータのバリエーションをより速くテストするのが容易になります。
私が最後に正社員として働いていた会社のひとつでは、マーケティングプラットフォームを構築していました。入社した時点でもう1年ほどプラットフォームを構築していて、テスターは一人でした。テスターの負荷は高く、7人の開発者がいる開発チームが毎週出してくる変更に追い付けずにいました。
製品全体が REST API プラットフォームの上に構築されていましたが、おそろしいことに、あまりテストも調査もされていませんでした。しかしこれはチャンスでもありました。私は最初の数日間でPOC用のテストを作成し、継続的インテグレーション環境で実行させました。その後、製品のリスクを特定し、リスク領域のテストを構築しました。
チームの要求を確認し、自分がテスターとして役に立てるところを探し、ツールを選定し、テストセットを実行するたびにその時々の状況に合わせて方向を転換しました。これも、どう変化に対応し、アジャイルを実践するかを示す良い例です。
改善を追求する
過去10年間のテストを振り返ってみると、進歩の大半は開発領域における改善です。開発者は、ペアプログラミング、テスト駆動、ビルドデプロイパイプラインやコンテナ技術の使用など、さまざまなことを取り入れてリリース時に高い品質を実現しています。皆が利用できるライブラリを作成したり、学んだことを共有するなど、開発者全体に貢献するという文化も強力に根付いています。
そうやって開発されたソフトウェアは、よりテストが容易であると同時に、よりテストが困難でもあります。簡単に見つけられるバグは、開発者テストによってあらかじめ取り除かれていることが多いでしょう。
それなのに、同僚のテスターたちの多くは、10年前に取り組んでいたのと同じ問題ばかりに注力しています。たとえば、どうすれば短縮された期間内に効果的にテストを行えるか、自分の作業の価値を示せるか、どうやって役に立つ自動化の仕組みを構築するか、効果的にカバレッジをレポートする方法とは、なぜこのバグは見逃されたのか、などです。
数カ月前、私が従事していたプロジェクトは厳しい納期に迫られていました。しなければならない作業は山積みでしたが、人員は足りませんでした。こういう場合、マネージャー層のおきまりの手は、納期が来るのが先か、作業が完了するのが先かはわからないが、とにかく残業させるというものです。
私たちは開発チーム全体でミーティングを行い、もっと効率化できる点はないかと話し合いました。問題のない範囲でペア作業を減らす、複数のプロジェクト間でテスターを流動的に融通する、数時間単位でミーティングを行わない期間を設けるなど、最終的には長い対策リストができました。
以前は、毎日のスタンドアップミーティングで、変更がプロセスに与えた影響と、何がうまくいって何を変える必要があるかを確認していました。スプリントのレトロスペクティブでも、変更がどうなっているか、次はどうしたらいいかを話し合う時間をとっていました。
今では、こういったことは日常的に話し合われます。どうすればもっと効果的かをいつでも話し合うことができ、新たな変更を行うのにミーティングを待つ必要はありません。
文化を変える
アジャイルマニフェストが発表されてから20年近くが経ちますが、いまだに「アジャイルになる」試みの途上にある企業や、変化に対応するふりをしながら、できるだけ硬直化した仕組みを温存できるフレームワークに肩入れしている企業も多くあります。いっぽう、成功している企業やプロジェクトでは、改善が可能な領域を積極的に追究し、新しいことを試し、結果の考察からまた別のことを試みようとする文化的な指向があります。テスターも、開発プロセスの端で待っているだけでなく、プロセスに関与できます。
自分の仕事のうち、改善できるもの、もっと効率化、あるいは有効化できるものは何でしょうか？新しいことを試し、結果を確認する。これを継続しましょう。
この記事はJustin Rohrmanによるゲスト投稿です。2005年以来、Justinはさまざまな立場でプロフェッショナルなソフトウェアテスターでありつづけています。現在は、Excelon Developmentでコンサルティングソフトウェアテスターおよびライターを務めています。業務以外では、 Association For Software Testing Board of Directorsの会長として、さまざまなプロジェクトの円滑化と発展を支援しています。
（この記事は、開発元Gurock社の Blog 「How Testers Can Be Truly Agile」2019年1月8日の翻訳記事です。）