We follow the shift-left approach, but I still find it challenging to manage what was analyzed earlier until it’s time to start the exploratory/manual testing.
Here’s what’s happening:
The PM team creates tasks with requirement documentation and assigns them to both development and QA.
The development team starts their analysis and implementation together. If they have any queries, they ask their TL/PM to get them resolved and continue the task.
However, in QA, we cannot start with manual testing until the development team’s work is done.
Since PM creates many tasks, here’s the current QA workflow:
QA members take one task to analyze and clarify any queries.
Then they move to the next task as the previously analyzed task is not yet developed.
Once the previous tasks come to QA, the members might have to put more effort into remembering what they understood during the analysis phase. Alternatively, if the member is on leave or busy with other urgent tasks, other members must take up the testing, leading to additional analysis effort.
What you described is a common and normal situation, it’s okay, and quite often there is no point trying to manage or improve it because the effort isn’t worth the results. The main goal here is to minimize the number of bugs, questions, mistakes, change requests, and scope changes during the development and testing phases. This involves clarifying requirements, resolving inconsistencies, adding missing and necessary information, and asking questions to understand features. By doing this, you can prevent issues in the later stages that are more expensive to fix. It doesn’t mean that you won’t have any bugs or questions, but you will have fewer of them. Well-written artifacts can help you to remember the context or help others understand. If a team member is on leave or busy with urgent tasks, it’s okay, we have all been in such situations. Adaptation to these circumstances is crucial, and the analysis phase can be a good help here.
We are utilizing low-code for development and automation to help us move faster and upgrade to production.
Yet manual testing and its flow are crucial to verify the stable feature before automation.
Could you suggest how and what we should focus on for test case writing?
I haven’t used test cases for a while maybe only for some complicated or important features when me and/or team members need detailed step-by-step instructions. I use checklists, they are shorter, simpler, easier to use and maintain, and some checks are described at a quite high level. However, this approach requires a product mind team, when everyone knows and remembers features and the app’s logic, and even if you don’t remember some details you can ask colleagues and it’s totally normal for the process and, highly likely, you should be okay with exploratory testing. Test cases might be needed in some circumstances but the volume, type, and details of the project and test docs highly vary in different companies and teams, they depend on the products and working processes so there is no one-size-fits-it-all advice
It sounds like the test team is doing ticket analysis by themselves rather than as a group?
My preferred approach is as a group because you get more participation and potential for deeper understanding. Plus it encourages everyone to do it and you can invite PMs to join so the questions are real time answered.
I always take notes during ticket analysis/ refinement just in case I forget something interesting. Plus from there I can start generating high level test ideas that I can use later, when / if I pick up the ticket.
This is how I encourage my test teams as well. I find it more effective in the long run due to the shared brainstorming. Plus I can then evaluate how well someone did in their testing afterwards since I have watched / help them understand the tickets prior to testing.
