A strategy to implement automated checks without losing sight of manual testing

The goal of this post is to show a possible way you can plan test case automation with development in order to automate tests (have automatic checks) as soon as possible, without losing sight of manual testing. The functionalities to be automated will have to be already tested manually prior to beginning.

This raises the question of whether it makes sense to automate testing before the application is ready. There are indeed tools that try to “automate” tests before implementation, as a part of Test Driven Development. The issue is that this can be a little hard to conceive. 

Here’s an example of an excerpt of a development plan in which we are working on nine functionalities in three cycles:

The important thing to see in the example is when each task is done for a group of features. For example, we can follow the tasks for F1 , F2 and F3 functionalities. In the first cycle, tests are implemented and designed. In the second, we’re ready to test functionality manually and then automate. In parallel with this, the development team implements the F4, F5 and F6 functions and designs tests for them. In the next cycle, we will have automated tests up and running for F1 , F2 and F3. In turn, we have tests already designed for F4 , F5 and F6, which we will manually execute, and then automate them so that they’re prepared for the following cycles. Note that we are already saving time in test execution, and we are only in cycle 3!

The interesting thing about this plan is that whoever does the automation could do manual testing themselves first and then automate it. This is beneficial because by performing manual tests first, the tester gets to know the functionality and then the automation will be easier and faster. It’s important to decide at this point if the functionality is suitable for automation or if it’s still very “green,” and should be left for a later stage.

The importance of this example is that it shows how to plan implementation and automation of tests. Here I am not considering the design of the implementation, which would have to go one cycle backward regarding implementation. If we follow a V model, this would be a little different, as we would define the tests at the same moment as the requirements and design wouldn’t be considered since its done at the same moment as implementation.

What’s your opinion of this method? Do you have any helpful ideas to share?

Recommended for You

The 4 Most Common Test Automation Challenges (and How to Overcome Them)
How to Avoid False Positives and False Negatives in Test Automation