チームが品質を作り込むために必要なこととは

ここ数ヶ月、品質やソフトウェアテストについて学んできた。本を読んだり入社予定のSET(業務委託中)と話したりしていて、学ぶ前の自分は品質保証を間違えて理解していたのだなと思うので共有する。

テストは品質を保証しない

2ヶ月くらい前の自分の中では、品質保証とは以下の図にあるテストの部分が品質保証にあたり、リリース前にテストすることで品質は保証される！と思っていた。

f:id:hisaichi5518:20220213024708p:plain — 雑な開発ライフサイクル

しかし、たくさんテストをしてたくさんバグを発見したとしても、バグを修正せずにリリースされれば品質を保証したとは言えないし、見つけたバグをすべて修正したとしてもプロダクトにバグがないことの証明にはならないので完全に品質を保証することは出来ない。

テストは、欠陥*1に気付く手助けをしてくれてそれはリスク軽減にもなるが、根本的に欠陥を防ぐものではないし欠陥がないことを証明するものでもない。

品質保証とはなにか？

品質保証とは、開発チーム*2が「このプロダクトは品質が高い」と言える状態にすることだと思っていた。では、開発チームはどうやって「このプロダクトは品質が高い」と判断するのか？

品質とはを語るとき「品質は誰かにとっての価値である」というワインバーグの言葉がよく引用されている。プロダクトの品質において"誰か"とは顧客*3で"品質とは顧客にとっての価値である"と言える。

つまり、プロダクトの品質が顧客にとって高いかどうかを判断出来るのは顧客だけであって開発チームではない。なので開発チームだけで「このプロダクトは品質が高い！」と主張することは出来ないのではないかと思う。

Agile Testing Condensedを読んでいると「チームで品質を作り込む」「チームで品質に責任を持つ」という言葉が出てくる。品質保証とは、チームが品質を作り込み品質に責任を持つことであると自分の中では理解した。

ちなみにこのチームのメンバーは、エンジニア・デザイナー・PdMだけではない。テスターもCSもビジネスチームもパートナー企業もチームメンバーである。またQAエンジニアは、品質を作り込み責任を持つ人ではなくチームに対して品質を作り込むように促し同様に品質に責任を持つように促す人と僕は認識している。

品質を作り込む開発ライフサイクル

ではチームで品質を作り込むには、チーム全員で実装したものをテストするのがよいのか？といえばそうではない。実装したものをテストするにはテストするまで時間がかかるし、バグを見つけても修正するのに時間がかかる。時間がかかるということは、顧客に価値が届くまで遅くなってしまうし開発チームのリソースも奪い取りアジリティがあるとは言えない。またリリース後にバグの検出が出来ておらずそのまま放置されていたりしたら顧客にとっての価値を作り込めているとは言えない。

なので、リリース前にテストを行うのではなく開発ライフサイクル自体が品質を作り込む形になっている必要がある。

チーム全員が各ステージで"テスト"をする

品質を作り込む開発ライフサイクルは、チーム全員が各ステージ（要件定義・設計・実装・リリース等）でテストを行う。

テストを行うといってもテストケースを作ってテストすることだけがテストではない。そのステージでの成果物たちに対してレビューを行い質問などをすることもテストである。このテストをステージごとに繰り返す事でアジリティを持って品質を作り込む事が出来る。

最近の自分の例で言うと自分が実装する時に与えられた要求を頭の中で整理してそのままコードを書いてテストを書くのではなく、一旦実装しようと思っているものを仕様として箇条書きにしてパートナー企業に共有した*4。それに対してパートナー企業からフィードバックや質問が来るので、それに答えたり参考にすることで仕様のバグを見つけることが出来た。このパートナー企業がしてくれた質問やフィードバックもテストであり、実装前だがテストを行ってチームで品質を作り込んだと言える。