Pocochaで実践するAgile Testing

こんにちは、SWETグループ兼PocochaでQAエンジニアを担当しているkariadです。 Pocochaではよりフロー効率を高めていくため、アジャイル開発体制への移行を進めています。今回はその中でもテストについて、Pocochaでの取り組みについて紹介します。

また、PocochaではSAFeという大規模アジャイルフレームワークも採用しており、本記事でもSAFeの用語が出てくることがあります。可能な限り用語がわからなくても意図が伝わるように書いていますが、Pocochaで取り組むSAFeそのものについては別記事にて後日紹介したいと思います。

いつテストをするのか？

アジャイル開発でフロー効率を高めていく上で考えなくてはいけないのはいつテストをするかです。従来のPocochaでは開発終盤にまとめてQAを実施していました。このときはバグの件数もそれなりにあり、仕様に関わる不具合が見つかると大きく手戻りが発生したり、QA期間中にバグ対応にかかりっきりになってしまう状態でした。これをそのまま持ってきてしまうと、大きくフロー効率を変えることができないと考えました。テストプロセスまで変えて開発をするために、Pocochaではエクストリーム・プログラミングも読んだ上でベースにしつつ、テストの部分では以下の書籍を主要メンバーで輪読会を実施した上でAgile Testingに取り組んできました。

その結果、体制としても、もともとQAと開発が別チームで動いていた状態から、今は開発チーム内にQAメンバーも含まれています。 QAが開発チームに参加するだけではなく、開発チーム全員で品質に対して責任を持つ、という考えをチームで共有しながら開発を進めています。

また、XPの価値の一つに「フィードバック」があります。フィードバックループを早くしていくためにテストも最後にまとめてではなく、常にテストし続けることの重要性がAgile Testing Condensedでも触れられています。早期のテストにより、バグの発見からバグの防止を重視することにも繋がります。

Agile Testing Condensedから考え方を、The BDD Booksからは具体的なプラクティスを取り入れました。そうしたテスト活動を開発プロセスの随所に導入することで常にテストしづづけることを意識しています。以下ではBDDから取り入れたプラクティスやその他活動について、Pocochaではどのように取り組んでいるかを紹介していきます。

実例マッピング

The BDD Books Discoveryで紹介されている実例マッピングをPocochaでは実施しています。実例マッピングとは要件について具体例をベースに会話することで共通の理解を得ていくプラクティスです。実例マッピングそのものの詳細な説明については誤解なく理解してもらうために是非本を読むことをおすすめするのと、すでに先行事例がいくつか存在しているため、割愛します。

PocochaではPdMが用意してきた要件に対して、実例マッピングを使ってルールや疑問点などを明らかにし、参加者の間で共通理解を築いています。実施タイミングとしてはSAFeのイベントであるPIプランニング¹の前に実施しています。また必要に応じて後述するストーリーチケットを作成する前にも実施しているチームもあります。 PIプランニング前のタイミングでは上記の実例マッピングの目的に加え、要件を具体化していくこととリスクになりそうなことを明らかにしていくことを目的としています。

実例マッピングにはPdM, PO, QA, 任意で開発チームエンジニアが参加しています。開発チームエンジニアが任意である理由は、POがエンジニアだからです。また、全員参加にしてしまうと、今開発している作業をブロックしてしまいます。これらのことから、開発チームエンジニアの参加は任意としています。

具体例をベースに議論することで、よりこの場合はどうなるかなどが共通認識を持った状態で議論が進みます。また具体例を上げていく中で、それで大丈夫なのかなどリスクに繋がりそうな事例も早期に発見することができています。またこの場にQAが参加していることも重要で、過去のPocochaではQAは仕様書を渡されて読みながらテスト設計をしていましたが、わからないことも多く、質問をたくさんして回答するやり取りが発生していました。それが実例マッピングの場で最初から参加することで、その場で理解を深められています。

Pocochaでは実例マッピングをMiroで実施しています。 Miroには実例マッピングの以下のようなテンプレートがあるためスムーズに始めることができます。気軽に始めたい、という方はMiroで試してみるのをおすすめします。 Example mapping template on miro

実例マッピングは比較的うまくいっているプラクティスですが、課題がないわけではありません。実例マッピングでどこまで細かく具体例を出していくかについてまだ答えがでていません。 Pocochaは複雑性が高いドメインということもあり、細かく出していくととても膨大な具体例の数になります。もちろんそこからルールが多くなる場合はストーリーが大きすぎるという示唆でもあります。どこまでやるか、については実例マッピングをやるタイミングも複数あってもいいのではないかと考えていて、タイミング次第で異なると考えています。

Gherkin記法とシナリオ

Pocochaでは実例マッピングを通じて要件が具体化された後、実際に開発していくための詳細な仕様を作成しています。また必要に応じてこのタイミングでより詳細な具体例を導くための実例マッピングを実施します。 PocochaではツールとしてJIRAでチケットを管理しています。 JIRAで作成されたストーリーチケットにはBDDにおけるシナリオを記述します。開発チームはこのストーリーチケットベースで開発を進めていきます。

シナリオはGherkin記法で記述しています。 Gherkin記法とはGiven, When, Thenなどのキーワードを使って振る舞いを記述する構文です。 Gherkin記法で仕様を、振る舞いを書くことでシンプルで誰にでもわかりやすいドキュメントにすることができます。実際にGherkin記法について少し見ていきます。

Scinario: シナリオ名
Given 前提条件
When 行動
Then 結果

追加で接続詞としてAndやButも登場しますが、基本となる構文はシンプルです。シンプルですが、Andで繋いで長いシナリオを書いてしまうこともできます。しかしThe BDD Books FormulationではBRIEFの原則として以下を紹介しています。

B: Bussiness language。ビジネスの用語を使うことで誰もが理解可能にする。
R: Real data。具体的なデータを使うことで境界値が明らかになる。
I: Intention revealing。意図を明確にする、シナリオ名で意図を記述することでフォローになる。
E: Essential。どのように振る舞うべきかを説明するために、シナリオの本質的ではない部分は削除する。
F: Fourcusd brief。1つのシナリオでは焦点を絞る。

BRIEFの原則について簡単に紹介しましたが、重要なのは簡潔であることです。長いシナリオは読んで理解するのも難しくなる上に、複雑化して勘違いやミスの元になります。また、少しこのGherkinの構文に注目すると、ユニットテストでいうところのAAA(Arrange-Act-Assert)と構文が似ています。 AAAが読みやすいテストコードとして有名であるように、開発者にとっても慣れ親しんだ構文と似ているGherkinまた読みやすい仕様、振る舞いだとも考えられます。

シナリオは実例マッピングで作成された具体例をベースに作成していきます。シナリオはPOとQAのペア作業で書くことが推奨されていますが、働き方の都合で時間が合わないこともあります。その場合どちらかが先に書くことはありますが、必ずもう一方もレビューして追記するようにしています。

Pocochaではシナリオを細かく分けて記述しています。これは見積もりを行う際にサイズが大きいとポイントも大きくなりわかりづらくなることと、一つのチケットに別途受け入れ条件をたくさん書くことで実装漏れが発生することを避けるためです。前述したように作成されたストーリーチケットにはGherkinで表現しきれなかった細かい受け入れ条件があれば追加で記載します。実装がストーリーチケットの単位で行われるため、受け入れも短いサイクルで実施しています。

細かいストーリーチケットを作成するなかでThe BDD Booksを読んだ上で参考として取り入れているプラクティスを紹介します。

シナリオアウトラインの活用

たくさんのシナリオを書いていく中でほぼ同じシナリオだが一部の要素だけがことなるシナリオが存在します。それらをすべて書いていくのはとても大変です。また一つづつ書いていくと全部をシナリオ化できたかわからなくなります。例えばそれらは表で書くと簡潔に表現できます。その表を活用するのがシナリオアウトラインになります。サンプルのため少し雑なシナリオにはなりますが例を見ていきます。

Scinario: ユーザーはアカウント連携を利用してログインができる
 Given <他サービスアカウント>のアカウントを持っている
 When <他サービスアカウント>連携でログインをした
 Then ログインに成功する

 Examples:
  | 他サービスアカウント |
  | Apple |
  | Google |

このようにパターンや組み合わせを取りうるシナリオは表形式で表現するほうがわかりやすい可能性もあります。もちろんシナリオアウトラインは何にでも使うわけではなく、パターンが多すぎる場合は表でもわかりづらいため、シナリオを分割することは必要です。

シナリオを書く上での課題

基本的に小さく作る、という方針はありますが、具体的にどのサイズでシナリオを作成するべきか、どこを切り口にするかはまだ固まっていません。各チームで試行錯誤しながら実施しています。またシナリオが各チケットに分散しているため、後から機能に対してどんな振る舞いがあるかを一括でみることが難しい、施策単位でJIRAは管理されているため機能ごとに今何が動いているかがシナリオから探しづらいという問題は残っています。このシナリオの課題はThe BDD Books Formulationを読んだ上で改善を進めています。

ユニットテスト

Pocochaでは必ずユニットテストが書かれていたというわけではありませんでした。しかしアジャイル開発をしていく上でフィードバックループを小さくすることができるため自動テストは必須といえます。また品質はチームで担保するものであり、誰かに丸投げできるものではありません。エンジニア自身で品質に対して責任を持つためにもユニットテストを常に書いていくという方針にしています。エンジニアもテストしていくことで、開発チームのQAはより探索的テストなどに時間を使うこともできます。

また、ユニットテストはドキュメントとしての価値もあります。ユニットテストをわかりやすい表現で記述することで、振る舞いを把握しやすくなります。わかりやすいユニットテストについては、テストの意図を記述することを意識しています。ユニットテストについてはDeNAにはSWETグループが存在しているため、SWETメンバーがサポートをしています。最初のうちはモブプログラミングやモブレビューの形でどうやってユニットテストを書くかだけでなく、どのようなユニットテストがドキュメントとして価値が高いかまで含めてサポートしました。その後、実際に書かれたテストが増えてきてからはユニットテストを書くにあたって押さえておきたいポイントというドキュメントを作成し、そちらを参考にしてもらっています。内容は盛りだくさんなため、中身の説明はまたどこかでできればと思いますが、例えば、目次は次のようになっています。

Point of UnitTest

また、テスト周りで困ったことがあれば、SWETメンバーに相談することも可能なため、ユニットテストを書くことのハードルを極力下げるようにしています。

メトリクス

アジャイルチームのパフォーマンス把握や、その改善につなげるためにはデータが必要となります。指標としてはFour Keysなどが有名です。また、PocochaではJIRAを利用しているため、主にJIRA APIから得られるデータをBigQueryに蓄積し、DataStudioでダッシュボード化しています。 JIRAにもレポート機能はあるのですが、細かい部分に融通がきかないため現在では自分たちで作成したダッシュボードがメインとなっています。まだ取り組みの途中ですが、基本的な部分ではベロシティ、変更失敗率などもダッシュボード化しています。このメトリクス収集にはSWETチームで作成したdev-vital基盤を利用しています。 dev-vital基盤については次の資料で説明されているため、ぜひ見てみて下さい。

今後の課題

シナリオの説明でも書きましたが、BDDでは本来Feature fileにシナリオを記載した上で、シナリオをSpecFlowなどを使って自動テストとして記述することで生きたドキュメントとすることを価値としています。しかし、モバイルアプリ開発においてはシナリオの振る舞いをすべて自動化するのは困難です。シナリオを自動化しようとするとユニットテストではできず、UIテストで書く必要があります。しかしモバイルアプリのUIテストは実行時間が遅く、Flakyであることも有名です。 BDDをそのまま実現することが私達の目的ではないため、生きたドキュメントを自動テストで実現することは現在は考えていません。しかし、そうなるとシナリオは各JIRAチケットに散らばってしまうこととなり、シナリオを後から追うことが難しいです。そのため、各チケットに散らばったシナリオをどのようにドキュメントとして追跡しやすように管理していくかが課題となっています。こちらは現在対策案を検討中であり、今後その取り組みをまたどこかで紹介できればと思います。

さいごに

紹介してきた取り組みはまだ実践し始めて半年くらいと日が浅めであるため、課題が残っていたり、まだ導入途中のものもあります。そのためこれらのテストにおける取り組みを一緒に推進してくれる仲間を募集中です。採用ページ

SAFeのイベントの一つであるPIプランニングは3ヶ月に一度、その後の3ヶ月間やることのプランニングを行います。 ↩︎