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

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 ...
LogiGear Magazine – December 2013 – Cloud Testing
By Jez Humble and David Farley Continuous Delivery from Jez Humble and David Farley is an important contribution to the field of software development. It takes continuous integration to the logical conclusion and covers how to set up a continuous integration system, delving into everything from check-in to delivery to production. It doesn’t state you ...
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 ...
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 ...
From the culture shift, to differences in Agile, Dave Farley and Michael Hackett discuss the nitty gritty of Testing in DevOps. For this issue of LogiGear Magazine, our very own Michael Hackett sat down with one of the godfathers of Continuous Delivery, David Farley. In this exclusive interview, David discusses how test teams and automation ...
If you haven’t already caught a glimpse, we announced in January the Testing in DevOps and Continuous Testing videos series, available on YouTube!
Having the right skills and experience, even if you have to go outside, is essential for designing tests for large-scale cloud deployments. Moving existing applications to a cloud environment adds new dimensions to testing. One of the primary reasons for moving to the cloud is scalability. Capacity to handle traffic and data transfer can be ...
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 ...
In this article, I share some of my experiences and observations on training teams, mainly in corporate settings. The operative word here is “team”, not “individual”. When training teams or groups in an organization, many of the considerations and benefits are different than those for the individual. We’ll examine those differences and I will share successful solutions. ...
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 ...
Disclaimer: This article was originally published in the LogiGear Magazine, but has been updated for the June 2020 issue. Leading an organization into Continuous Delivery is a daunting task that usually takes software development teams months if not years. This guide covers the main points that organizations need to consider to increase their chance of ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe