A lot of time during the test process, we get to hear the phrase ” When will testing be complete?!”. The common refrain we can think of is – “Never”. In a way this might be the correct phrase; but that does not alienate us from not being responsible if the product gets a bug. As test people, we do not have the liberty to say – “Look I told, testing was not completed!” 🙂
There are many different aspects of judging when a particular test cycle is complete. One criteria depends on the test plan. The Test Plan, which is created using the design and engineering specifications document, should cover the common scenario’s. Along with the common scenario’s, we should also have what we in test parlance call the border cases and negative cases. The border cases are those which are not so common scenario’s, while the negative ones are if we use the application in a way it was not meant to be used, what is the behaviour.
Another very very imporatant aspect of development and subsequent testing, I was taught early on in my software education, was documentation. Whatever happens, the documentation should be kept on top. May it be a specification discussion or related to any new test that you add during development or testing. Mostly, one should not feel it as an attack on your ego, if someone else informs you on it, and then to mention why it was added and not have pangs of being crucified for missing it in the initial draft. That is the reason a draft is created. But mostly it is not so, and we miss some critical testing in this manner.
Coming to the topic of being “test complete”. The best bet is to write a comprehensive test plan based on the specifications and get it reviewed by all – dev and test teams, as well as the product managers. Once this exercise is done, rest assured that you have covered a good percentage of scenario’s on how the user can use your application. As they say in test – “Think like the user, not the owner of the product/component” 🙂