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

by nihonbuson

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

はじめに

Slide 4

Slide 4 text

4 Visionalとは新規事業も既存事業も、  それぞれの成長フェーズに合わせて  スピード感をもって柔軟に推進できる体制となりました。  株式会社ビズリーチが、グループ経営体制へ移行し誕生しました。

Slide 5

Slide 5 text

5 組織体制・事業一覧

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

当時の状況

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

課題の深掘り

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

QAチーム内のレビューも手厚くチケット A(担当X) B(担当Y) C(担当Z) 観点出し設計設計設計実施実施実施 ● 観点出しはチーム全員でやっていたが、テスト設計以降は個々人の作業になっていた ○ テスト設計のレビューもほとんどできていない状態

Slide 27

Slide 27 text

QAチーム内のレビューも手厚くチケット A(担当X) B(担当Y) C(担当Z) 観点出し設計実施実施実施設計設計設計レビュー ● テスト設計したものに対してレビューを行う ○ QAメンバー全員が参加 ● 作成完了したものをレビューするのではなく小出しに行う ○ 設計の方針ぐらいの粒度もレビュー ● テスト設計とテスト実装で考え方を分けた実装実装実装

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

余談テストの振り子

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

テスト実施がいつ終わるのか分からないチケット A(担当X) B(担当Y) C(担当Z) 観点出し設計実施実施実施設計設計設計レビュー実装実装実装 ● テスト設計はレビューの中で進捗を把握 ● テスト実施は個々人に任せているのでいつ終わるか分からない ● テスト実施期間最終日に「間に合わない」とアラートがいつ終了？

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

テスト実施も2段階に！消化実績：OK/NG関わらずテスト実施したもの

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

改善結果

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

設計工数の減少チケット A(担当X) B(担当Y) C(担当Z) 観点出し設計消化消化消化設計設計設計レビュー実装実装実装

Slide 61

Slide 61 text

設計工数の減少チケット A(担当X) B(担当Y) C(担当Z) 観点出し設計消化消化消化設計設計設計レビュー実装実装実装 ● コツが分かるとテスト設計は工数が減ってくる ○ テスト設計工数 ○ テスト設計レビュー工数 ● 1件あたりのテスト実施工数はほとんど変わらない

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

開発 ScrumイベントにQAも参加 Sprint 1 開発 QA Sprint 2 時間消化設計設計確認プランニング開発スプリントレビューリファインメントスプリントレビュープランニングリファインメント

Slide 66

Slide 66 text

開発 ScrumイベントにQAも参加 Sprint 1 開発 QA Sprint 2 時間消化設計設計確認プランニング開発スプリントレビューリファインメントスプリントレビュープランニングリファインメント開発実装完了前からテストパターン、ユースケース、モデルなどを共有

Slide 67

Slide 67 text

開発実装完了する前にこんなやり取りも… 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 開発実装前からテストパターン、ユースケース、モデルなどを共有 ←状態遷移図らしきもの

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

まとめ

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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