20250226 presentation

2025/02/26　QA Tips LT会 - vol.3
プレゼン資料

Transcript

1. アジャイルQAを定点観測している話 Kazuhiko Kikuno
2. Kazuhiko Kikuno 社 つくるAI株式会社（トグルホールディングス（株）傘下） 属 プロダクトユニット 職 QAエンジニア（マネージャー） 業 横断QAチームの管理全般
3. 弊社のスクラムチームのスプリント スプリント 開発エンジニア 単体テスト(UT) QAエンジニア 結合テスト(IT) QAエンジニア 総合テスト(ST) 1週間(通常5営業日) 開発 UT プラ ンニ ング テスト設計 レビュー IT ST テスト設計 レビュー 総合テストは改修確認を含め スプリント終了期限までに終了基準を満たせるよう稼動させる 単体テストの終了基準を満たしたら ・結合テストが始められる 結合テストの終了基準を満たしたら ・総合テストが始められる プランニングで仕様が固まったら ・開発が始まる ・IT/STのテスト設計が始まる
4. スクラムチームで継続的に開発されている生産物とその活動が スプリントごとにどれぐらいの安定感を捻出しているか 一定のスタンスで観察・測定すること。 アジャイル QAの定点観測とは？ 目的：継続性のある測定・観察で、 物と活動がどれだけ良くなっているか／悪くなっているかを受け止める
5. 何を使って測定するのか？
6. 何を使って測定するのか？ ゾーン分析
7. 定量的な品質管理をする上でテスト品質を可視化する手法 ゾーン分析とは？ ゾーン８ ゾーン５ ゾーン６ ゾーン７ ゾーン１ ゾーン２ ゾーン９ ゾーン３ ゾーン４ ↑ バグ密度 （件 / KSLOC） ケース密度（件 / KSLOC） → テスト密度とバグ密度の指標を分析するために 2次元座標上に3×3のゾーンを設定する 基準値(下限) 基準値(上限) 基準値(上限) 基準値(下限)
8. 算出したケース密度、バグ密度がどのゾーンに収まったのか、チャートに則って評価する。 ゾーン分析のみかた
9. 測定の準備 (※)ソフトウェア開発データ白書 2018-2019 情報通信業編「 7.5.8.SLOC規模あたりのテストケース数、検出バグ数：全開発種別」に掲載された値 測定期間 2024年7月から1ヶ月単位（4〜5スプリント分の合算） 開発ソースコード行数 各スプリントでコーディングされたソースコードの増分（行数） テスト密度を算出するテスト数 各スプリントのIT/STで実施されたテストケース数 バグ密度を算出するバグ数 各スプリントのIT/ST期間内で検出されたバグ数 ゾーンの基準値（下限／上限） 上限：IPA発行資料(※)の基本統計量(P75)の値 下限：IPA発行資料(※)の基本統計量(P25)の値
10. 結果（2024年7月） ケース密度 測定結果 最小値(※) P25(※) 中央値(※) P75(※) 最大値(※) IT 59.86 0.6 38.2 59.9 106.4 1513.5 ST 58.74 0.5 8.3 17.3 33.7 108.1 バグ密度 測定結果 最小値(※) P25(※) 中央値(※) P75(※) 最大値(※) IT 0.15 0.00 0.55 1.21 2.64 27.03 ST 1.58 0.00 0.01 0.12 0.68 7.14 (※)各ベンチマーク値：ソフトウェア開発データ白書 2018-2019 情報通信業編「 7.5.8.SLOC規模あたりのテストケース数、検出バグ数：全開発種別」より引用。
11. 結果（第1回目の測定） ゾーン3： テスト内容は適切 (点検してもいいかも ) ゾーン6： 前工程の品質確保不足。要内容点検
12. やってみてわかったこと なんだ、STはアレだったけれどIT….まあまあいいじゃん。
13. やってみてわかったこと STは前工程点検しろ、って言われてるのに、 ITは内容適切ってマジで大丈夫？
14. やってみてわかったこと ITで不具合を見つけるとその場で修正 →解決、という文化が根付いており、 ITのバグ数が正しく計上出来ていないのが原因 STあんなに荒れたのに、ITって？
15. 結果（それから半年後） ケース密度 測定結果 最小値 P25 中央値 P75 最大値 IT 97.11 0.6 38.2 59.9 106.4 1513.5 ST 60.95 0.5 8.3 17.3 33.7 108.1 バグ密度 測定結果 最小値 P25 中央値 P75 最大値 IT 8.68 0.00 0.55 1.21 2.64 27.03 ST 0.99 0.00 0.01 0.12 0.68 7.14
16. 結果（2025年1月までの累計） 8月 7月 9月 10月 11月 12月 1月 8月 11月 9月 10月 7月 12月 1月
17. やってみてわかったこと (改)と課題 • STを数こなして荒れる　 →　IT以前のフェーズにまだ何らかの問題が残っている。 • 正しくITのバグ数を正直に数え直して本当の「不味さ」が見えた。 • ITに不安を覚えるため STも荷重にテストを積み、その結果新しいバグを見つけてしまう 悪循環にも陥っている。 • 立て直すには、初期フェーズから愚直に品質を見直す。
18. 正直に向き合えば、正しい課題が見つかる。 見つかった課題に正しい打ち手を施せば、課題は必ず解決する。（はず） まとめ
19. 正直に向き合えば、正しい課題が見つかる。 見つかった課題に正しい打ち手を施せば、課題は必ず解決する。（はず） まとめ うちの開発チームは元気があってよろしい！
20. Thanks!! https://toggle.co.jp/ https://note.com/toggle/n/nfb93dc7c3ec3?sub_rt=share_pw