『アジャイル品質パターン「QA to AQ」』を読んでの感想となります。
（2024/12/8記載）
動機
今月からアジャイルでのプロダクト開発でQAリードという役割を担うこととなり学習。
今まで品質保証のためのプロセスが不十分な状態が続いたため、思考整理の拠り所とするため。
プロジェクト内容
・ウォーターフォールで新規開発
・設計〜単体テストを開発チームが担当
・結合テストをQAチームが担当
・総合テスト後、１スプリントごとにリリース迄を行うスクラム開発が継続
新規開発時に発生した問題
案件通して結合テスト不具合が低減せず常に検出。
問題に対する私の整理
・結合テストを開発チームから分離したことで、開発チームで結合テスト工程で意識すべき品質を意識できていなかった。
・QAチームだけで結合テスト不具合を拾い切るにはスコープやスキルが不足していた。
QA to AQをもとに考える今後の対策
・QAを含むOneチーム
開発チームが自分達の作ったものに対する品質を意識できる状態をつくる。
開発チームが結合テストの主体となることで、直接フィードバックを受けれる状態にする。
・プロダクト品質チャンピオン
QAチームが行っていたことと同等のテストを実施するために、
プロダクト品質チャンピオンが開発チームのフォローアップをする。
・アジャイル品質スペシャリスト、重要な品質の発見
QAチームで不足していたテストを実施するために、
・システム品質ダッシュボード、着陸ゾーン
スプリントごとの品質状態を可視化するためのメトリクスを用意する。
また、持続すべき品質状態をプロダクトチーム全体で合意する。
・品質作業の分散、できるだけ自動化
開発チームが価値あるインクリメントを作り続けていく上で、必ずしも効果的なフィードバックが期待できないテストは外部での実施も検討する。
また、テストにかける時間を低減していくために、適切な自動化を推進する。
まとめ
・AQ＝同一スプリント内での開発・テストというだけでは品質は保証ではない。
・開発チームがQAを意識して開発を進めるには適切なフィードバックを得られる状態が必要。
・その状態を持続可能とするために、テスト実施者ではないテスト推進者としてのQAが必要。
・個人的にはQAと開発チームの関係は、QAのイネーブリングチームとして、初期はコラボレーションで立ち上げ、徐々にファシリテーションに移行し、チームが充分に機能したら、必要最小限のタスクのみ実施するぐらいが良い想定。
まとめのまとめ
QA問わずロールの定義やチーム設計が超重要と思っているこの頃です。
で、よく考えず進めてしまっていた過去は反省しつつ、
リファクタしていくことも超重要というのがこれからの話。
