Recently, I noticed our testing team discussing formal testing vs informal testing, and it made me think about something I've experienced quite often as a developer.
The difference is actually pretty simple.
Formal testing is structured and planned.
There are defined test cases, expected results, test data, execution steps, and documented outcomes.
Informal testing is more exploratory.
You don't necessarily follow a predefined test case. You try different inputs, unusual scenarios, edge cases, and sometimes simply ask:
“What happens if I do this?”
Both are important.
Formal testing helps us make sure the application behaves according to the requirements.
Informal testing helps us discover the things we didn't think about while writing the requirements.
And this is where I think developers have an important responsibility.
Before handing a feature over to the testing team, developers should do both.
Don't just verify:
“Does my code work?”
Also try:
“How can I break my code?”
Check the happy path.
Try invalid inputs.
Try unexpected combinations.
Try boundary conditions.
Think about what a real user might do — even if it wasn't mentioned in the requirement.
Because the testing team shouldn't be the first people to discover that our feature is broken.
They should be the people who validate and challenge the confidence we've already built as developers.
Tags
#SoftwareTesting #Testing #QualityEngineering #SoftwareDevelopment #DeveloperExperience #QualityAssurance #Agile #CleanCode #ShiftLeftTesting
Top comments (0)