Telerik blogs
New Addition to the Progress Telerik Mascot Family

This guide explains the importance of creating a test plan and the sections to include. This guide also provides information on modular test design and codeless testing as well as tips on selecting a test tool, and test cases best suited for automation.

Once the codeless testing project is approved, then it’s time to get started with planning. Develop a codeless testing strategy or plan document before you start coding tests. Excitement is high, but the reality is one must plan the approach first to ensure both short- and long-term business success. Plan first to avoid mistakes and problems that are avoidable with planning.

The test strategy or plan document doesn’t have to be formal—you can use a checklist or an outline. As long as it contains the plan details in a readable format, and communicates test selection, organization, tool and work structures, it fits the bill. In fact, use the data and research from the project proposal and rework it into the test strategy or test plan. Add the decisions that have been made on test selection, organization and development principles. Include attachments to samples of test cases and any samples or instructions for test decisions around design, organization, execution and results reporting.

Planning is essential. Granted, some decisions may change as the project matures. However, the importance of having a plan, documenting decisions and designs, is important. Keep in mind the plan is a living, but crucial document for project success at every step.

Make the most of your green light and create a test strategy plan for your codeless automation project. What data or information needs to be part of the plan? How should the plan be formulated and who needs to be involved in the decision-making?

Key Takeaways

  • What information do you include in a codeless testing test plan or strategy document?
  • Learn the decision points to cover in the test plan.
  • Modular test design for codeless testing adds to automated test script reusability.
  • Improve test automation creation, maintenance and reusability across the business.
  • Discover the importance of test data and providing a separate automation environment.

Codeless Automation Test Plan Basics

Start by using a test plan template or create your own. For the codeless automation project, create the test plan with the following sections:

  • Test Design
  • Test Selection (or application functions designated for codeless automation)
  • Test Priority
  • Test Organization (or how tests are stored)
  • Test Environment Details
  • Test Data & Test Data Management
  • Tool Selection & Training

Using the above sections helps to define the project and provide guidance to team members.

Now, who to include in the writing and review of the test plan? You’ll need at least one representative from development, a QA tester or team lead or manager with previous test automation experience, and a product owner or manager. You’ll also need an IT person, or whoever sets up and manages your testing environments for assistance in deciding on the setup of the codeless test environment.

Codeless Test Automation Plan Basics has related bubbles test design, test selection, test data & environment, tool selection & training

Test Design

Two options here: do you start with test design or select tests first? Start with design because it impacts what tests are selected for test automation. Codeless test automation works best with a modular test design.

If your existing test suite is not based on a modular design, then don’t recreate the wheel. In the case where the testing team is not currently using modular test design, then start from scratch by creating new tests. Create a new test suite in a modular design pattern. Next, determine how to break up the application functionality into chunks. For example, let’s use a simplistic example of ordering an item from an online store. First, the users must log in. The login steps or authentication process represent a chunk. Next is the order process or selecting items to order, and the third chunk involves paying for the order selected.

Take the chunks you have gathered and create a codeless test for each. Ensure they run successfully within the modular chunk. Now, decide how to connect tests. Tests are connected so they run as a group or as a batch to represent the full workflow steps.

Finally, determine the size. Keep each test limited to one or two verification points. Decide how many connections between modular test scripts are reasonable. Test design decisions are critical so that team members create tests with the same basic structure that are easily connectable. Connections must follow the same pattern so tests run smoothly from one module to another.

Test Selection & Test Priority

First, decide which functions or tests are candidates for codeless automation. Selecting tests initially may be time-consuming. Laying out and reviewing the current test cases and suites takes time. Narrow down tests by focusing on those that test the main customer workflows. These tests may be critical or high-priority tests for all the main application functions. Read more: Tests to Automate.

Keep in mind that it’s not feasible to simply automate every test. Many manual tests include multiple verification points and handle complex scenarios. Many may even be end-to-end system regression tests. These types of tests are not the best candidates to start with. You can replace these later with automated modules. Select the tests that fit your modular design and start small. Codeless automated tests are critical tests that verify the application functionality in a straightforward path.

For example, automating your main customer workflow functions first provides not only test automation, but also a smoke testing suite that may be executed before the start of any regression testing period, or at the end of each sprint.

Test Suite Organization

A modular test organization is the most efficient way to develop an agile codeless test automation suite. Creating small, modular-style tests automate the main functions of an application in small chunks that can be reused without having to re-create the entire test.

Design your test suites around application functions such as authentication, order, payment, or creating a new account and saving. Likely you’ll end up with 10 or more functional areas depending on the complexity of the application and its integrated parts. Underneath each main suite are the “chunks” of modular tests that belong to it. These we’ll term “mother” tests.

Create separate test suites for end-to-end, system and integration tests. These tests come later after all the functions are automated. Each automated test is then combined and connected in a workflow pattern to provide full test suite coverage.

Once the test cases are built to cover a workflow, they’re combined and edited to create the workflow. The edited test case becomes part of the specific workflow while the “mother” test remains untouched and available for reuse.

Test Data & Test Environment

When creating codeless test automation, one must have access to a separate, distinct test environment. Automated tests are executed frequently and create massive amounts of data. In fact, you’ll need a process to manage or update the data on a daily basis to accommodate automated test executions. With each automated test suite execution, the test data must be refreshed or cleared so testing can start over. Another reason for a separate automation environment is to keep executions from messing with test data for manual testing.

You’ll need to set up and maintain the automation environment to keep up with the latest testable code on a clean data environment. Clean data and a separate environment prevent false failures from data collisions or interference from manual test data.

Tool Selection & Training

A codeless automation test plan requires defining the tool you’re using. Additionally, plan time and resource restrictions during training. Training is critical whether it’s an internal team effort, online or in-person. Plan in training time and the need for testing resources to concentrate on training rather than working during training. Consider dividing the resources into teams to complete training, while others continue performing their work. In this way, as employees complete the training, they can start automated test development and serve as a resource to other team members.

Remember to ensure the tool selected works within your development architecture. Additionally, using a tool compatible with all the coding languages used in development is far less likely to encounter integration challenges when automated scripts are executed.

Consider using a tool that takes care of test creation, organization and execution. Getting a tool with features that include test management and test development options makes test automation more manageable. Tools like Telerik Test Studio.

Plan to Project Success

First comes the test planning to define the tests, test development, test management, tools and training. Planning provides a solid, well-designed process and helps to work through issues before they derail the project. Design and development decisions assist in selecting the correct tool to meet the team’s codeless test automation needs. Planning for a complex project like codeless test automation is essential for success and a positive return on investment.

Codeless test automation tools like Test Studio allow anyone to automate regardless of coding skills. At the same time, the tool provides options for automating complex test scenarios by developing code. Ideally, leveraging both across a QA testing or software development team makes financial sense. The more useful the tool is for enabling and enhancing codeless test automation development, the better the return on investment.

The value of codeless test automation is anyone can do it. With the help of a codeless automation tool like Test Studio, tests are editable, expandable with code and managed effectively.

About the Author

Amy Reichert

A QA test professional with 23+ years of QA testing experience within a variety of software development teams, Amy Reichert has extensive experience in QA process development & planning, team leadership/management, and QA project management.  She has worked on multiple types of software development methodologies including waterfall, agile, scrum, kanban and customized combinations. Amy enjoys continuing to improve her software testing craft by researching and writing on a variety of related topics. In her spare time, she enjoys gardening, cat management and the outdoors.


Related Posts


Comments are disabled in preview mode.