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

すり抜けバグからの学びなの 2022.9.20 JaSST nano vol.16 mediba なりた

⾃⼰紹介株式会社medibaでauoneポータルの⽴ち上げやauコンシューマーサイトのプロジェクトマネージメントなどを担当し、品質管理部⾨の⽴ち上げなどを担当している。テレワーク⽣活で必要にかられ⾃転⾞に乗れるようになった。なりた @tkym_fuente

会社の紹介 https://www.mediba.jp/

振り返りってうまくいってます？

うまくいっているのかよくわからん KPTでやってみることが多い改善点を洗い出す次にトライすることを決めるやってはいるものの、改善サイクルがまわっているような気がしない

なぜなのか • 「次にトライすること」が実⾏されない • 次の開発ではその改善⽅法があてはまらなかったり • トライすることが実⾏されても⼿応えがない同じような商⽤障害が発⽣したり、総合テストのコストがかかっている

振り返りからの学びのサイクルをつくりたい振り返りをもとにトライしたことが品質向上に結びついていることをデータで⽰せば学びのサイクルが⽣きるのでは？

やってみたことその① 振り返りにテスト結果の分析データからわかる情報を取り⼊れる

・仕様に関わる原因が多い・総合テストよりもっと早いフェーズで解決したいものが多い

やってみたことその② トライしたことが品質向上につながっているか、定量的にはかれるメトリクスを決める DDP（Defect Detection Percentage：⽋陥検出率）ではかることにしました https://www.nttdata.com/jp/ja/data-insight/2021/0204/ 参考サイト「バグ密度・テスト密度に依存しない品質保証への挑戦」より特徴 •
すり抜けたバグの数が少なく100％に近づくとDDP率が上がる（Goodな傾向） • すり抜けたバグの数が多くて0%に近づくとDDP率下がる（Badな傾向）

DDPを取り⼊れるときに考慮したこと DDPを取り⼊れる⽬的の明確化 • チーム内での改善サイクルを回すための施策としてメトリクスを導⼊ • 時間軸でモニタリングし、改善できているかを図る⼀つの指標として使う medibaでの計測⽅法 • 総合テストで検知したバグチケットを対象とする •
総合テストで検知するのが妥当なバグと、それ以前に検知するのが妥当なバグ（すり抜けてきたバグ）かに仕分ける • バグチケットの「本来の検知すべきフェーズ」を3つのフェーズに分類（実装前・開発テスト・総合テスト）気をつけること • 案件の性質・リリースまでのリードタイム・要件の複雑さ・開発スコープなどによりDDPは変化するものでありDDPの良し悪しのみで品質をはかるのではなく、チームごとに継続してモニタリングして次に改善する施策を⾒つけるのが⼤切 • 改善施策や改善ポイントを共有することは⼤切で、DDPの推移を他チームと⽐較するものではない

やってみたことその③ テスト結果データからわかった課題を解決するための施策をやってみる l データでわかったこと：エンジニアとテストエンジニアがテスト観点の相互レビューをしていないのでテスト観点の重複や抜け漏れが多いのでは →テストケースの抜け漏れを防ぐためエンジニアとテストエンジニアでテストスコープや観点の相互レビュー l
データでわかったこと：要件定義フェーズでの課題が多いので、要件定義で⾜りない情報を作れる仕組みがあればよいのでは →要件強化バージョン仕様書フォーマットを作成し、テストエンジニアもディレクターやシステムディレクターとともに要件定義をおこなった

やってみたことその④ • 過去半年分のデータからDDPを算出して基準値を決める →平均すると約60％でした • リリース後の振り返り資料にテスト結果分析データ＆DDPを反映してモニタリングする基準値を上回れば振り返りをもとにトライしたことが品質向上に結びついていることになるのでは、と考えチーム⽬標に組み込みました。

結果

2022年4⽉から8⽉までのデータ開発案件 DDP 改善施策の実施改善施策の内容改善施策をやった案件は DDPが基準値60％を超えました

開発案件Bの振り返り資料の⼀部振り返り資料にDDPの値や、検知すべきフェーズの情報も反映しました

開発案件Bの振り返り資料の⼀部重⼤なバグが次のテストフェーズにすり抜けていることもデータで⽰し振り返りで対策を考えました

まとめ • テスト結果の分析データから「すり抜けたバグ」に着⽬して改善施策の仮説を⽴ててみた • 「すり抜けたバグ」を定量的な品質管理のメトリクスDDPでモニタリングしてみた • 開発が終わって振り返りをするときに改善施策が実施されたか、DDPの値も参考にし、次の改善施策を決める、というサイクルを回し始めた
• 案件の性質・リリースまでのリードタイム・要件の複雑さ・開発スコープなどによりDDPは変化するものでありDDPの良し悪しのみで品質をはかるのではなく、チームごとに継続してモニタリングして次に改善する施策を⾒つけるのが⼤切 • データで可視化されると改善施策もなんだかやる気が出る

最後に募集⼀覧はこちらカジュアル⾯談も実施中です。 https://hrmos.co/pages/mediba/jobs ｍedibaでは⼀緒に働く仲間を募集中です♪ 会社紹介資料はこちら https://speakerdeck.com/mediba/about-mediba

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

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

nari

Other Decks in Technology

Featured

Transcript