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

テストをスクラムチームに還すためのQAエンジニアの取り組み

honamin
November 05, 2022

 テストをスクラムチームに還すためのQAエンジニアの取り組み

Scrum Fest Sapporo 2022 の資料です!

honamin

November 05, 2022
Tweet

More Decks by honamin

Other Decks in Technology

Transcript

  1. スライドトップと
 してご利用ください
 マネーフォワード事業本部 
 山田 太郎
 © Money Forward, Inc.

    テストをスクラムチームに 還すためのQAエンジニア の取り組み presented by honamin / QA Engineer HR Solution Div. Product Development Dept. © Money Forward, Inc.
  2. @honamin / QAエンジニア 株式会社マネーフォワード ビジネスカンパニー HRソリューション本部 プロダクト開発部 QAグループ • Name:

    建川穂波 / Honami Tatekawa • Twitter: @hona_suke • きになる技術: テスト分析の自動化 / Test analysis automation • 趣味: 合唱 / Chorus • 居住地: 熊本→東京 / Kumamoto→Tokyo 北海道は人生2回目です✨
  3. QAエンジニアとして参画した時点の状況 • 機能仕様書 ◦ ほぼすべて揃っている。更新されている • 詳細設計書 ◦ 設計が複雑な場合書かれている。更新はされていない •

    テスト仕様書 ◦ プロダクトローンチ時のものが作成者のマイドライブ内に点在している ▪ 作成者はばらばら ▪ フォーマットは統一されていたり、いなかったり ▪ 一覧化されていないため、どんなケースが存在しているのかわからない • その他 ◦ チームメンバーが作成したテストについてのドキュメントがちらほら ▪ テスト設計の方針だったり、テスト技法の資料だったり その1:既存ドキュメントがどれくらいあるかを調べる
  4. QAエンジニアとして参画した時点の状況 • 品質に対する考え方 ◦ チーム内にテスト戦略のようなものが存在し、意識としてはとても高い ◦ リード陣の品質に対する知識量が多い • 品質の現状 ◦

    プロダクトローンチ直前の段階でデグレードが多かったため、 リグレッションとしてシナリオテストを自動化、実行している ▪ 不具合数の具体的な計測はできていない • テスト工程の課題 ◦ テスト作成や実行に時間がかかっている ▪ 作成はおそらくスキル面の問題 その2:チームの品質に対する考え方や、品質の現状(不具合数や可視化できているか)やテ スト工程の課題についてヒアリング
  5. チームにおけるQAエンジニアの役割 • QAエンジニアのお仕事 ◦ テストレビュー ▪ 機能テストのテスト観点・テストケース ◦ テスト作成サポート ◦

    E2E自動テストの推進サポート ◦ チームの品質戦略策定サポート ◦ スクラムイベントへの参加 チームが自走できるための サポートを行っています! • 一緒にテストを作ってみたり • E2Eテストをリファクタしたり • 品質戦略を考えるためのデー タを提供したり その3:チームと伴走しながらチームとプロダクトについての理解を深めていく
  6. 開発フローとテスト仕様書の作成 要件定義 仕様作成 設計 機能実装 機能テスト リリース テスト作成 • その機能を担当する開発エンジニ

    アが機能実装前にテスト仕様書を 作成 • テストファーストな機能開発 このタイミングでテスト仕様書を作成するメリット • 仕様へのフィードバックが早い段階で行える • 開発エンジニアはテストを参照しながら機能 を実装するため、機能テスト時点での不具合 が少ない • 手動テスト、自動テストの切り分けを行った 上で機能テストを実施できる ※設計は案件により前後
  7. ボトルネックその1:テスト観点出し • 人事管理では左記のフローでテス ト作成を行っています • レビューはQAエンジニアと開発エ ンジニアペアで行っています ◦ 仕様と照らし合わせて不足している観 点はないか、仕様に不明瞭な点や不足

    している点はないか ◦ 設計と照らし合わせて観点は足りてい るか テスト観点作成 レビュー テストケース作成 レビュー 作成完了 テスト作成のフロー ※案件によりあったりなかったり
  8. ボトルネックその1:テスト観点出し 初回レビュー時 手続き設定(機能名) A 従業員項目設定が初期値の時に手続き設定にカスタムカテゴリーが表示されない B すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力なし) C すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力あり) D

    すべてのカスタムカテゴリー・項目に入力必要性設定が反映される E 従業員項目設定にて、カテゴリー・項目が使用になっている項目のみ手続き設定で使用できる F 従業員項目設定を変更した際、手続き設定にも反映される G 手続き設定で一度保存された従業員項目(カスタム)は、従業員項目設定で非使用に変更しても、設定値が保持さ れる H 手続き設定で選択したカテゴリーが、従業員項目設定ですべて非使用に変更されたとき空の手続き設定になる I 手続き設定の作成中に従業員項目設定を非使用に変更された場合、非使用になった項目は作成されない J 手続き設定の編集中に従業員項目設定を非使用に変更された場合、非使用になった項目は反映されない K 手続き設定の作成、編集中に選択しているすべてのカテゴリーが非使用に変更されたとき、手続き設定が保存され ないこと L デフォルトカテゴリーを含めた手続き設定を作成できる きになるポイント 観点ではなく機能仕様では? 観点ではなくテストパターンでは? 自明もしくは重複の情報では? 網羅性をどうやって判断しよう🤔 文字数が、文字数が多い…!
  9. ボトルネックその1:テスト観点出し カイゼンしたこと • Fixまでのリードタイムを短縮 ◦ 最長1週間→最短1時間 • 洗い出し方を体系化 ◦ 観点リストからピックアップ

    ◦ 観点出しに時間がかかる場合はモブで ◦ 他テストにも流用が可能に • レビュー時間の短縮 ◦ 1時間かかっていたレビューが15分で完了 従業員項目設定のテスト観点
  10. ボトルネックその2:テスト作成の属人化 カイゼン① 「全員」がテストを作成できるようなスキルトランスファー • 開発歴10年、でもテスト分析や設計の経験 なし、の人はかなり沢山いる • だけどユニットテストは書いたことがある (謎が深い) • 根気のいる二人三脚ではあるが、2・3回繰

    り返すと1年くらいで低>中または高にスキ ルアップできる テスト作成スキル QAエンジニア がやること 高 観点出し〜ケース化まで安 心して任せられる ・レビュー(小) ・必要な場合は相談MTG 中 レビューには時間がかかる が、作成自体はひとりでで きる ・レビュー(大) ・要所要所で進め方の MTG 低 ※スクリプトテスト作成の経験0 どんな手順でテストを作成 するかから説明が必要 ・レビュー(大) ・時間をガッツリとって一 緒に作成 ・プロジェクトの期限的に 間に合わない場合はQAエ ンジニアが作成をお手伝い することも
  11. カイゼンしたこと • テスト作成スキルの確実なレベルアップ ◦ 2,3回テストを一緒に作るとスキル低>中、高へ ◦ 時間はかかるが着実 ◦ 楽しく作れば苦手意識も払拭できる(?) •

    テストを作りやすい環境へ ◦ 「テストが作りやすくなりました」との声あり ◦ 新しくジョインした方への効果はまだ測れていない ボトルネックその2:テスト作成の属人化