In the latest blog post from Michael Bolton, he likens software testing to smoke detectors. Just as smoke detectors don’t prevent fires, testing on its own doesn’t prevent problems. Touching upon a few different types of testing, Bolton emphasizes the “revealing” nature of the practice. Software testing reveals and directs attention to existing errors, which Bolton argues, are not a waste as many tend to believe.
“Every error that someone discovers represents an opportunity to take action that prevents the error from becoming a more serious problem.”
To learn more about software testing roles that go beyond “preventing problems,” read Bolton’s full article here.
What exactly is the optimum ratio of testers to developers within an organization? As with many general questions directed at the software development community, the answer is: it depends. However, the issue deserves some attention.
Different cases will call for different solutions—developing a completely new application? You’ll probably need one or two testers per five developers. Delivering a maintenance release? Testers should outnumber developers. Take a good hard look at your project and the tester-developer ratio, then read through the rest of this article to ensure you’re working with the optimal number based on your project’s requirements.
Faster development, faster testing, faster time to market—the need for speed is driving the software development world and testers who fail to adjust their mindset and skills accordingly may fall behind.
Agile methodology is especially prevalent. For testers either working in an agile environment or looking to do so, this Testing Excellence article serves as an excellent guide. In it, author Amir Ghahrai outlines the twelve principles of the Agile Testing Mindset, lists several skills all agile testers should have and explains the role of a tester in an agile team. Check it out!
Does it seem like no matter how much testing takes place before an application is pushed to production, end users still manage to find a high number of functional defects and usability and/or performance problems? This doesn’t necessarily mean that testers are slacking in the bug-hunting department—their mindset may just require a bit of tweaking.
Oftentimes, software testers are focused and biased by User Stories instructions. Without defocusing enough to search for the surrounding problems in a product, testers are only proving that the product can perform at the level required by the Product Owner. Here is where Destructive Software Testing (DST) comes into play. DST is a method that aims to erase all the biased information from the User Story so that testers can identify points of failure in a program.
Read on in this Test Huddle article for tips on how to set the correct context for DST.