はじめに
こんにちは。「マネーフォワード クラウド勤怠」のエンジニアをしています katuoです。クラウド勤怠チームでは約半年前から、新機能開発をする上で発生し得る障害やインシデントを回避するべく、中・大規模の新規開発をする場合はQAチームのSammy（森田）さんに勤怠チームに入って頂き、ソフトウェア品質の向上に向けた様々な活動を実施してきました。本記事ではQAエンジニアがチームに入ったことによってチーム全体や自分の中で起きた変化をお伝えできればなと思っております。
※ 本記事では一部QAエンジニアをQAと略させていただきます。
QAのイメージと期待感
自分自身、初めてQAと密にコミュニケーションを取りながら開発することになり、正直QAのことをあまりよく知りませんでした。
漠然として抱いていたQAのイメージは「テスト技法などソフトウェアテストに詳しい人」「テストケースを作成、実行する人」「テストの重要性を訴求してくる布教者」などがありました。また時には「ここのテストは何故やってないんですか？」「品質はどうなっているんですか？」といったようなことを何度も繰り返し指摘してくる、アプリケーションエンジニア視点ではちょっと距離を置きたくなるような人達といったネガティブイメージもありました。
一方でクラウド勤怠は扱うドメインの特性上、計算ミスやサービス停止が許されないミッションクリティカルなプロダクトであるため、ソフトウェア品質の重要性自体に対しては、潜在的に意識はありました。なのでQAが入ることで、テスト技法の知見を吸収したり、テストを実施して頂いたりすることでのソフトウェア品質の向上や中・大規模開発時に何処と無く感じていたテスト周りの不安感の解消などに繋がるのではないかという期待感がありました。
QAが入った時点でのテスト事情
単体テスト
単体テストはサーバーサイド側とフロントエンド側でそれぞれ状態が異なるのですが、チーム全体として大きな問題は抱えていませんでした。サーバーサイド側、Railsに関して、カバレッジは定常計測していなかったのですが、最近チームに加わったRailsの業務経験が豊富なメンバーから「テスト多いですね」といったフィードバックを頂いていたりと、サーバーサイドの単体テストという文脈ではまずまずテストは書けている印象でした。
一方、フロントエンド側、Vue.jsやslimなどに関して、テストは殆ど書けていませんでした。これに関しては前々からチーム内で認識されており、半年前に「Vue Test Utils」といった単体テスト基盤を導入することでビジネスロジックによるUIの挙動などの単体テストを積極的に書いたり、徐々にslimを引き剥がしてテストが書けるVue.jsに移行したり、既存Jestのテストケース数を増したりなど、フロントエンド全体で単体テストが増えていく傾向はありました。
過去記事: 「Vue Test Utils」を導入して、Vue Componentの単体テストを書けるようにした話
結合テスト
結合テストはいくつか問題を抱えていました。例えば、プロジェクトの規模感によってプロジェクト終盤やリリース直前にエンジニアやプロダクトマネージャーが実施したり、しなかったりで結合テストのやる、やらないが個人に依存していました。また、Google Spreadsheetなどで作成したテストケースも作成者本人にとって必要な最低限の情報しか書かれておらず、時間が経った後、テストケースを見返したり、メンバー間で相互にテストケースのレビューがし辛いなどの問題がありました。
シナリオテスト
シナリオテストは開発プロジェクトがシナリオテストを作る、作らないがプロダクトマネージャーの裁量に任せられており、実施されないケースもありました。またプロダクトによってはテスト自動化ツールなどを活用してシナリオテストの自動化を導入するケースなどがありますが、私たちのプロダクトではRSpecのシステムテストが少し入っている程度で、このあたり導入を進めていこうという話も特にチーム内で上がってきたりはせず、放置されていました。
ソフトウェア品質に対する認識
誰かに「プロダクトのソフトウェア品質は問題ないか」と聞かれたときに「恐らく問題ない」と返すことしかできませんでした。というのも不具合件数が0件ではないが、件数として多くもないし、また不具合も大きいものから小さいものまで様々といった感じで、何か定量的な観点でプロダクトのソフトウェア品質に対して評価をすることができていませんでした。
QAがチームに入ることで生まれた品質向上へのアクション
QAが勤怠チームに入って約半年が経ち、その間チーム内ではプロダクトのソフトウェア品質向上に向けたさまざまな取り組みが実施されるようになりました。その中でも比較的大きなアクションを選定して書いてみます。
テスト工程を組み込んだ開発プロセスの見直し
中・大規模の新機能開発をする場合、開発プロセスのどこのフェーズでテスト観点やテストケースを作成するのかをチームで議論しました。（実際に議論で使用したmiroの一部画像を添付します）
これらについて議論をするようになったことで、各メンバーがテストを開発プロセスの1つとし認識するようになりました。また同時にテストの工数がチーム内できちんと認識されるようになり、事前にスケジュールを組む時にテスト込みでの見積もりがエンジニアやプロダクトマネージャー側で行われるようになり、時間がないからテストを省略するといったことが発生し辛いチームカルチャーを構築することができました。
副産物として、設計や実装フェーズばかりに注意が向いてしまいがちなアプリケーションエンジニアが、開発プロセス全体を俯瞰して考え、どうやったら効率よく成果物をアウトプットすることができるのかについて議論できるようになったことも非常に良かったと思っています。
テスト計画書の作成
プロジェクト序盤にテストを作成に着手する前に「どの範囲をテストするのか」「どのような技法でテストするのか」などを定めたテスト計画書をQAと一緒に考えながら作成しました。
クラウド勤怠はドメインの特性上、全画面数が200ページを超える大規模なプロダクトなので影響範囲を把握するのは非常にハードルが高いです。特にチーム歴が浅いメンバーはまず、どんな画面やどのくらいの数の画面があるのかを把握できてないことが多い印象でした。今回のテスト計画書の作成をきっかけに影響範囲調査や新メンバーのオンボーディング資料として活用できるよう機能名と画面URLの一覧が記載されたGoogle Spreadsheetを作成しました。
このシートをコピーして、テストを作成する前に機能追加やリグレッションなどの観点で影響のある画面などをリストアップすることで、漠然とあった何をテストしたら良いのかの不安を大幅に軽減することができ、テスト対象を絞り込みやすくなりました。
QAによるテストレビュー
結合テストなどをQAにレビューして頂きながら、テスト観点やテストケースの作成をするというイテレーションを繰り返しました。自分以外の人が読む前提のしっかりとしたテストケースを作成した経験がなかった自分はテストケース作成に関して、非常に苦しみました。具体例を挙げると「どのような単位でテストを作成するのか」「因子と水準をどう決めるか」「どこまでテストを書けば良いのか」「テストの説明はどこまで書けば良いのか」「プロジェクトのどのフェーズで、どれだけのテストを書けば良いのか」など様々なことで悩みました。こちらの詳細は別の記事に詳しく記載していますので、興味があればお読みください。
苦しんだ一方で、半年間を振り返ってみるとQAのレビューを通じて、エンジニア側が作成する組み合わせテストなど、結合テストの作成能力が飛躍的に向上しました。その結果、複雑な組み合わせテストケースで不具合を洗い出せたり、結合テストをしっかり書いたことで仕様の不明確な箇所が明らかになり、プロジェクト中盤において大きめな仕様不備に気づくことができたりなど、様々なポジティブ影響を享受することができました。
過去記事: 【クラウド勤怠】爆発する組み合わせテストと真摯に向き合う
不具合分析会の開催
2週に1回のペースで、その間で起きた不具合について、チームメンバーで振り返りを実施するMTGが開催されるようになりました。このMTGでは発生した不具合について「不具合のランク付」「不具合が発生した原因」「不具合を防ぐための対策」などについて議論し、評価した内容をGoogle Spreadsheetに蓄積していくことで、メンバー内で不具合を起こさないようにする知見を共有・蓄積できるようになりました。更に月に1回、過去に蓄積した不具合データと比較をすることで「数ヶ月の期間で見た時に不具合の件数が減っているか」「不具合の特徴はあるか」などを振り返り、以前と比べてソフトウェア品質の状態を定量的に比較できるようになりました。
正直な所、始めてから1~2ヶ月目はこんなに不具合の詳細部分までの議論をして果たして意味があるのだろうか？といった気持ちで懐疑的でした。しかし3ヶ月目以降になると不具合が起こりやすい画面や不具合の傾向などが少しずつ見えてくるようになり、エンジニア側でも開発をするときに「このあたりはバグが起こりやすいから、もう少し詳しくコードを読んでみよう」「このあたりはリグレッションテストをした方が良いかもしれない」といった行動が観測できるようになり、確実にエンジニア間で蓄積した不具合のナレッジが活用できるようになりました。
QAやテストに対するイメージやメンタル面での変化
QAと半年間一緒に仕事をしたことで、半年前に自分の中で抱いていたQAやテストに対するイメージなどが大きく変化しました。その中でも大きな変化をピックアップして書きます。
QAエンジニアという職種の奥深さ
自分自身、恥ずかしいことに「QAエンジニア ≒ テスト作成・実行者」といった程度のイメージしか持っていなかったのですが、実際に一緒に仕事をしてみると品質工学であったり、非常に難しく、奥が深い分野の内容を扱う職種であることに気づきました。また「Scrum Fest Niigata 2022」に登壇・参加したりして、普段アプリケーションエンジニアとして見ている領域とは異なった方向に目が向くようになりました。
また実際に自分で手を動かして苦しみながら、テストを設計・作成したことでテストを設計・作成することの難易度を身を持って体感しました。まして普段、プロダクトのドメインやソースコードを知らない場合でもこれらのテストを作るQAエンジニアは本当に凄いなというリスペクトの気持ちでいっぱいになりました。
全てをテストをすることができない
自分自身、テストを作る時にどこまで、どのくらい作れば良いのかわからず、考えれば考えるほど湧き出てくる組み合わせに翻弄され、さらには開発業務やその他業務を抱えながらのテスト作成に大変疲弊していました。言われてみれば当たり前のことですが、全ての組み合わせであったり、全てのケースをテストすることはできません。そしてこの辺りQAですらどこまでテストをすれば良いのか非常に悩む部分であり、一概に答えは出せないものであるということを知りました。なのでマインド的に「全ての組み合わせのテストをすることができない」「時間内に可能な限りのテストをする」といった気持ちを持つことが非常に重要であることに気づきました。また肌感ですが、この規模のプロジェクトならこの程度のテストをやれば十分だろうといった経験則に基づく感覚も少しづつ芽生えてきました。
テストの設計・作成は楽しい
半年間、QAから様々なテスト技法に関する知見を吸収したことでテストを設計・作成するときの引き出しが増え、次はどの方法・技法を使ってテストを設計しようかといった普段アプリケーション側の内部設計をするような楽しさを感じられるようになりました。また自分が書いたテストによって仕様が整理され、明らかになっていく過程やテストによって不具合が見つかった時の楽しさも感じられるようになりました。そしてなにより、自分が書いたテストをQAやプロダクトマネージャーに「綺麗」「読み易い」といったフィードバックを貰えるのも非常に嬉しく、やりがいを持って取り組めるようになりました。
見えてきた課題や改善していきたいこと
QAがチームに入ったことでソフトウェア品質の向上に向けた具体的なアクションが起こる一方で、課題や今後改善していきたい箇所なども見えてきたので主要なものをピックアップして書きます。
メンバー間でのテストレビュー
半年間、テスト観点やテストケースのレビューは全てQAに時間を取って頂いて実施していました。この構造はチーム内で複数案件が稼働すると、テストレビューがQAに1点集中してしまい、レビューが待ちの状態になったり、QAに負荷が集中してしまうといった問題が起きました。またQA自身も各機能やプロダクトの仕様を全て細かく把握することが難しいので、深く突っ込んだレビューをすることができないなどの問題もありました。このような課題を解決するために、テストレビューをQAだけに頼るのではなく、エンジニア間でテストのレビューを回せるような状態にしていきたいと思っています。
不具合分析結果の活用
不具合分析を進めていくことで、プロダクトの不具合が発生しやすい機能や画面の傾向が徐々にわかるようになってきたのですが、これらの情報に再度アクセスしたい場合、自ら膨大な不具合蓄積シートを検索したりしないといけないため検索性が低く、貴重な情報資産が新メンバーなどに共有しにくいという問題がありました。今後、テストを作成したりするときにバグが発生しやすい箇所などを誰もが把握できるような参考資料などを作って、不具合の資産をさらに有効活用できる状態にしていきたいと思っています。
開発プロセスとテスト進捗
開発プロセスの中でテストを作成するにあたって、プロジェクト序盤に作成することで事前に仕様不備を発見しようと試みたのですが、プロジェクト終盤になるにつれて具体的な情報が見えてきたり、途中で仕様が変更されたりするとテストを作り直さないといけないなどの手戻りが発生してしまうことがありました。プロジェクト序盤で具体的なテストを書くことはコストが掛かる上、変更が発生しやすいテストであるということを認識し、スモークテストから始まり、最後は組み合わせテストといったように徐々にテストの複雑度を上げていくなど、最適な方法を諸々考えていく必要があると思っています。
他にも新機能開発中に不具合を発見、修正した後にどこまでテストをやり直す必要があるのか？などの議論も曖昧にしてしまっているのでこのあたりも詰めていきたいと思っています。
シナリオテスト自動化の推進
日常リリース時の動作確認テストや不具合修正後のリグレッションテスト実行など、ルーチン化しているテストがあるのでこれらは自動化していきたいなと思っています。このあたりチーム内で「mabl」というテスト自動化ツールを使ってシナリオテストを自動化していこうといった話がでていたりするので、今後運用コストや効果などを議論して、必要であれば導入していこうと考えています。
最後に
改めて、アプリケーションエンジニアである私にソフトウェアテストという別世界があるのを教えてくださった Sammy（森田） さんに感謝しています。QAと一緒に仕事をすることでテストの重要性はもちろんのこと、開発プロセスなどにも目が行くようになり、ソフトウェアエンジニアとしての視野が広がりました。今後も機能開発とソフトウェア品質のバランスを取りながら、ユーザーに価値を届けていくために尽力していこうと思います。最後までお読みいただきありがとうございました。
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【会社情報】 ■Wantedly ■株式会社マネーフォワード ■福岡開発拠点 ■関西開発拠点（大阪/京都）
【SNS】 ■マネーフォワード公式note ■Twitter - 【公式】マネーフォワード ■Twitter - Money Forward Developers ■connpass - マネーフォワード ■YouTube - Money Forward Developers
