Testing is all about gathering information, and the most direct way to gather information is by asking questions. The more questions we ask (tests we perform), the more answers we receive (information we gain). But some questions are harder than others and require more human involvement. Let automation handle the easy!
Ingo Philipp is on the product management team at UiPath. His responsibilities range from product development and product marketing to test management, test conception, test design, and test automation. Before that, he worked as a theoretical astrophysicist in the field of high-energy particle physics and computational fluid dynamics. He holds a Master of Science degree.
All Stories by Ingo Philipp
This may not be what testers want to hear, but Ingo Philipp is convinced we can't ever answer the question "Did we find all bugs?" It all comes back to the fact that testing can prove the presence of bugs, but not their absence. Here, Ingo explores how we find and fix bugs, as well as the notion of quality assurance.
Testing is regarded as the number one bottleneck in the software delivery process. Most people simply conclude that developers are value centers, and testers are cost centers. But developers' work also brings cost, and—more importantly—testers' work also brings value. It's time to reframe our thinking about testing.
Exploratory testing is one of the most widely known but poorly understood practices in the software testing community. The term suggests that exploratory testing is a special testing activity, but in reality, all true testing is exploratory in nature. Let's rediscover what exploratory testing should—and shouldn't—mean.
Without revealing problems, there is no problem-solving, since we can't solve something we aren’t aware of. Each solved problem is one fewer problem in the software—and the software is improved each time a problem is removed. But it's not testing alone that improves software. So when does that happen?
Continuous testing entails executing automated tests to obtain rapid feedback on business risks. Where does that leave exploratory testing? Obviously, it doesn’t make sense to repeat the same exploratory tests across and beyond a sprint, but exploratory testing can be a continuous part of each software delivery cycle.
Specification-based testing is critical for determining whether a user story is “done done.” But that doesn’t ensure a positive user experience. Coherence, comprehension, and usability are beyond the scope of automated functional testing. Here are three reasons agile teams should embrace exploratory testing.