すり抜けバグからの学びなの

2022/09/20 JaSST nano vol.16で発表したドキュメントです

Transcript

1. すり抜けバグからの学び なの 2022.9.20 JaSST nano vol.16 mediba なりた
2. ⾃⼰紹介 株式会社medibaでauoneポータルの⽴ち上げやauコンシューマーサイトのプロジェクトマネージメント などを担当し、品質管理部⾨の⽴ち上げなどを担当している。 テレワーク⽣活で必要にかられ⾃転⾞に乗れるようになった。 なりた @tkym_fuente
3. 会社の紹介 https://www.mediba.jp/
4. 振り返りってうまくいってます？
5. うまくいっているのかよくわからん KPTでやってみることが多い 改善点を洗い出す 次にトライすることを決める やってはいるものの、改善 サイクルがまわっているよ うな気がしない
6. なぜなのか • 「次にトライすること」が実⾏されない • 次の開発ではその改善⽅法があてはまらなかったり • トライすることが実⾏されても⼿応えがない 同じような商⽤障害が発⽣ したり、総合テストのコス トがかかっている
7. 振り返りからの学びのサイクルをつくり たい 振り返りをもとにトライしたことが品質向上に結びついているこ とをデータで⽰せば学びのサイクルが⽣きるのでは？
8. やってみたことその① 振り返りにテスト結果の分析データからわかる情報を取り⼊れる
9. ・仕様に関わる原因が多い ・総合テストよりもっと早 いフェーズで解決したいも のが多い
10. やってみたことその② トライしたことが品質向上につながっているか、 定量的にはかれるメトリクスを決める DDP（Defect Detection Percentage：⽋陥検出率）ではかることにしました https://www.nttdata.com/jp/ja/data-insight/2021/0204/ 参考サイト「バグ密度・テスト密度に依存しない品質保証への挑戦」より 特徴 • すり抜けたバグの数が少なく100％に近づくとDDP率が 上がる（Goodな傾向） • すり抜けたバグの数が多くて0%に近づくとDDP率下が る（Badな傾向）
11. DDPを取り⼊れるときに考慮したこと DDPを取り⼊れる⽬的の明確化 • チーム内での改善サイクルを回すための施策としてメトリクスを導⼊ • 時間軸でモニタリングし、改善できているかを図る⼀つの指標として使う medibaでの計測⽅法 • 総合テストで検知したバグチケットを対象とする • 総合テストで検知するのが妥当なバグと、それ以前に検知するのが妥当なバグ（すり抜けてきたバグ）かに仕分 ける • バグチケットの「本来の検知すべきフェーズ」を3つのフェーズに分類（実装前・開発テスト・総合テスト） 気をつけること • 案件の性質・リリースまでのリードタイム・要件の複雑さ・開発スコープなどによりDDPは変化するものであ りDDPの良し悪しのみで品質をはかるのではなく、チームごとに継続してモニタリングして次に改善する施策 を⾒つけるのが⼤切 • 改善施策や改善ポイントを共有することは⼤切で、DDPの推移を他チームと⽐較するものではない
12. やってみたことその③ テスト結果データからわかった課題を解決するための施策をやってみる l データでわかったこと ： エンジニアとテストエンジニアがテスト観点の相互レビューをしていないのでテスト観点の 重複や抜け漏れが多いのでは →テストケースの抜け漏れを防ぐためエンジニアとテストエンジニアでテストスコープや 観点の相互レビュー l データでわかったこと ： 要件定義フェーズでの課題が多いので、要件定義で⾜りない情報を作れる仕組みがあればよ いのでは →要件強化バージョン仕様書フォーマットを作成し、テストエンジニアもディレクターや システムディレクターとともに要件定義をおこなった
13. やってみたことその④ • 過去半年分のデータからDDPを算出して基準値を決める →平均すると約60％でした • リリース後の振り返り資料にテスト結果分析データ＆DDPを反 映してモニタリングする 基準値を上回れば振り返りをもとにトライしたことが品質向上に 結びついていることになるのでは、と考えチーム⽬標に組み込み ました。
14. 結果
15. 2022年4⽉から8⽉までのデータ 開発案件 DDP 改善施策の実 施 改善施策の内容 改善施策をやった案件は DDPが基準値60％を超え ました
16. 開発案件Bの振り返り資料の⼀部 振り返り資料にDDPの値 や、検知すべきフェーズの 情報も反映しました
17. 開発案件Bの振り返り資料の⼀部 重⼤なバグが次の テストフェーズに すり抜けているこ ともデータで⽰し 振り返りで対策を 考えました
18. まとめ • テスト結果の分析データから「すり抜けたバグ」に着⽬して改善施策の仮説を⽴ ててみた • 「すり抜けたバグ」を定量的な品質管理のメトリクスDDPでモニタリングしてみ た • 開発が終わって振り返りをするときに改善施策が実施されたか、DDPの値も参考 にし、次の改善施策を決める、というサイクルを回し始めた • 案件の性質・リリースまでのリードタイム・要件の複雑さ・開発スコープなどに よりDDPは変化するものでありDDPの良し悪しのみで品質をはかるのではなく、 チームごとに継続してモニタリングして次に改善する施策を⾒つけるのが⼤切 • データで可視化されると改善施策もなんだかやる気が出る
19. 最後に 募集⼀覧はこちら カジュアル⾯談も実施中です。 https://hrmos.co/pages/mediba/jobs ｍedibaでは⼀緒に働く仲間を募集中です♪ 会社紹介資料はこちら https://speakerdeck.com/mediba/about-mediba