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.