はじめに

右も左もわからない現場に行き、行なったことのないAPIを使ったテストを含め、
決められた期間内にノルマを達成しなければいけない。
そんな状況の中、先駆者の助言もいただきつつ、
触ったことがないツールを手探りで理解しながら、
ケース作成・テスト実行を行なってきた体験談をまとめてみました。

手探りでしたので「それ違うんじゃない？」と思う部分もあるかもしれませんが、
温かい目で見ていただけると幸いです。

まず始まってみて

そもそもAPIのテストってどうやってなにをテストするの？から始まり、
最初に得た情報は、

　「APIに関する仕様書はこれです」
　「POSTMANというツールを使ってテストをします」

の2点です。
仕様書は英語と他言語の2言語で書かれており、日本語の説明はありません。
翻訳機能を使っても、誤翻訳が混じったり、意味が逆転することもしばしば。

POSTMANの使い方講習が開かれるも、
そもそもAPIでどうなるかのイメージがわかないメンバーには、
使い方を説明されるだけでは理解するに至らず、手探りする日々が始まります。

唯一講習で得て役立ったのは
**「APIのテンプレを作成し、テスト実行者はコピーしてから使う」**ことでした。

何が出来るのかを理解する

まずは「POSTMAN」を理解すること。
テストケースを作るにも、テスト実行をするにもまず理解をしなければ始まりません。

そもそもPOSTMANとは？

「APIの動作を確認するツール」であること。
Requestの内容やTokenを設定し、APIに送ることでResponseが返ってくること。

簡単に述べるとこのような感じでしょうか。
実際には他にも色々なことが出来るようですが、
今回のテストには無関係でしたので捨ておきます。

ではPOSTMANの画面を見てみましょう。

※当記事内の画像は記事用に編集している為、実際の画面とは異なる部分があります。

細かい部分の説明は省きますが、
開発側で用意していただいているコードをインポートし、送信を行ないます。
例として「現在存在しているギルドルームの情報を取得するAPI」を送信したとします。

正しい入力が行なえていればSuccessResponseの結果が返ってきます。
Responseにはフィールドのtypeとvalue(IDや数値など)に
取得したデータが表示されることがわかりました。

ではSuccessResponseになる状態でテンプレ化すれば良いのか？
と言われればそうではありませんでした。

APIの内容によっては、「Params」や「Body」などの各種入力内容を変更したり、
対象とする「ユーザーID」や「ギルドルームID」など固定ではない入力箇所がある為、
テスト実行者個々で入力する必要がありました。

ここまで理解を終えたら、テストケースの作成に移ります。

何をテストするかの粒度を考える

各種APIにはフィールドが数多くあり、それぞれにどのtypeが表示されるのか、
どのようなvalueが表示されるのかが仕様書に記載されています。
全てをケース化して網羅しようとすると膨大な量になり、
ケース作成もテスト実行も工数が掛かります。
時間にも限りがある為、粒度を考える必要がありました。

▼考えられた粒度
① 全フィールド × 全type × 全value の確認＋状態別・イレギュラーの確認
② 全フィールド × 全type × 全value の確認
③ 全フィールド × 全tyep × 任意value の確認

①では仕様書に記載されているvalueパターンを全網羅します。
一例として、ギルド内の役割をResponseで確認する場合に、type「role」の確認として、
　・ギルドマスターなら「Admin」
　・副マスターなら「co-admin」
　・メンバーなら「member」
の3種類全てを確認します。

加えて、実機を操作して状態を変更した場合の確認や、
イレギュラー動作時の確認も観点として含めます。
一例として、ギルド内の役割をResponseで確認する前に、
実機でギルドを解散させる・ギルドから脱退するなどをして、
対象を失くしてから送信をし、正しくエラーが返ってくるかを確認します。

②では仕様書に記載されているvalueパターンを全網羅します。
ただし、記載のvalueが表示されることの確認のみとし、
実機動作やイレギュラーの観点は含めません。
下げた粒度についてはフリーテスト時に補う形とします。

③では仕様書に記載のtypeが全て表示されるかの確認はしますが、
valueパターンは網羅せず、いずれかのvalueが返ってきているかどうかの確認までとします。
粒度についてはフリーテスト時に補う形とします。

どの粒度でテストを行なうのかを、
現場のリーダー、及び開発方と擦り合わせて決めていきました。

テストケースにどこまで落とし込むか

テストの粒度も決まり、ケースを作成していくわけですが、次の問題にあたります。
テスト条件・テスト手順をどのような内容にするかです。

前述の通り、POSTMANを理解することと、
SuccessResponseを正しく得るためには入力対応が必要です。
そこで思い出したのが講習で習った内容
**「APIのテンプレを作成し、テスト実行者はコピーしてから使う」**になります。
テンプレ化に踏まえて以下の対応を行ないました。

・実行者全員で共通なものは全て入力を終えた状態にしてRequestをテンプレ化する
・どのAPIでどのテンプレを使うのか手順に記載して明確化する
・実行者個々で入力が必要な内容だけ手順に盛り込む
・上記を実行するのに必要な最低限の知識を全員に説明して把握する

上記を行なうことにより、テスト条件・テスト手順の記載が簡略化でき、
実行者全員で統一されたテストが行なえるようになりました。
また、POSTMANではRequestをエクスポートできる為、
テンプレセットとして他の方に共有も可能でした。

以上の対応により、ケース作成・テスト実行も進行でき、無事にノルマを達成です！

終えてみて

端折った部分も御座いましたが、APIのテスト経験のお話は以上になります。
手探りな日々でしたが、POSTMANの使い方を理解出来た途端に大きく見え方が変わります。
理解する為の資料やマニュアル作りも対応策の1つになると思います。

これからAPIのテストを実行する予定がある方への参考となれば幸いです。