スライドトップと
 してご利用ください
 マネーフォワード事業本部 
 山田 太郎
 © Money Forward, Inc. テストをスクラムチームに 還すためのQAエンジニア の取り組み presented by honamin / QA Engineer HR Solution Div. Product Development Dept. © Money Forward, Inc.

登壇者の自己紹介

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

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

会社と組織の概要

マネーフォワード

ビジネスカンパニー

HRソリューション本部

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

アウトカム

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

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

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

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

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

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

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

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

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

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

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

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

ボトルネックその１：テスト観点出し

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

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

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

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

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

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

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

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

ボトルネックその２：テスト作成の属人化

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

ボトルネックその２：テスト作成の属人化 カイゼン①　「全員」がテストを作成できるようなスキルトランスファー ● 開発歴10年、でもテスト分析や設計の経験 なし、の人はかなり沢山いる ● だけどユニットテストは書いたことがある （謎が深い） ● 根気のいる二人三脚ではあるが、2・3回繰 り返すと1年くらいで低＞中または高にスキ ルアップできる テスト作成スキル QAエンジニア がやること 高 観点出し〜ケース化まで安 心して任せられる ・レビュー（小） ・必要な場合は相談MTG 中 レビューには時間がかかる が、作成自体はひとりでで きる ・レビュー（大） ・要所要所で進め方の MTG 低 ※スクリプトテスト作成の経験０ どんな手順でテストを作成 するかから説明が必要 ・レビュー（大） ・時間をガッツリとって一 緒に作成 ・プロジェクトの期限的に 間に合わない場合はQAエ ンジニアが作成をお手伝い することも

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

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

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

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

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

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

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

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

タイトルに込めた想い

「テストをスクラムチームに還すためのQAエンジニアの取り組み」 このタイトルは「Modern Testing Principles」の７と@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.”

質疑応答

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

宣伝

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

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

Thank You!