Consider.
When a developer is assigned to rectify a bug, they cannot reproduce it. Is the reason environmental? Are both using the same data?
Either way, the developer comes back and asks for more information.
You can reproduce it, so you get on a Teams or Zoom call and show it to him. Now you’re both burning time. Perhaps this allows the developer to reproduce the issue, or perhaps not. Perhaps the bug only occurs on certain hardware. Perhaps the bug only exists on the three customers you happened to use.
From the tester’s perspective, they have found a bug and documented it as well as they could. The developer knows he can fix the bug if he can reproduce it, so there is frustration on both sides. While this is all going on, there is one certain truth – the testing of the Order Entry function is on hold.
The tester naturally moves on to their next assigned task, where the same thing will almost certainly occur. Their life becomes a jumble of partially completed tasks at various stages of progress.
So, it doesn’t matter who does it; manual testing is amazingly inefficient. And once we get into the world of UAT, complexity increases exponentially.
UAT is typically performed by business users because they have knowledge of the business requirements. However, testing is not their day job. Testing may not be their favorite activity. In fact, it rarely is. If it was, they’d be testers.
What’s new? – business users don’t like testing, feel they’d be much more productive doing their day jobs and have never been trained on how to test, but that should be OK; they only have to run through a few business scenarios and ensure that life is good.
But let’s pause for a moment. Even that previous statement is more complicated than it might at first appear. Whoever is running the UAT program, and that is probably someone in the IS team, needs to know about the good tests as well as the bad. Without that information how can they justify that the application has been sufficiently tested to go live?
And what if a business user finds a bug?
Will they be as diligent as the QA professional? Will they repeat the test multiple times, so they can document it properly? Will they create a structured email and send to the coordinator? I think not. And what happens when the developer can’t reproduce the issue? Will the business user welcome the conversation about the environment, hardware specifications, and the exact steps they took to create the issue?
Probably not – but there can be a better way. Without reinventing the wheel there are substantial gains to be had with some easily implemented solutions.
Is there a better way? We think so.
