こんにちは、ClaraチームでQAをやっている @ayuay46 です！
この記事では、Claraの概要と、Claraチームでの開発・テストプロセスについてご紹介します。
Claraの誕生秘話
Claraとは、AWS版Kintoneが使用する米国向け販売管理システムのコードネームです。
AWS版Kintoneのリリースまでは、日米ともにKintoneは自社クラウド cybozu.com を利用しており、販売管理システムも日本で作った共通のものを利用していました。
そのため、米国のマーケティングチームが現地に特化した新しい施策や売り方をしたい場合に、都度日本の開発チームに仕様変更・機能追加を依頼する必要がありました。
また、開発チーム側も日本向けと異なるロジックを実装する必要がありコストがかかっていました。
そのような問題を解決するために、米国向けのKintoneがAWSに移行するのに合わせて、販売管理のグローバルSaaSを利用した米国独自のシステムを構築しました。 国内データセンターからだとレイテンシが大きいため、AWSを利用しているYakumoを基盤としています。
Yakumoの詳細については他記事を御覧ください。
Claraの開発プロセスについて
Claraチームではアジャイル開発をしています。
1週間スプリントで、要件ごとに上記の図のようなイメージで開発しています。 ※「相互レビュー」については後述。
要件は、販売管理システムを実際に利用する米国の現地メンバーと検討していくのですが、この段階からQAも入っています。 最もよく使われる操作方法はどういったものか、どういった手順をテストに落とすべきか、この段階から知ることができます。
また、リリース作業は、各要件のテストの進捗を把握しているQAが行っています。 回帰テストは自動化されているため、高速にリリースすることができます。
テストポリシー
Claraは外部サービスと多く通信するのですが、外部サービスの挙動についてはテスト対象としていません。
テストの範囲を明確に「自社製品」に限定することで、外部サービスを過剰にテストしないようにし、リリース速度の低下を防いでいます。
もちろん、手動でテストを実施するときは外部サービスを触るので、そこで外部サービスの仕様変更やバグに気づくことはあります。
また、テストはなるべく自動化しています。 テストピラミッドの考え方を参考にして、Large/Medium/Smallに分割しています。
Largeテスト
各サービスが結合された状態の挙動、かつ、ユーザーが最も利用すると想定しているケースをLargeテストとして実装しています。
Largeテストの範囲は「ハッピーパス」と呼ばれる正常系の代表ケースが主です。 他の細かなパターンはMediumテストやSmallテストでカバーしています。
Mediumテスト
APIテストがこれに当たります。Largeテストとは異なり、Mediumテストでは外部サービスと通信する箇所はモックを作成しテストしています。
Smallテスト
いわゆるユニットテストです。 1つのクラスやメソッドなどのロジックのテストをします。 またフロントエンドのテストもSmallテストとして分類しています。
相互レビュー
ClaraではDevやQAという立場に関係なく、チームとして製品の品質を高める活動をしています。 活動の一つの例として、DevとQAがお互いの成果物をレビューします。
QAが作成したテストケースをDevがレビューし、過不足がないかを確認します。 基本的にはテストは自動化するのですが、自動化が難しい箇所などがあればQAが手動でテストを実施します。
また、テスト設計をもとに、QAはDevが実装したテストコードに過不足がないかを確認します。 不足しているテストは追加で実装します。 その場でDevとQAでモブプログラミングするか、または、Devが代表的な1ケースのみを実装しそれを参考にしてQAが実装します。
まとめ
Claraチームでは、DevとQAの境目が少しずつなくなってきたなと実感しています。
一方で、製品コードを見る機会も増えたため、テストがホワイトボックスになりすぎないよう気をつけていきたいと考えています。
テストプロセス改善も随時進めて行く予定です。 テストピラミッドの考えを参考にしてテスト自動化の方針を決めていましたが、開発が進みテストが充実してきた今、テストポリシーに沿えているのか振り返ったり、テストポリシー自体を見直したりもする予定です。
