If you have been asked to test a product end-to-end, how would you go about it? By ‘end-to-end’, I don’t mean testing the product/solution for its complete flow. I mean taking part in validation and verification in all stages of the product development as a tester, from requirements to production environment.
I have been thinking about this aspect for a while now. A testing lead or an architect usually gets involved in all phases of the product development, while the test engineers test one aspect or the other of the product. But when it comes to taking care of a feature or an aspect like performance, should the same person be involved in all the phases or different people should be involved?
Knowledge Of Implementation
When as a tester you are familiar with the detailed design and the code, because you had participated in test-driven development sessions or white-box testing, you become knowledgeable about the implementation. When you are familiar with the implementation, chances are that your testing might get influenced by that knowledge. For a person who is a tester and a developer, this influence usually does not exist as they would wear different hats during testing and development, but for someone who cannot consciously put themselves in an assumed role, this will be a challenge, and they tend to be influenced by the knowledge of the implementation.
Information Hand Over
On the other hand, if the same testing person(s) are not involved during the coding and post-code, the person involved during coding should transfer the information to the tester who is testing post-code the requirements, architecture, and design details, so that the post-code tester knows what to look for. But transfer of information always comes with its own challenges of miscommunication, full details not being conveyed, etc. This risk is significant, and maybe creates equally damaging situations similar to a tester who tests with the implementation knowledge of the product.
What should we do?
To me, it sounds like it makes sense to have two sets of people, one with the implementation knowledge, and the other without. The test team without the implementation knowledge can get the details of the product in a black-box fashion from requirements, architecture, overall design details (but not the detailed design or the code), and also from the being-developed customer-facing product documentation. There would definitely be challenges in transfer of knowledge in test cases and test design between the two teams, but those can be streamlined and processes can be put in place so that unnecessary information need not be transferred, and relevant information is indeed shared.
For strategies on testing team composition in validation and verification for your organisation, contact me.