The learner can explain what an API is, why it is tested directly, and write up an API-related defect.
APIs, direct testing and writing up a defect
APIs, direct testing and writing up a defect
An API (Application Programming Interface) is a contract between programs. It defines what requests one program can make to another, what data to send, and what response to expect back. When you use a weather app on your phone, it talks to a server through an API: "Give me the forecast for this city." The server answers in a structured format (usually JSON). The app then displays that data on the screen. The key word is contract: both sides agree on the format, and if either side breaks the agreement, something will go wrong for the user.
Testers check APIs directly — bypassing the user interface — for several reasons. It is faster: you skip the browser rendering and send requests straight to the server. API tests are also more stable: a button's label or colour can change without breaking the test, but a broken API response is always a broken response. In addition, bugs often hide behind the interface: the UI may show a friendly error message while the API silently returns wrong data or quietly fails. Postman is one popular tool that lets testers compose requests, send them, and inspect responses without writing a single line of code.
When testing an API, a tester checks at least three things: (1) the status code matches what the contract specifies; (2) the response body contains the expected fields with correct values; (3) error cases are handled correctly — for example, a missing required field should return 400, not 500. When something does not match the contract, it should be written up as a defect — exactly like any other bug found through the interface.
Lesson notes
APIs, direct testing and writing up a defect
An API (Application Programming Interface) is a contract between programs. It defines what requests one program can make to another, what data to send, and what response to expect back. When you use a weather app on your phone, it talks to a server through an API: "Give me the forecast for this city." The server answers in a structured format (usually JSON). The app then displays that data on the screen. The key word is contract: both sides agree on the format, and if either side breaks the agreement, something will go wrong for the user.
Testers check APIs directly — bypassing the user interface — for several reasons. It is faster: you skip the browser rendering and send requests straight to the server. API tests are also more stable: a button's label or colour can change without breaking the test, but a broken API response is always a broken response. In addition, bugs often hide behind the interface: the UI may show a friendly error message while the API silently returns wrong data or quietly fails. Postman is one popular tool that lets testers compose requests, send them, and inspect responses without writing a single line of code.
When testing an API, a tester checks at least three things: (1) the status code matches what the contract specifies; (2) the response body contains the expected fields with correct values; (3) error cases are handled correctly — for example, a missing required field should return 400, not 500. When something does not match the contract, it should be written up as a defect — exactly like any other bug found through the interface.