こんにちは。SouzohでQAをしている____rina____です。
先日、「ショップデザインの編集」で商品をまとめたり、並び替えられるような機能をリリースしました。
こちらの機能は、メルカリShopsマガジンで新機能として紹介されています（メルカリShopsマガジンでは、新機能やネットショップの開設・はじめ方などを紹介しています。）
「ショップデザインの編集」で商品をまとめたり並び替えられるようになりました | メルカリShopsマガジン
売れてるショップの活用例４選！ショップデザイン機能で商品を魅力的に見せよう
私の推しのショップさま（豊洲まぐろ一代 メルカリ店さん）も掲載されています。リリースした週にこの機能を使いこなされていて、想像以上にかわいくしてくださってうれしかったです🐟
今回このショップデザインの編集機能の開発では、Acceptance Criteria を充実させたことによって、 QA だけでなくみんなで何がテストされるべきか、そのためにいつ、どんな開発をすべきかを考えることができるようになりましたので、取り組み方について紹介します。
Acceptance Criteriaとは
Acceptance Criteriaとは、日本語で受け入れ基準といいます。国際ソフトウェアテスト資格認定委員会（International Software Testing Qualifications Board）の用語集では
ユーザ、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない基準。
とあります。
私たちは、スクラム開発を採用しており、PBI（Product Backlog Item）はストーリーチケットとして作成しています。そして、ストーリーチケットにPBIを満たすためのAcceptance Criteriaを記入しています。通常、Acceptance Criteriaは、Product Manager(PM)がAcceptance Criteriaを書きますが、改修のようなチケットの場合は、エンジニアが記載することがありました。
今回はこのAcceptance Criteriaをより充実させて、私が普段書いているテストケースを必要としないようにしました。
今までのテスト設計と課題
ソウゾウでは、テスト設計のドキュメントの作成はルール化されていません。事前に作成する人もいますが、特別必要としない人もいます。ソウゾウではQAエンジニアが開発チームに入り、同じ人が一貫してQA活動を行うようにしているため、これまではあまりルール化の必要がありませんでした。
そのかわり、仕様レビューを行う、事前に何をテストするかを考える、頻繁なコミュニケーションを取るといった行動をし、チケット単位にはどのような観点でテスト実施したかを残すようにしています。
私はテスト計画とテストケースを事前にできるだけ作成していたのですが、自分自身で設計しテスト（システムテスト）をおこなうと、せっかくドキュメントを作成してもあまり他の人が見ること、使うことがなく、自分自身のためだけのドキュメントになっていました。テスト設計のドキュメントを使えば、私たちがどのようにテストをおこなおうとしているかを事前に知ることができますし、エンジニア自身でテストを行ったり、実装時に気を付けることもできる可能性があると思いますが、うまく活用できておらずもったいないと思っていました。
そこで Acceptance Criteriaにテストケースを追加することを試してみました。
Acceptance Criteriaの例
今回記載したAcceptance Criteriaの一部を紹介します。テストケースというには簡単すぎるかもしれませんが、あまりローレベルテストケースにならないようにしています。
どんな効果があったの？
Acceptance Criteriaをもとに関係者で共有会が可能になった
Acceptance Criteriaがある程度できた後に関係者であるPM、デザイナー、エンジニア、QAで集まって共有会をしました。その場で詰め切れていなかったメッセージがあることや仕様の変更の発生があり、みんなで合意しながらすすめることができました。
今までは、メッセージの文言などはQA時に気づくことも多く、その結果デザイン変更などが発生することもあったり、背景を正しく全員に伝え切れないこともあったので、とても効果的だと思っています。
Acceptance Criteriaをもとにテストをおこなう順序決めが可能になった
通常PBIの優先度はプロダクトオーナーが決定するのですが、今回のような開発の場合、複数のPBIをまとめてリリースする必要があります。その場合、テスト実施のしやすさで順番を決めることも重要だと考えています。リリースに必要なPBIを最後にまとめてテストをするのではなく、PBI単位または、いくつかのPBIでテストを実施することができました。
Acceptance Criteriaを見てPMやエンジニアがテストをおこなうようになった
何を確認したいかを書いてあるので、先立ってまたは並行してPMやエンジニアがテストを実施してくれるようになりました。
別のQAエンジニアにスムーズに業務共有することが可能になった
この開発中に、あたらしいQAエンジニアがチームに入ってくれました。開発終盤にも関わらず、かなりスムーズにテスト実施して、不具合指摘をしてくれていました。これがなかったら、Specを読み込むか、先にいるメンバーが説明やレビューに時間をかける必要があったのではないかと思います。
Acceptance Criteriaをみてデザイナーが追加の指摘することが可能になった
共有会に限らず、作成したAcceptance Criteriaを見て、デザイナーから足りないケースを指摘してもらいました。当初の「QAや個人だけにしか価値を発揮しなかったテストケース」から脱しました！Nice QA！
Acceptance CriteriaにPMがいい感じにテストケースを書くようになった
PM自らがAcceptance Criteriaにテストケースを書いてくれるようになり、その内容も私が追記を行わなくて良いレベルでした！最高！
Acceptance Criteriaの書き方
私たちは、機能をつくるときに、役割ごとにドキュメントを作成しています。Acceptance Criteriaをつくるときに、これらのドキュメントをインプット情報とすることで、さまざまな観点からの情報を追加することができます。次に各ドキュメントについて説明します。
Spec
PMがプロジェクト単位に作成する要求仕様です。ショップデザイン機能のような施策の内容についてまとめて書いてあります。
Acceptance CriteriaはSpecをもとに記載していることが多いです。Specには”できる”ことを記載していることが多いため、ここでは”できない”ことや、記載されていないパターンなども Accceptance Criteriaに追記します。例えば「○○円以上で、ボタンが押せること」というものがあれば「(○○-1)円以下の場合、ボタンが押せないこと」を追記したり、「エラーメッセージを表示する」とあれば、「エラーメッセージは○○と表示される」ということを追記したりします。
デザイン
実際の画面のUIやメッセージ、遷移がわかるものです。
Design Doc
開発設計ドキュメントです。ここで、今回の機能で必要となるAPIやデータの構造などがわかるようになっています。
ユーザーストーリーマッピング
スクラムチームのみんなで作ります。ユーザーストーリーマッピングは必須ではないのですが、作っている場合、このあとのストーリーチケットの作成がしやすく、ストーリーチケットをユーザーストーリーマッピングを見ることで俯瞰して理解することができると感じています。
ストーリーチケット
ユーザーストーリーマッピングでできたユーザーストーリーやMVP（Minimum Viable Product）からPBIをストーリーチケットにしています。Specから直接チケットを作成することもあります。Acceptance Criteriaはこのチケットに記載されています。Specに書いていることも記載しますが、さらに具体的な内容や、書いていない内容も追記します。ストーリーチケットとベースとなるAcceptance CriteriaはPMが作成しますが、QAがさらに追記しています。
Acceptance Criteriaをストーリーチケットに追記する際に質問がある場合は、Slackや朝会などで確認します。例えば、「一覧画面のボタンを押して詳細画面に行きたい」というストーリーチケットがあった場合に、ボタンの表示名の確認のAcceptance Criteriaが必要になるが、このストーリーチケットで確認するのか？それとも別のストーリーチケットに追加すべきか？を改めて検討します。この場合は、一覧画面を表示することに特化したストーリーチケットがあれば、そのストーリーチケットにボタン名の表示についてのAcceptance Criteriaを追加し、開発を進めることをチームメンバーと合意して進めます。
次に、このストーリーチケットを実行したいときに実行のブロッカーとなるストーリーチケットを検討します。先ほどの例では、一覧画面にボタンがないと、”一覧画面のボタンを押して詳細画面に行きたい”を確認することができません。そのため、”一覧画面を表示する”チケットを”一覧画面のボタンを押して詳細画面に行きたい”のブロッカーチケットとして紐付けをおこないます。
今回のような機能の場合、エンジニアがまとめて機能実装をしてしまいがちで、その場合テストもまとめて実施しなければならなかったのですが、これらをおこなうことで開発上の優先度も決めやすくなりました。
おわりに
関係者でAcceptance Criteriaをもとに共有会をすることによって、開発するときの解像度はあがりました。
しかし、共有する時間がかかったり、ストーリーチケットが長文になって読みづらくなったり、チケットの紐付けが複雑になって理解しづらい、仕様漏れがまだ発生しているなどの課題もあります。
それでも、開発時のコミュニケーションコストが下がったり、今までだとテスト実行時に発覚した問題を事前に防ぐことができたりしてます。
現在のショップデザインの編集を開発したメンバーとは違うメンバーで開発をしており、同様にAcceptance Criteriaの記入と共有を実施していますが、うまくワークしています。
Acceptance Criteriaの読み合わせ会後にエンジニアとPMからポストされたSlackメッセージ
今回紹介した方法は、新しいメンバーやプロダクトに深い知識がないメンバーがいた場合にも、フォローしあって解決できるやり方になっていると思います。
スクラム開発やアジャイルQAのやり方に悩まれている方の参考になれば幸いです。
