QAチームの立ち上げで何をすればよいか

最近別部署のQAチームの立ち上げにちょっとだけ関わったので、それについて思ったことの備忘録。

何からすればよいのか？

以前に比べればソフトウェアQAへの関心も高まって、関連書籍やウェブに情報がありますので、そういったものを読めば良いとは思いますし、お金があるなら専門のコンサルにお願いするという手もあります。
ここでは最低限これはやっておいたほうが良いと思うものを挙げてみます。

どういった品質を目指すのか、実装チームと協議し、合意する

これは絶対にやったほうが良いです。実装チームは一番近くにいる仲間であり、かつ最も敵になりやすい(対立しやすい)存在だったりもします。
バグか/バグでない、直す/直さないといった不毛な議論を避け、QAをスムーズに行うためにも、実装チームと「プロダクトとして目指すべき品質」についてちゃんと意識合わせをしておくのが重要です。
では目指すべき品質、というのはどうって決めればよいのでしょうか。

ユースケースから考える

このプロダクト/サービスはどういうユースケース/使用用途を想定して作られているのか。それによってどういった不具合が想定されるのか。
そしてどういった不具合が出るとユーザーに影響が出るのか。(ユーザーインパクト)
ユースケースを基にしたユーザーインパクトからテストケースを創出し、品質を担保するというやり方です。
このユーザーインパクトはバグのレベル分けにも使えたりします。そのためにも、なるべく具体的な(でも細かすぎない)内容にしておいたほうがよいでしょう。

品質特性から考える

ISO/IEC 9126やその後継のISO/IEC25010の品質特性から、それぞれの品質特性をカバーするテストケースを構築するというやり方です。
これをするとテストカバレッジが把握しやすいです。品質特性が複雑、というのであれば、まずは「機能テスト/非機能テスト」という観点だけでも良いかもしれません。

まとめ

時間がないから、とりあえずその時間内でやれることだけやるって感じに流されがちですが、最初にちゃんと組み立てておくだけで(組み立てたものを全部やる必要はない)、バージョンアップしながら計画的に品質を上げていく施策も取れますので、やっておくことをお奨めします。