スクラムでも結合テストの観点をちゃんと考えて実施するという話
この記事はマネーフォワード関西開発拠点 Advent Calendar 2022の1日目です。担当のマネーフォワードのクラウド会計Plus開発メンバーの井上（@ino_dev）です。
今日は会計Plus開発の『のれんチーム』で行っている、品質担保のための結合テストの運用についてまとめてみます。
振り返りの中で徐々にやり方はアップデートされているのですが、品質アップの取り組みに興味のある方の参考になれば幸いです。（トップバッターなので、皆の敷居を下げるために全力でふざけようかと思いましたが、笑いの取れそうなネタが思いつかなかったので真面目な話をします…）
スクラムにおける完成の定義に加える
会計Plusの開発ではJiraでタスク（バックログアイテム）を管理しています。
それぞれのタスクを『完了』としてよい条件がいくつか定義されており、『結合テストを行う』ということもそのなかの1つの条件になっています。
完成の定義の内容は細かくは色々ありますが、現状ざっくり以下のような流れになります。
（１）スプリントプランニング（設計・サブタスクの定義）
（２）結合テストの観点作成
（３）結合テストの観点チェック（テスト実施内容のレビュー）
（４）サブタスクごとに実装
（５）コードレビュー
（６）結合テストの実施
（７）プロダクトオーナーレビュー
（８）デプロイ
これらの流れはレトロスペクティブ（振り返り）でアップデートされることがあり、結合テストをこの記事の流れでやることになったのもチームの振り返りによるものでした。
プランニング中に『結合テストを作成するサブタスク』を作成する
会計Plusの1つのチーム単位では、現在ソフトウェアエンジニア(以下エンジニア)は4名程度で構成されており、そのメンバー＋ものによってはプロダクトオーナーでスプリントのはじめにプランニングを行っています。
プランニングでは『チーム内の誰が実装しても同様の成果物が出せる』ことを基準に、実際に手を加えるコードや作るclassやmethodの内容、その他実装するべきものなどについて全員で順次話していきます。
実装方針や設計について見通しを立てた後、タスクをどのように進めるのかという共通認識を得るために、少なくとも並列で作業できる単位で細かめにサブタスクも作成していきます。
このとき、新機能に関してはほぼ全て「結合テスト作成」というサブタスクを切っておいて、タスクに初めて着手し始める人が結合テストの作成から実施していきます。
実装前に観点を整理するというタスクを設けることで、設計後の考慮漏れに早い段階で気づきやすいという効果も感じています。
結合テストの観点はQA用のテンプレートに書き出す
結合テストは会計PlusのQAエンジニアのsudaさんが作成された結合テスト観点や確認項目をSpreadSheetのテンプレートに記載していきます。
テストの条件や確認したいことなどを、実装していないエンジニアにも分かるように記載をしていきます。
この時、受け入れ要件を確認するだけでなく、組み合わせや閾値のパターンなどを整理したり、デザインカンプや実際の画面動作の確認なども行うことでテスト対象の漏れも大部分を防ぐことが出来ます。
テスト方法はQAエンジニア＋同チームのエンジニアでレビューを行う
結合テストの項目が出来たらその項目自体もレビューを行います。
自分のチームのエンジニアはもちろん、QAエンジニアにもテスト対象や観点などを見てもらうという運用で、テスト項目として不十分そうな内容には指摘をいれてもらいます。
見るのは観点の漏れや認識ミスなどがないかというところがメインで行います。
出来るだけ実装していない人が結合テストをする
実装が終わってコードレビュー（2人以上のエンジニアからApproveをもらう）が終わったら、結合テストを依頼します。
この時、認識違いなどがあった場合に指摘がもらいやすいよう、出来るだけ直接実装に関わっていない人に結合テストをしてもらうことになっています。
なお、機能追加などを行う場合は、必ず自動テストのコードも同時に追加するので、それによって確実に担保されそうなテスト項目は、コメントを書いたりそれ自体を端折ったりはします。
逆に、結合テストが難しい項目に関しては自動テストで動作を担保できるようにします。
おまけ：プロダクトオーナーレビューとスプリントレビューはUXを担保するもの
結合テストが終わったら、機能追加の場合はプロダクトオーナーにもレビューを依頼します。
ただし、プロダクトオーナーのレビューはあくまで受け入れ要件が満たされて、顧客に十分な価値が届きそうかという点に対してのレビューであり、UI/UX以外の挙動が正しくどうさするかということは目的にはしていません。
基本的には結合テストですべての実装を終えて「エンジニア的には良いものできているけどどう？」という最後の価値確認に見てもらいます。
スプリントレビューも同様で、より価値を上げるためにはどうすればよいのかという情報収集や周知のための場であり、リリースするまたはリリースした内容が使える状態かどうかということは、『個人の動作確認』『自動テスト』『結合テスト』によってエンジニアが担保します。
まとめ
以下のような取り組みにより品質の担保に取り組んでいます。
完成の定義に結合テストを組み込んでいる
プランニング時に結合テスト作成のサブタスクを作って着手した人がやる
結合テストの項目（観点）はエンジニア＋QAが見て品質を担保
結合テストは実装者以外がやる
もしチームの取り組みとして参考になるものがあれば幸いです。
また、「こういう風にすればいいよ！」「ウチではこんなコトやってるよ！」なんてものもあればTwitterででもコメントください。
それでは、次回マネーフォワード関西開発拠点 Advent Calendar 2022の2日目は、マネーフォワードの技術広報であるluccafortさんです！
是非次の記事もチェックしてみてくださいね！
ーーー
もし開発方法やチームの状況など興味がある方は、カジュアル面談などもされているので是非↓から応募してみて下さいね！
この記事が気に入ったらサポートをしてみませんか？