Hello World,
Marcus Thomas reporting to you from the aimFast Portal, where automation is in motion and Fast is how we achieve it.
I’m going to share with you some strategies of how you can develop a test automation framework AND a regression test suite from scratch within a 2 week sprint. That’s right, for most, that sounds like a very bold statement to make.
Let me start with the Why. Outside the obvious reasons of cost and money, this will force your team to think about the approach and more importantly, the maintenance. Your automation team has to be as nimble as the scrum team they support. We can no longer just shift left, we need to be able to adapt to ANY change at the pace of a sprint.
Over the course of 20 years of designing and implementing test automation frameworks for just about every technology out there, I have tried many different approaches with many different automation tools and the one I’m about to share has proven to be the most effective no matter the automation tool you are using. And that’s key, your design should not be based on one particular tool.
There are three key processes in the FAST approach.
Functional Area Analysis
We’re all familiar with the various different frameworks; POM, BDD, Robot, to name a few. Each one of these frameworks allows your team to develop abstract keywords that hide the code implementation details of the function that you want to perform on the application. We nailed this process down but what is usually missing is applying the same tactic to the functional areas of the application.
The automation team should be able to analyze the entire application by the functional areas. The objective of functional area analysis is to analyze the application screen-by-screen by how you would write your manual test cases. The functional areas should be broken down into reusable modular steps. This approach allows the team to create a codeless abstract functional step that can be automated without knowing the requirements or the tests to automate. This significantly reduces the time it takes to automate test cases because the team can easily string together the modular functional steps into test cases once the requirements or test cases are known.
The other advantage is that your team can, what I term, “swarmmate” the functional areas. This means the entire team can swarm and automate all the functional areas of the application at the same time without risk of duplicating work.
Next, I will explain exactly how to design a test automation framework that will allow your team to “swarmmate”.
Automate the manual process
The abstraction technique is automation 101. However, the level of abstraction determines the amount of work the frameworker, the builder, and the maintainer will need to do. Whether you have a team that all have programming skills or a mixed team of non programming and programming skills, you have to consider these 3 roles when designing your test automation framework which I will explain later.
The next thing to consider is attempting to restrict or predict the types of test cases that will need to be automated. This leads to an abundance of unplanned or unnecessary work (the ultimate killer of agile projects). Your framework should automate the manual process of testing the application versus the functional behavior of the application. This means your team can automate the test case exactly how the manual test would be executed. In order to accomplish this, you need to develop object classes to handle each type of web element in your application. Basically, your design cares little about requirements, acceptance criteria, test cases, or even the application itself. What you care about is the ability to handle a text box, drop down, link,
button, etc. The good old classic keyword driven framework at the object level.
Automate like a manual tester
Now that you understand how to design a truly agile framework that is flexible and scalable, let’s talk about how to implement the 3 roles so that you can automate an entire application within a 2 week sprint.
Day 1
The automation team collaborates to complete the functional area analysis and produces a list of functional steps that will be automated. The team reviews the objects, data, and the actions that will be needed to automate each functional step.
Day 2 – Day 5
The frameworker develops the custom action classes to perform on the objects and assign each action a keyword and also creates a custom data generator class to handle the data to perform on an object. The amount of code is minimized to the number of actions you need to perform.
Therefore, there will be far less code to write and maintain while providing the maximum flexibility for the tester to automate any test case.
Day 3 – Day 7
The builder creates the modular abstract functional steps using the action keywords. The functional steps are created to be reusable across different test cases with very little or no change. The builder can start as soon as the frameworker has started to map out the keyword actions. Since the process doesn’t involve writing code, this role can be done by a manual or automated tester allowing more members to swarm on creating the functional steps. The same is true with the maintainer role.
Day 2 – Day 10
The maintainer builds the test scripts using the modular functional steps. The maintainer will be able to quickly automate any test case for any acceptance criteria since the functional steps were designed to be abstract. The maintainer can start automating the test cases as soon as the team completes the functional step analysis.
Learn more about our free OpenFast framework solution at www.quartconsulting.com/efast.
Create a free project today and automate like a manual tester without developing a framework from scratch, follow the step by step directions provided in our Get Started Guide.