Inverting an existing framework often leads to a different perspective, and in many cases a better solution to an existing problem.
The challenge is this: how can we do something different to improve quality and increase throughput of activities such as verification. How about inverting the existing framework of software testing? In all cases, the results were exemplary. Visit HCL's Software Testing and Verification unit to know more about the services.
The inversion of the framework – as with everything – starts with a simple question …
Q: Who has the primary responsibility of building in quality in any deliverable?
A: The developer. Not the reviewer.
If that is the case, one wonders why almost all software companies have freshers / less experienced software engineers as developers and more experienced software engineers as reviewers. Shouldn’t it be the other way round?
Reviewer is seen as some sort of gate-keeper, and therefore, they will be able to catch errors committed by less-experienced engineers. But from experience I can tell you that for every error caught, there lurks another error that goes undetected. Also, the reviewers seem to have a mental threshold – the moment the number of errors detected by reviewer crosses that threshold, the effort to detect more errors reduce.
Given this state of affairs, the following is recommended …
Have more experienced engineers do the test script and procedures development
Have the less experienced engineers do the test reviews
More-experienced engineers will generate higher-quality software test artifacts
Less-experienced engineers will be exposed to good quality test artifacts and with experience will generate better test artifacts themselves.
Psychologically, since a more-experienced engineer would dread being caught out by a less-experienced engineer during the test review, they would do a better job. The less-experienced engineer does a better job due to exactly the same reason.
The throughput would increase since a more-experienced engineer is likely to generate artifacts at a faster clip than a less-experienced engineer.
It is also a better utilization of a better paid engineer.
Unfortunately, there is a social angle which needs to be addressed. Becoming a reviewer is considered by young engineers as a ‘promotion’. The engineers will need to be educated otherwise: the job is testing; the role can be that of a developer or a reviewer, and the role is interchangeable. The need is to address the mindset and explain the logic to the team. It is, without doubt, essential that the entire team be behind the idea.
Crazy idea? You bet!
Does this inverter framework work?
Yes it does.
Note from the author: I have personally tried out the concept, both as a reviewer-turned-developer and also as a Project Manager, where the team had to be persuaded to reverse roles. In all cases, the results were exemplary.