Quickly starting with Test Automation, part 3 – Advanced Automation tips

Here is the final blog in our ‘Quickly starting with Test Automation’ series, part 3 – Advanced Automation tips. We advise you read parts 1 and 2 first if you haven’t done so already, in order to get a grip with the basics and refresh your mind on some vital automation points.

Now that you have arrived at the last hurdle, it’s time to dig deep and take your software engineering skills to new heights by utilising test automation to its fullest potential. We know that keeping systems up to speed against competitors, the constant change in business requirements and new technology means thinking outside the box and elevating you and your team’s abilities.

With real-time information and agile delivery in the palm of your hands, configuring, deploying, and executing tests has never been easier.

So, are you eager and ready to learn more? Then read our advanced automation tips below!

Creating a test automation framework

Nobody goes into test automation blindly. Think of cooking without a recipe book – sure, you could improvise but there’s a high chance the outcome won’t look or work as expected.

In test automation, you will hear the phrase “framework” mentioned a lot but what does it mean?

TechTerms provides a nice summary of what a software development framework is:

“A framework, or software framework, is a platform for developing software applications. It provides a foundation on which software developers can build programs for a specific platform. For example, a framework may include predefined classes and functions that can be used to process input, manage hardware devices, and interact with system software.”

Therefore, what we are building here is an application with the sole purpose of testing other applications. Information on build tools, object repository, generics and more are all included within a framework and this helps to streamline the development process by lowering the cost of maintenance, providing clear, targeted reports and maximising overall test coverage.

However, this is not same as an application with a graphical user interface we would be accustomed to. The application only comes to life when we execute a script and stops when the script/s have finished. We often describe a framework like a spine and the tests themselves use the spine or backbone to simplify the amount of coding we do at script level.

It’s always best to start with some basic test cases and then see what you can abstract from the tests themselves to make the scripting easier.  For example, all of your tests will open and close the application, so there are 2 methods/functions that we can create right away.

When adding to our framework we need to look at what other common/global things we need:

• A configuration file to store URLs, usernames, passwords, and other global parameters
• A way to capture screenshots when something goes wrong
• A log to capture information as we execute our tests
• Loading and manipulating test data
• Working with databases
• Error handling
• Interfacing with our application(s) under test

This core framework code we are creating will essentially become our “helper methods”.

Remember to create pertinent libraries to store methods/functions so there is a logical structure to what we are doing. It’s also important to make sure we adhere to coding standards appropriate to the language we are writing our code in for reusable and maintainable tests that other developers can use in the future.

Code modularisation to remove duplication

Keeping the wheels of development turning is exactly what we want to achieve in all our methods/functions. Good code modularisation is key in the sense it allows us to take large, complex programs and organise them and their functions into easy, manageable, readable divisions.

Nothing is worse than being overwhelmed by hundreds of lines of code, allowing confusion to set in on what method works best for a specific function, resulting in the quality and accuracy of a software’s deliverables being compromised.

When writing your test automation framework, you should think about the different layers you are developing. We refer to this as business and technical layers. The technical layer is all of the items we discussed in the above section to open the application, print the screen, create logs etc. The business layer is where the automated tests interact directly with the application.

All too often we see poorly implemented solutions because the business layer was not implemented well. People forget that this is should still be managed in the same way as the technical layer for maintainability. This results in test frameworks that take an exceptionally long time to create in the first instance and become a maintenance nightmare.

Think about how many scripts contain the same basic code such as logging in. If that is contained in 200 scripts and the business process changes, it means a change in 200 places rather than 1 simple change in a method/function.

Selenium solutions often follow the page object pattern and with tools like Cucumber, we are guided down the right road. But it’s still surprising how many problems still occur due to poor code design and structure.

Creating features and scenarios

As testers, we aren’t excluded from putting ourselves in the end-user’s shoes and figuring out real-world scenarios of an AUT to ensure the software is working for use cases or stories and meets business requirements specifications.

Declarative vs. imperative – While you are learning writing your scenarios, using the imperative style makes sense so you understand how everything links together. But once you have that technical knowledge you need to focus on using the declarative style. Imperative provides HOW you are doing something, where declarative helps shape the WHAT and WHY.

Declarative scenarios allow for greater collaboration with the business and development as people switch off with long drawn out imperative scenarios. They also help to give us a noticeably clear articulation of the business rules we are testing.

Imperative scenarios are too closely coupled with the application in test, so as the application UI changes over time there will be a lot more code refactoring that is needed. These scenarios are often littered with test data inputs which makes them noisy and hard to follow. Keep this to a minimum and only expose data that has a material impact on the scenario itself.

Version your code with source control

The greater reliance on automated testing means that IT teams need to be in control, especially when it comes to supporting all interlinking efforts made by developers creating automated tests and any changes to the suite throughout the process. Source control is essential as a way of housing code to a single location in order for teams to access the most current version.

Without it, you will not be able to integrate automated scripts into the CI/CD pipeline seamlessly and if the master copy becomes corrupted, you cannot effectively roll back to a previous version.

The beauty of version control is that it is super-fast and robust, offering command-line utilities such as the ever-popular Git. As long as you have a broad understanding of this and how it works, then you’ll be helping your teams achieve better quality outcomes in the long-run.

Continuous Integration

Continuous Integration is where everything comes together, and we start using the automated tests we have written with our framework to begin testing the development code. When a developer makes a change to the application codebase and checks it back into source control, our Continuous Integration (CI) server picks up this change and executes a series of predefined jobs. The jobs will build the application and execute the different branches of code we have created i.e. Unit, Integration and UI (Web).

There are numerous solutions out there but we recommend starting with tools like Jenkins or Microsoft DevOps. Jenkins is Open Source so it’s simple enough to download locally onto your PC or laptop to help familiarise yourself with how it works, and providing extremely comprehensive with simple examples of how to create jobs and pipelines.

Although Microsoft DevOps is a commercial solution, you have free access for up to 5 users for education and small development projects, plus everything is online in the cloud. It provides everything you need for a project from dashboards, user stories, code repository, templates and CI pipelines – a brilliant way to get started very quickly and easily. Microsoft Market Place also contains plugins and other tools to help you along the way once you have mastered the basics.

Why choose Spike95

It’s simple. We possess an unparalleled knowledge of automation as technical testing experts, who know exactly how to get you moving in the right direction. We find the solution that’s right for your business, using the necessary tools, and technological integrations needed to resolve issues and bring higher value.

Click here to download a PDF copy of part 3 of our Quickly Starting Test Automation guide with our compliments. We hope you found our advanced automation tips helpful.[vlt_social_share title="Like this post? Please share!"]