はじめに
先日、関西PHP勉強会でLTを行いました。
簡単なテストレベルの概念やテストタイプの概念を紹介したのですが、そこで頂いた質問について改めて考え、回答したいと思います。
「テスターはどのタイミングで関与するのが良いのでしょうか？」
早期テストで時間とコストを節約
ソフトウェアテストの原則として、「早期テスト」というものがあります。
これは、プロジェクトのできるだけ早期の段階でテストの視点を加えることで、早期にバグの予防・検出を行い、品質リスクと品質コストを軽減することができる。結果として手戻りの抑制にもつながるという原則です。これは、ほとんどのプロジェクトで適用できる考えです。
したがって、テスターが参加するタイミングは、プロジェクト開始時、要件の策定段階など、何かが始まった時です。
少なくとも、テスターが参加できる段階になったら、その時点で参加することが望ましいと考えられます。
最も望ましい早期テスト
最も望ましい早期テストは、会社設立時だと考えます。
会社設立時に、テストの考え方、あるいはそれからより踏み込んで、品質保証の考え方をきちんと取り入れ、プロセス品質、内部品質、外部品質ともに十分に組み込める業務プロセス、開発プロセスなどを整備しておくことが理想です。
TQMに基づいた会社設立は、最も望ましい早期テストだと考えます。
プロジェクト開始時点、製品企画時点
とはいえ、そこまでできる会社は多くないでしょう。
次の段階としては、プロジェクト開始時点、あるいは製品の企画時点が考えられます。
様々な開発プロセスや仮説検証の方法を考える中で、テストの視点を加味して、どのように進めるのが最適か、また、その中でどのようにテストを行うのか、テストプロセスをどのように組み込むのか、あるいはどの程度テストすれば十分に仮説検証ができるのか、といったことをテスターの視点で考えることが大切です。
仕様が出来上がってからではなく、ビジネスの観点、仕事の進め方の観点を考慮する際に、テストの気持ちに思いを馳せることが重要です。
仕様や要件の策定開始時点
それでも難しい場合はあるでしょう。
その場合は、仕様や要求を考える時点で、テストへの配慮が必要です。
この場合、開発プロセスは決まっているかもしれませんが、製品仕様を検討する中で、様々なテスト容易性の配慮、品質特性の配慮が可能になるからです。
レビューはテスターの専門分野でもあります。
より効果的なレビューの技術を適用することも考えられるでしょう。
現実的な線では、この段階でテスターが参加可能ことが最も多く、そして、多くのテスターの実力が発揮できるタイミングだと思います。
仕様が出来上がった時点
仕様や要件のFix後はテスターが参加できる最も遅い段階です。
これより遅い段階は、基本的に許容できない、あるいはほぼ確実にテストの失敗につながると言っても過言ではありません。
可能であれば、仕様を作成している最中からテストを検討することが望ましいです、多くのテストに理解がない多くの現場やコストがかけられない現場では、調達の関係でテストベース（仕様）が出来上がった段階で、テスターが作業を開始することがあります。
これは、ソフトウェアの詳細設計やコーディング中に、テスターがテスト設計やテスト計画を行うということです。
この時点で、テストを考慮したプロジェクト計画は立てられない可能性があります。
しかしながら、こういった場合でも何とか良い仕事をして成果を上げるのがテスターの役割だと考えます。
それ以降
コーディング中、特にソフトウェアが完成した後にテスターを集めている現場も少なくないでしょう。
これは基本的に手遅れです。
しかし、そのような状況でも、素早くテスト設計を行ったり、探索的テストを採用したりして、何とか頑張ることも必要です。
早期から入ってもうまく働けないテスターもいる
ただし、これらの提案は、テスター自身がある程度の実力を持っていることが前提となります。
例えば、「テスト実行以外したくない」「テスト設計の実力がない」「ビジネスについて考えたくない」といったレベルのテスターであれば、早期から参加してもあまり意味がないでしょう。
したがって、テスターの実力に応じて、テスターの関与のタイミングをある程度考慮する必要があります。
また、早期から参加しているプロジェクトマネージャーやビジネス側の人の品質への理解も重要です。
テスター自身に実力があっても、品質へのモチベーションが低い状態では、早期での参加があまり意味をなさなくなってしまいます。
必ずしもテスターは必要ではない
ここで「テスター」という言葉を使いましたが、必ずしもテスターという固有の役割を持つ人間が必要というわけではありません。
テスターという独立したロールがいるというよりも、テストの知識や視点を早期から取り入れることが重要です。
したがって、どうしてもテストの専門家をプロジェクトの早期から参加させられない場合は、自分自身がテストの知識や知見を持ってプロジェクトに貢献することが必要だと考えます。
