ウォータフォールプロジェクト管理は開発とテストを異なる二つのステップに分割します：開発者はフィーチャーを構築し「壁に投げつけ」、QA チームがテストを行います。QA チームは詳細なテストプランを作成して実施します。また、彼らはリグレッション（新しい作業によって生じたバグや再発したバグ）が既存のフィーチャーに見られないか、丹念にチェックしながら不具合を整理します。
多くのチームはこのようなウォーターフォール型または他の古典的なテスト・モデルを使用しているため、製品が大きくなるにつれテスト量は飛躍的に増加し、QA チームは常に付いていくのに必死です。プロジェクト所有者は、リリースを遅らせるか、テストをスキップするかという望ましくない選択に直面します。（99% どちらが勝つか、おわかりでしょう？）一方、開発チームはすでに他の作業に着手しています。つまり、技術的負債が積もるだけではなく、それぞれの不具合に取り組むことにより、コード・ベースの 2 か所の間でコンテキスト切り替えが必要となり、大きな犠牲がともないます。何ともばかげた損害です。
さらに悪いことに、QA チームは昔から、どれだけバグを見つけるかにやりがいを感じており、これでは開発者が守りに入るだけです。開発者と QA 双方にとって、コードのバグを減らしつつ、プロジェクト所有者が強いられる過酷なトレードオフを排除できる、今よりも良い方法があったとしたらどうでしょう？より良い万能のソフトウェアを作れると思いませんか？
アジャイルと DevOps テストに入りましょう。
従来の方法からアジャイルテスト方法への移行
アジャイルと DevOps チームの目標は、持続的に品質を伴う新しいフィーチャーを納品することです。しかし、従来のテスト方法論はアジャイルまたは DevOps フレームワークの内容に合いません。開発ペースに合った、各ビルドで品質を保証するための新しい方法が必要になります。アトラシアンでは、アジャイルなテスト方法を採用しています。Jira Software のシニア QA チーム・リードの Penny Wyatt とともに、テスト方法を詳しく見ていきましょう。
クレジットカードの負債が少しずつ膨らむように、最初は小さな問題だったものが雪だるま式に大きくなり、あっという間にチームの重要なアジリティを脅かします。雪だるま式に大きくなる技術的負債に立ち向かうために、アトラシアンでは、開発者が偉大なチャンピオンになれる力を与えます (というよりも、期待します)。開発者は品質をコントロールする主要なスキルを製品に活かしてくれるものと確信しています。
- 開発者はコードに関する問題を解決することが得意である。
- 開発者は作成したテストが失敗した時に、他の誰よりもそれを修正する能力がある。
- 開発者はフィーチャー要件とテストの意義を理解して、より良いコードを作成するものである。
わたしたちは、バックログの各ユーザーストーリーには、フィーチャーコードと自動化テストコードが必要であると考えています。テストチームが自動化テストを行っている間に開発者をフィーチャーコードにアサインするチームもありますが、ひとりのエンジニアが製品一式のデリバリーを担当した方がより効果的だと思っています。
新しいフィーチャーのバグと既存のフィーチャーのリグレッションは別々に扱いましょう。開発中にバグが見つかったら、時間を割いて間違いを理解し、修正してから先に進んでください。リグレッションが見つかったら (以前は機能していたものが機能しなくなった、など)、再発する可能性があります。将来リグレッションが再発しないよう、自動化テストを作成します。
これは、開発者が単独で作業するという意味ではありません。チームに QA エンジニアがいるということも重要です。フィーチャーの開発にとって QA エンジニアは重要な視点をもたらすうえ、優れた QA エンジニアはバグが隠れていそうな場所を認識しているため、予測して開発者にアドバイスできます。
探索的テストを通して人の手によるチェック
わたしたちの開発チームは QA チームのメンバーと探索的テストでペアを組み、有益に実践することで深刻なバグを開発中に回避しています。コードレビュー同様、このおかげでテストに関するナレッジを開発チームに伝えることができています。開発者が今より優れたテスターになれば、最初から今より優れたコードに仕上がります。
しかし、探索的テストは手動テストなのでは？いいえ。少なくとも、手動のリグレッションテストとは違います。探索的テストはリスクベースで、批判的思考によるアプローチです。リスクに関するナレッジ、実装の詳細、カスタマーニーズを用いてテストを実施できます。このことをテストプロセスの早い段階で知っていれば、開発者や QA エンジニアはテストケースのスクリプト、詳細なテストプラン、要件などを必要とせず、問題を早急に包括的に発見できます。探索的テストセッションから得た洞察を元のコードや自動化テストにフィードバックすることができるため、従来の手動テストよりもずっと効率的だといえます。また、探索的テストではある意味フィーチャーを使用する体験ができ、それはテストスクリプトで得られるものではありません。
品質を維持するには探索的テストと自動化テストが必要です。新しいフィーチャーが開発されたら、自動化テストのみを実施するのではなく、新しいコードが品質基準を満たしているか、探索的テストを実施してもっと広範な意味で確認します。自動化テストにより発生するリグレッションからしっかりとコードを保護することに加え、使いやすさ、視覚的なデザイン、フィーチャーの無駄全般、などを確認します。
変更は本当に難しい
アジャイルテストの経験がうまくまとまった個人的なストーリーをお話しましょう。仕事を始めたころに管理していたエンジニアチームのことをわたしは今でも覚えています。そのチームは、自動化テストの作成に強い抵抗を持っていました。何故なら「それは QA の仕事」と思われていたからです。バグとなるコードが何度となく繰り返し作成され、自動化テストがチームの仕事を遅らせると彼らが考えるすべての理由を聞きました。それからは、わたしは断固として譲りませんでした：新しいコードは自動化テストで実証する必要がある。
一度のイテレーションのあと、コードは良い方向に向かい始めました。テストを作成することにもっとも反対していた開発者が、テストが失敗すると一番早く行動を起こすようになったのです。何度かイテレーションを繰り返すうち、自動化テストも改良され、複数のブラウザをカバーする規模になり、わたしたちの開発カルチャーも良い方向に向かいました。フィーチャーの完成までには、今までより長くかかりました。しかし、バグとやり直し作業が激減し、結果的には莫大な時間を節約できました。
変更が簡単であることは滅多にありません。ですが、多くのことに価値があるように、新しい方法に取り組めば、「なんでもっと早くやらなかったのだろう？」という疑問しか残らないはずです。
