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 external data formats?

This blog post is in response to Challenge 7 of the #GivenWhenThenWithStyle blog post series with Gojko Adzic  You can see what the challenge is here: https://specflow.org/blog/how-to-deal-with-external-data-formats-givenwhenthenwithstyle/ Having the message format in the test would  (as mentioned in the challenge) look terrible and would be difficult to understand.  If I was to rewrite this scenario I would do something like the following: 1) Write a test that tests the validity of the payment message. So something like Scenario : payment message validity Given an account EE382200221020145685 has a balance When the system receives a payment message Then the payment message is valid.  I would store the actual payment message in another file as not to clutter the scenario file and this message would be passed into the test in the When line. The Then part of the test could cover various areas, such as: - All the correct tags are present  - The xml is valid 2) I wo...
Post a Comment
Read more

Benchmarking in C# - Simple Job attribute

In this post I am going to continue my servies on BenchMarkDotNet and I will explain what the various parameters do that are present in the simplejob attribute.  Now I say all....... the documentation is not great so I will explain what 3 out of the 4 do :) So If you remember in my previous post I had a MyFirstBenchmark class which contained the details about the benchmark test that I wanted to run. In this class there is an attribute called SimpleJob and this attribute contains a few parameters that can be configured when you run a test.  By default BenchMarkDotNet will choose the number of iterations that will return the best precision. However, using the simplejob attribute allows you to quickly get a set of statistics. Below is how my test was setup: Now as you can see I had the following parameters in the SimpleJob attribute: launchCount - This parameter allows you to define how many times the benchmarking test is run warmupCount ...
Post a Comment
Read more