$30 off During Our Annual Pro Sale. View Details »

テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities

nihonbuson
September 16, 2020

テスト活動の納得感を持ってテストケースを激減させた話 #D3QA / Improving convinced testing activities

以下のイベントの投影資料です。
https://d-cube.connpass.com/event/187308/

お問い合わせは https://twitter.com/nihonbuson まで。

【発表資料内にあるURL】
▽P2:書籍『Agile Testing Condensed』
https://leanpub.com/agiletesting-condensed-japanese-edition

▽P36:書籍『A Practical Guide to Testing in DevOps』
https://leanpub.com/testingindevops

▽P55:プランニングポーカーかんたんガイド
https://www.slideshare.net/Ryuzee/ss-11644359/4

▽P69:Agile Testingのエッセンス #scrumosaka
https://speakerdeck.com/nihonbuson/agile-testing-essence?slide=21

▽P69:Scrumチームに「テストは活動だ」という意識を浸透させるまでの物語
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14747/scrum

▽P72:QA採用募集ページ
https://hrmos.co/pages/hrmos/jobs/160009310122

nihonbuson

September 16, 2020
Tweet

More Decks by nihonbuson

Other Decks in Technology

Transcript

  1. テスト活動の
    納得感を持って
    テストケース数を
    激減させた話
    ブロッコリー

    View Slide

  2. 自己紹介
    ● 風間裕也(ブロッコリー)
    ● 2018年10月入社
    ● QA基盤推進室 QA Evangelist
    ● 社外活動
    ○ JaSST Review実行委員長
    ○ WACATE実行委員
    ○ 書籍『Agile Testing Condensed』
    翻訳
    書籍『Agile Testing Condensed』表紙

    View Slide

  3. はじめに

    View Slide

  4. 4
    Visionalとは
    新規事業も既存事業も、

    それぞれの成長フェーズに合わせて

    スピード感をもって柔軟に推進できる体制となりました。

    株式会社ビズリーチが、
    グループ経営体制へ移行し誕生しました。

    View Slide

  5. 5
    組織体制・事業一覧

    View Slide

  6. どの言葉に興味を持っている?
    テスト活動の納得感を持って
    テストケース数を激減させた話

    View Slide

  7. どの言葉に興味を持っている?
    テスト活動の納得感を持って
    テストケース数を激減させた話
    ここ?

    View Slide

  8. スライドを読む際の注意点
    ● テストケース数の激減は結果でしかなく、
    テストケース数の削減数などは目標としていません
    ● 本スライドは、「こういうことをすればうまくいく」
    というプラクティスや理想の押し付けではありません
    ● 現場でその時点での問題点を元に改善をした話です

    View Slide

  9. 本日の内容
    ● 社内のプロダクトに半年間関わった中で行なった
    以下の4つの改善活動を紹介します
    ○ テスト技術面の改善
    ■ テスト設計フェーズの強化
    ■ テスト設計レビューの強化
    ○ テストマネジメント面の改善
    ■ 進捗状況の可視化
    ■ 負担の分散

    View Slide

  10. 当時の状況

    View Slide

  11. 開発とQAのスケジュール状況
    Sprint 1
    開発
    QA Sprint 1
    Sprint 2
    Sprint 2
    Sprint 3 Sprint 4
    Sprint 3
    時間
    ● QAは1スプリントずれてテストを実施

    View Slide

  12. 開発とQAのスケジュール状況
    Sprint 1
    開発
    QA Sprint 1
    Sprint 2
    Sprint 2
    Sprint 3 Sprint 4
    Sprint 3
    時間
    ● QAは1スプリントずれてテストを実施
    ● これしか決まってない!

    View Slide

  13. 以前のQAメンバーの意見
    人数が足りない
    みんなが何やってるのかを
    把握できない
    実施、設計に専念できない
    開発とQAが分断されてて
    やりづらい

    View Slide

  14. 課題の深掘り

    View Slide

  15. 実施に時間がかかる
    人数が足りない 実施、設計に専念できない
    ● テスト実施に時間がかかっていた
    ○ テスト設計に1割、テスト実施に9割(感覚値)
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計

    View Slide

  16. 実施に時間がかかる
    人数が足りない 実施、設計に専念できない
    ● 出来上がった画面を元にテスト設計していた。
    ○ テスト設計は実装完了しないと着手できない状態。
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計

    View Slide

  17. 設計内容
    どんなパターンなのか
    パッと見て分からない
    テストケースを
    減らす働きが発生しない
    テスト設計とテスト実装が
    混ざった状態

    View Slide

  18. 開発とQAでタイミングが異なる
    ● QAが質問したりフィードバックをする時は
    開発者は次のSprintの作業をしていた
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計
    開発とQAが分断されてて
    やりづらい

    View Slide

  19. 各自の設計および実施作業が完全に分断
    ● 設計および実施は各自で行っていた(共有はほぼ無し)
    ● 実施完了の見込みを把握するのが難しい状況だった
    みんなが何やってるのかを
    把握できない
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)










    実施
    実施
    実施

    View Slide

  20. テスト技術面の改善①
    テスト設計フェーズ
    の強化

    View Slide

  21. 設計を手厚く
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計

    View Slide

  22. 設計を手厚く
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    設計 設計 実施 設計 実施 設計

    View Slide

  23. 設計を手厚く
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    設計 設計 実施 設計 実施 設計
    ● 設計:実施=1:9 から 設計:実施=5:5 へ
    ● テスト設計は開発のSprint完了前から着手
    ○ 開発の成果物が完成しなくても設計はできるはず!

    View Slide

  24. フィードバックも素早く
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    実施
    設計 設計 実施
    設計
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    設計 設計 実施 設計 実施 設計
    ● 開発への質問も、当該Sprint中にできるようになった

    View Slide

  25. テスト技術面の改善②
    テスト設計レビュー
    の強化

    View Slide

  26. QAチーム内のレビューも手厚く
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)










    実施
    実施
    実施
    ● 観点出しはチーム全員でやっていたが、
    テスト設計以降は個々人の作業になっていた
    ○ テスト設計のレビューもほとんどできていない状態

    View Slide

  27. QAチーム内のレビューも手厚く
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)




    設計 実施
    実施
    実施
    設計
    設計
    設計
    レビ
    ュー
    ● テスト設計したものに対してレビューを行う
    ○ QAメンバー全員が参加
    ● 作成完了したものをレビューするのではなく小出しに行う
    ○ 設計の方針ぐらいの粒度もレビュー
    ● テスト設計とテスト実装で考え方を分けた
    実装
    実装
    実装

    View Slide

  28. テストプロセス(JSTQBより)
    テスト
    分析
    テスト
    設計
    テスト
    実装
    テスト
    実行
    何をテスト
    するか
    それをどう
    テストするか
    テストの実行に
    必要なものすべて
    を準備したか
    テストスイートを
    実行する
    参考:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02

    View Slide

  29. テストプロセス
    テスト
    観点出し
    テスト設計
    テスト
    実行
    テスト
    分析
    テスト
    設計
    テスト
    実装
    テスト
    実行
    具体的なテスト活動(改善前)

    View Slide

  30. テストプロセス
    テスト
    観点出し
    テスト
    パターン
    作成
    テスト
    手順作成
    テスト
    実行
    テスト
    分析
    テスト
    設計
    テスト
    実装
    テスト
    実行
    具体的なテスト活動(改善後)

    View Slide

  31. 設計物の変化(設計を手厚くする前)
    どんなパターンなのか
    パッと見て分からない
    テストケースを
    減らす働きが発生しない
    テスト設計とテスト実装が
    混ざった状態

    View Slide

  32. 設計物の変化(設計を手厚くした後)
    パターンの列挙を重視
    (実装ではなく設計)

    View Slide

  33. 設計物の変化(設計を手厚くした後)
    パターンの列挙を重視
    (実装ではなく設計)
    ● パターンを洗い出した上で、優先度が低いパターンを
    考えるようになった
    ○ チケット、観点、画面単位で実施しないものを
    選んでいた状態だったのが、
    組み合わせパターン内で
    実施しないものを選ぶように
    ● テストケースが増えていくレビューから、
    テストケースを減らしていくレビューへ

    View Slide

  34. テストプロセス内でのレビュー指摘内容
    テスト
    観点出し
    テスト
    パターン
    作成
    テスト
    手順作成
    テスト
    実行
    テスト
    分析
    テスト
    設計
    テスト
    実装
    テスト
    実行
    具体的なテスト活動(改善後)
    足りない観点を追加
    パターンに対する
    整理・削除

    View Slide

  35. 余談
    テストの振り子

    View Slide

  36. テストの振り子
    ● 「このテストを
    やれば良い」
    という、絶対的な
    方法はない
    ● 行うべきテスト数
    は振り子のように
    動く
    A Practical Guide to Testing in DevOpsより

    View Slide

  37. テストの振り子
    テスト
    やりすぎ!
    テスト
    しなさすぎ!
    A Practical Guide to Testing in DevOpsより

    View Slide

  38. テストの振り子
    テストやりすぎ! テストしなさすぎ!
    バグの報告 多く報告しますが、
    ほとんどは修正されない
    バグがあまり見つからない
    本番環境でのバグ ゼロ 多い
    レビュー時の行動 テスト範囲を頻繁に削除 テスト範囲を頻繁に追加
    テストにかける時間 「時間かけすぎでは?」 「十分やったの?」
    仲間はテストを 自分では行わない あなたが不必要だと思う
    テストまで行う
    マネージャーから テストが多すぎると言われる テストの詳細を聞かれる
    A Practical Guide to Testing in DevOpsより

    View Slide

  39. テストの振り子
    テストやりすぎ! テストしなさすぎ!
    バグの報告 多く報告しますが、
    ほとんどは修正されない
    バグがあまり見つからない
    本番環境でのバグ ゼロ 多い
    レビュー時の行動 テスト範囲を頻繁に削除 テスト範囲を頻繁に追加
    テストにかける時間 「時間かけすぎでは?」 「十分やったの?」
    仲間はテストを 自分では行わない あなたが不必要だと思う
    テストまで行う
    マネージャーから テストが多すぎると言われる テストの詳細を聞かれる
    A Practical Guide to Testing in DevOpsより

    View Slide

  40. テストの振り子
    テスト
    やりすぎ!
    テスト
    しなさすぎ!
    A Practical Guide to Testing in DevOpsより
    改善前は左の状態だった

    View Slide

  41. テストマネジメント面の
    改善①
    状況の可視化

    View Slide

  42. テスト実施がいつ終わるのか分からない
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)




    設計 実施
    実施
    実施
    設計
    設計
    設計
    レビ
    ュー
    実装
    実装
    実装
    ● テスト設計はレビューの中で進捗を把握
    ● テスト実施は個々人に任せているので
    いつ終わるか分からない
    ● テスト実施期間最終日に「間に合わない」とアラートが
    いつ
    終了?

    View Slide

  43. 実施進捗表の作成
    実施完了の数から
    進捗率を算出

    View Slide

  44. 実施進捗表の作成
    毎日のケース数を記録
    →記録する手間がかかる

    View Slide

  45. 実施進捗表の作成
    毎日のケース数を記録
    →記録する手間がかかる
    →記入を自動化

    View Slide

  46. 実施進捗表の可視化による新たな課題
    進捗が100%にならない
    →開発者の修正が終わってない

    View Slide

  47. テスト実施も2段階に!
    消化と改修確認で
    フェーズを分けた

    View Slide

  48. テスト実施も2段階に!
    消化実績:OK/NG関わらずテスト実施したもの

    View Slide

  49. テスト実施も2段階に!
    完了実績:開発が修正してテストOKになったり
         次回リリースと判断にしたもの

    View Slide

  50. テスト実施も2段階に!
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    実施
    設計 設計 実施 設計 実施 設計

    View Slide

  51. テスト実施も2段階に!
    Sprint 1
    開発
    QA
    Sprint 2 Sprint 3 Sprint 4
    時間
    消化
    設計 設計 消化 設計 消化 設計
    確認 確認 確認
    ● バグ改修の確認は、開発者による改修まで空き時間がある
    →次のSprintのテスト設計を行う

    View Slide

  52. テストマネジメント面の
    改善②
    負担の分散

    View Slide

  53. 担当者によって負担が異なる
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)




    設計 消化
    消化
    消化
    設計
    設計
    設計
    レビ
    ュー
    実装
    実装
    実装
    ● 担当1人あたりのチケット数を同じにしていた
    ○ チケットによって重さが異なっているので、
    消化完了日にばらつきが発生
    ○ 担当が割り当てられており、ヘルプしづらい

    View Slide

  54. チケットを読んだらプランニングポーカー

    View Slide

  55. プランニングポーカーとは
    ● 最初から工数(絶対値)を算出することは難しいが、
    比較してポイント(相対値)を付けることは可能
    プランニングポーカーかんたんガイド より

    View Slide

  56. プランニングポーカーとは
    ● ポイントはフィボナッチ数列の数を利用
    ○ 1, 2, 3, 5, 8, 13, ∞
    ○ それぞれの数は別の数の2倍より大きいor小さい
    ■ 5 < 3の2倍
    ■ 8 > 3の2倍
    ● メンバー全員でポイントを一斉に出して、
    出てきたポイントが違ったら自分の考えを表明
    ○ 目的は計画を立てることだけではなく
    議論をして認識の違いをすり合わせるためである

    View Slide

  57. ポイント数を基に割り振り

    View Slide

  58. 改善結果

    View Slide

  59. 発見不具合数はそのままテスト項目数削減
    本格的な改善実施

    View Slide

  60. 設計工数の減少
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)




    設計 消化
    消化
    消化
    設計
    設計
    設計
    レビ
    ュー
    実装
    実装
    実装

    View Slide

  61. 設計工数の減少
    チケット
    A(担当X)
    B(担当Y)
    C(担当Z)




    設計 消化
    消化
    消化
    設計
    設計






    実装
    実装
    実装
    ● コツが分かるとテスト設計は工数が減ってくる
    ○ テスト設計工数
    ○ テスト設計レビュー工数
    ● 1件あたりのテスト実施工数はほとんど変わらない

    View Slide

  62. ヘルプがしやすい状況に
    ● チームで行う活動が以前よりも増加
    ○ プランニングポーカー
    ○ 観点出し会
    ○ テスト設計レビュー
    ○ テスト消化進捗の把握
    ● 誰かの進捗が遅れていても、他の人がヘルプしやすい
    ○ どんなチケットをやっているか把握している

    View Slide

  63. QAメンバーの声
    ● 以前は「これは仕様です」「はい」という
    会話だったが、最近では「仕様です」と言われても、
    自分で考えて「これが仕様で良いのか」と、
    開発チームと議論できるようになった
    ● 効率的に最小限のテストケースを考えるようになった
    ● 優先度の議論ができるようになった
    ● 以前は個々で設計・実施していた状態だったが、
    「テストはチームでやるもの」という認識になった

    View Slide

  64. 開発チームとの
    さらなる協働

    View Slide

  65. 開発
    ScrumイベントにQAも参加
    Sprint 1
    開発
    QA
    Sprint 2
    時間
    消化
    設計 設計
    確認






    開発








































    View Slide

  66. 開発
    ScrumイベントにQAも参加
    Sprint 1
    開発
    QA
    Sprint 2
    時間
    消化
    設計 設計
    確認






    開発








































    開発実装完了前から
    テストパターン、
    ユースケース、
    モデルなどを共有

    View Slide

  67. 開発実装完了する前にこんなやり取りも…
    Sprint 1
    開発
    QA
    Sprint 2
    時間
    消化
    設計 設計
    確認
    P
    l
    a
    n
    n
    i
    n
    g
    開発
    R
    e
    v
    i
    e
    w
    R
    e
    f
    i
    n
    e
    m
    e
    n
    t
    R
    e
    v
    i
    e
    w
    P
    l
    a
    n
    n
    i
    n
    g
    R
    e
    f
    i
    n
    e
    m
    e
    n
    t
    開発実装前から
    テストパターン、
    ユースケース、
    モデルなどを共有
    ←状態遷移図らしきもの

    View Slide

  68. 開発と協働して動く場面が増加
    ● 大きなFeatureを取り掛かる時には事前に議論
    ○ 気になる部分、テストする場所を事前に共有
    ○ テスト観点出しやテストパターン作成を
    きっかけに仕様漏れを検知
    ○ 「このFeatureはテスト工数がかかりそうだから、
    開発の見積もりポイントが大きくなりそう」
    ● 開発が考えたテストケースのレビューに参加し、
    QAがレビュアーとして伝える活動も出てくる
    ○ この観点は必要/不要
    ○ この部分はこのように考えればパターンが削れる

    View Slide

  69. 開発とテストエンジニアが協働した事例
    ● 発表済
    ○ Scrum Fest Osaka 2020の発表(実例マッピング)
    ■ Agile Testingのエッセンス #scrumosaka
    ● 発表予定
    ○ 開発側の視点はブログ記事を近日公開予定
    ○ Regional Scrum Gathering Tokyo 2021で
    プロポーザル提出中
    ■ Scrumチームに「テストは活動だ」という
    意識を浸透させるまでの物語

    View Slide

  70. まとめ

    View Slide

  71. まとめ
    ● テスト設計を早めに着手することで、早い段階で
    開発者にフィードバックできるようになった
    ● テスト設計とテスト設計レビューを手厚くすることで
    全体の工数を削減する流れになっていった
    ● 進捗算出を自動化した
    ● テスト実施フェーズをテスト消化と改修確認の
    2つに分けることで、改修確認フェーズには
    次のSprintのテスト設計に着手できるようになった
    ● ポイントを基にチケットの大きさを把握することで、
    適切に割り振れるようになった

    View Slide

  72. おわりに
    ● 本日の発表のように、テストの考え方を用いて
    開発と協働することができるQAを募集しています!
    ○ これからテストの考え方を持ちたい人も大歓迎!
    ● 興味のある方は、下記ページなどの募集ページからの
    ご応募をお待ちしております!
    ○ https://hrmos.co/pages/hrmos/jobs/160009310122

    View Slide