🤖
【QA】完璧を求めないためのリリース条件
導入
QA中、立て続けに細かなバグが見つかる場合、すべてのバグに対応しようとするとリリース日が不必要に遅れてしまうため、この条件を満たせばバグが残っていてもリリースしてOKという条件を作成したものになります。
※ スクラム開発をしている現場での条件になります。ウォーターフォール式の開発をしている場合は違った条件になると思います。
方針
リリースした後にユーザーに不都合やネガティブ感情を与えない状態であることを確認できていること
ネガティブ感情を与える状態とは？
- できるはずのことができていない
- 何をしたらいいかわからない
- 見づらい
- 使いづらい
ただし、上記は仕様面の観点なので、リリース時の判断以前に仕様/デザインのレビューが実施されていることが重要となる。
リリース条件
必須条件
- 機能要件を満たしていること
- 機能要件におけるバグが解消されていること
- 正常系において画面が崩れていないこと
- 異常系においてユーザーに誤解を与える類の状態が残っていないこと
機能要件とは？
ここでは以下のように定義
Issueの背景に記載されている問題を解決する内容であること
上記はリリース時に確認することではないため、実際はIssueの完了条件が満たされていることと同義になるはず
先送り可能なもの
- 異常系において無害な表示上の問題である
- ユーザーが気づきにくいデザイン上の指摘（マージンの数値など）
- プロダクトの仕様率が低いブラウザ/デバイスのみで発生し、クリティカルなものでないもの
その他のフィードバック受けたこと
この条件だと当たり前品質しか満たせないのでは？
結論
リリース指標に当たり前品質・魅力的品質の考慮は不要
理由
そもそも、当たり前品質に相当する開発か、魅力的品質に相当する開発かはその案件が生まれた段階で決まっている。そのため、魅力的品質を上げるのであれば上流で検討するべき内容。
また、魅力的品質の定義はあったら嬉しいが無くても困らないものなので、魅力的品質が足りていなかったとしてもリリースを遅らせる理由にはならない。
Discussion