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.

    View Slide

  2. 登壇者の自己紹介

    View Slide

  3. @honamin / QAエンジニア
    株式会社マネーフォワード ビジネスカンパニー HRソリューション本部 プロダクト開発部 QAグループ
    ● Name: 建川穂波 / Honami Tatekawa
    ● Twitter: @hona_suke
    ● きになる技術: テスト分析の自動化 / Test
    analysis automation
    ● 趣味: 合唱 / Chorus
    ● 居住地: 熊本→東京 / Kumamoto→Tokyo
    北海道は人生2回目です✨

    View Slide

  4. みなさんのことを教えてください!
    ・みなさんの職種
    ・現在QAエンジニアと一緒に働いていますか?
     (答えられる範囲で大丈夫です!)

    View Slide

  5. 会社と組織の概要

    View Slide

  6. マネーフォワード

    View Slide

  7. ビジネスカンパニー

    View Slide

  8. HRソリューション本部

    View Slide

  9. プロダクト開発部とQAグループ
    ・QAグループは開発部横断で存在
    ・QAエンジニアはチーム担当制
     ・「何をやるか」はプロダクトの成熟度や
      チームの状況、課題によるので様々
    大体スクラム、時々LeSS
    開発組織として目指す姿(品質面)
    ・品質の最適化に向けた取り組みが日々の開発フローに自然と組み込まれている
    ・エンジニア自身が品質を担保した状態でリリースできる開発組織

    View Slide

  10. アウトカム

    View Slide

  11. アウトカム
    ● スクラムチームとQAエンジニアの取り組みについての
    事例を知ることができる
    ● 実際の取り組みを自分のチームに持ち帰って実践することができる
    ● スクラムチームとの関わり合いをもっと密にしていくための
    やる気と勇気を手に入れることができる

    View Slide

  12. クラウド人事管理チームとQAエンジニア

    View Slide

  13. プロダクトについて
    ・2021年7月ローンチ
    ・求められる品質
     従業員データの正確性 🌟🌟🌟🌟🌟
     データ収集のしやすさ 🌟🌟🌟🌟
     他サービスとの連携  🌟🌟🌟🌟

    View Slide

  14. QAエンジニアとして参画した時点の状況
    プロダクトチームにQAエンジニアとし
    て途中から参画する場合、まず何から
    始めますか?もしくは始めてほしいと
    思いますか?
       の場合
    その1:既存ドキュメントがどれくらいある
    かを調べる(機能仕様書、詳細設計書、テス
    ト仕様書など)
    その2:チームの品質に対する考え方や、品
    質の現状(不具合数や可視化できているか)
    についてヒアリング
    その3:チームと伴走しながらチームとプロ
    ダクトについての理解を深めていく

    View Slide

  15. QAエンジニアとして参画した時点の状況
    ● 機能仕様書
    ○ ほぼすべて揃っている。更新されている
    ● 詳細設計書
    ○ 設計が複雑な場合書かれている。更新はされていない
    ● テスト仕様書
    ○ プロダクトローンチ時のものが作成者のマイドライブ内に点在している
    ■ 作成者はばらばら
    ■ フォーマットは統一されていたり、いなかったり
    ■ 一覧化されていないため、どんなケースが存在しているのかわからない
    ● その他
    ○ チームメンバーが作成したテストについてのドキュメントがちらほら
    ■ テスト設計の方針だったり、テスト技法の資料だったり
    その1:既存ドキュメントがどれくらいあるかを調べる

    View Slide

  16. QAエンジニアとして参画した時点の状況
    ● 品質に対する考え方
    ○ チーム内にテスト戦略のようなものが存在し、意識としてはとても高い
    ○ リード陣の品質に対する知識量が多い
    ● 品質の現状
    ○ プロダクトローンチ直前の段階でデグレードが多かったため、
    リグレッションとしてシナリオテストを自動化、実行している
    ■ 不具合数の具体的な計測はできていない
    ● テスト工程の課題
    ○ テスト作成や実行に時間がかかっている
    ■ 作成はおそらくスキル面の問題
    その2:チームの品質に対する考え方や、品質の現状(不具合数や可視化できているか)やテ
    スト工程の課題についてヒアリング

    View Slide

  17. チームにおけるQAエンジニアの役割
    ● QAエンジニアのお仕事
    ○ テストレビュー
    ■ 機能テストのテスト観点・テストケース
    ○ テスト作成サポート
    ○ E2E自動テストの推進サポート
    ○ チームの品質戦略策定サポート
    ○ スクラムイベントへの参加
    チームが自走できるための
    サポートを行っています!
    ● 一緒にテストを作ってみたり
    ● E2Eテストをリファクタしたり
    ● 品質戦略を考えるためのデー
    タを提供したり
    その3:チームと伴走しながらチームとプロダクトについての理解を深めていく

    View Slide

  18. 人事管理チームの開発フローとテスト

    View Slide

  19. 開発フローとテスト仕様書の作成
    要件定義
    仕様作成
    設計
    機能実装
    機能テスト
    リリース
    ※設計は案件により前後

    View Slide

  20. 開発フローとテスト仕様書の作成
    要件定義
    仕様作成
    設計
    機能実装
    機能テスト
    リリース
    テスト作成
    ● その機能を担当する開発エンジニ
    アが機能実装前にテスト仕様書を
    作成
    ● テストファーストな機能開発
    このタイミングでテスト仕様書を作成するメリット
    ● 仕様へのフィードバックが早い段階で行える
    ● 開発エンジニアはテストを参照しながら機能
    を実装するため、機能テスト時点での不具合
    が少ない
    ● 手動テスト、自動テストの切り分けを行った
    上で機能テストを実施できる
    ※設計は案件により前後

    View Slide

  21. テスト作成におけるボトルネック

    View Slide

  22. テスト作成におけるボトルネック
    テスト作成サポートやテストレビューを行っていく中で、
    いくつかのボトルネックが見えてきました。
    その中から以下の2つを紹介します。
    ボトルネックその1:テスト観点出し
    ボトルネックその2:テスト作成の属人化

    View Slide

  23. ボトルネックその1:テスト観点出し

    View Slide

  24. ボトルネックその1:テスト観点出し
    ● 人事管理では左記のフローでテス
    ト作成を行っています
    ● レビューはQAエンジニアと開発エ
    ンジニアペアで行っています
    ○ 仕様と照らし合わせて不足している観
    点はないか、仕様に不明瞭な点や不足
    している点はないか
    ○ 設計と照らし合わせて観点は足りてい
    るか
    テスト観点作成
    レビュー
    テストケース作成
    レビュー
    作成完了
    テスト作成のフロー
    ※案件によりあったりなかったり

    View Slide

  25. ボトルネックその1:テスト観点出し
    例:従業員項目設定(カスタムカテゴリー)を従業員からの手続き申請でも使えるようにする
    従業員項目設定の機能概要:
    従業員の情報にユーザーがカスタマイズした
    任意の項目を追加することができる
    従業員情報詳細画面 従業員項目設定画面
    手続き申請の機能概要:
    従業員がスマホやPCから自身の情報を申請す
    ることにより、必要な情報を紙媒体なしで収
    集できる(入社時など)

    View Slide

  26. ボトルネックその1:テスト観点出し 初回レビュー時
    手続き設定(機能名)
    A 従業員項目設定が初期値の時に手続き設定にカスタムカテゴリーが表示されない
    B すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力なし)
    C すべてのカスタムカテゴリー・項目に従業員項目設定が反映される(表示名と補足文章がすべて入力あり)
    D すべてのカスタムカテゴリー・項目に入力必要性設定が反映される
    E 従業員項目設定にて、カテゴリー・項目が使用になっている項目のみ手続き設定で使用できる
    F 従業員項目設定を変更した際、手続き設定にも反映される
    G 手続き設定で一度保存された従業員項目(カスタム)は、従業員項目設定で非使用に変更しても、設定値が保持さ
    れる
    H 手続き設定で選択したカテゴリーが、従業員項目設定ですべて非使用に変更されたとき空の手続き設定になる
    I 手続き設定の作成中に従業員項目設定を非使用に変更された場合、非使用になった項目は作成されない
    J 手続き設定の編集中に従業員項目設定を非使用に変更された場合、非使用になった項目は反映されない
    K 手続き設定の作成、編集中に選択しているすべてのカテゴリーが非使用に変更されたとき、手続き設定が保存され
    ないこと
    L デフォルトカテゴリーを含めた手続き設定を作成できる
    きになるポイント
    観点ではなく機能仕様では?
    観点ではなくテストパターンでは?
    自明もしくは重複の情報では?
    網羅性をどうやって判断しよう🤔
    文字数が、文字数が多い…!

    View Slide

  27. ボトルネックその1:テスト観点出し
    レビューした観点の課題
    ● 観点自体に正解不正解はないが、書き方の粒度が作成者毎に違うと
    認知コストがかかる
    ● 文字数が多いとレビュー工数がかかる
    ● 観点が不足していた場合、追加しにくい
    ● 抽象度をあげないと他テストへの流用ができない

    View Slide

  28. ボトルネックその1:テスト観点出し
    その他の課題
    ● テスト観点出しへの苦手意識
    ○ 「テスト観点」ってそもそも何?
    ○ 何のために一覧化>レビューするの?
    ● 作成開始からレビューFixまでのリードタイムが長い
    ○ ツッコミどころが沢山あるおかげでFixまで時間がかかる
    ■ テスト観点作成だけで1週間かかることも…
    ■ スキルの問題もあるが…

    View Slide

  29. カイゼン① チーム共通のテスト観点リストを作成
    ボトルネックその1:テスト観点出し
    観点リスト テスト仕様フォーマット
    ● 観点出しで苦しんでいた開発エンジニアが
    主導して作成
    ● プロダクトの今のフェーズに必要な観点の
    詰め合わせ
    ● 市場不具合が出てしまった際かつ観点が不
    足していた場合は更新するなどし、最新化
    している

    View Slide

  30. ボトルネックその1:テスト観点出し
    カイゼン② 関係者を集めたモブテスト観点出し
    ● 対象機能の開発に携わるエンジニアとレ
    ビュアーが集って実施
    ● 1時間でみんなで観点を出す
    ○ 足りなかったら延長戦
    ● レビュアーもその場でレビューする

    View Slide

  31. ボトルネックその1:テスト観点出し
    カイゼンしたこと
    ● Fixまでのリードタイムを短縮
    ○ 最長1週間→最短1時間
    ● 洗い出し方を体系化
    ○ 観点リストからピックアップ
    ○ 観点出しに時間がかかる場合はモブで
    ○ 他テストにも流用が可能に
    ● レビュー時間の短縮
    ○ 1時間かかっていたレビューが15分で完了
    従業員項目設定のテスト観点

    View Slide

  32. ボトルネックその2:テスト作成の属人化

    View Slide

  33. ボトルネックその2:テスト作成の属人化
    テスト作成における属人化問題
    ● テスト作成が「できる」人「できない」人がでてきた
    ● チームとしては「全員」できるほうが望ましい
    ● だけど実際問題、テスト作成が苦手な人はいる

    View Slide

  34. ボトルネックその2:テスト作成の属人化
    カイゼン① 「全員」がテストを作成できるようなスキルトランスファー
    ● 開発歴10年、でもテスト分析や設計の経験
    なし、の人はかなり沢山いる
    ● だけどユニットテストは書いたことがある
    (謎が深い)
    ● 根気のいる二人三脚ではあるが、2・3回繰
    り返すと1年くらいで低>中または高にスキ
    ルアップできる
    テスト作成スキル
    QAエンジニア
    がやること
    高 観点出し〜ケース化まで安
    心して任せられる
    ・レビュー(小)
    ・必要な場合は相談MTG

    レビューには時間がかかる
    が、作成自体はひとりでで
    きる
    ・レビュー(大)
    ・要所要所で進め方の
    MTG

    ※スクリプトテスト作成の経験0
    どんな手順でテストを作成
    するかから説明が必要
    ・レビュー(大)
    ・時間をガッツリとって一
    緒に作成
    ・プロジェクトの期限的に
    間に合わない場合はQAエ
    ンジニアが作成をお手伝い
    することも

    View Slide

  35. ボトルネックその2:テスト作成の属人化
    カイゼン② テスト作成に必要な資料やフォーマットを整備
    機能テスト仕様書フォーマットのReadme
    ● 開発チームにジョインしてまもない人でも
    第一歩が踏み出せるような資料や枠組みを
    作成
    ● といってもひとりで走り出しは難しいの
    で、最初のうちはフォローしながら

    View Slide

  36. カイゼンしたこと
    ● テスト作成スキルの確実なレベルアップ
    ○ 2,3回テストを一緒に作るとスキル低>中、高へ
    ○ 時間はかかるが着実
    ○ 楽しく作れば苦手意識も払拭できる(?)
    ● テストを作りやすい環境へ
    ○ 「テストが作りやすくなりました」との声あり
    ○ 新しくジョインした方への効果はまだ測れていない
    ボトルネックその2:テスト作成の属人化

    View Slide

  37. 開発チームにテストに関するスキルや
    品質に対するマインドを伝えていく取り組み

    View Slide

  38. 日々の取り組み以外にも勉強会やワークショップを開催!
    品質特性についての勉強会とワークショップ
    日頃話している「これはこうしたいよね」がどの品質に分類
    できるのか、その結果チームはどこを気にしているのかをみ
    んなで認識

    View Slide

  39. 日々の取り組み以外にも勉強会やワークショップを開催!
    ホワイトボックス観点についての勉強会
    私自身はそこまで知識が厚いとは言えないので、チームのシ
    ニアエンジニアさんに勉強会を開いていただきました!

    View Slide

  40. 日々の取り組みと知識注入の合わせ技
    なんとなーく知っている
    知識として生かせる
    当たり前に
    なっている
    ● 勉強会
    ● ワークショップ
    ● 機能設計
    ● テスト作成
    ● レビュー対応
    チームの文化へ

    View Slide

  41. 人事管理チームとこれからやりたいこと

    View Slide

  42. クラウド人事管理チームとこれからやりたいこと
    ● 今現在のやり方にとらわれず、どんどんカイゼンをまわしたい
    ● 「みんなやっている」からではなく、
    その時のチームに合った形を探し続けたい
    ● 最新のテスト技法や技術を積極的に取り入れて行きたい
    ● 「テストスキル」をチームナレッジへ
    チームで品質を担保しつつ
    ユーザーに価値を届ける速度をより上げていきたい

    View Slide

  43. タイトルに込めた想い

    View Slide

  44. 「テストをスクラムチームに還すためのQAエンジニアの取り組み」
    このタイトルは「Modern Testing Principles」の7と@mkwrdさんの「独立QAチーム1年戦記」から
    着想を得ています。
    「還す」という言葉ほど、人事管理チームではテストを外に出していたわけではありませんが、私が
    チームにジョインした時点で「テスト」の知識がある開発エンジニアはかなり少数でした。時代に伴い
    「開発者自身がテストをする」場面が減ってきているのではないかと感じます。
    テストはQAエンジニアの生業かもしれませんが、開発エンジニアにとっても大事なプラクティスのひ
    とつと考えます。品質を作り込めるのはどの時代においても開発エンジニアだけです。その開発エンジ
    ニアが「テスト」の知識を得ることにより、開発チームはスケールし、プロダクトをよりよい品質で、
    かつアジリティを損なわずにリリースできる未来への一歩になると信じています。
    https://www.moderntesting.org/
    https://speakerdeck.com/mkwrd/210107-rsgt2021-an-independent-qa-teams-1-years-war?slide=55
    “We expand testing abilities and knowhow across the team; understanding that this may reduce
    (or eliminate) the need for a dedicated testing specialist.”

    View Slide

  45. 質疑応答

    View Slide

  46. Q:開発エンジニアがテストに腹落ちすることに難しさを感じていて、その辺で
    何か工夫してたら知りたいなと思いました (事前にいただいたご質問)
    A:
    まずは「なぜ腹落ちしていないのか」の見極めが重要な気がします。開発者の方を何人か集め
    てワークショップをひらいてはどうでしょうか(わたしも結果が気になりますw)。
    ユニットやインテグレーションなどの機能面のテストはユーザーのためのテストというより、
    開発チーム支援のためのテストであるというお話もあるように、テストはあらゆる面でチーム
    を助けてくれるので、そこら辺を重点的にお話しされるのも良いかもしれません👀
    参考:アジャイルテストの四象限
    伝え方が難しいということでしたら「腹落ちしている」開発エンジニアの方から「腹落ちして
    いない」開発エンジニアの方へテストの効果についてお話ししていただくのもいいと思いま
    す。(QAエンジニアから語りかけるより同職の方からの方が効果があったりします)

    View Slide

  47. 宣伝

    View Slide

  48. 登壇します🐥 きてね!
    ソフトウェアテスト
    自動化カンファレンス2022
    E2E自動テスト導入の
    つらみ・解決・ふりかえり
    12月3日(土)
    mabl experience’22
    タイトル未定
    mablの具体的なHow toに
    ついてお伝えする予定
    12月1日(木)

    View Slide

  49. Meety や Twitterでぜひお話ししましょう🐥

    View Slide

  50. Thank You!

    View Slide