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

For this month’s book review, I read Continuous Testing for DevOps Professionals: A Practical Guide from Industry Experts, by various authors and edited by Eran Kinsbruner. The book is divided into 4 sections: Fundamentals of Continuous Testing, Continuous Testing for Web Apps, Continuous Testing for Mobile Apps, and The Future of Continuous Testing. The Fundamentals ...
Times have changed, the tools have improved, and with books like this available you have no reason to not give CI a go. I still remember the first time I was on a project that used NAnt and CruiseControl.NET. It was years ago and both were new tools with plenty of bugs. The project manager ...
Introduction Everything changes. It’s the only constant. The landscape of software testing is undergoing a fast and dramatic change driven by societal, business and technology changes that have placed software everywhere. Computing is ubiquitous. There is hardly anything today that doesn’t contain a CPU or information transmission capability, with software to drive it. From smart toasters ...
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. 
Run your TestArchitect API and headless browser tests inside Docker containers as easy as flipping a switch Docker is a virtualization platform enabling you to create containers – mini virtual machines— which have their own predefined environment, including file system, libraries and settings. Best of all, these light-weight images eat up only a few megabytes ...
Do you want to speed up your automated tests by a factor of 10 and deploy your application continuously? In this article we share how the JIRA development team at Atlassian has accomplished this using Stages in Bamboo. Stages have allowed the JIRA Development team to take a week’s worth of testing and condense it ...
DevOps may be the next big buzzword, but Test teams really need to focus on its little sister, Continuous Delivery If you pay attention to trends in software development—from the perspective of what some sophisticated teams are doing, what articles and books are being written, to conference topics, you may have noticed the tools being ...
How Halliburton leveraged outsourcing to achieve their goals. Organizations are focusing on speed, both in Continuous Integration and rapid deployment as a competitive advantage. Many software development organizations can significantly shorten development cycles by implementing one or a combination of Agile practices, continuous integration & deployment methods, and feature branches. While these frameworks and techniques ...
Over the years we’ve provided an extensive number of articles, videos, and infographics that provide a wealth of knowledge about Continuous Delivery.
The book is an incredibly effective and valuable guide that details the risks that arise when deploying cloud solutions. More importantly, it provides details on how to test cloud services, to ensure that the proposed cloud service will work as described. It is a great start to the topic. The 6 chapters detail a paradigm ...
LogiGear Magazine June Issue 2018: TESTING in DEVOPS
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 ...

Leave a Reply

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

Stay in the loop with the lastest
software testing news

Subscribe