Software is becoming more complex. Boeing’s 787 aircraft runs on about 7 million lines of code, but a 10-year-old sports car may contain processors running up to 100 million lines of code. Even relatively simple web applications are still more complicated than they were a few years ago, and while users and customers may appreciate the new functionality, every new feature is an opportunity for something to break. In-depth testing is the only way to make sure that you can deliver the features your customers want alongside the quality that they demand.
Components of in-depth testing
What do we mean when we talk about In-Depth Testing?
First, we want to make sure that testing is shifted as far left as possible—with QA in the room during every part of the development process. This includes the customer requirements phase and the early drafting phases where no code has in fact been written yet. This will let the QA process influence developers and help them create more stable and resilient applications from concept to release.
Second, we want to make sure that testers perform tests as often as possible. In previous software development regimes, software testing was conducted as a discrete phase at the end of the development cycle, right before release. This didn’t provide a lot of time to test, and restricted testers from performing some more complex and labor-intensive forms of testing.
Testing in-depth means implementing a continuous testing process that takes place in parallel with development and then continues after release. This allows testers to perform a wider variety of tests, including more complex tests. In addition, automation helps testers delegate repetitive and routine tests to machines, allowing them to focus their creativity on more interesting problems with more strategic impact.
Finally, in-depth testing means expanding test coverage. Before implementing widespread automation and continuous testing, you might only achieve 40-50% test coverage—not exactly the definition of in-depth testing. By using automation, and by implementing more varieties of tests, you’ll be able to get your test coverage much closer to 100%, especially in terms of code coverage.
To recap, in-depth testing means performing more tests, more kinds of tests, and testing at more stages of development. How do you put an in-depth testing plan in action?
Get started with In-Depth with mabl
Shifting testing left and implementing continuous testing are both part of testing in-depth, but they require more policy changes than technology changes. Implementing automation and expanding test coverage are both more dependent on technology. How can you leverage technology in order to expand test coverage and create more in-depth testing?
Your first responsibility is to identify testing roadblocks. For example, you might find that your existing test tool takes a long time to identify dynamic elements, which means that your tests run longer or require more manual intervention. Alternatively, you might find that your tests break every time you publish a new feature, or that you’re spending a lot of time performing manual regression tests.
In any event, you’re going to find areas where your existing testing solution forces QA to slow things down and work by hand. These areas are prime candidates for automation.
Once you’ve identified areas to automate, your next step is to expand test coverage. This isn’t as simple as looking at areas where you’re not currently testing and then starting to test them—you need to approach this in a strategic manner. Instead you should be looking for gaps:
- At the design level where there aren’t enough tests designed to meet customer requirements
- At the execution level where the designed tests aren’t being performed
- At the code level in which the application’s code base hasn’t been fully triggered through tests
It’s clearly more important to expand your coverage at the design and execution level than it is at the code level. What’s more, if you focus on increasing tests at the code level without implementing automation, then you’re just making more work for your testers without allowing them to focus on more critical problems.
Here at mabl, we strive to make automated testing easy for everyone so that the QA team can extend in-depth testing throughout the development cycle. To learn more about how you can increase your variety of testing and improve test coverage with mabl, sign up for a free trial of mabl today.
