Whenever the question “when to start Testing?” is asked to any individual in the IT industry today, anywhere in the world, working at any profile with knowledge of Software Development would say:
Testing should start from the very beginning of the Requirement finalization stage
No matter if the person is a Developer, a Project Manager, a Product Owner or a Tester himself, the answer would play around the same lines.
The reality
But even when there is such an awareness about when Testing should start and what Importance Early start of Testing has, It remains rare in the industry to find Testing Projects or instances where a testing team is called at the very beginning of a product’s requirement finalization. There are varying reasons that create this scenario, Such as:
- The mind-set – “ let’s start creating something first, Testers can be called in later ”
- The Cost aspect – “ Why pay for a Tester so early when there is no code to test ?”
I don’t find the above thought process wrong but, having said that, the thought process is not correct either.
The best time to start Testing is neither when your build arrives nor when the requirement is not finalized yet.
I understand you would not have any doubts on the first statement, but as for the second statement, my reasons would be:
- The requirement finalization is more of a business decision – a tester cannot say don’t include this feature if the business wants that feature (after all they are PAYING for that feature) but he can still help improve the features once it is a part of the finalized features list.
- The product might go through many changes and it is never static. Constant changes in the requirements are identified and implemented in the initial stage of the product. So if a tester starts testing it, he might need to redo the same thing again and again.
In this case our question still holds ground with no answer but this one –
The Best time to start Testing is right after the requirement is finalized and the architecture is decided.
This should be the point where Testers should be called in and told:
“This is our finalized set of requirement (but we know secretly that it is not) and this is the architecture we are planning to implement, Can you please go through both and let us know, if both are fine individually and to each other and if not what needs to be changed and where.”
When this is done, the following are some of the many advantages:
- Since the People involved in requirement finalization know that they have to deliver an exact set of requirement at an exact date. Which passes on to individuals who would otherwise spend more effort on the same at their COST. The requirement not only arrives on time but is also more filtered and more exact.
- The testers get to know better what questions must be asked both at functionality level and at Technical levels, thus helping them to understand better.
- This helps testers create Priority based scenarios
- Testers get to know pain points in the system which could later create issues.
- Since the development has not yet begun, they can help alter the architecture or functionality without any piece of code and effort being wasted. If it was done after deployment it would have cost time, money and the effort of multiple Individuals.
- The Project remains on track as per the decided timelines.
But ….. it’s never too late to start testing your product, a good Testing partner understands your needs and delivers anytime.
Written By
Amit Vyas | Software Tester
0