How Does Test Planning Differ for Manual and Automation Projects?

We all agree that Automation projects are different in nature from Manual testing ones. Although, autonomous automation projects don’t really exist (or should not exist ideally), both manual and automation projects are dealt differently when being planned.

A mis-planned project inevitably gets is executed; this not only affects the current project and casts a shadow on the individual’s capabilities, but can also lead to the loss of confidence in the team for the client/management- affecting further business.  I would rather say that we testers be safe than sorry.

A good Dilbert comic about planning..

Before we go any further, I want to establish what this article is NOT going to be about.

1) This is not an in-depth discussion of automation frameworks. Different projects use different frameworks depending on the nature of their AUTs, architecture, complexities, team’s expertise etc. The information regarding the frameworks can be found at the below links:

Test automation frameworks part 1 and part 2.

2) This is also not about template, format or creation of a test plan document. We are going to address the pre-documentation considerations for an automation project, more in the lines of a feasibility analysis.

3) This also not tools specifically

Every activity in the SDLC takes time, effort, infrastructure- in other words- MONEY.

For a manual testing project the cost consuming factors are:

  1. People
  2. Tools – Test/defect management
  3. Infrastructure – environment
  4. Time
  5. Training

For an automation project, in addition to the above items it needs expenditure for:

  1. Automation tools
  2. Add –in for test management tool integration
  3. Add-in to support AUT (like SAP, Oracle etc)
  4. Framework set up
  5. Tool-specific training

Given these circumstances, does the success of an automation project depend on how well you have written the code, how many reusable components you wrote or in how few lines of code you achieved the desired result?

No.

There is one and the only question that determines the success – “Are you able to generate a better ROI (Return on Investment) in comparison to the manual route”? – If not immediately, eventually.

If the answer to this question is “NO” then you have planned the automation project incorrectly.

Normally, a test plan has the following sections. We are going to discuss each one of them focusing on automation specific aspects to consider:

Automation Testing Test Plan Sections

Section #1: Scope

Section #2: Test strategy

Section #3: Resources/roles and responsibilities



Section #4: Tools

Pick automation tools based on the following rules:

Section #5: Schedules

Section #6: Environment

Section #7: Deliverables

Section #8: Risks

If you are going to propose an automation solution, be sure to choose cost-effective tools and solutions to make sure that the automation endeavour does not burden the project. It is important to set the expectation that ROI for an automation project cannot be positive immediately but can be clearly seen over long periods of time.

Therefore, if you propose automating a system, pick the one that is

Section #9: Test data

Section #10: Reports/results

We, as automation enthusiasts might think that clients/management don’t easily buy the automation proposals.

However, when our ultimate goal is to maximize ROI through automation, we are in perfect harmony with the management/client’s goals too. This will ensure that we not only get to automate our project but will be able to do so, with lots of consent, co-operation and excitement.

Planning and thorough analysis on all the factors listed above can be our ally through this journey. Again, ROI means everything.

This post is written by STH authors team member Swati Seela.

Have queries or things to discuss? Feel free to post in below comments.