Redefine your testing and make quality a competitive advantage

DevOps make software delivery more efficient and accelerates the speed in which innovation can be brought to the market. Testing is an integral part of this process, yet often the weakest link. A big part of the problem is that Testing and its value is not properly understood. In order to understand the solution, you must first understand the problem.

Mindset changes

In this talk we will first look at the different ways of looking at testing, the difference in mindset and approach that is required when you move from:

• a focus on manual testing to a focus on automated testing,
• then from automated testing as an extension of manual testing to continuous testing,
• then finally shifting the testing left and starting with the tests.

Shifting Left

Shifting left warrants a deeper dive, for it is not just about writing the tests first, it changes completely the focus of the tests. The tests become living documentation that must be predictively and collaboratively developed by the entire team. This means that the tests extend the requirements into the specification. They must be written taking into account the full-stack from front-end to back-end, giving the development team all the info they need to implement the feature. If the tests are deeply integrated in the C.I. pipelines, then that means that they are constantly executed and validated, turning them into a living documentation, which validates the 'requirements' not the 'code'

In a deeply integrated context, then each execution cycle is available to everyone in the whole project, all the time. Fast and comprehensive feedback helps to remove silos and misunderstandings in the team. It's like turning the lights on in the project.

Shifting Right

One of the problems that arises is as the volume of automated tests increases, then the time to execute these tests will also increase. A developer needs fast and focused feedback, therefore the test execution needs to be prioritised to focus on most relevant tests first. Once this set of tests passes, then the developer gets the 'initial' feedback and the greenlight to keep working and the build progresses to the next stage of the build process whereby increasingly comprehensive sets of tests will execute, one stage after the other. Staged quality gateways enable both fast and comprehensive feedback. As the quality gateways improve in scope and depth, so too will 'trust' in your pipelines. At the end, any build that passes through all of your quality gateways comes out the other side as a shippable piece of code. This means not just continuous integration... but continuous delivery.

Democratising of testing

Another critical success factor for systematic test automation at scale is moving away from a silo mentality and embracing an 'agile' attitude towards quality. This means all stakeholders in the development team are 'owners' of quality, technical and non-technical alike. For this to work the tools used must be accessible for the whole team.

There are typically two barriers towards accessibility or 'full-team' engagement with Testing:

1. the tools are too expensive
2.  they are too complex/complicated to use

If a tool is prohibitively expensive, then access is restricted. This, obviously, reinforces the 'silo' nature of development that we want to avoid in a DevOps environment. Equally if a tool is too complicated to use, if it's something that you can only access via an IDE then the non-technical members of the team are also 'out-of-the-game'. Again this is something to be avoided. An increasingly popular solution to address the 'technical' accessibility point is through 'low-code' tools based around a graphical user interface. If the barrier for engagement is removed, then non-technical members, such as testers/POs/BAs are able to exploit their domain knowledge much more effectively. They are able to offer a much higher 'qualitative' input and this in turn is only good for the development process.

So how does all this look?

In the final phase of this talk we will discuss what this looks like in the context of an integrated Continuous Integration context. How tools like Xray and Testifi's own CAST can extend the Jira eco-system to create an entire software delivery platform. I would like to share some of the things that work for us and give you a big picture perspective of how the above theory translates into a tangible platform.

About Testifi

Testifi's mission is to redefine software testing. By changing the way companies 'test' then this gives companies a clear view of their entire software value stream, allowing them to maximise the efficiency of the team, bringing innovation to life in a fast, stable and secure manner. Our solutions are backed by industry best practices and science to give development teams the tools they need to make 'quality' a competitive advantage.

Testifi was founded in 2017 and consists of 35 people, with offices in Munich (HQ), London and Budapest. We supplement our products with 'Done-for-you' or 'Done-with-you' services to enable you to 'Do-it-yourself'.

Company Website: www.testifi.io

Dan's Linkedin Profile: linkedin.com/in/danburns6

Testifi on Linkedin: https://www.linkedin.com/company/testifi