After finishing writing manual test cases (lets say in 3 days) we submit to PO(Product Owner) for review.

Now my question is, when to start manual testing and how (Might be based on our manual test cases). As well as same for automation.

Also how to decide, which test case need to be automate and which test case need to be manually tested?

3 Answers 3


There are a few questions to unpack in there.

First, when to start testing in a 2-week sprint: as soon as possible. Many experienced Scrum teams focus on getting one or two backlog items to a testable state before moving on to others so that testers can get working on those. This creates a better flow of work through testing so that it doesn't all pile up at the end.

Or, Testing first: There are even techniques like Test-Driven Development and Behavior-Driven development where you write failing tests before writing any code. This requires developers, testers, PO, and stakeholders to work very closely together and integrates the two activities continuously. In both of these cases, you take it one test case at a time, develop to that test case, then move to the next one. TDD is focused at the code level and is driven with unit tests and the average cycle of testing and development is usually measured in minutes. BDD is higher-level and probably more like the testing you are thinking of, but even with these the full cycle to define and resolve each test case is rarely greater than a few hours.

As for automated vs manual, my best experiences have been to treat the approach to them the same. I can define a test scenario and then if it's something I'll want to test repeatedly, automate it in the development process. Otherwise, leave it manual. For most teams, this opens up more options for test automation. When a QA engineer has to automate a test after the fact, they are often stuck doing automated black-box testing. When you automate during development, the developer can help create hooks into different levels of the code, testing behavior very close to its source instead of having to test it from three levels away, leading to more effective and less fragile tests.

Finally, I'm curious about the PO approval. High level test-cases are often closely related to acceptance criteria. In fact, there is a practice called Spec by Example where the two are the same thing. I would expect any of these types of test cases to be defined and agreed upon before the backlog item was brought into a sprint. That's not to say some things won't come up in exploratory testing, but I'm used to seeing those result in quick hallway conversations with the PO, not a formal process. On the other hand, tests tied to the implementation itself are often the purview of the team, not the product owner.


Use 3 amigos in your team.

So, basically at the start of a sprint, a Product Owner, a Developer, and a Tester sit down to talk about a user story that the system under development should do. The Product Owner describes the user story. The Developer and Tester ask questions (and make suggestions) until they think they can answer the basic question, “How will I know that this story has been accomplished?”

No matter how or when it’s done, these three amigos must agree on this basic criteria or things will go wrong. Turning this agreement into an automated acceptance test (or three) gives it a precision that often tests the agreement and uncovers fuzziness or conflicting definitions in the words we use.

If your testing is purely manually executed then you’ll have the problem where the testers have to wait until the developers think they’re done before they can start verifying the functionality. This puts the testers behind from the very beginning. It also delays the feedback to the developers when the functionality doesn’t behave as expected and results in bug-fix cycles on code thought to be complete. These things combine to slow down the pace of development.

It’s more valuable to automate those tests while the code is still written. As development proceeds, you can see those tests start to pass, providing a clear indication of the progress. If a developer writes code expected to make a particular test scenario work, but the test fails, then you can delve into the issue right away. Is there a mistake in the code, in the test, or just a lingering disagreement about what we intended to do?

Automated acceptance tests express the growth of functionality in our application. This way you also blur the line between a manual and automated test.

Apart from this, you may always perform additional exploratory manual testing around the edges as required.



You're late. You should have started test automation before you submit the tests for review. Actually you should not submit testing for review since your tests should be build over the acceptance criteria which are to be provided by product owner before you start implementation of the feature.

I believe the most effective way to automate the tests in two-weeks iterations is to start using BDD approach like you are to introduce BDD "wrapper" for each particular acceptance criteria and do not consider the feature done unless you have that wrapper in place. So the core statement is that you do the automation only on the level the acceptance criteria are described. All other testing you're doing manually unless you gain a good library of business action implemented in BDD.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.