Skip to main content

Write Frameworks

Shift left is a phrase often heard in software development. There are many ways you can do this. You can get testers involved at the story writing stage or get testers testing on feature branches before the code goes into master.

But what can you do though to shift left your automation?

Now let's imagine you have someone who writes UI test automation. Let's call them a test automation engineer. Now this person would typically write tests after the developer has finished their work. Now on the face of it this is great, they can write some tests whilst the developer starts on another feature.

However, this creates its own problems. If the test automation engineer has questions or finds issues they have to interrupt the developer and get some answers. This feedback loop could be quite long which could delay the releasing of the feature and more importantly delaying the value to the user of that feature.

What if there was another way…..

Now shifting left is about getting testing performed earlier in the Software Development Life Cycle.

One way to do this from a test automation perspective is that test automation engineers do not write tests but instead write frameworks. These frameworks should enable the users of the framework (the developers) to quickly and easily write tests. Now these frameworks can be at the integration or UI level, but the important thing is that they enable the developer to write tests quickly and easily. They need to abstract away any complexity that makes writing tests difficult and time consuming. This will enable features to be delivered quicker and more importantly give value to the users quicker.

How would this work?

Example 1

Imagine you get a story from the product owner and a UI testing framework has been implemented. As a team you analyse what is required for the feature and decide during story writing/backlog refinement that there is no additional work to be done to the framework in order for implement the UI tests that are required. The developer will be able to write the tests using the framework as it is. That means that as a team you can define the acceptance criteria in say BDD format e.g. specflow and use this as the basis for the UI tests. The test automation engineer doesn’t need to do any work and the developer can quickly and easily write those tests because the framework will support the testing of the new feature.

Example 2

Imagine you get another story from the product owner. As a team you analyse what is required for the feature and decided during story writing/backlog refinement that there is additional work to be done to the framework in order for implement the UI tests that are required. As a team you can define the acceptance criteria in again a BDD format e.g. Specflow and use this as the basis for the UI tests. However, before the developer then starts on the feature the test automation engineer can start updating the framework to support the feature that needs it. Now typically the story writing/ backlog refinement session will typically be prior to the sprint in which the feature will be started, so there is time for the test automation engineer to update the framework prior to the sprint starting.

In both these examples the developer writes the tests. The test automation engineer doesn’t write tests they write a framework that enables the developer to easily write tests . Yes the test automation engineer needs to know what new features in the framework the developer might need but that can be managed through early insight of features and good communication. Another advantage is faster feedback. There is no lag waiting for the test automation engineer to write the tests. The feedback happens when the developer executes the test - which is happening whilst they are developing the feature.

Now imagine if you didn’t have a framework? The developer would need to understand all of the details in order to write the tests. For example, they would need to know what selector to use to find a UI element. Abstracting all the detail away from the developer in a framework enables the developer to focus more on developing the feature and less on the details about the tests that they need to write.

Utopia

In one of our projects we managed to reach what I would call test automation utopia. We had an integration test framework that used Specflow and the framework covered a large percentage of the system. What we were able to do was agree the acceptance criteria with the product owner and write the integration tests in Specflow as the acceptance criteria of the feature. Then when the developer needed to write the tests they could just copy the Specflow from the story into their branch and the tests ran with no coding required at all. This made the testing a copy and paste exercise for the developer.

Now I appreciate this may be rare but it can be done. It took us a while to get there but once we did we could deliver features quickly.

The developer is the customer

Now once you have created a framework what's the future? Well the future is that the developer is the customer and the framework is the product. The test automation engineer then works on maintaining and improve the framework to satisfy the customer needs. The framework becomes an internal product that supports the development of a product and helps improve its quality. By doing this you are shifting left and shifting left in a way that is more likely to be accepted and undertaken. If you didn’t write a framework and just told the developers to test then you may be shifting left but not in a way that benefits your team or the end user. It doesn’t matter who writes the tests, what matters is that they get written and the easier you make it to write tests the better.

Comments

Post a Comment

Popular posts from this blog

Testing and Mindfulness

How aware are you? Do you live in the here and now or is your mind always somewhere else? This blog post is about Mindfulness. Mindfulness is a simple meditation and is defined as (According to Wikipedia): "The intentional, accepting and non-judgemental focus of one's attention on the emotions, thoughts and sensations occurring in the present moment" Now Mindfulness has become more popular in the west in recent years as it has shown to have benefits for people who are suffering from Depression and Anxiety. It has been around for a while and is often thought to of originated from Buddhism and some people believe it started thousands of years ago. Now modern life is hectic and I’m sure we all have lots of things going on in our lives that keep our Brains busy and trying to focus on one thing at a time can be a challenge. I can't remember the number of times I've been doing something and my mind is somewhere else entirely. Mindfuln...
Post a Comment
Read more

How to deal with pauses and timeouts in specflow

So this blogpost is in response to the weekly Specflow blog posts and challenges that have been written by Gojko Adzic. This weeks challenge was how would you rewrite or rephrase the below scenario: Given a user registers successfully When the account page reloads And the user waits 2 seconds Then the account page displays "Account approved" My initial though was something like this: Given a user registers successfully  When the account page reloads   Then the account page is displayed within a satisfactory time period     And the account page displays "Account Approved" Now the problem with this scenario is what defines a satisfactory time? You could add it as a comment or in a scenario outline but over time the time a user waits could change and if this is updated in the code behind but the scenario outline or comments are not, then what the test does and what is described do not match - this would potentially cause issues in the future. My next ide...
Post a Comment
Read more

Building a test strategy for a new team

Teams, we have all been on them. Some are good and some are bad. Some we never wanted to leave and others we probably couldn't wait to leave. Now most of the time (well in my experience anyway) you tend to get put into a team that already exists. Maybe you are a new hire or maybe you have asked to change to a different product team.  When you do this, more than likely there will already be a testing strategy in place. It may be that you adapt it and change it in any way you see fit to improve the testing. But imagine if everyone on the team was new? How would you decide your testing strategy? This post will go through some useful things you can do to help a new team develop a test strategy. Table of Contents 📈 What is a Test Strategy? 🤔 Where should I start? 🎯 Understand the company and their goals 💪 Play to the teams strengths 👁️‍🗨️ Understand what quality looks like 📏 Understand Scope 🧪 Understand the type of tests you need 📊 Measure your success 🤝 Collaborate 📝 Summar...
Post a Comment
Read more