Your team is divided on testing methods. How do you navigate the manual vs. automation debate?

Both manual and automation testing are essential in software development. Manual testing is vital for exploratory and usability scenarios where human insight is key, while automation excels in repetitive and regression tasks, ensuring efficiency. The challenge lies in knowing when to apply each approach. Automation boosts speed and accuracy, but not all tests can be automated. A balanced strategy that leverages both methods leads to higher quality and reliability.

It's more about identifying use cases that are repetitive and have minimal or no dependency on complex or frequently changing test data. Only those scenarios should be considered for automation, as the main objective is to reduce repetitive tasks as much as possible. This allows more time to be dedicated to manually testing complex user scenarios.

Aligning testing methods with project requirements is crucial for effective quality assurance. Understanding user interactions and critical functionalities helps determine the right balance between manual and automated testing.

Test strategy will help to clarify the needs of automation testing versus manual testing. There might be debates around testing methods and your goal as a leader is to help and navigate. Debates should be around "How we can achieve best quality of a product as a team" rather than "Automation vs Manual Battle". Discussions and clarification about how each method could help to achieve the best user experience, high quality of the product within SDLC is crucial. And in addition, test strategy is alive and may be changed in a life cycle to help everyone be on the same page.

Team skills, tool availability, and project timelines influence the feasibility of automation. Sometimes, focusing on manual testing with a gradual shift towards automation is more practical.

Resources evaluation is a part of your strategy. For manual testing you should define one set of skills, tools and frameworks. And for automation testing there would be different set of skill sets, tools, frameworks. If you have experienced team they can help you to define and choose convenient resources based on product tech architecture, tech stack. Moreover, while a product is growing and improving, your evaluated resources might be and would be changed. Maybe due to migration needs maybe due to expansion to other regions worldwide or even due to your test strategy and implementation of a new types of testing.

Each test cycle is unique and should be strategised with a balanced approach. As the feature to be tested is being developed,part of team can be mobilised to develop test scripts as per the user stories with judicious decision whether same are automatable.Leverage pipeline for automated execution

Combining manual and automated testing creates a robust testing strategy. Automating repetitive tasks frees up time for exploratory testing and complex scenarios that require human expertise.

Scrum is about Agile. And Agile is not about Scrum. Be agile is not only about SDLC. It is also about your balance, your ability to shift and switch from one tool to another, from one testing methodology to another in a short period of time without "putting spokes in wheel". Risk based testing is a good approach and would be valuable addition to the balancing between manual and automation testing. With pre-defined test case suites that linked to manual testing and for automation testing based on risky and mandatory functionality that have to work after each and every release you would be able to find that exact balance.

Communication is a key to success. I always say that. Speak to people. Jump on huddles, have a short calls, or offline office catch ups. No matter where it is, does matter how fast you can get that information you need. Better to have 5 min call rather than struggling with chat/texting few hours in a row to sort out roadblocks. Encourage your team to use this approach to resolve any development blockers, conflicts, etc. Have a retrospective calls to discuss concerns, improvements and any other things that you as a team is doing great, advantages and disadvantages. It will boost not only delivery but also quality of the processes, team collaboration and also transparency and "open door" policy.

Stimulate your team and colleagues for continuous learning. In a new tech era it is mandatory to stay up to date on latest tech trends, tools in SQA and software testing. One good practice I saw at one company where QA team encouraged to have weekly meeting about they learnt. It could be any information. Starting from testing tools for manual or automation testing and up to soft skills like mentoring, leading, etc. With this approach you emphasize that continuous learning is a benefit not only for career growth but also for self improvement and self management. This continuous learning culture in company will force to a new horizons.

Just an example: Create an env when people want to learn. We keep meetings for tasks, keep meeting to show case what you learnt this week. Let others share knowledge in that meeting.

You can’t review testing strategy often it would not be a strategy then, you can apply different tactics inside strategy, however, knowing different tactics, which are part of exploratory testing, requires experience and passion for quality which demands skilful QA professional, which is quite rare as you can’t get skilful an experienced QA professional as they are often moving away from manual testing as soon as opportunity arises.