Testing continuous technological change can seem like chaos. There are many challenges that need to be managed, such as unavailability of power, excessive temperature, incorrect configuration, unexpected behavior of services, network downtime, and processing slowdown in production. By deliberately engineering chaos, we’ll be able to discover many of our systems’ weaknesses before our users do.
Companies that want to reduce testing costs usually try working with fewer people, or even cutting back on the amount of testing done. But with those approaches, quality usually suffers. Releasing a critical bug and suffering the subsequent pain usually costs multiple times what testing would. There are better ways to save money, and it can be done just by being smarter about our test cases and their structure.
DevOps does speed up your processes and make them more efficient, but companies must focus on quality as well as speed. QA should not live outside the DevOps environment; it should be a fundamental part. If your DevOps ambitions have started with only the development and operations teams, it’s not too late to loop in testing. You must integrate QA into the lifecycle in order to truly achieve DevOps benefits.
Teams everywhere are looking to speed up testing without sacrificing quality, so once again, some of the top articles last year were about continuous integration, machine learning, and—of course—how to best implement and use test automation. But readers were also interested in what they shouldn't be doing, with two high-ranking articles about test practices we should stop and a tool you may be misusing.
Many people misunderstand the purpose of Cucumber. Because it seems to yield clearer, plain-language test scripts, testers want to use Cucumber as a general-purpose testing tool, including for API tests. But its true purpose is as a BDD framework. You may be thinking, what’s the harm? Here’s why it makes a difference—and why you should choose another tool for API testing.
Many testers spend their time doing functional testing and don't come out of this cocoon. But software testing is all about discovering quality-related information to assist stakeholders in making informed decisions, and there are multiple ways to discover information in addition to functional testing. Here are six actions that will help you add more value to your projects.
There are many metrics to measure the effectiveness of a testing team. One is the rejected defect ratio, or the number of rejected bug reports divided by the total submitted bug reports. You may think you want zero rejected bugs, but there are several reasons that’s not the case. Let's look at types of rejected bugs, see how they contribute to the rejected defect ratio, and explore the right ratio for your team.
If you’re new to automated testing, you’re probably starting off with a lot of questions: How do I know which tests to automate? Why is automated testing useful for me and my team? How do I choose a tool or framework? This article answers a lot of those questions—and gives you some more to consider!—so you have an excellent foundation for beginning your automation endeavors.
Continuous operation tests find important bugs, partly as a result of their long operation and partly by increasing the probability of finding statistical bugs. However, CO tests have their own downsides. Mandating a periodic reset or reboot can work around these issues, as well as save time and cost for testing, reproduction, debugging, and fix verification.
We like to hope that we will consider all possible situations when devising our tests, but it’s all too easy to overlook the unusual cases. That’s the benefit of random test generators. We might feel comfortable after testing a few dozen test cases; these tools generate hundreds. With more stuff getting tossed at the wall, there is a greater likelihood that something interesting sticks.