TL;DR
I often hear from developers their definition of done: “Feature is implemented and I have done unit testing that covers happy path”. In this post I will try to elaborate what is on the other side of happy path.
So why they only test for happy path? Because in order to test “alternative paths” you need to have software testing knowledge background. Something like BBST series: Foundations, Bug Advocacy and Test Design. Because testing alternative paths is not SO EASY (like happy path).
And often, alternative path testing is synonym for ALL OTHER TESTING. Like scenario testing, domain testing, risk analysis, taking out requirements from other people’s minds (not literally), non functional testing, …
Which is wrong. For example, functional testing is usually a synonym for feature testing. You test one feature independently from other features. And very often testing stops at that point.
But your product is a sum of all features, your users will use several features in combination just to do one task with your product. And here scenario testing comes into play. And this is heavy lifting, to come up with scenarios that user will possibly trigger. Requirements can only capture just few of those scenarios, which are excellent starting point for software tester to come up with more real scenarios. And that is just scenario testing.
So stop the madness with abandoning your QA team. For those “alternative paths” you do not need developers that know how to code. You need software testers.
And QA is not Quality Assurance, it is Quality Assistance.
