プログラマが知るべき97のこと/プログラマとテスターが協力してできること
テスターとプログラマが協力し合えば、奇跡が起こせます。両者の協調が進むと、まず、問題管理システムを使ってバグ情報をやりとりする時間が減らせるでしょう。そして、「バグなのか、それとも新機能なのか」を見極めるための時間も減らせます。その分の時間を、ソフトウェアの機能をより充実させること、顧客の要望に応えることに使えるのです。両者の協調の機会は数多くあります。実は、コーディングの開始前から協力し合うことも可能なのです。
たとえばテスターは、顧客と協力し、FIT(Framework for Integrated Test)などのツールを使用して顧客のドメインの言葉で受け入れテストを書き、それを自動化することができます。受け入れテストをコーディング開始前に渡されれば、プログラマは、ATDD(Acceptance Test-Driven Development :受け入れテスト駆動開発)を実践できます。プログラマはテストの実行のために必要になる部品を作り、テストに合格するようにコードを書きます。このテストは「回帰スイート」の一部となります。テスターとプログラマがこういうかたちで協力すれば、機能テストは早いうちに完了するので、空いた時間を探索的テスト(exploratory testing)にあてることができます。境界条件のテストや、全体的な流れのテストができるのです。
さらに一歩進めることもできます。プログラマがコーディングを始める前に、テスターは「どういうテストをするつもりか」という考えを伝えるだけでなく、同時に、プログラマに何か提案はないかと尋ねるのです。そうすれば、プログラマからは、テストカバレッジをあげるのに役立つ情報、あるいは、どれが必要なテストでどれが不要なテストかの見極めに役立つ情報が提供されることが多いのです。テストについて早い段階から知っていれば、プログラマは、これから書こうとするコードがどういうものなのかをかなり明確にしてからコーディングを始めることができます。それによってバグの発生は大幅に減らせるでしょう。たとえば私が関わったあるプロジェクトでは、私がFITを使って書いてプログラマに提供したテストにより、ワイルドカード検索の際、クエリに具体的にどういう実行結果が求められるかが明らかになりました。プログラマは当初、入力された文字列を補完して検索する機能だけをイメージしていたのですが、どうもそれだけではないとわかったのです。その後、顧客と十分に話し合い、正しい解釈を基にコーディングを始めることができました。テスターとプログラマが協力し合えば、こうしてバグの発生を未然に防ぐことができ、時間も節約できるのです。
プログラマとテスターは自動化に関しても協力し合うことができます。当然のことながら、プログラマは優れたコーディングプラクティスがどういうものかを理解しています。テスターはプログラマの助けを借りれば、チーム全体で利用できる堅牢なテスト自動化スイートを作ることもできるでしょう。私の知る限り、テストの設計が悪いせいで、自動化プロジェクトが失敗するということが少なくないようです。設計が悪いテストとは、不要なテスト項目が多すぎるものや、テスト項目の独立性が低いものなどを指します。テスターに技術的な知識がないと、独立性の低いテスト項目ができてしまうことがよくあります。自動化などの作業においては、テスターがボトルネックになることが多いので、是非プログラマと協力して効率化をはかるべきでしょう。協力すれば、プログラマも、テストについて早いうちに知ることができます。協力と言っても、簡単なツールを提供するくらいで済むこともありますが、その際に得られるフィードバックは、長い目で見ればコードの質を高めるのに役立ちます。
テスターは、ソフトウェアを破壊し、プログラマの書いたコードからバグを見つけ出すことだけが自分の仕事である、という考え方をやめるべきです。そしてプログラマは、テスターのことを「自分たちの邪魔をする敵」となどと考えるべきではありません。そういう考えをやめれば、協調できる可能性が高まります。プログラマが、品質向上も自分の仕事の一部であると考え、テストしやすいコードを書くことも当然の責務であると考えるようになれば、回帰テストの自動化をテスターと共同で進めることなども簡単にできるようになるでしょう。プログラマとテスターのチームワークで、プロジェクトはまるで奇跡のようにうまくいくはずです。