こんにちは、freeeでQAエンジニアをしているymty（ゆもつよ）です。この記事はfreeeカード Unlimited の開発の裏側について紹介する連載の第8回目（最終回）になります。

今までの連載の中で、freeeカード Unlimitedのアーキテクチャーやインフラといった技術的な側面や、若い優秀なエンジニアや、EMからエンジニアにロールチェンジした敏腕エンジニアが取り組んでいること、そしてEM（エンジニアリングマネージャー）がどのようにチームに関わっているかといった話題がありました。

この記事では、freeeカード Unlimited の開発でQAの人たちがどのようなことをしているかを書きたいと思います。スクラムチームでのQAのやり方の参考になれば幸いです。

freeeカード Unlimited の開発でアジャイルQAを始めた経緯

freeeカード Unlimited の開発は、スクラムで行っています。スクラムでの開発に適したQAの実践方法を私たちはアジャイルQAと呼んでます。

アジャイルQAを行うきっかけは、金融開発チームのEMであるyokotaさんと約2年前に話をしたときでした。

yokotaさん

「現状はQAにテストをして欲しい時に依頼をして、それから入ってもらっているが、今後はQuality Firstでやっていきたい。」「小さい単位でテストしていけるといい、と考えている。」「金融特有の言葉があるので、それも追々理解いただけるといいな。」

ymty

「ぜひやりたい！（アジャイル開発の経験ないので超やりたい...yumotsuyoの心の声）」「KickOffの段階から入りたい！スクラムイベントにも参加するようにします！」「金融のアジャイル開発にあったQAの形を作ってきます！」

この会話が発端で、アジャイルQAは始まりました。

QAのテストはアジャイル開発ではどうあるべきか

アジャイル開発に適したテストをQAが行うために大事なことは、ビッグバンテスト（開発が終わったらQAがテストを一気に始める）を行うのではなく、早い段階からテストを始めて、安心を積み上げていくことだと考えます。結果的に、ビッグバンテストを行うよりも開発を速くする効果があります。

QAのメンバーがアジャイル開発の一員になるにあたり、最初に決めた行動指針は以下のことでした。

できるところからどんどんテストする

プロダクトの全体像／仕様はengとQAで一緒に理解していく
仕様が理解できたらすぐにテストケースを設計していく
QAの観点で（なるべく早くからテストが始められるように）何から開発をして欲しいか意見をいう
仕様が変わったらテストケースもメンテする
開発が完了したら後はリグレッションテストだけにする

少人数でテストをする

テスト設計とテスト実行は同じ人が行う（仕様を詳しく知ってる人がテストをするのがよい）

QAのメンバーへは...

開発チームの一員として価値がある行動をしよう！(テストするだけがQAじゃないよ！)
リリースされる前に（ユーザーと同じ目線で）プロダクトに最も触れているのは自分なんだと自負できるようにしよう！
「バグを見つける」「テストを進捗させる」常に「足りないor余計なテストはないか」を考える

そうして、金融開発チームにてアジャイルQAを取り入れた開発の経験を積んでいき、 freeeカード Unlimited の開発もアジャイルQAで行うことになりました。

freeeカード Unlimited の開発でQAがやってること

ここからは、freeeカード Unlimited の開発でQAがやってることを書いていきます。

スクラムイベントへQAが参加してチームの一員となる

私は、freeeカード Unlimited の開発が始まった当初にチームに合流しました。当初は、ユーザーストーリーマッピングやストーリーチケットの見積もり会などに参加しました。このころ、QAは私一人でしたが、今ではQAのメンバーも増えて、朝会、リファインメント、振り返り、プランニングといったスクラムイベントには全て参加しています。

QAがチームの一員として参加することで、今の開発全体の状況がわかり、QAは自分たちが何をしていくのがチームにとってよいことなのかが判断できるようになります。できるところからどんどんテストしていくためには、チームの状況を把握したうえで、どこからテストしていきたいかをチームに伝えることが大切です。結果的に早い段階からQAがテスト可能になり、エンジニアもQAも待ち時間が発生してしまうといった状況に陥らずに開発を進めていくことができます。開発が終わった後からQAが本格的にテストを始める方法とは異なり、開発が終わった時には計画したテストが終わっているので、一通りリグレッションテストをすれば、すぐにリリースができます。

前述したように、金融開発チームは、freeeカード Unlimited の開発よりも前からアジャイルQAの経験を積んでいます。前回のyokotaさんの記事にあるように、金融開発チームは、チームとしてうまくQAと連携する方法を知っていたので、freeeカード Unlimited の開発でも問題なくアジャイルQAを適用することができました。

できるところからどんどんテストをする

アジャイルQAでは、スプリントごとにdoneしたストーリーチケットを、その後のスプリントでまとめてテストします。

freeeカード Unlimited のQAとしては、具体的にどんなことをやったのか、オーソリ*1のテストを一例として紹介します。オーソリのテストは、ざっくりいうと下図の中の「ここのテスト」という部分のテストになります。

オーソリのテストでは、事前準備として、画面上の申し込みからデータ登録を行い、一連の処理をしていくことが必要です。しかし、一連の処理が完成するのを待っていると、アジャイルQAになりません。なので、以下の箇条書きで示すように準備して実行します。

freee会計の事業所を用意して、テスト設計したオーソリのパターンに沿ってデータを作る。
カード発行依頼に必要なデータをデータベースからSQLで取ってくる。
カード発行をするためのAPIをPostman（APIテストのツール）で実行し契約番号を取得する。データは [2. ]のデータを使う。
アクティベート状態にするためのデータをinsertする。データは[2.]と[3.]で持ってきたデータを使う。
テスト設計したカード利用パターンが確認できるJSONを作ってPostmanでPOSTする。
期待した通りのデータで登録されていることを確認できるSQLを実行する。 →5と6でのレスポンスはテストの期待結果として確認する。

テスト設計したオーソリのパターンの一部を以下に掲載します。表の上段のまとまりが「オーソリ→クリアリング」といったテスト実行の際の処理順序を定義しています。中断のまとまりが、処理順序の中でどのような内容のデータを組み合わせていくかを決めています。3つ目のまとまり（最初の列に連番をつけている項目群）がテスト条件を列挙したものになります。このパターンは、ドメインエキスパートであるプロダクトマネージャーに抜け漏れがないかをレビューしてもらい、テストとしての質を確保しました。

QAとしては、オーソリ処理の品質が重要だと考えていたので、このような方法でなるべく早くにオーソリのテストを始めるようにしました。

画面がない段階からテストする

画面がない段階からAPIを叩いてテストをするのは、設計面のハッピー（freeeではバグのことをハッピーと呼びます）を見つける効果もあります。

例えば、画面入力のバリデーションチェックを確認するテストをする際にも、APIテストだとバリデーションがバックエンドで効いているかをテストできます。他にも、マイクロサービス間の不整合がないかといったテストもUI上からテストするよりも確実に行えます。

チームとしてQAに取り組むからこういうことができる

エンジニアには、QAがRDSに接続できるよう権限を絞ったアクセス権を作ってもらったり、テストデータ作成ミスでうまくいかない時に助けてもらったり、逆に手間をかけてしまってるかもしれないという噂もあります（笑）。しかし、そのおかげで早い段階で安心感を積み上げるようテストができています。できるところからどんどんテストしていくのは、チーム全員の力で実現できていると実感します。

受け入れ基準はQAが書く

freeeカード Unlimited でのアジャイルQAとしての他の取り組みとして、ストーリーチケットの受け入れ基準を書くことについて言及したいと思います。

まず、アジャイルかどうかに関わらず、QAが予定しているテストはチーム内で共有する必要があります。freeeの中でよくやる方法は、テストプランのレビューと一緒に、QAがテストすること一覧の内容をチーム内で確認する時間を取る方法です。この方法は完成したプロダクトに対してのエンハンスではやりやすいのですが、全くの新規開発だと実施するタイミングや回数に課題がありました。

freeeカード Unlimited の開発に参画して間もない頃、ふと「QAがテストすることって、ストーリーチケットの受け入れ基準と一緒なんじゃないかな」とひらめきました。そして、「QAが受け入れ基準を書きたい」とプロダクトマネージャーに提案をして、受け入れてもらいました。

エンジニアは、リファインメントにてストーリーポイントをつけていきます。QAは、仕様を理解したらすぐにテストすることを考えて、リファインメントより前に、ストーリーチケットへ受け入れ基準として記載するようにしていきました。受け入れ基準を記載しておくことで、QAは何をテストしようとしてるのかがエンジニアに共有できました。エンジニアは、ポイントをつける際に受け入れ基準も考慮していました。そして、プロダクトマネージャーとエンジニアとQAで、OKとすることの認識に齟齬があれば、早い段階で解消ができるという効果もありました。しかし、一番の効果としては、QAがテストすること一覧を確認するミーティングでチームのみんなの時間を余計に使わなくて済むようになったことだと思います。

重篤度(Severity)をチームで合意する

ハッピーには、重篤度(Severity)を付けます。重篤度(Severity)は優先度（Priority）とは異なり、ユーザーが利用している時に発生するとどれだけ良くないことになるかの度合いです。

ハッピーに重篤度(Severity)を付けることで、リリースまでに絶対直すべきか、リリースブロックにはせずに、なるべく早く修正してhotfixをリリースするという判断ができるようにしました。

重篤度(Severity)を付けることは、昔からあるプラクティスであり実践している人たちも多いと思います。freeeの全プロダクトでも重篤度の定義をして運用をしています。

重篤度(Severity)は、エンジニア、プロダクトマネージャー、UX、QAのみんなで意識合わせをして、同じ目線で見れることによって初めて迅速な判断が可能になります。freeeカード Unlimited は全くの新規プロダクトなので、この合意をするタイミングが難しかったです。ドッグフーディングをするあたりでみんなに集まってもらい、何度かのディスカッションを行って決めました。リリースが近づいてくると、朝会などの場で修正が終わってないハッピーを確認し合いますが、その時にも重篤度(Severity)は判断基準として役に立ちました。

テスト自動化への取り組み

freeeでは、エンジニアが自分で書いたコードのテストを書いています。freeeカード Unlimited も他のプロダクトと同様に、エンジニアがテストを書いて、実行結果がOKであればチケットが完了になります。

QAは、前述したように、エンジニアが完了にしたチケットのうち、ストーリーチケットをQAで行うテストの単位としています。 freeeカード Unlimited では、ストーリーチケット単位で行うテストは、全て手動テストで行っています。

「あれ、自動化はしないの？」と思う人たちも多いかもしれないですが、QAが行う最初のテストは、ユーザーが使うのと出来る限り同じように操作したほうがよいというのが私の考えです。そうすることで、UXと一緒に見た目の動きも確認できます。

ただし、前述したオーソリのテストのように、最初はPostmanを手動でポチポチしながらテスト実行していたものを、前段の一連の処理が繋がってもポチポチ手動でテストをやっていると、テスト実行に果てしなく時間がかかってしまいます。

一連の処理の手動テストが終わったころ、QAメンバーのひとりが、オーソリまで全ての処を一発で実行できるAPIテストを作ってくれました。APIテストによって、オーソリの後の処理（例えば、請求など）を手動テストする際にも、テストのための準備が一瞬でできるようになりました。テスト準備が一瞬で出来るので、常に新しくデータを作ってテスト実行ができます。これは、オーソリまでの一連の処理を常にリグレッションテストしているのと同様の効果もあります。

APIテストによって、申込からオーソリまでの一連の流れを一瞬でテスト出来るようになったのも、エンジニアと同じチームとして取り組めているからこそだと思っています。一つ例を挙げると、APIテストにおけるバッチ処理の対応が挙げられます。オーソリまでの一連の流れの中には、いくつものバッチ処理が裏側で実行されています。それらはAPIでは操作できないものもありました。APIテストでコントロールできない場合は、テスト環境にセットしたスケジューラーがバッチを稼働させるのを待つ必要があります。こうなると、申込からオーソリまでの一連の流れは一瞬で実行できません。一連の流れを全て終わらせるのに丸1日かかってしまうこともあります。

「これじゃテストのスピードが出ないのでなんとかしたい！」と、APIテストを書いてるQAメンバーがエンジニアに相談し、テスト用にバッチ実行のAPIを作ってもらいました。そのやりとりを見ていて、「あー、アジャイルQAってスクラムチーム全体で取り組むから実現できるんだな！」と改めて感じることができました。

最近は、一度実行した手動テストから、リグレッションテスト用にSeleniumをベースにしたe2eの自動テストを書いて、常に実行するようにしています。開発対象の一連の処理が完成し、安定してきた今だからこそe2eの自動テストが作れるようになりました。

今後は、APIテスト、e2eテストの両方を増やしていき、リグレッションテストの高速化を図っていこうと思っています。

まとめ

今回、この連載にて、freeeカード Unlimited の開発チームとしてアジャイルQAの話ができる機会をいただけたことに感謝です。QAとして取り組んでることをもっとたくさん書きたいのですが、すでに結構な文字数になっているので、ここで終わりにします。

この連載も今回で終わりになりますが、2021/10/29 (金) 19:00〜のfreee Tech nightには、freeeカード Unlimited のエンジニアであるtabachainさんとimamuraさんが登場し、記事では語り尽くせなかった開発秘話を話してくれる予定です。私も楽しみです。

freee-tech-night.connpass.com

freeeカード Unlimitedの開発は、これからも続きます。チームのみんなで、より良いプロダクトに進化させていきますので、どうぞご期待ください。

freeeのQAでは仲間を募集しています。アジャイルQAによって「マジ価値を届けきる」ためのリリースが速くなるという世界を一緒に実現しませんか！ https://freeecommunity.force.com/jobs/s/detail/a4l1000000170iZAAQ

*1:クレジットカードのサービスには、オーソリと呼ばれる、お客さまのクレジットカードが決済可能かを確認する処理があります。カードで買い物をするとき、お店のカードリーダーにクレジットカードを差し込んだ直後に「通信中」になり、「カードを抜いてよい」という状態になるまでの間に内部でいろいろやっているのがオーソリです。