僕の考えるQAの全体像です
間違っている可能性もあります
なお前提として、これは私の経験上ウォーターフォール型の開発をある程度想定して書いています。
続編はこちら：私の思うQAの全体像 ver.2 - mhlyc -practice
製品のライフサイクルに寄り添い、正しいプロセスで開発できていることを確認する
製品を企画し、テストの計画や開発計画、場合によっては販売計画も立てつつ、開発要件の定義、設計と仕様化、実装、テスト、運用保守〜廃棄までの製品のライフサイクルの中で、常に意識すべきなのが品質保証です。
それぞれのプロセスの中で、やるべきことをきちんとできているか、次の工程に進むのに十分な準備ができているか確認します。
確認のためには計画がないと確認ができませんから、計画をきちんと立てることは大前提として重要です。品質確保のための施策も合わせて検討していきますから、そのインプットとして過去事例や類似のプロジェクトでの取り組み、そのほか社外での取り組みを参考にします。
また、開発の状態は移り変わっていきますから、計画が実態に合っているかは確認して計画を直さないといけません。
まず、どう開発を進めることで効率よく品質を確保していけるか常に考え、そのためのアクションをとっていくのが基本です。
プロセスが良ければ本当に品質が保証できるのか？→プロダクトそのものの品質をテストで測る
プロセスだけみるのでは不十分で、もちろん作ったものそのものを見る必要もあります。これは主にテストやレビューで確認していきます。
プロダクトに求められる機能要件・非機能要件の確認、その要件を設計・仕様化し実装できているかの確認をしていきます。
ウォーターフォール型開発ではテストレベルが段階的に分かれていることが多いため、各テストレベルにおいて目標となる品質レベルに達しているかどうかを確認していきます。目標となる品質のレベルは対象プロダクトが社会的に与える影響度や、技術的な実現難易度、コストや使用できるリソースの状況によっても変動します。しかし少なくとも、要求レベルは顧客と合意を取った上で、その約束を守れるかをテストを通じて測っていきます。
もちろん、テストは測るためだけのものではないので、テストの結果をプロセスの改善に活かしたり、次のテストの設計に活かすこともします。
プロセスとプロダクトの確認で品質は保証できるのか？
正しいプロセスで正しいプロダクトを作っていれば、品質は保証できるように思えます。
ただ、ここで品質をどう捉えるかという話があります。
結局、これまで話した内容は計画ありきのものであって、そもそも企画から抜けてましたとか、要件から漏れてましたみたいなことがあったら丸ごとダメになってしまいます。
もちろん要件定義や企画のフェーズからより良いアウトプットを出せるように工夫することも必要ではありますが、プロジェクト開始から市場へのリリースの期間が長くなってしまえばしまうほど、要件や企画の内容が市場のニーズからずれてきてしまうこともあると思います。
その場合は、別のプロセスモデルを検討すべきです。
別のプロセスモデルの検討 例：反復型開発
例えば、１サイクルで終了する予定のものを、２つに分けてサイクルを２周するようにします。
こうすることで、要件を取り込んだり企画を検討するフェーズが２回訪れることになります。これにより、市場のニーズとの大きなずれを少なくできる可能性があります。
また、要件がすぐに変更され、最初に決めたまま動かさないのが極めて難しいこともあります。その場合はアジャイルな開発手法の導入を検討します。
顧客の姿勢によるところはありますが、ウォーターフォール型開発がプロセスモデル的に絶対の正解では当然ありませんので、プロジェクトの特徴やプロセスモデルの長所・短所を鑑みて抜本的な改革を提案するのもQAの役割の一つでしょう。
まとめ
QAの役割は以下の通りです。
- 効率的・効果的なモノづくりの仕方、およびその確かめかた（＝テストの仕方）を計画する
- モノづくりを正しい（当初計画した通りの）プロセスで行なっていることを確認する
- 正しい（＝お客さんの要件に沿った）モノを作れていることをテストやレビューによって確認する
- 当初定義していたプロセス、あるいはプロセスモデルそのものに問題がある場合は問題提起し、プロセスの改善を開発と協調して行う
もちろん上記の意見は私見ですので間違いを含むことがあります。
ご意見・ご感想お待ちしております。
