わりとQAエンジニアやテスト会社の人参加直後あるあるだと思うのですが、表題のような問いを受けることがあります。

つまり、開発プロセスのどの段階で、どのような成果物を共有すれば、QA（テスト）エンジニアのみなさんは職務がまっとうできますか？という質問ですね。

これの答えが意外と難しいなぁと思ったのでブログ記事を書きながら考えてみようと思った次第です。考えてから書いているのではなく、書きながら考えたものをお届けしております。

一般的なべき論：なるはや、全部！

QAとはどうあるべきか、的なことを色々な方が言っていますが、それらを総合したうえで答えると以下のような内容になりそうです。

  • 参加は早い段階が望ましい
  • 情報やドキュメントはすべて共有してほしい

コーディングが終わって動かせるぞ、となってから呼ばれて「はいこれ」と言われても困りますし、ソフトウェアに含まれる問題を修正するコストは要件時点とシステムテスト時点では大きな差がある、と言われています。つまり早い段階で問題（の芽）を見つけることが重要で、そのためにQAは開発の初期段階からMTG等に参加して口出ししたい、という人が多そうです。

同様の理由で、情報やドキュメントの類はすべて見られる状態にしておいてもらえると、勝手に情報拾って問題点や疑問点について都度話すことができます。

が、たぶんこの回答って、聞いた側が求めているものではない、んですよね。。。それもわかる。

過去このへんでも少し触れています。：「QAが上流から参画する」とどうなるの？～テストフェーズだけではないQAのお仕事～ - Tech Team Journal

自分がしている回答

上記のべき論ももちろん伝えるのですが、これだけ伝えて「じゃあMTG呼びますね」となってから形骸化してしまった経験が何度もあり、単純に上流から参加するだけじゃいかんな、とも思っています。

私が伝えているのは、おおむね以下の内容です。

  • いちばん事前準備がいらない方法は、SUTを渡してもらって探索的っぽくテストすることです。
    • とりあえず何かしらのフィードバックはできるけれども、有益な指摘が出ないかもしれないし、質問やコメントが大量にいくかもしれません
  • 仕様書や設計書などのドキュメントがある場合は、開発前にそれを連携してもらえたら、コーディング中にテスト考えておけます
  • 個々のプロジェクト単位だとテストに閉じた活動になりがちなので、上2つのいずれかのパターンで2, 3プロジェクト参加してみて、そこから品質面での改善ポイント見つけましょう

情報が揃ってないとできません、だとそれはそれで相手方も困りますし、一方で「QA側でいい感じにやっておくので！」だけだと、協力している感も出ず、チームやプロセス側の改善に入っていけません。動けるけどこれがベストじゃないよ、という点は伝えつつ進めたいところですね。

とくに一人目QAやテスト会社からの常駐で現場に入ったときなどは、そのチーム・組織で開発者とQAがそれぞれいつ何をインプットに何をするのか、を明確にするために、PFDなど描きながら認識合わせていくのが一番よさそうです。