この記事はJustin Rohrmanによるゲスト投稿です。
Salesforce.comは、組織内の一部の部署からテスト職をなくす動きを進めています。面接を受けて開発の仕事に移れる場合もありますが、確約はありません。Yahooも数年前に同じ措置を行いました。こういった組織は、テストは誰にでもできる業務であり、時間的にも場所的にもできるだけ開発に近いところで行われるべきというスタンスを取っています。
一部の組織はテスト職なしで申し分なくうまくやっていけるでしょう。その他の組織は数年のうちにこっそりテスト部門を雇用しなおし、人員削減で消えてしまった品質プラクティスを再構築しようとするでしょう。
ハンドオフ（受け渡し）があるか
「壁の向こうに放り投げる」というフレーズを聞いたことがあるなら、ハンドオフとはどんなものかはよくご存じでしょう。組織内の複数の職能のあいだで作業を受け渡すたびに、時間的な中断と情報の移管が発生します。通常、ハンドオフのフローでは、開発が始まる何か月も前にプロダクトマネージャーがユーザーストーリーを収集します。開発者はキューに積まれたストーリーを取り上げ、ときにはいくつか質問をしてコーディングに取り掛かります。単体テストが作成されることもありますが、私の個人的な経験では、ハンドオフが多い組織では、開発者テストという文化はあまり盛んではありません。
その後、それまでおそらく「テスト計画を立てたり」しながら待っていたテスターの出番がやってきます。この時点で、テスターは新しいビルドという形ではじめて新しいコードに触れることになります。変更を説明したバグトラッカーのカードから、何がどのようであるべきかについて、何となく分かる場合もあるでしょう。
私がこのようなシナリオで作業する場合は、まず見つけやすいバグから始めます。たとえばフィールドが誤ったフォーマットのデータを受け入れているためページをサブミットしたときにエラーが発生する、プラットフォームの違いによるレイアウトやユーザーエクスペリエンスの問題がある、製品を使用していると開発者コンソールにJavaScriptエラーがレポートされる、といった問題です。その後、もっと長時間にわたって製品を使った場合や、ユーザーが実際に行う操作に近いもっと複雑なシナリオで発生するような、見つけるのが難しい問題に移ります。このようなテストでは、パフォーマンス、データ負荷処理、データの保存やユーザビリティなどの問題が見つかることがあります。
これらすべて、テストセッションとしてあたりまえのことですが、重要な点は、このようなテストには時間がかかり、しかも予定されたリリースの直前まで遅らされるということです。壁の向こうに作業を放り投げるということは、多くの場合、コミュニケーションの損失を意味します。開発プロセスの部分部分を、作業をフォローすべき次の担当者が見ていないのです。変更がテスターのもとに届く頃には、多数の誤った仮定が積み重なっています。このような誤った仮定やコミュニケーション不足は、いずれも製品のリスクにつながります。
このようなスタイルで開発する組織にはテスターが、それも他の組織より多くのテスターが必要です。なぜなら、多数の未知のリスク（またの名を問題）がリリース直前まで発見されずに残っているからです。
予測が難しいソフトウェアがあるか
法的規制が適用される分野やモバイルプロジェクトなどの一部のプロジェクトでは、どんなに優れた開発プラクティスを実践していても、サイクルは比較的長くなります。モバイルプロジェクトでは、ストアで公開するためにサイクルが長くなり、デプロイメントスケジュールも予測できません。AppleでもAndroidでも、製品がストアで利用できるようになる前に通るレビュープロセスがあります。プロセスを迅速化する方法もありますが、それでも普通は何日かかかります。新しいバージョンがストアで公開された後、ユーザーが実際に最新バージョンをインストールするかどうか、またいつインストールするかは、通常ほとんど制御できません。
FDAやSECなど規制当局の承認を必要とするプロジェクトは、リリースのたびに行う何層ものプロセスがあり、そのぶんリリースサイクルに時間がかかります。
上記のどちらのシナリオでも、リリース後に問題が起これば、次のリリースにどれだけ追加の時間が必要になるかは予測できません。これらのケースでテスターは有用ですし、法規制の領域では必須です。
リカバリーを容易にするのに投資するか
ソフトウェアのバグは発生します。これは避けがたい事実です。どれだけ多くの開発プラクティスを実践して優れたコードを設計しても、どれだけテストを行っても、いずれユーザーは問題を発見します。大事なのは、重大な問題が見つかったとき、修正にどれだけ時間がかかるかです。
たとえば、ウォーターフォール型の組織の場合、顧客にリリースを提供してから次のリリースの作業を開始するでしょう。リリースサイクルが進むうちに、顧客が現在の製品バージョンを使うようになり、問題に気づきます。顧客は問題をレポートし、問題は他の10個あるいは15個のバグのバックログと合わせて次のリリースに予定されます。バグフィックスはおそらく1か月かそれ以上先の次のリリースで提供されるでしょう。問題がよほど重大であれば、パッチリリースに入れられるかもしれませんが、それでも早くて1週間はかかるでしょう。
2週間ごとにリリースしているアジャイル型の組織でもサイクルは似ていますが、バグフィックスは何か月か後ではなく1～2週間で公開されます。より早くリリースするのも不可能ではないかもしれませんが、現在の開発サイクルを阻害することになり、フィーチャーや別のバグフィックスが予定に収まらなくなるおそれがあります。(でなければ、誰かが夜も働いて修正を完了させることになるかもしれません)。
このようなモデルで作業する企業はテスターを必要とします。なぜなら、運用中に問題が見つかった場合のコストがビジネスセールスのサイクルを阻害するからです。どのリリースも、新しい機能を求める顧客や、動き出すための変化を必要としている潜在顧客に期待を抱かせるものであるべきです。リリースに計画外のバグフィックスを含めることは、ほかの何かがはじき出されることを意味します—少なくとも、持続可能なペースで働いている企業にとっては。
もう1つの選択肢は、リカバリー能力に多大な投資を行うことです。これには、コードの設計を改善するためのテスト駆動型開発などのプラクティスや、フィーチャーフラグを使用して必要に応じて変更を追加または削除できるようにすることや、高度なモニタリングによって問題が発生したらすぐに発見することや、分刻みで変更をビルドおよびデプロイする能力などが含まれます。大がかりなプロセスやツールが必要になりますが、運用中に発生したバグから回復するために必要な作業の量もやはり大きなものです。
テスターは必要か？
この質問に答える簡単な方法は、テスターを全員クビにして、どうなるか確かめてみることです。製品がだめになって顧客が離れていったなら、おそらくテスターは必要だったのでしょう。
こんな方法はお奨めしません。ソフトウェアのリスクと障害からのリカバリー能力を見て判断しましょう。顧客は製品が最初の１回で動くことを絶対に必要としていますか？リリースの周期は時間ではなく週単位ですか？問題の原因になっている変更を切り離し、コードを書いてから数分で修正をデプロイすることができますか？答えが順に「はい」、「はい」、「いいえ」なら、組織内で何人かのテスターを維持することをお奨めします。
この記事はJustin Rohrmanによるゲスト投稿です。2005年以来、Justinはさまざまな立場でプロフェッショナルなソフトウェアテスターでありつづけています。現在は、Excelon Developmentでコンサルティングソフトウェアテスターおよびライターを務めています。業務以外では、 Association For Software Testing Board of Directorsの総裁として、さまざまなプロジェクトの円滑化と発展を支援しています。
（この記事は、開発元Gurock社の Blog 「Do We Really Need Testers?」2019年2月19日の翻訳記事です。）