開発経験のないQAエンジニアのAPIテスト実装までのキャッチアップ
はじめに
これは Kyash Advent Calendar 2021 の15日目の記事です。
Kyash QAチームの@Tokkiです。 KyashのQAエンジニアとして品質管理と品質保証を担当しています。
KyashにQAが発足してから1年半程が経過しました。 今回は開発経験の少ないQAエンジニアが『APIテスト実施』をやってみた時のお話をしたいと思います。
新しいプロダクトのリリースとAPIテストへの取り組み
新サービスの開発が決まり、QAでもAPIテストを実施することになりました。 とはいえ開発経験が少ないQAエンジニアである自分が一人では、限られた期間でテスト実行までを完了することはできません。
そこでSET(Software Engineer in Test)メンバーである@konifarに参加してもらい、APIに関するレクチャーを受けながら最終的にQAエンジニアがAPIのレビューやテスト実施ができるようにすることにしました。
まずAPIテストを始めるのに、必要なことの洗い出しをしました。
ツールの選定とテスト実施時のルール決めについては、SETメンバーにリードしてもらいながら方針を固めました。
Postmanを利用したAPIテストについてはKyashプロダクトブログに公開されておりますので、読んでいただけたら嬉しいです。
※KyashのAPIのテストにおけるPostmanの運用方針
今回はPostmanによるAPIテスト実施前にやった基礎学習や、PostmanからScenarigoに移行した時の内容に触れていきたいと思います。
APIの基礎知識を身につける
テスト設計をするには、前提としてAPIの基礎知識がないと何もすすめることができません。
まずAPIの概要を理解する為にこちらの本を読みました。 Web API: The Good Parts Web APIを設計し開発するにあたって必要な知識や注意点、APIの構造などについて述べられています。 QAする立場では開発することはありませんが、「開発する際に注意しているポイント」や「API構造を理解する」ことでAPI仕様レビューやテスト設計の際の気づきを得ることができました。
次にQAチーム内で週1回1H（Total 3回実施）のAPI学習の時間を設けました。 これはSETメンバーから直接現場で必要な知識をインプットしてもらうと言う内容にしました。
第1回目勉強会の内容
(ゴール)
- API関連の基礎用語についてざっくり理解できている
- APIのテストを設計する上で、過去にKyashでテスト実施したことのあるAPIのテストケースの意味がわかる
- Postmanを使ったAPIのテストの実行イメージが持てる (基礎知識）
- Postmanツールのdemo
- HTTPメソッド/パラメータ/レスポンス/トークン/UUID などについて
- API仕様レビュー時に考えるべきこと
第2回目勉強会の内容
(ゴール)
- Postmanを使用してみる
- SlackのAPIを叩いて、そのレスポンスを確認する
- 実施に簡単なコードを書いてテストする機能の使い方を試してみる
- テスト環境や変動する値などでも、柔軟にAPIテストが実施できるように、定数を使用する方法を理解し、試してみる
実際にPostmanを使って操作してみることで、機能の使い方と効率的なテスト設計のポイントを理解していきました。 今後同プロダクトに新しくメンバーがアサインされた場合理解できるように、社内のドキュメントにインプットした内容を整理しナレッジ化しました。
こんな感じで手順を残してみていた
第3回目勉強会の内容
(ゴール)
- PostmanのPre-request Scriptをざっくり理解する
- base64 encodeの処理
- /oauth2/tokenを事前に呼ぶ処理
- レスポンスの一次変数への代入
- PostmanのTestsをざっくり理解する
- status codeのチェック
- レスポンスに特定のkeyが含まれているかのチェック
- レスポンスの値のチェック
単体テストで行う検証は全てTestsに書く方針にしました。 右側にSNIPPETSがあるので、書きたいテストに近いものをもってきて編集する形で進めました。
APIの基礎学習を経て、最初にテストケース毎にAPIテストをPostmanで実装・実行しました。
Scenarigoへのテスト移行準備とテスト実装
前回Postmanで実装済みのテストをScenarigoに移行することで、GitHubで管理してチームでテストをメンテナンスしやすくするというのが今回のテーマでした。 Scenarigoに移行については@konifarがソフトウェアテスト自動化カンファレンス2021での登壇資料を是非ご覧ください。 Introduction to API Testing Automation by Postman
一定のAPIへの実装を開発メンバーが行った時に、CIでテストが自動実行されれば常に既存の機能に問題がないか確認を行うことができます。
また、Postmanではプランの都合上テストを追加・編集できるのがQAメンバーだけに限定されていましたが、今後行うAPIのテストは開発者が直接Scenarigoで記述していけば良いので効率的です。
準備1: テスト実装環境を整える
テスト実装を行うのに使用するツールは以下です。
各ツールのインストール後にSSH keyを登録し、GoのPathを通すなどの設定を行いテスト実装が可能な環境が整いました。
準備2: テスト実装に必要な開発ツールの基本操作を理解する
PostmanのシナリオはJSON形式で書いてます。 それを１ケースつづScenarigoで実装していきます。
前回は「Postman」というツール1つを使用すればよかったのですが、今回からはそうはいきません。 テストコードを実装するので、開発者と同じようにGitHubのPull Requestフローを理解しなければなりません。 最初に戸惑ったのは、GItとGitHubの概念の理解が必要な以下の複雑な一連の作業の流れでした。
- プルでソースの変更を取り込む
- Masterのリポジトリから作業用のブランチを切る
- テストシナリオの新規作成、改修などの実装をする
- 変更箇所をローカルでテスト実施
- コミット＆プッシュする
- プルリクエストを作成する
- レビュー結果問題がなければマージする
テスト実装と実施1: 簡単なテストシナリオを書いてみる
最初はシナリオの内容がシンプルなものから作成を始めました。 できたら次は『値の部分を置き換えるだけで作成できる』様なテストシナリオから実装する。という様にテストシナリオ的には複雑ではないものから着手することで、開発の一連の作業をまずこなしてみることにしました。
それでも最初は作業が複雑なのでどこかでミスってしまいがちでした。
初期は調べても理解できないことも多く、SETメンバーに連携してフォローしてもらう体制を維持しながら進めていました。
またテスト実装は日々の業務の合間の時間で「1日シナリオを4つ実装する」などと決めて実行し、開発で生じる一連の動作に慣れるようにしました。
最初の頃は都度何かしらエラーにぶつかりました。
- SSH Keyは設定済みのはずなのに、なぜかエラーになり再設定を行わないとならない
- ローカルでテスト実行しようと思ったら、GoのPathが通っていなかった
- PushしようとしたらSource Treeに怒られてPushできない
何か1つエラーが解決して作業が進むと、次の段階でまたエラーにあう繰り返しです。 作業が流れるように進むこと自体が大変でした。
表示されたエラーの内容をGoogle検索して、原因と対処法を確認し実行してみることを実践し課題を解決しながら学んでいきました。
上記の対応を何度か繰り返しているうちに、エラーで見るべきポイントや何で怒られているのかがなんとなく分かるようになってくるので良かったです。
テスト実装と実施2 :基本作業の流れ&遭遇したエラーの解決方法をナレッジとして整理
今後QAの他のメンバーがAPIテストを担当する場合も想定して、作業の基本の流れはナレッジとして整理しました。 アウトプットすることで頭の中が整理され、不明点が明確になり確実に作業が定着していきました。
作業手順やエラーの解決方法を、Doc.に整理してナレッジとした
テスト実装と実施3: 細かくPRを出す
テストシナリオの実装作業に慣れてくると、ついまとめて大量に複数の実装をPRとして出してしまいたくなります。
実際に最初はPRの出し方が下手で『自分が混乱する』『レビューする人に不親切』な出し方になっていました。
とりあえず実装したものを大量にまとめてPRに出した結果、レビューでの修正が複数あるのでそれを全て修正するのには時間がかかりました。 そして単純に内容を把握して対応するのにも、大量の実装をまとめてしまうと何の実装のどの部分を直すのかの把握で混乱すると感じました。
レビューする人もPRのTicketのタイトルからなんとなくどの内容の変更なんだなーと思って開いたら、複数の違う内容が混在していたらレビューできなくはないけれど混乱すると思いました。
といった感じでPRは、『手戻りが発生した時に対処しやすい対応方法で進める』のがいいと学びました。
変数に関するアカウント情報の追加だけをPRで出し、その後その変数を使用するテストの実装を別のPRで出した。
テスト実装と実施4: PRのレビュー
実装した自分のテストを見てもらうことで、コメントにもらえる質問・確認・指摘などのFBがものすごく勉強になり価値あるものだなという経験になりました。
なるほどと気づきがあることでちょっとしたことですが、実装時に気をつけるポイントとなりました。
- 変数名を書くときはどんな条件・何用のものなのかより分かりやすくする
- コードの中には本当に必要な場合のみコメントを入れる、不要なコメントは変更時の手間を増やす
テスト実装と実施5 :自動化やAPIテストで使用するアカウントは専用で用意し管理する
様々なテスト条件に合わせたアカウントがテストシナリオごとに必要になります。 通常の手動テストでは、テスト条件ごとに都度必要なカウントを作成しています。 作成されたアカウントはテストエンジニア同士で認識し使用できるように、アカウントリストに整理し管理しています。
APIテストで使用するアカウントも別途作成し、APIテスト専用のアカウントとして共通のリスト内でステータスを変更して管理する様にしました。
CIで自動テストが実行される際に使用するアカウントの条件が、他のテストの実施に使用されて変わってしまうことを防止すること。 APIテストで使っている各アカウント情報も、一括で把握・管理できる様にするためです。
テスト実装をScenarigoでやってみて
きつかったこと
既存の業務や会議体をある程度整理して、決まった作業時間を日々の中で確保すること。 Scenarigoへのテストシナリオ移行は、担当のメイン業務とは別枠のチャレンジとしての取り組みでした。 担当業務はそのままの稼働で調整せずに行ったので、日によって時間確保が難しいケースもありました。
自動化なども含めて今後も実践で実績を残していきたいと考えているので、この辺は整理し改善したいと思います。
良かったこと
SETメンバーにフォローをしてもらえる環境があったことで、Scenarigoへのテストシナリオの移行が可能でした。
実際に簡単な実装内容から徐々に実践で身につけていくことが、頭で色々考えるよりも理解が早かったと感じました。 開発者の視点に近いものを体験できたことが、一つ大きな収穫でした。
普段QAとしてテスト実施以外の品質管理に関すること全般を担当しています。ゼロから作り上げることや、既にある課題に対する改善を実施しています。 それらは直ぐに期待結果や成果が目に見えて分かることがとても難しいものです。
そうなると常に目の前にある課題に対していろんな角度から向き合って、アプローチし続ける日々が淡々と続きます。 業務の間に開発の実装（テスト実装）をやることで、スパンと結果が出る作業ができるので頭の切り替えになりました。
QAチームに開発知識のあるSETメンバーがいたこと。 Android開発者でスペシャリストであるSETメンバーがいたことで、導いてもらいながら実践できる環境であったというのが最も良かったです。 @konifarの功績と未経験分野にチャレンジし続ける自分の好奇心の成果は大きいなと感じます。
さいごに
Kyash Advent Calendar 2021 はまだまだつづきます、あしたの投稿もおたのしみに〜。
