How Does Test Planning Differ for Manual and Automation Projects?

Automation projects are generally acknowledged to differ substantially from manual testing projects. Despite the fact that fully autonomous Automation projects aren’t ideal, there is a strong need to approach the planning process differently for Manual and Automation projects.

Combining scheduled projects can have negative effects, such as affecting the current initiative, sparking questions about individual skillsets, and causing a loss of team confidence. As a result, it’s often better to be safe than sorry and prioritize the safety of testers.

=> Click Here For The Full Test Plan Tutorial Series

Check out a Dilbert comic strip that comedically highlights the difficulties in planning:

Prior to moving forward, it’s vital to state what this article does NOT address.

#1) This piece does not enter into an in-depth discussion regarding Automation frameworks. Different projects utilize different frameworks driven by their application under test (AUT), architecture, complexity, and the team’s knowledge. More details about frameworks can be found in the links below:

Test automation frameworks part 1 and part 2.

#2) This piece isn’t about templates, formats, or creating a Test Plan document. Instead, it centers around considerations prior to documenting an automation project, especially feasibility analysis.

#3) This article doesn’t solely address tools. Every event within the software development life cycle (SDLC) demands time, effort, and infrastructure, which implies financial expenditures.

For a Manual Testing project, the cost-intensive elements include:

• Workforce
• Tools – Testing/Defect management
• Infrastructure – environment
• Time
• Instruction

For an Automation project, besides the factors mentioned above, there are added costs for:

• Automation tools
• Add-in to connect Test Management tool
• Additional module to support AUT (such as SAP, Oracle, etc.)
• Framework establishment
• Tool-specific teaching

In light of these situations, is the accomplishment of an automation project dependent on the quality of the code, the reusability of components, or the concise nature of the code to attain the desired outcome?

Not exactly.

The achievement of an Automation project centers around this important question: “Does it deliver a superior Return on Investment (ROI) compared to the Manual method?” If not straight away, then sooner or later.

If the answer to this query is “NO,” then the Automation project’s planning has been faulty.

The following sections are usually included in a standard Test Plan. We’ll address each segment, concentrating on considerations specific to automation:

Sections of an Automation Testing Test Plan

Section #1: Scope

• Designate the test cases/scenarios that necessitate repeated regression testing over multiple cycles.
• In certain situations, even the most basic test cases demand complex automation solutions. If these solutions are utilized only once, automating them is not practical. Give priority to reusability.
• Exploratory testing cannot be achieved via Automation Testing.

Section #2: Testing strategy

• In regard to Automation, this part refers to the Framework. Although certain frameworks are difficult to create but highly effective, they need considerable time, effort, and expertise. Strive to find a balance that maximizes outcomes without taxing resources excessively.
• Establish best coding practices, name conventions, test asset storage locations, test result formats, and so on to maintain consistency and achieve higher productivity.

Section #3: Resources/Roles and Duties

• Understand the team’s skills and anticipate the scope of automation beforehand. This action aids in the assembly of a team that can cater to both Automation and Manual testing requirements. Choose team members with the right attitude who don’t see Manual testing as inferior.
• Pick team members who are skilled in AUT, Test Management, Defect Management, and other SDLC activities.
• Define the team’s duties and roles.

Section #4: Tools

Here are some guidelines for selecting Automation tools:

• If the company already holds licenses for a specific tool, investigate the possibility of employing it.
• Look into open-source tools (trusted ones).
• Assess whether team members are familiar with the selected tool or if further training or recruitment is necessary.

Section #5: Timetables

• Set aside time for code walkthroughs and script examinations.
• Frequently maintain scripts. If a piece of code won’t be in use for the next six months or longer, ensure regular upkeep to lessen the risk of failure.

Section #6: Environment

• Ensure compatibility between the desired environment of the AUT and the selected Automation tool. Take this factor into account before obtaining the tool license.
• Examine if the existing Test Management Tools and the proposed Automation tool can be linked for added benefits.

Section #7: Materials

• The supplies of an Automation project are the Test scripts. However, not everyone is proficient in automation or programming languages. Hence, plan for the creation of a “How-to” document that aids current and future team members in understanding the scripts, even if the original author isn’t present.
• Embed comments in the script to improve understanding.

Section #8: Threats

When presenting an Automation solution, prioritize cost-effective tools and solutions to prevent the project from being weighed down by excessive costs.

Establish realistic expectations that an Automation project’s ROI might not be immediate but can be attained over time.

Consequently, select a system for automation that:

• Is stable and requires minimal upkeep
• Offers extensive regression testing capabilities
• Has minimal reliance on human intuition or manual intervention

Section #9: Test Data

• Consider the security elements of data when planning test data.
• Avoid embedding test data into the scripts to lessen maintenance work and to prevent potential errors during changes.
• Give precise values as opposed to relying on assumptions. For instance, rather than stating “enter the first name” for a Manual test step, specify entering a name comprising 5 characters. Testers can key in “Swati,” “Seela,” or any other 5-character name. However, automation tools cannot make such assumptions.

Section #10: Reports/Outcomes

• Technical script execution outcomes might not be readily deciphered by other team members. Therefore, make plans to write detailed outcomes in notepad or excel spreadsheets as supportive actions.
• Include comprehensive documents related to the framework, review results, defect reports, and execution status reports.

As advocates of Automation, we might assume that clients/management are not quick to embrace Automation proposals.

Nonetheless, when our objective is to maximize ROI through Automation, we are in alignment with the goals of the management/client. This harmony ensures that Automation projects can be executed with agreement, collaboration, and enthusiasm.

Planning and thorough analysis of all the elements cited above will prove invaluable on this Automation journey. The eventual key consideration is the ROI.

This article was authored by Swati Seela, who is a part of the STH authors team.

Do you have any queries or subjects to deliberate on? Feel free to post them in the comments below.

=> Click Here For The Full Test Plan Tutorial Series