Bonnie Bailey explains how our reactions can reveal what our expectations are for software quality. Quality is easier to recognize by our reactions than by what metrics, tools, or automation results tell us—no matter how much stock we put in their reliability.
Bonnie Bailey is a software test engineer for a health care information technology company. Bonnie is an avid reader of fiction and non-fiction, including software design, testing and development, disruptive and emerging technologies, business leadership, science, and medicine. She also enjoys writing.
All Stories by Bonnie Bailey
Bonnie Bailey writes on the importance of knowing your users and keeping them close to you. The more you live and breathe your users, the more you know what they look like. Keeping your users close also implies making room for their data and their environments.
Commit messages say a lot about the developers and test automation professionals who writes them—or who doesn’t write them at all. Trivial on the surface, the presence and substance of a commit message can indicate how forward-thinking a person is, which may indicate bigger things about the code.
Bonnie Bailey writes on how toilet paper problems, which are problems in which the effort required to resolve them are proportional to their current urgency, affect software development. When dealing with toilet paper problems, you're less likely to prepare for other potential problems.
In software development and testing we often encounter situations in which someone just isn't being very agreeable. Sometimes intelligent, reasonable people just don’t get it. The good news is those people probably haven’t gone temporarily stupid, so you can stop banging your head against a wall.
Similar to the story of David and Goliath, software developers and testers hunt giants too—bugs, that is. Like David, they should believe that where there is one giant, there are probably five nearby, and they should hope to find each one.
Software testers are hunters. At least, they should be. Their prey: fragility. Like some organizations and people, software can suffer from fragility, and it is the software tester's direct responsibility to sniff out fragility, call it by its name, and work to squeeze the life out of it.