弁護士ドットコム株式会社 Creators’ blog

弁護士ドットコムがエンジニア・デザイナーのサービス開発事例やデザイン活動を発信する公式ブログです。

mablers.jp登壇レポート_APIテストのリアルをお届け！弁護士ドットコムでのmablの活用方法

QA CLOUDSIGN イベント・カンファレンス

こんにちは。クラウドサイン事業本部 QAチームの田中です。 先日、自動テストツール「mabl」のユーザーイベント「mablers.jp」にて、APIテストをテーマに登壇させていただく機会がありました。 今回は、スライドでお伝えしきれなかった部分を中心に振り返りながら、登壇レポートを書かせていただきます。

※イベントの詳細情報はこちらをご覧ください。

登壇資料

資料はSpeakerDeck に公開しております。

アーカイブ動画

この登壇はYouTubeにアーカイブ動画を公開しております。

発表内容

今回の発表は「APIテストで見えた新しい未来」と題し、クラウドサインの環境へのAPIテストの導入プロセス、具体的な効果、今後の展望などを発表しました。

なぜAPIテストを導入したか

なぜAPIテストを導入したかを説明するスライド(P.15)。新機能のE2EテストはUI操作からアプローチしている。

  • その理由

外部公開されているWeb APIサービスのテスト整備をする過程で、APIという仕組みをテストに活用する事に大きなメリットを感じていました。

他方で、これまで新規機能のテストはUIテストが担っており、フロントエンドの実装を待たないとテストができませんでした。 これではテストサイクルに柔軟性が無いため、内部API（外部公開されていないAPI）をテストに活用することを決めました。

何故mabl で取り組んだのか

どのように解消したか(mablの活用)を説明するスライド(P.24)。mablの利点を紹介している。

  • mablの利点

「mabl」の直感的な操作はAPIテストのハードルを下げ、APIの構造理解を補ってくれます。 また、チームで継続して利用する事でノウハウが蓄積され「mabl」の効果を最大化できます。

具体的な取り組み

APIテストを行う上で意識したことを説明するスライド(P.25)。「実装される画面と、ユーザーの画面操作を想像してテストする」、「UIテストで確認すべき箇所にあらかじめアタリをつけておく」ことを紹介している。

  • テスト対象のAPIの選定にあたり

実装されているAPIがシンプルで直感的に理解しやすく、ユーザーに近い処理/操作が表現しやすい為、フロントエンド向けのバックエンドのサーバ（Backend For Frontend）に実装されているAPIでテストを実施しました。

この項については、参加者からも具体的な質問が上がっていましたので、いくつか内容を抜粋します。

Q：API単体のテスト、複数APIを繋げたシナリオテスト、どちらもQAEが担当？

→どちらもQAが担当しています

Q：フロントエンドのテストとの重複する部分、どう扱っている？そもそもQAが扱いたい？

→現状は重複を許容していますが、将来的にはアーキテクチャを理解した上で切り分けていきたいです。

Q：Open API vs Internal API考慮しなければならない点は　違う？同じ？

→ Open API は一つのAPIの機能にフォーカスしたテストで、 Internal API はAPI間の繋がりを意識したシナリオテストにフォーカスしているイメージです。

効果

テスト工程の変化を説明するスライド(P.30)。テスト工程を40%前倒すことに成功。具体的には、これまでは開発進捗70%からテストを開始という状況であったが、mablの活用により開発進捗30%からテスト開始ができるようになったことを紹介している。 開発工程の変化を説明するスライド(P.31)。バグの60%をAPIテストで検出できた。具体的には、プロジェクトのテストにおけるバグの60%をフロント実装前のAPIで検出、バグのフィードバックサイクルが早くなったことを紹介している。

  • APIテストがもたらした効果

APIテストの導入により、バグの早期検出が可能となり、プロダクトのフィードバックサイクルが向上しました。

副次効果 わかった事を説明するスライド(P.34)。開発エンジニアとQAのシンクロ率が向上して紹介している。スライド右側にネクタイを絞めた男性が万歳して喜んでいる画像が挿入されている。

フロント実装前の開発エンジニアは、形になってない機能をイメージしながら実装を進めています。今回QAがやったAPIテストに関しても、まだ実態が無い状態の機能と、その先にあるユーザーを想像してテストをしていました。 これにより開発とQAの間でイメージが共有され、一体感を持ってプロジェクトを進められました。

課題と今後の展望

これからやりたい事を説明するスライド(P.37)。「クラウドサイン全体へのAPIテストの浸透」と「UIテストの見直し」について紹介している。スライド下にネクタイを絞めた男性がパソコンを黙々と眺めている画像が挿入されている。

APIテストの浸透

  • API自体の役割が何か、APIテストは何をテストすべきなのか という部分の浸透ができていないので、知識のアップデートを進めていく
    • その上で開発エンジニアにAPIテストの有効性を伝えていく

UIテストの見直し

  • APIテストというものがテスト工程に入ってきたので、これまでのUIテストの捉え方に変化が求められる
    • バックエンド、フロントエンドのアーキテクチャの理解を深め、何故そのテストをやるのか？といった問いに明確な回答ができるテストを作っていく

参加者の反応

発表後のパネルディスカッションでは、より具体的なAPIテストのプロセス部分の質問や、そもそもどうやってAPIに関する知識をつけているのか等、実際に”やる側”の細かい内容の質問が多く寄せられました。 参加者にいただいた質問の内容から、APIテストの「How」への高い関心が伺い知れて興味深かったです。

また、イベントの終了後、ポジティブなフィードバックをいただけた事が嬉しかったのと、QAチームでもこれが起点となってAPIに関する会話も増えてきた実感があり、社内でのAPIテストの普及にも弾みがついたと感じています。

まとめ

今回登壇内容を考える過程で、APIテストだけではなく、QAチームのテストプロセスの現在地の整理が出来たことが大きな収穫でした。 また、登壇がきっかけで、QAチームとして次にやるべき事とその道筋が明確になりました。今後も振り返りを形にする（発表する）という行為は、形はどうあれ継続してやっていきたいですね。

今回は発表側でしたが、自社で抱えている課題解決のヒントを得るという意味でもコミュニティに参加する事で得られる各社の知見がインセンティブになると感じました。 改めてこういった機会をくださった mablers.jp様に感謝申し上げると共に、次回のイベントでまたお会いできることを楽しみにしています！

© Bengo4.com, Inc. 2005