How To Plan Test Case Automation with Development

The goal of this post is to show a possible way of organizing automation based on the development plan in order to automate tests 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. We still have a long way to go in terms of awareness and devoting resources for testing and automation to prioritize this type of functionality in GXTest. Anyway, this approach is definitely good and worth sharing.

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 to 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?