API検証 提供中

画面がなくても、検証はある。

注文・決済・会員APIが仕様どおりに応答するかを毎回確認します。スキーマ、ステータスコード、権限をケース別に判定し、UI検証と同じリリース判定に反映します。

デモを依頼プラットフォームを見る

サーバー・API案件は、画面収集を行わずAPI検証から始めます。

検証すること

仕様が、そのままケースになる。

エンドポイントごとの期待応答をケースに記述し、実際の応答と比較します。正常系だけでなく、拒否すべきリクエストや他ユーザーの注文へのアクセスが実際に拒否されるかも同じ実行で確認します。

  • 応答スキーマ — フィールド、型、必須値が仕様と一致するかを比較します。
  • ステータスコード — 24時間を過ぎたキャンセル要求に409を返すなど、成功・拒否・競合のコードをルールに沿って確認します。
  • 権限 — 別のユーザーや役割からのリクエストが403で拒否されるかを確認します。

ケースと実行

ケースは3つの出所から。

APIケースもUIケースと同じ方法で作成します。要件文書とコードから下書きを作り、担当者が書いたケースを追加。PRが開かれると、変更されたエンドポイントに応じて新規・修正・削除ケースを提案し、承認されたものだけをセットに加えます。

  • 文書ベース — 機能一覧と要件から、エンドポイント別の入力値と期待結果を抽出します。
  • コードベース — ルート、ハンドラー、入力検証ロジックから、エラー経路と境界値を導きます。
  • PR提案 — 変更を読み取ってケースを提案し、担当者が承認または却下します。
  • 自動実行ルール — リポジトリ・ブランチ・変更パターンを指定し、push・PRごとに実行します。

結果と判定

失敗した呼び出しには、リクエストとレスポンスが残る。

失敗ケースには送信したリクエスト、受信したレスポンス、実行ログが付きます。決済APIで上限超過の案内が欠けていれば、どのフィールドが空だったかまで確認できます。重大度がリリース判定を決めます。

  • 致命的・重大な失敗が1件でもあれば、 FAILになります。
  • 軽微・低影響の失敗のみの場合は、 CONDITIONALとなり、人が確認して決定します。
  • 同じコミットで結果が反転するテストは隔離されます。実行は続きますがFAILの原因にはならず、その実行はCONDITIONALになります。
  • 失敗はJira課題として自動起票され、再検証の結果と紐付きます。
リリース判定と検証範囲

検証項目

1回の実行で、確認すること。

ケースごとに検証項目を組み合わせて期待結果を定義します。ひとつでも一致しなければ、そのケースは失敗として記録されます。

応答スキーマ

フィールド名、型、必須値、入れ子構造が仕様と一致するかを比較します。

ステータスコード

200・201・400・403・409など、状況に応じたコードが実際に返るかを確認します。

権限・役割

登録済みのテストアカウントで呼び出し、許可されていない役割のリクエストが拒否されるかを確認します。

エラーメッセージ

拒否のレスポンスに理由と案内メッセージが含まれているかを確認します。

データ整合性

作成後に取得した値が一致するか、キャンセル後に状態が正しく変わるかを続けて検証します。

CIパイプラインでの実行

GitHub Actionsのワークフローステップとして実行し、PRごとに結果を受け取ります。

API仕様書との連携 プレビュー

OpenAPI仕様を登録すると、エンドポイント一覧とスキーマをケース案に直接利用できます。

リリースゲート プレビュー

判定がFAILの場合、PRチェックを失敗させるか、デプロイを停止します。

よくあるご質問

API検証の導入前に

画面のないサーバー・API案件だけでも使えますか？
はい。リポジトリ接続後に種類を自動判別し、画面収集を省略してAPI検証に進みます。対象URLとテストアカウントのログイン情報を登録すれば始められます。
OpenAPI仕様書は必須ですか？
必須ではありません。文書・コード由来の下書きに担当者が書いたケースを加えて構成できます。仕様書からエンドポイントとスキーマを直接取り込む機能はプレビューで提供しています。
既存の単体テストやCIパイプラインを置き換えますか？
置き換えません。単体テストはそのままに、GitHub ActionsのステップとしてAPI仕様の検証を追加します。push・PRに合わせて実行し、結果をリリース判定にまとめます。
本番データにアクセスしますか？
ステージング環境を推奨し、登録されたテストアカウントでのみ呼び出します。本番データベースや本番アカウントの認証情報は求めません。
人はどのような業務を担当しますか？
担当者はPR提案を承認し、CONDITIONAL判定を確認します。マネージドQAを併用する場合、専門家が仕様検証ケースをレビューし、失敗を分類して修正後の再検証まで担当します。
UI検証とは別々に結果を見ますか？
同じ実行・同じレポートで確認できます。APIとUIの失敗をひとつのリリース判定にまとめ、セキュリティ検査の結果も同じ画面に表示します。

ひとつのエンドポイントから。

リポジトリと対象URLを接続すると、通常5分で初回実行まで進めます。デモでは、API仕様の検証結果がリリース判定につながる流れをご覧いただけます。

デモを依頼導入相談

sales@qoretix.com+82-33-242-0210平日 10:00–18:00 KST