More and more industries and companies are running on software today. Most of the suppliers we subscribe to deliver their goods via online digital products and services. As an engineer in the trenches, you can see how software is consuming more and more, and why our jobs as testers are more important than ever. It’s up to us as testers to keep pace with the rapid growth. We are the quality champions and leaders of our software.
As teams push harder and faster to get features into the hands of our customers, we are the last line of defense for educating our team to potential unseen consequences of our development decisions. The digital testing landscape is changing fast, and in this article, we will see how Continuous Testing helps us to deliver quality products.
Agile
In the pre-agile model, which is the classic software development Waterfall model, testers only began testing once the software requirements and development were complete, and we as testers had limited inputs and insights. It was basically a world full of silos.
Agile broke those silos down and brought everyone together as one team. That change was a significant one because it meant teams could work for years on a project without speaking or getting any feedback from their users. As you might imagine, resolving issues found in production were almost impossible to resolve, and fixing deep-seated architectural issues with the software required spending a great deal of time and money. Agile was the first wave of modern software development that addressed the issues presented in the Waterfall development approach.
DevOps
Once Agile took root, the second wave — DevOps began to appear. Again, it took some time for it to gain acceptance, but it ultimately caught on even faster than Agile. DevOps gave birth to the collaboration between software development and software operations, creating practices like continuous integration and delivery to provide services and products at high velocity. This approach creates a mechanism that allows us to quickly get our products into the hands of our users, which means quicker feedback in order to determine whether it’s delivering the value we’ve promised. Like Agile did before it, DevOps broke down even more silos between teams merging software operations with the rest of the team.
Continuous Testing- Current State of Testing
The best definition of Continuous testing is the ability to instantly access the risk of a new release or change before it impacts customers. You want to identify unexpected behaviors as soon as they are introduced. The sooner you find or prevent bugs, the easier and cheaper they are to fix. This approach is often accomplished by executing automated tests that probe the quality of the software during each stage of the Software Development Life Cycle (SDLC). The mantra of continuous testing is “test early, test often, and test everywhere in an automated fashion.” Testing begins not after everything is completed but from the start. Each step along the way serves as a quality gate, baking in excellence at each stage of the SDLC pipeline.
Now with continuous testing, we’re not only running tests in an automated fashion using the same tools and languages as the developers (and leveraging open-source libraries), but we’re doing them continually all the way through into production– beginning with development. We’re not waiting until the end like in the old “waterfall” days. It’s important to remember that continuous testing is not just about end-to-end, UI test automation. With the need to quickly release software, we can no longer rely on manual and automated UI testing only. When we talk about automation in the context of continuous testing, it’s the process of automating any manual task that is slowing down the process. It doesn’t need to be a “test.” For example, before my team could do continuous integration, we needed to have an automated deploy job for our software. Having folks manually install the latest build on the nightly automated test environment was not a scalable solution. These types of tasks are critical and need to be automated.
CI Process
A typical continuous testing process consists of seven key elements: Develop, Build, Test, Report, Release, Monitor, & Repeat. Ultimately, the process starts with testing the quality of the feature. A recent study tells that 64% percent of total defect costs are due to errors in the requirements and design phases of the SDLC. So you must be careful before you start the development, you should ask these – Is it really what our customer wants? Has your team cleared up any confusion or misunderstandings before coding even starts? Getting clear on what it is you are trying to deliver to the customer can find bugs before a line of code is ever written! This is one reason some teams use acceptance criteria practices like Behavior Driven Development to help drive this communication and test the team’s assumption against what their customers really want.
Once the team agrees on what it is they are developing, testing approaches like TDD should drive the process and let you know if your code actually meets your business objectives. Code that is checked into your continuous integration process needs to be probed for quality. Automated style checks, security, performance and unit tests, automatic tests on check-in with a required pass/fail ratio needed before promotion to production, etc., will ensure that broken code is not promoted to production.
Related Blogs
With continuous integration, your developers need to make their code testable. If you want to write test automation for your code, you need to be able to separate it into individual pieces. The secret is to build small things that can be combined into larger things. The best way to build small things is to have a good test suite around the small things, so that when you combine them into the bigger things you have to write less tests on the bigger thing first off; it’s also easier to test the bigger things because you already have guarantees about how the smaller things work. You don’t want to write code just for testing. You want to write code that is testable but doesn’t do any more than is needed. What it often comes down to is breaking these things down into smaller pieces, and testing the individual pieces.
Comments(0)