I often get asked this type of question:
I have joined as a new member in a project, as a QA lead. All the previous team members have left, there is minimal documentation to help. Client has suggested a few changes that might cause regression impacts. How will you analyse the impacts?
Sounds familiar, right? It’s all too common to join a project to find yourself that everyone from the past has left and there is no or minimal documentation to know about the product. There might be a test plan, but most probably it is outdated, or needs key updates from the latest software. There is an upcoming release soon, and you need to start testing. It’s quite common to see this, especially in startups.
Always go with the best practices and principles of knowing the product as deeply as possible as you could. You could start-off with two key areas and then build your expertise incrementally to have a complete knowledge of the product and its testability
- Constant communication with key stakeholders (developers, product owners, and the client)
- Building an evolving test strategy that can eventually lead to test plan(s)
It takes a lot of perseverance, persistence, and hard work to build testing expertise in a scenario like this. It’s not about the tools that you can use. It’s mostly just about one thing:
Domain Knowledge
If you have stayed in a domain for a while and have worked with similar kind of products that have a common theme or related themes, it’s easier for you to find your way through the complex maze of keywords and phrases. For example, if you are in the telecommunications sector for four years, it would be easy for you to understand the lingo and quickly ramp-up your knowledge on the telecommunications product that you are taking over as the test lead. But if you were from telecommunications domain, and start working on banking and financial services, it’s not going to be easy for you at all.
Software Testing is not just about reading some documentation and coming up with test cases. It is not just about GUI screens and what automation tool or framework you can use to test the GUI. Testing is about learning about the product, its business and industry background, how it is placed in the market, and how it is adding value to the end customers against its competitor products. If you approach validation and verification from that angle, the quality of test strategy and test plans that you build will be totally superior and will be appreciated by the management and the business.
Yes, things are challenging because of time pressure and sometimes non-availability of support. But if you hang-in there and build expertise based on your domain knowledge and developing knowledge of the product, you will eventually succeed as a Software Testing lead.
For consulting on building deeper testing expertise, feel free to contact me.