Key Enablers for Continuous Testing
Over the last year, I’ve heard a lot of buzz around the term “continuous testing,” or testing before, during, and after each software change is made. This is both exciting and confusing for me: It’s great that people are pushing for more testing, but isn’t continuous testing something that testers have always been striving for? Still, any excuse for getting people excited about additional testing is a win.
There are several activities your organization should adopt to move toward continuous testing:
- Collaborating on requirements (behavior-driven development, or BDD)
- Constantly validating change (regression testing)
- Dev-test pairing in exploratory testing and reviewing test cases
- Automated testing in CI (unit testing, API testing, and code analysis)
- Continuously improving test approaches, test suites, and test scripts
- Reviewing customer feedback and product ratings
There are also some enablers your organization should embrace. Let’s look at three practices that will help your company get ready for continuous testing.
Whole-Team Quality
It's important to realize that QA does not “own” quality. QA doesn't introduce issues that impact quality, and they don't fix these issues. They simply find them and point them out.
Many of these issues could be identified earlier. If we shift the focus of testing to start sooner in the development process, we can save time and money.
Good quality code starts with the design of the software. Get developers to do test-driven development. Better yet, get the organization to adopt BDD practices: Have the developers, testers, and product owner all agree on functionality and tests before code is written. Shifting testing left is key to your continuous testing journey.
Build Orchestration and Continuous Integration
Having an automated build and continuous integration (CI) pipeline is vital to being successful in your continuous testing effort. This way, once code is committed to a source control repository, testing can begin. This means you need to ensure that your application builds, unit tests pass, code coverage is at an acceptable level, and so on.
Developer-level testing is crucial, as it provides rapid feedback and ensures that at the lowest level, the code does what is expected. Consider what other things you can throw into your CI: static or dynamic analysis, some security checks, or maybe even some API validation. The more information, the better, as long as it provides rapid feedback to the team.
Automated Testing below the UI
One big thing to remember when testing is that your application is more than a user interface. You probably have some APIs, a back end, and a database, all of which should be tested. Not only is it easier to test at these lower levels, but these areas can typically be tested earlier in the development process because they usually don’t need to be fully developed in order to start testing them. This means you can get started testing sooner, which is of course the goal.
Additionally, API tests typically run tens to hundreds of times faster than the UI tests. This plays in perfectly with our idea of rapid feedback, and keeps pushing testing further left.
Remember, you can’t test continuously if you don’t start testing early!
Max Saperstone is presenting the session Getting to Continuous Testing at STARWEST 2019, September 29–October 4 in Anaheim, California.
