Six letters that tell an FDE what a client's API really does

On your first day at a client site, what you usually get is a base URL, a token and out-of-date API documentation. Nobody has told you what the system returns when you pass the wrong parameter.

Amber Race’s course Exploring Service APIs through Test Automation, on Test Automation University (Applitools), covers why testing service APIs matters and teaches through worked examples in each lesson. Although it comes at the subject from a testing angle, it teaches exactly the skill you need in those first days: getting to know an unfamiliar API systematically.

Race is a Senior Software Development Engineer in Test at Big Fish Games, with more than 15 years of testing at Big Fish and Microsoft. The course page gives neither a release year nor a running time.

The material is split into four sections: an introduction to API testing, exploring APIs with Postman, the POISED strategy across six chapters (3.1–3.6), and writing tests, covering a first test, data-driven tests, advanced techniques and Newman.

For an FDE, the course’s value does not lie in Postman. It lies in a way of thinking: before you write the first line of an integration, find out how the client’s system reacts to bad input, an expired token or unusual data.

Why treat an API as a contract?

Chapter 1 opens with a plain definition: an API is a piece of code that talks to another piece of code. From there Race reaches her main point: APIs are contracts that let programs communicate with each other. Testing an API therefore means checking whether what the two sides agreed still holds.

This view changes the question you bring to customer discovery. Instead of asking “what does this API do?”, you ask “what does this API promise, and to whom?” If the client cannot answer, that is the first risk to write into the deployment plan.

The chapter’s second idea is sharper still. Race warns that you cannot assume an API will always be called through the user interface as intended.

In enterprise environments this happens every day: an old cron script, an ERP system or the very agent you are about to build will call the API directly, skipping every check the UI quietly performs.

POISED turns exploration into a checklist

In the course, POISED is a heuristic for test coverage with six categories: Parameters, Output, Interop, Security, Errors, Data. An independent post on the Abstracta blog credits Race with developing the heuristic. That post describes POISED as six aspects to consider when assessing a system’s quality and resilience.

Imagine you are integrating with a logistics company through a hypothetical endpoint, GET /shipments?from=&to=&page=. The table below is an illustrative example, not taken from the course. It shows how the six categories become concrete tests.

Category	Test on the hypothetical endpoint	What you want to know
Parameters	Omit from, set page=0, page=-1, a badly formatted date	Whether the API validates input or relies on the UI
Output	Compare every field with the docs, look for fields that can be null	Which fields your code will depend on
Interop	Call it directly, without the UI, as another system would	How it behaves without a UI layer in front
Security	Use an expired token, a token from another tenant	Whether data leaks beyond the permitted scope
Errors	Force 4xx and 5xx errors, read the error messages	Whether errors are clear or expose a stack trace
Data	Use real records with special characters and different time zones	Whether real data matches the samples in the docs

The last column is what is worth taking to a meeting with the client. Every blank cell there is a question someone on the client’s side must answer before you go to production.

Which order wastes the least time?

If you have been a software engineer for a few years and know Postman, skim chapter 1 for the idea of the contract, skip most of chapter 2, and spend your time on the six POISED chapters. Then do chapter 4, especially the data-driven tests, because that is how you cover the variations in a client’s real data without writing every request by hand.

If you have never written an API test, follow the course in order. Chapter 2 gives you enough Postman skill that the later examples do not become an obstacle.

In a 2016 TestGuild podcast, Race offered simple advice for getting to know an unfamiliar API: just play with it. POISED is a way to make that play deliberate.

From exploration to a deployment safety net

The final chapter teaches Newman, a tool that runs Postman collections from the command line and requires Node.js. Race ends the course by putting collections into a CI environment such as Jenkins, so that API checks become part of the build.

For an FDE, this is the most important shift. The tests you write in the first week to understand a client’s system are the same ones that raise the alarm when the client quietly changes the API three months later. Once the client has answered a question from the last column of the table, that answer should become an assertion in the collection that runs in CI.

Professionally, you can turn the course into evidence. Build a small repo: pick a public API, write a collection covering all six POISED categories, and run Newman in GitHub Actions.

On your CV, describe how you explored the behaviour of an unfamiliar API and then monitored it with automated tests. When you read an FDE job ad, look for lines about integrating with client systems: that is where to bring up the repo in an interview.

Integrating without exploring first is a bet on the client’s documentation. Race’s six letters let you know what the API really does before you have to place that bet.