3 Ways to Get in Shape for Continuous Testing

Making the leap to CT is easier than you think— follow this guide to transform your testing process

No pain, no gain! Achieving Continuous Testing shouldn’t take a “Hans and Franz” attitude. It should be painless, more like a natural progression from implementing certain practices over time.

Testing continuously throughout the SDLC (Software Development Life Cycle) means you’re not thinking about testing as a phase or as an event. It means every asset created as part of the SDLC, regardless of whom it was created by, must be tested.

If a developer creates a method, that has to be tested at the unit level, and then at the integration level, as that method interacts with other components. And that’s where manual testing becomes a bottleneck. In a fast-paced, agile development environment, if those simple tests are not automated nor triggered by a CI (Continuous Integration) agent for unattended execution, that means code development is being slowed down.

Similarly, if a tester is creating a functional test case to test a story from the backlog, and that test case is manual, it means someone has to manually execute it within the sprint. Again, a manual testing approach means the testing team will continue to be seen as slow. Developers need immediate feedback “in-sprint,” not just at the unit level, but also at the story level. That can only be accomplished if functional tests are created in an automated fashion from the beginning, not after the sprint is completed, as it is traditionally done.

So how do you get in shape for taking up the Continuous Testing challenge?

1. Be Smarter with Requirements

Is your team still capturing requirements in a textual form? If yes, then the team is working too hard. Instead, requirements should be captured in a visual form, such as a flowchart. With the expected behavior of the application (including business rules) modeled in a diagram format, it becomes easy to identify all the possible paths and permutations in a mathematical way. Each of these paths and permutations represents a test case. That means test coverage can be accurately calculated and optimally defined, based on risk.

So, what does that mean? It means that as you’re visually modeling the requirement. You are finding many missing requirements conditions you hadn’t considered, identifying gaps and clarifying ambiguities, all of which will cause defects to be entered in the application code. This is a required warm-up exercise to start down the Continuous Testing journey so you truly shift all the way to the left. Otherwise, you’ll get stuck on making improvements only in the Development discipline, not the entire SDLC.

2. Practice TDD Test-Driven Development

With requirements having the form of a diagram, technology is able to tell developers what tests they should be coding for. This optimization essentially removes the burden from developers to have to read requirements or user stories in a textual format, interpret them, and then think about tests so they can start coding for those tests to pass.

By automatically modeling these business processes, hours of time and effort can be saved on the already overloaded list of tasks a developer has to complete on a daily basis. This also puts a focus on writing only the application code that is necessary to fulfill that particular requirement, as opposed to writing unnecessary code for that sprint to be completed.

Lastly, with the requirement being the diagram, it becomes easier for the developer to visualize the interfaces that are required for her code to work. For example, if the user story in scope needs to make a call to a third-party API and it is not available, the developer can virtualize that API so she can write her code to realize the user story assigned to her, without having to wait for that third-party API to be available. Once it becomes available, the developer’s code will be ready and only a quick integration test will be required, which would’ve been automated already when the virtual API was defined.

3. Test Automation

Traditionally, “Test Automation” has been a term used to describe Functional Test Automation performed by the Testing or QA team members. This Functional Test Automation actually meant automating the execution of the test. The actual creation of the automated script, in whatever scripting language, was still a manual task (i.e. someone had to manually write the code to automate a test).

In today’s world, however, Test Automation refers to any automation performed on any testing-related tasks, regardless of by whom. That includes unit tests developers create, API tests, end-to-end tests, security tests, performance tests and the list goes on. The caveat is that Test Automation now must include the generation of the automated script, not just its execution.

This understanding is essential. Think for a moment of what this means. By automatically generating the automated script code and automatically triggering its execution, fully unattended and hands-off, you are truly enabling a continuous testing state.

If you have to manually intervene in the automated execution, you don’t have, by definition, a continuous test execution. You’re semi-automated at best, since you have to stop, do something, watch the outcome, and enable the execution to continue. That is not good enough in a fully automated Continuous Delivery pipeline, where your organization is delivering code to your end users much more frequently and with better quality.

No Need to Sweat

Sounds like too much for you? It really is simpler than you’d think because you’re not improving the three areas at once, you’re doing that over time as you’re educating your team and organization, getting buy-in from all stakeholders and gaining their trust by showing small positive results iteration after iteration. And if others have done it, so can you!

So, don’t sweat it, jump on that Continuous Testing treadmill, start slowly and keep on cranking up the speed with the little wins that will happen week after week. In a couple of iterations, you’ll be running without breaking a sweat, and be in shape to support your organization’s DevOps initiative and the goal to transform to a continuous and modern software factory.

Alex Martins
Alex is currently working at CA Technologies as the CTO for Continuous Testing. He has more than 18 years of experience in large-scale application design, development and testing. For the last 13 years Alex has been focused on software quality engineering and testing discipline as the pillars for DevOps transformations. He led HP’s Global Testing Innovation capability creating Continuous Testing offerings to support Digital Transformation initiatives and was one of the Innovation leaders in Cognizant’s Mobile and IoT QA practice.
Alex Martins on Linkedin

The Related Post

This post is part of the Pride & Paradev series With continuous deployment, it is common to release new software into production multiple times a day. A regression test suite, no matter how well designed, may still take over 10 minutes to run, which can lead to bottlenecks in releasing changes to production. So, do ...
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, ...
LogiGear Magazine – February 2013 – The Rapidly Changing Software Testing Landscape
LogiGear Magazine – December 2013 – Cloud Testing
DevOps has been described as Agile on Steroids; DevOps has also been described as Agile for Operations/IT. I like both of those descriptions. Many organizations want Development, Test, and Operations teams to move to DevOps now. DevOps is a big topic, but DevOps is not the focus of this article. We will not be talking ...
How to Adopt the “Third Way” in the Dojo’s Method to Master CD In The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations the authors describe “The Three Ways” – the underlying principles forming the basis for all DevOps practices. 
Continuous Testing and Continuous Monitoring What is the goal of Continuous Integration? Is it to enable Continuous Delivery of the code developers’ produce out to users? Yes, eventually. But first and foremost it is to enable ongoing test and verification of the code. It is to validate that the code produced and integrated with that ...
Special considerations that should be applied to an application running in the cloud. Over the last weeks, I have found myself in several rather intense discussions about “cloud testing”: what it is, what it isn’t, and what it means for testing and QA professionals. The major source of confusion in these discussions usually revolves around ...
LogiGear Magazine June Testing in Continuous Delivery Issue 2017
LogiGear Magazine June Issue 2020: Transform Your SDLC With Continuous Testing
From adopting the culture, to implementing Continuous Delivery With the relative newness of DevOps, there are not yet a ton of DevOps books. That’s why we’ve assembled a list of the 7 best DevOps books based on four criteria: the number of ratings from Amazon, the average Amazon rating, number of ratings from GoodReads and the ...
Fitting QA into a modern DevOps group In a traditional software engineering organization, the QA group is often seen as separate from the Development group. Developers and testers have different roles, different responsibilities, different job descriptions, and different management. They are two distinct entities. However, for folks outside the engineering team – say in Operations ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news