Many software testers are lamenting the impending demise of their jobs thanks to artificial intelligence. But Jon Hagar thinks there's no need to panic just yet. Here, he details some capabilities he's seen in AI, relates how these can be used in software testing, and explains why he thinks most people don't have to worry—although he also explains who should! As usual, it comes down to a willingness to learn new things.
Whole-team testing means the whole team understands and participates in testing, using testing education as a tool to support quality efforts. And to be able to support testing in a meaningful way, team members must experience how testing is done by professional testers. Understanding skilled testing can help non-testers realize what quality criteria should be there and what elements of a product contribute to great quality.
The way we think about what necessitates test coverage being “complete” influences how we test and the cases we create. After all, you wouldn't design tests for situations that don't occur to you—and you can't test what you can't see. It's time to take off the blinders. Here's how you can find where the bugs in your products are occurring, and then adjust your strategy to pinpoint them.
A command-line package installer is a handy tool that installs your desired software package without a fancy UI, yet it often proves to be more effective than some tools integrated into expensive IDEs. Brew and Pip are two of the more popular options for package installers when using the script language Python. But what’s the difference between them, and which makes more sense for your use? Here’s an introduction to Brew and Pip for testers.
Everyone on the software team has the same goal of delivering the best product they can, so letting testers discover bugs is always good—the more bugs found, the better! But misconceptions often lead to testers getting the bad rap of "breaking" the software. It's a tester's job to think like a user. Developers and stakeholders might call that negative testing, but the result is a better product, and that’s all positive. Let's change the way we talk about testing.
AI-based tools have transformed from a vague, futuristic vision into actual products that are used to make real-life decisions. Still, for most people, the inner workings of deep-learning systems remain a mystery. If you don’t know what exactly is going on while the input data is fed through layer after layer of a neural network, how are you supposed to test the validity of the output? It’s not magic; it’s just testing.
Data analysts have to know a lot about diverse business areas so that our reports provide usable information, not just data. We can use this awareness of the value of information to merge different data sets in order to answer new questions, and even help our users make better decisions. But in order to do this, we need to present not just the data, but the information value represented in that data.
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.
Simple rules are great for guiding us through an overwhelming workload. Sometimes complicated solutions are necessary, but simple rules often outperform complex algorithms, making them more efficient than sophisticated, difficult flows. They can also break down big goals into practical daily guidelines testers can follow to perform more effectively. Let’s see how simple rules can be applied in software testing.
A move to DevOps creates an opportunity to shift the testing process to the left. But what if you went further? DevOps supports continuous testing, so you can advocate for a constant focus on quality, with testing permeating the entire software development process. Here's how you can actually have a faster testing process when the software is tested throughout the lifecycle, by developers, testers, and automation alike.