I recently came across a situation that reminded me of one important lesson in development:
Don’t wait for SIT or UAT to discover what your API can handle.
Imagine an API that works perfectly during development and SIT with normal test data. Everything looks fine.
Then, suddenly, during testing, someone sends a much larger response — maybe millions of records or a payload that crosses the expected limit — and the API can't handle it.
Now it's a last-minute problem.
That’s exactly why I believe API behaviour should be documented before it reaches SIT.
Things like:
- Expected response size and capacity
- Maximum supported load
- Timeout limits
- Failure scenarios
- Large-data behaviour
- Server/resource limitations
- Expected error responses
These shouldn't be questions we discover during UAT.
There’s another lesson I’ve learned from the same experience:
Once a feature reaches UAT, don't casually introduce new requirements.
Whether it's frontend or backend, a new requirement at that stage can affect existing functionality, testing, integrations, and timelines.
If something genuinely new comes in, it should go through proper change management and impact analysis rather than quietly becoming part of the current release.
The more I work on projects, the more I realise:
Good development isn't just about making the happy path work.
It's about asking “What can go wrong?” before the environment tells us.
Tags
#SoftwareDevelopment #API #BackendDevelopment #SoftwareTesting #SIT #UAT #QualityEngineering #DeveloperExperience #Agile
Top comments (0)