In a previous post we talked about the 8 Benefits of a Test Automation Framework.

Now that you’re convinced that having a test automation framework is a good idea, today we’re going to cover the techniques you can use to build one.

Just a quick reminder. A testing framework is the Automation Engineers common platform.

It’s not a tool to perform a specific task. The framework is an infrastructure where different tools can do what they do best.

A well designed framework makes a tester more productive. This productivity will then improve the quality of the application under test. Well hopefully.

Techniques For Building A Testing Framework.

There are a few techniques that you could use to build your testing framework.

Linear Technique:

When procedural codes used. This the type of approach is used with record and playback tools like Selenium IDE. This can be simple to get going to but not recommended.

Pros: Quick test development. Little programming skill needed to build test.
Cons: Maintaining the test is a nightmare.

Structured Technique:

When focus on using control structures. Common ones are “if-else”, “switch”, “for”, “while” conditions. You’ll see a lot of test harnesses or one off scripts using this approach.

Pros: Framework is easy to read and understand.
Cons: Very rigid and not flexible.

Data-driven Technique:

Data is persisted outside of tests in a database, spreadsheet, or other mechanism.

Pros: You can cover a wide range of scenarios with ease.
Cons: Building a robust data set can take a lot of time.

Keyword-driven Technique:

Using keywords / actions words that trigger the function you would like to run. These words are normally stored in a table of some kind. That’s why this type of framework is also called table-driven testing.

Pros: Maintenance is low in the long run. Reusability. Not tool specific.
Cons: High learning curve. Longer time to market.

Agile automation framework Technique:

Focusing on doing a lot to testing up front. Sometimes even before the application code is written. You end up with something called the “Agile Test Pyramid”. This is when the framework splits like this 50% – 60% Unit Level Automation, 20% – 40% Middle Tier, 0% – 10% UI Automation. This technique has gained a lot of popularity. BDD and TDD use this technique.

Pros: Gets the whole team involved in testing.
Cons: Slow ramp up time.

Hybrid Technique:

When you combine two are more of the above techniques at the same time.

Pros: Being able to choose the best from multiple techniques.
Cons: Can end up with spaghetti framework if not done correctly.

Defining The Goal of Your Testing Framework

It’s good to know where you’re going before trying to get there. Defining a good helps you choose the right toolset, & the best techniques to use for the foundation of your framework. Ask yourself:

How long are we planning on using this framework? Should it be closely tied to the AUT? Who’s going to be using it the most? How much can we invest into building this? Who’s going to build it? Who’s going to have to maintain it? You get the idea.

Answering these questions will help you define the goal of your testing framework.

Here are a few example goals.

• Maximize test coverage. That’s coverage of the applications functionality. We want to be careful to avoid The Code Cover Trap.
• Scale with the business. Some types of testing just don’t scale without automation. The goal here is to create something that will keep up with the expected growth of the application under test. This could also mean scaling with company growth (aka – riding the unicorn).
• Bulletproof testing results. If a failed test case means that your nuclear reactor is over heating, than you don’t want any false positives. With this goal you try to avoid false positives over everything else.
• The ultimate regression. We won’t to know what we break before we break it… well kind of
• Focus on integration with continuous builds. The clean build hero. The focus here is to have scripts that will run with each commit and validate that the system is ok when new code is added. If you’re going to be pushing directly to production then this is something you’ll want.
• Master End-to-End scenarios. Covering all major business scenarios from the top down.

There are many ways to build an automation testing framework. What’s important is that you use the best technique to meet your goals.

What techniques have you used to build out your testing frameworks?