【英語版やってみました】http://taichiw-e.hatenablog.com/2019-01-07バグチケットに各APIのリクエストとレスポンスが貼ってあったらバグの調査は早く終わるのか?モヤモヤと考えたことを書き出しています。実践もまだしてません。APIが相互作用するサービス*1に関わっています。こんな感じで組織が別れています*2。このサービスについて不具合が起票されることがあります。リリース前のQAだったり、残念ながらリリース後、本番可動しているサービスに対してだったりします。いずれにしても大事なこととして、不具合はここの視点、最も浅いレイヤである、UIの「挙動が期待通りでない」事象として発見されます。4にバグが有るDB1のデータが正しくないDB2のデータが正しくない不具合を修正するためには、この中のどこに問題があるかを見つける必要があります。いずれか)にバグが有るケースを考えます。バグが有る、ということは外から見たプログラムの挙動として、以下の2つのいずれかに分類することができます。伝搬することになります。3を修正する必要があります。4そのものは正しく動作していますが、リクエストが誤っているため期待通りでないレスポンスを返し、最終的にそのレスポンスが原因となってUIの挙動が期待通りになりません。2を修正する必要があります。「赤い矢印」が見つかればどのプログラムがバグっているのかわかる前項で見たとおり、期待通りでないリクエスト、またはレスポンスである、「赤い矢印」がどこから始まっているかがわかれば、バグのあるプログラムである、「赤い四角」の箇所が特定できそうです。こんな表を自動生成することはできないでしょうか。4※矢印はイメージです。TraceIDを発行しているため、一つのUIアクセスから始まる各APIのリクエスト/レスポンスを集めてくるのは技術的には可能そうです。4へのリクエストが間違っています。2にバグが有る、と推測することが可能です。気づくことができるのは誰でしょうか...。Dが担当しているので、それぞれのチームのエンジニアに気づくチャンスがありそうです。2の担当エンジニアは、上の表から以下のことに比較的簡単に気づけそうです。いう推測は立てられそうです。4へのリクエストの検証についてはどうでしょうか。シンプルな間違え*3ならばすぐ気がつけそうですが、もう少し複雑な間違えですとすぐには気づけないかもしれません。4のリクエスト使用を誤って理解しているかもしれません。4の担当エンジニアが気づくためには、以下のことを理解している必要があります。4のリクエストが生成されるのが正しいのかなぜならば、バグの起票時点では、UIレベルの情報しかないからです。これも、即座に正しいか誤っているか判断できる場合もあると思います。4の使われ方によっては、中間のAPIの仕様を知らないとリクエストの正誤の判断が難しいかもしれません。いう気がしてきました。レスポンスの正しさの確認のほうが簡単かもでは一旦、「すべてのAPIのリクエストは正しい」と仮定して、レスポンスの正しさだけに注目したらどうでしょうか。バグの起票時に、UIレベルで「本来Aという振る舞いをすべきところ、Bという振る舞いをしている」ということは記載されています。