Before getting an answer to this, let’s look into widespread practise. When do we start testing?
Usually testers, tend to start testing once a piece of software is ready for testing. Which means it has been developed and passed to testers by the developer after his own verification. Peeping inside developer’s work, developers do test what they build, though level of testing might differ per developer. The maxim that a good tester can be a better developer reflects that testing starts before the piece is actually ready for testing.
“Testing is more than testing(and should start before testing).”
– Dorothy Graham
One of the reason for testing is finding bugs. Finding bugs always satisfies tester, but same time we have to understand as early the bug is found, it satisfies everyone in team. Finding early bugs will reduce development efforts fixing them and in turn will reduce cost in resolving them. Finding bug in production/live might require a roll-back of release, finding critical bug just before release will block the release and people may hate you for this. But if the same bug is found in test execution you are hero. One step further, if same bug is observed during development it’s blessing for everyone in team.
Finding early bugs also helps in adding more quality to product. Lately observed low impact bugs are prone to be won’t fix and live for lifetime of product, due to big cost attached in fixing them.
“Fixing bugs is only important when the value of having the bug fixed exceeds the cost of fixing it.”
– Joel Spolsky
So, a clear win answer, for when to start testing, is as early as possible, to be specific start testing even before development begins. Testing activity has to be spread out to cover each phase of product development.
To specify at an abstract level, tester’s involvement must be in analysing requirements/acceptance criteria, testing unit level methods as they are developed, feature testing once it’s developed, regression testing for product impacts and continuously monitor production/live application.
I am sure every tester will be more excited to get entry into each phase of product build cycle. This will help product a lot by reducing the cost of development and will improve the process of building product. It will truly benefit testers by increasing the transparency in product development which will give them a better understanding of how to test, where to test and what to test. It will eventually reduce the late comer bugs as well.
Though this sounds simple, adapting this and enabling testers to get involved in each phase will require tester’s to be more pro-active and skilled to understand product, code and technologies involved. Testers will have to work more closely with team. They should be made integral part of each phase. Tester’s have to wear the different caps in each phase but without loosing their own testing mindset. This is where the different agile methodologies will help to setup the best suitable build process for your team. At the end, it’s team work which leads you to a better product.