Some people assume that exploratory testing is a task with low-effort thinking, where the tester simply goes through the application and sees what comes up. While we shouldn't discount doing just that, because sometimes it does reveal some interesting bugs, there are techniques and patterns that testers can follow when exploring an application. Let's look at a two-step process to use in exploratory testing.
There are many established ideas for ways to test software, but the industry is changing every day, and there's plenty of room for growth of new ideas—or challenges to traditional ones. Here are three ideas for "wish-list" research to conduct in order to shake up some of the conventional notions you may have about software testing techniques.
Continuous testing shortens feedback loops through automated testing that occurs throughout the development lifecycle—hence "continuous." Testing and QA become the responsibility of everyone working on the software, not just testers. Let's look at some proven practices from organizations that have used continuous testing effectively to realize tangible benefits.
Most organizations understand that test automation is essential for modern application delivery processes. They’re just not sure how to make it a reality in an enterprise environment without exorbitant overhead and massive disruption. Enterprise organizations typically achieve small victories, but the process ultimately decays due to challenges in five main areas. Understanding these challenges will help us overcome them.
When it comes to testing, there tends to be a differentiation between “production software” and everything else. But our ideas and principles about testing software are true for all software, not merely the code that will run in front of customers or the APIs that make things happen. Any software built for a purpose needs to be tested against that purpose, including the software running our test automation.
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.
Fixing a bug in one area of the software may break something in another area. To detect whether defects have been introduced, we need to perform regression testing—executing certain test cases again to see whether a change has affected other existing features. But how do you make time for another testing cycle prior to every production release? You need to get QA involved earlier in the software development lifecycle.
Traditional GUI automation is linear; it follows a set of steps. The first time you run it, it can't add any value, as the feature isn't done until the automation runs. Once test automation runs a second time, it effectively becomes change detection. This leads to a large number of "failures" that are not actually failures. Whether they are false positives or false negatives, we need a way to fix the automation tooling.
Risk-based testing is an approach to testing that helps us handle our limited resources. It’s also a valid model for years to come because it focuses testing resources where they can have the most impact—regardless of whether limitations are due to budget, tight schedules, or even the uncertainty of an unexpected situation like COVID-19. Here are some practical tips, examples, and steps you can use to adopt risk-based testing.
After finding and reporting a bug, a tester may get this response from a developer: "Please rerun the test on the latest version of the code and check if the bug still reproduces." This seems like a rational request; just as a change can cause a bug to appear, it can also fix a bug. But is following up the responsibility of the tester or the developer? And if the bug is no longer there, how do you classify and close it?