Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ヤプリQA課題の見える化

 ヤプリQA課題の見える化

Yappli Tech Conference 2024 登壇資料
イベントページ: https://yappli.connpass.com/event/328754/

"QAグループの山口( @Myamaguchi75201 )が、弊社のQA業務の紹介やリグレッションテストの工数削減、不具合分析などの取り組みについて発表します!"

山口茉莉江

December 26, 2024
Tweet

Other Decks in Technology

Transcript

  1. Speaker 開発統括本部 プロダクト開発本部 開発1部 QA2グループ ⼭⼝ 茉莉江 • 2023年2⽉にヤプリへ⼊社 •

    QAエンジニアとしてプロジェクト のQA計画〜実⾏まで管理 • 不具合分析によるプロセス改善検 討に注⼒ • 好きなものは国内旅⾏/お酒
  2. ヤプリのQA業務 00 ヤプリQAの紹介 QA 3本の柱 • この他にも開発〜QAまで横断して利⽤する共通観点の作成、QA業務で発⽣する 細かいタスクの⾃動化など様々な改善も業務として実施 個別QA 不具合や機能改善に対するテスト

    (機能テスト) 週次QA リリース前の動作確認 (リグレッションテスト) プロジェクトQA 新規開発プロジェクトや開発⼯数規模の ⼤きい機能に対するテスト (機能テスト、モンキーテストなど)
  3. • 前提 ◦ リグレッションテストケースは4本存在する ▪ CMS(SV/Front) ▪ アプリ ▪ Block

    UI CMS(SV/Front) ▪ Block UI アプリ ◦ リグレッションテストケースには”⼿動実施ケース”と”⾃動テストケース”が存在 する ◦ 検知件数の数値化は、⼿動と⾃動化両⽅のケースを対象に計測 リグレッションテストによる不具合検知件数の集計 02 リグレッションテストの⼯数削減施策
  4. • 集計結果からの詳細分析 ◦ ⼿動実施分の件数が多く、⾃動化テストケースでは発⽣件数が少なかった ◦ リグレッションテストで検出した不具合の中で、各個別QA対応のマージ要因はほぼ無かった ◦ 検出不具合の多くは、理想の検知タイミングは個別QAフェーズだった ◦ OSver違いの不具合はほぼ発⽣していない

    ◦ 不具合の発⽣した機能はリリース対象機能のみだった リグレッションテストによる不具合検知件数の集計 02 リグレッションテストの⼯数削減施策 リグレッションテストケースの対象は、リリース対象機能のみで ⼗分だとわかった
  5. 実施対象OSの選定 02 リグレッションテストの⼯数削減施策 ケースの対象 • アプリ、Block UI アプリのテストケース 対象OSの選定⽅法 •

    アプリ ◦ iOS/Androidの推奨OSverのうち最上位OSのみを実施 ◦ 上記以外のOSverは遷移確認などを網羅した簡易観点確認のみを実施 • Block UI アプリ ◦ iOS/Androidの推奨OSver対象の8デバイス中、4デバイスずつを隔週で 交互に実施
  6. ◦ 「正常系」の確認のみ抜粋する ※異常系観点は個別QAで担保 ◦ エラー表⽰の確認など異常系観点はリグレッションテストの対象外にする ◦ ⽬的を達成する⽅法が複数ある場合は、1つの⽅法で確認する 例)モーダル閉じる⽅法がいくつかある場合など ケース追加のルールを作成 02

    リグレッションテストの⼯数削減施策 上記の通りリグレッションテストで担保するラインを定めることで 過剰なケースを削減 対象のケース • CMS、Block UI CMSのテストケース ケース追加のルール
  7. ⼯数削減施策の結果 02 リグレッションテストの⼯数削減施策 運⽤開始後 平均 17 ~18 時間 運⽤開始前 24

    ~ 25 時間 • 週次で平均6.5時間以上の⼯数削減に成功 • リグレッションテストケース削減‧⾒直しに伴う事故発⽣件数は0件 リグレッションテスト
  8. 03 不具合分析による要因の可視化 ツール選定、JIRA項⽬の⾒直し 1 前提 使⽤ツール  ‧JIRA  ‧Googleスプレッドシート 実施⽅法 個別QAの差し戻し件数を集計する前に、

    JIRAで起票される不具合チケット内容の構成 を洗い出し その後、集計しやすいように項⽬をJIRA上で フィールド化
  9. 分析結果 03 不具合分析による要因の可視化 個別QAチケット起票数: 226 件 サブタスクチケット起票数: 75 件 起票率:

    33.2 % 特定の期間にて個別QAチケットの不具合をサブタスクチケット化して集計。 結果、サブタスクのチケット起票率は33.2%と、実施前の体感と⽐較して想定していたよ りも低い数値となった。 よって、純粋な不具合数(サブタスクチケットの起票数)が増加傾向にあるのではなく、不 具合が発⽣した場合コミュニケーションコストの増幅が負荷要因になっているのではない かと仮説が⾒えてきた。
  10. 分析から⾒えたこと 03 不具合分析による要因の可視化 • 件数の数値化や、要因分類化は⾒えていなかった本質的な要因の洗い出しに 繋がった • コミュニケーションコスト削減のためチケットフローやJIRAの構成内容など 定期的な⾒直しが必要 •

    分析内容を開発部全体で報告することにより、抱えている課題の共有や改善 策の検討がよりしやすくなった • 集計対象期間により結果にバラつきが出たので、実装者とQAの双⽅が負荷な く機能開発を進めていくのには継続して集計分析と課題検討が必要
  11. リグレッションテスト肥⼤化対策に向けて今後取り組むこと 1 • ⼯数削減施策の未対応部分を実施 • 障害発⽣数の継続観測 • より効果的なリグレッションテストケースの定期⾒直し • ⾃動化チームと連携したリグレッションテストケースの⾃動化移⾏推進

    不具合分析の結果から開発や他チームとのより強固な連携を⽬指す 2 • 不具合分析結果の共有を継続 • 分析結果を元に開発チームと協⼒して横断的な施策の検討 • 不具合要因からより上流の⼯程へと改善施策の検討 04 まとめ