ヤプリQA課題の見える化

by 山口茉莉江

Slide 1

Slide 1 text

Yappli Tech Conference 0 2024.10.17 ヤプリQA課題の⾒える化

Slide 2

Slide 2 text

Speaker 開発統括本部プロダクト開発本部開発1部 QA2グループ⼭⼝茉莉江 ● 2023年2⽉にヤプリへ⼊社 ● QAエンジニアとしてプロジェクトのQA計画〜実⾏まで管理 ● 不具合分析によるプロセス改善検討に注⼒ ● 好きなものは国内旅⾏/お酒

Slide 3

Slide 3 text

⽬次 1. QAプロセスにおける現状の課題 2. リグレッションテストの⼯数削減施策 3. 不具合分析による要因の可視化 4. まとめ

Slide 4

Slide 4 text

ヤプリQAの紹介

Slide 5

Slide 5 text

ヤプリのQA業務 00 ヤプリQAの紹介 QA 3本の柱 ● この他にも開発〜QAまで横断して利⽤する共通観点の作成、QA業務で発⽣する細かいタスクの⾃動化など様々な改善も業務として実施個別QA 不具合や機能改善に対するテスト（機能テスト）週次QA リリース前の動作確認（リグレッションテスト）プロジェクトQA 新規開発プロジェクトや開発⼯数規模の⼤きい機能に対するテスト（機能テスト、モンキーテストなど）

Slide 6

Slide 6 text

ヤプリのQA業務 00 ヤプリQAの紹介

Slide 7

Slide 7 text

QAプロセスにおける現状の課題

Slide 8

Slide 8 text

01 QAプロセスにおける現状の課題リグレッションテストの肥⼤化 1 ● 新規機能開発（プロジェクトQA）や不具合‧機能改善（個別QA）が完了した後、⼤量のテストケースが纏まって追加される ● 過去に追加したテストケースの定期的な⾒直しが⾏われていない ● テストケース追加のルールや運⽤フローが存在しない ● テストケース追加の⽅針を定める ● 追加済みのケースに対しては項⽬の⾒直しを実施

Slide 9

Slide 9 text

01 QAプロセスにおける現状の課題個別QA(機能テスト)の不具合検知件数の増加 2 ● 個別QAで不具合の検知件数、差し戻しが増加していると感じられる ● 不具合件数が増加していると感じるが具体的な数値に落とし込めていない ● 不具合修正後に修正箇所以外でデグレが発⽣している ● 不具合発⽣の要因を可視化できていない ● 不具合検知件数の集計 ● 不具合発⽣要因などの可視化 ● 定期的な集計と分析を実⾏

Slide 10

Slide 10 text

リグレッションテストの⼯数削減施策

Slide 11

Slide 11 text

リグレッションテスト⼯数削減のために取り組んだ4つのこと 02 リグレッションテストの⼯数削減施策

Slide 12

Slide 12 text

● リグレッションテストによる不具合検知件数の集計 ● テストケースの⼀部を実施対象の機能に限定 ● 実施対象OSの選定 ● テストケース追加時のルール作成 02 リグレッションテストの⼯数削減施策

Slide 13

Slide 13 text

Slide 14

Slide 14 text

● 前提 ○ リグレッションテストケースは4本存在する ■ CMS（SV/Front） ■ アプリ ■ Block UI CMS（SV/Front） ■ Block UI アプリ ○ リグレッションテストケースには”⼿動実施ケース”と”⾃動テストケース”が存在する ○ 検知件数の数値化は、⼿動と⾃動化両⽅のケースを対象に計測リグレッションテストによる不具合検知件数の集計 02 リグレッションテストの⼯数削減施策

Slide 15

Slide 15 text

リグレッションテストによる不具合検知件数の集計 02 リグレッションテストの⼯数削減施策全体 21 件⾃動化 2 件⼿動実施 19 件集計結果

Slide 16

Slide 16 text

● 集計結果からの詳細分析 ○ ⼿動実施分の件数が多く、⾃動化テストケースでは発⽣件数が少なかった ○ リグレッションテストで検出した不具合の中で、各個別QA対応のマージ要因はほぼ無かった ○ 検出不具合の多くは、理想の検知タイミングは個別QAフェーズだった ○ OSver違いの不具合はほぼ発⽣していない ○ 不具合の発⽣した機能はリリース対象機能のみだったリグレッションテストによる不具合検知件数の集計 02 リグレッションテストの⼯数削減施策リグレッションテストケースの対象は、リリース対象機能のみで⼗分だとわかった

Slide 17

Slide 17 text

Slide 18

Slide 18 text

テストケースの⼀部を実施対象の機能に限定 02 リグレッションテストの⼯数削減施策ケースの対象 ● アプリのテストケースケースの選定⽅法アプリのケースを以下の3つの優先度に分類 ● プッシュ通知などユーザー利⽤率の⾼い機能：毎週マストで実施 ● 主要な機能：⽉に⼀度で実施 ● 上記以外の機能：リリース対象に該当する時のみ実施

Slide 19

Slide 19 text

Slide 20

Slide 20 text

実施対象OSの選定 02 リグレッションテストの⼯数削減施策ケースの対象 ● アプリ、Block UI アプリのテストケース対象OSの選定⽅法 ● アプリ ○ iOS/Androidの推奨OSverのうち最上位OSのみを実施 ○ 上記以外のOSverは遷移確認などを網羅した簡易観点確認のみを実施 ● Block UI アプリ ○ iOS/Androidの推奨OSver対象の8デバイス中、4デバイスずつを隔週で交互に実施

Slide 21

Slide 21 text

Slide 22

Slide 22 text

○ 「正常系」の確認のみ抜粋する ※異常系観点は個別QAで担保 ○ エラー表⽰の確認など異常系観点はリグレッションテストの対象外にする ○ ⽬的を達成する⽅法が複数ある場合は、1つの⽅法で確認する例）モーダル閉じる⽅法がいくつかある場合などケース追加のルールを作成 02 リグレッションテストの⼯数削減施策上記の通りリグレッションテストで担保するラインを定めることで過剰なケースを削減対象のケース ● CMS、Block UI CMSのテストケースケース追加のルール

Slide 23

Slide 23 text

⼯数削減施策を実施した結果 02 リグレッションテストの⼯数削減施策

Slide 24

Slide 24 text

⼯数削減施策の結果 02 リグレッションテストの⼯数削減施策運⽤開始後平均 17 ~18 時間運⽤開始前 24 ~ 25 時間 ● 週次で平均6.5時間以上の⼯数削減に成功 ● リグレッションテストケース削減‧⾒直しに伴う事故発⽣件数は0件リグレッションテスト

Slide 25

Slide 25 text

不具合分析による要因の可視化

Slide 26

Slide 26 text

不具合分析を⾏うための⼟壌づくり STEP 1 03 不具合分析による要因の可視化

Slide 27

Slide 27 text

03 不具合分析による要因の可視化ツール選定、JIRA項⽬の⾒直し 1 前提使⽤ツール ‧JIRA ‧Googleスプレッドシート実施⽅法個別QAの差し戻し件数を集計する前に、 JIRAで起票される不具合チケット内容の構成を洗い出しその後、集計しやすいように項⽬をJIRA上でフィールド化

Slide 28

Slide 28 text

03 不具合分析による要因の可視化個別QAチケット起票フローの再定義 2 前提使⽤ツール ‧Conﬂuence 実施⽅法個別QAチケットの起票フローを再定義チケット起票者に新たに設定したフィールドを記載した上でフローを回していくように整備個別QAテスト中に出た不具合はJIRAの ”サブタスクチケット”として起票する

Slide 29

Slide 29 text

分析項⽬ごとの集計と分析 STEP 2 03 不具合分析による要因の可視化

Slide 30

Slide 30 text

03 不具合分析による要因の可視化集計値の決定 1 前提実施⽅法分析⽤に不具合の”発⽣事象”、”発⽣要因”のフィールドを新たに追加項⽬名や各項⽬の内容を定義化した後に、過去のチケットから不具合をサブチケットに分離させた後、プレ集計を実⾏使⽤ツール ‧Conﬂuence

Slide 31

Slide 31 text

03 不具合分析による要因の可視化集計〜分析作業を本格始動 2 前提使⽤ツール ‧JIRA ‧Googleスプレッドシート実施⽅法集計期間を定め、スプレッドシートにサブタスクチケットを抽出さらに各項⽬ごとに集計し、集計結果を元に発⽣要因に対する改善施策の検討

Slide 32

Slide 32 text

分析結果を開発チームへ共有 STEP 3 03 不具合分析による要因の可視化

Slide 33

Slide 33 text

03 不具合分析による要因の可視化分析結果の共有 1 前提実施⽅法集計値を元にグラフ化更に集計結果から⾒えた分析内容も併せて報告現在は⽉に1度、開発部全体の共有の場で報告を実施中使⽤ツール ‧Googleスライド

Slide 34

Slide 34 text

不具合分析を実施してみた結果 03 不具合分析による要因の可視化

Slide 35

Slide 35 text

分析結果 03 不具合分析による要因の可視化個別QAチケット起票数： 226 件サブタスクチケット起票数： 75 件起票率： 33.2 % 特定の期間にて個別QAチケットの不具合をサブタスクチケット化して集計。結果、サブタスクのチケット起票率は33.2%と、実施前の体感と⽐較して想定していたよりも低い数値となった。よって、純粋な不具合数(サブタスクチケットの起票数)が増加傾向にあるのではなく、不具合が発⽣した場合コミュニケーションコストの増幅が負荷要因になっているのではないかと仮説が⾒えてきた。

Slide 36

Slide 36 text

分析結果 03 不具合分析による要因の可視化 1位：影響範囲考慮漏れ 2位：プログラミング誤り 3位：実装漏れこちらは影響範囲考慮漏れが1位という結果になった。機能に対して相互影響が多い機能に対しては影響範囲の洗い出しの難易度が⾼いということを再認知。また、仕様通りのケースもいくつかあり、QA側の仕様理解の浅いポイントも可視化することができた。

Slide 37

Slide 37 text

分析から⾒えたこと 03 不具合分析による要因の可視化 ● 件数の数値化や、要因分類化は⾒えていなかった本質的な要因の洗い出しに繋がった ● コミュニケーションコスト削減のためチケットフローやJIRAの構成内容など定期的な⾒直しが必要 ● 分析内容を開発部全体で報告することにより、抱えている課題の共有や改善策の検討がよりしやすくなった ● 集計対象期間により結果にバラつきが出たので、実装者とQAの双⽅が負荷なく機能開発を進めていくのには継続して集計分析と課題検討が必要

Slide 38

Slide 38 text

まとめ

Slide 39

Slide 39 text

リグレッションテスト肥⼤化対策に向けて今後取り組むこと 1 ● ⼯数削減施策の未対応部分を実施 ● 障害発⽣数の継続観測 ● より効果的なリグレッションテストケースの定期⾒直し ● ⾃動化チームと連携したリグレッションテストケースの⾃動化移⾏推進不具合分析の結果から開発や他チームとのより強固な連携を⽬指す 2 ● 不具合分析結果の共有を継続 ● 分析結果を元に開発チームと協⼒して横断的な施策の検討 ● 不具合要因からより上流の⼯程へと改善施策の検討 04 まとめ