QAエンジニア目線のAPIテストでの気付き

#記事の概要
日頃画面検証の業務が多いのですが今回API新規開発で組み込み前の振る舞い動作検証の依頼を頂いた。
その中で気づいた、こうすればよかった、、あーすればよかったを記載していきたいと思います！

##検証で利用したツール
Postman
※めちゃめちゃお世話になっています・・・！！

デスクトップ版のアプリを利用しており、
TeamWorkspaceを使えば同時並行で作業(Collectionやリクエストの追加等)が可能です！
ペアを組んで作業しているので効率的に作業を進められました！
※ちなみに参考にさせて頂いた記事
https://qiita.com/Molly95554907/items/e367e83129ea1173c317
https://blog.linkbal.co.jp/4447/

##検証ボリューム
今回の検証が対象のAPIにデータセットの情報を送り、
統計モデルで計算された値が期待値通りに増減するか？という観点でした。
※画面も見えないので初めはポカン状態。

開発者やPOの方々と期待値の仮説を立てて、実験的に検証し答えを出していく。という検証方針です。

ユーザーストーリーマッピングに沿った検証パターンとデータセットの値をmin、max、中央値のパターンのかけ合わせやシステムで再現したい仕様の動きもコミコミでテスト計画～設計を行ったのでスクリプトを作成し、ある程度データセット作成の自動化も行いましたが手動検証時に必要なリクエストが💀3000件以上💀となりました。
※実はまだ絶賛対応中です😹

##工夫した点
・TeamWorkspaceをうまく利用した。
　初めはメンバー各々ローカルでリクエストを作成していましたが、
　TeamWorkspaceでスクリプトを同時作成し、他の人が作成したリクエストは積極的に流用した。

・FindandReplaceで置換作業などを行い、リクエスト作成を簡略化した。
　これがなかったら本当に詰んでました。大分助かりました。
　但し注意しないといけない点としては、Collection単位での置換となり、
　Collection配下の特定のリクエストだけ置換したいという事であれば一度別のCollectionに移して置換する等工夫が必要。

##こうすればよかった・・・・
リクエストをAPIの種類毎で管理していたのですが、これが失敗。

FindandReplaceの活用シーンで感じた点で、
シナリオベースで分けた方が一括でパラメータやtoken情報等も更新出来るので
リクエストを管理する際にもう少し考えておけばよかったなぁと思いました。

ユーザーストーリマッピングの観点が含まれている際はテストシナリオベースで管理すべきだと気づいた。

##最後に
つらい検証ですが、答えのない検証をプロダクトチーム一丸となって挑戦出来たのは良い経験になりました。

またこれまで画面上での検証が多かったのですが、データ観点で検証出来た事も新たな取り組みだったので今後QAチーム内にノウハウを落とし込んでいきたいと思います。

最後まで読んでくれてありがとう御座いました！