友人が「開発者のためのテストと品質の話」というタイトルで資料を作っていましたので、ちょっと便乗します。
私ならこんな話をする、というものです。
と思って書いてたら内容が変わってしまったので、タイトルを変えています。
なお当方はQAです。そのため目線はQA目線になっています。あらかじめご了承ください。
※ここでいうQAとは、一般的に「テストエンジニア」「QAエンジニア」「品質保証部門」といった組織の人間を指しています。その業務の主な内容は、テストやレビュー、そのほか品質を高めるあるいは保証するための様々な取り組みを主導することです。
QAは何のためにいるのか
我々QAは何も開発者の皆さんを貶したりマウンティングしたくてQAをしているのではありません。もしそんなことをするQAがいたら、そいつはQAの名の下に優越感に浸りたいだけのただの愚か者です。
QAと開発者のゴールは「価値のある製品を作り、世の中に出す」という同一のものです。QAと開発が敵対構造となることがありますが、本来であれば敵対する必要はありません。
なぜQAは「ウザい」のか
なぜQAはウザいのでしょうか？
開発者なら自明なことをわざわざ何度も聞いてきて時間を取られるからでしょうか？
実運用に乗れば大した問題にもならないようなことをさも重要な指摘だとばかり鬼の首を取ったような行動をされるからでしょうか？
全てはつながっていく
一つ覚えていてほしいのが、「全てはつながっていく」ということです。開発を極めるということは、すなわちテストと品質を極めるということです。優秀なエンジニアほど良いテストをしますし、品質に対する高い意識を持ちます。
QAはうまく使え
便利屋みたいに使ってくれという意味ではありません。ただ、「テストと品質に関してプロフェッショナルな領域を持っている専門職」と思えば、活用の機会はあるはずです。
テストの自動化をやるならどこからやるのがいいか？
効率的なテストをするにはどうするのがいいか？
ほかにテストすべき観点はないだろうか？
こういった問いかけに答えられるのが良いQAです。何も答えられないような人はQAじゃなくてただの人なので、ただの人だと思って接してください。
QAという組織を持つもう一つの理由
QAという組織を作る動機の一つに、「第三者の目線を入れる」というものがあります。
「セルフチェックしました」という成果物と「第三者に見てもらいました」という成果物のどちらが品質的に信頼できそうでしょうか？
人は成果物に対して一度作る側の目線を持ってしまうと、それを綺麗に忘れて第三者の目線からチェックする、いわゆる「帽子を被り直す」ということが極めて苦手です。もちろんセルフチェックも重要ですが、全てをそれでチェックし切るのは難しいでしょう。
V＆VのValidation（妥当性確認）
開発者としてはV&Vの検証、いわゆる「正しくものを作っているか」という目線に偏ってしまうことがあります。なお、これは開発者の能力の話をしているのではなく、一般論を述べているに過ぎないので悪しからずご了承ください。
設計書通り、仕様通りに作っているからOKではなく、「そもそも正しいものを作っているのか？」という妥当性確認の視点から口出しができる人間は貴重です。顧客やユーザ目線の話もこのあたりから出てきます。実際に作ってない人間が何を偉そうに、と思うかもしれませんが、それはそれ。偉そうなやつはあとで一発蹴りを入れてやるにしても、フィードバックの機会を早期に得られることは開発者にとってもメリットのはずです。
ちなみに、「なんで今さら？」みたいな指摘をリリース間際になって言ってくるQAは怒っていいです。「もっと早く見つけてくれないか。それがあなた達の仕事だろう」と言ってやってください。
まとめ
何が言いたいかというと、「開発者とQAが協力することで、より良い製品を世の中に出していける」ということです。QAはうまく使ってください。ちゃんとしてるQAは役に立ちますし、価値のある製品の開発に大きく貢献します。
ダメなQAには「ちゃんとやれ」と言ってください。QAに対する要望を出してもいいと思います。
QAと開発者は対等であるし、それぞれがきちんと責務を果たすことでより良い開発を進めていけるようになるでしょう。
