Archive of Testing Articles

Last week, Ivan Chalif, a product manager / blogger, tapped into a thread criticising product managers for not adopting and espousing agile, or at least rapid-release techniques. In this article we look at Ivan’s comments and one of the articles that he referenced. We also share our own perspective and an alternative analysis of what may have happened.

People who are new to software, requirements, or testing often ask “What’s the difference between a use case and a test case?” This article answers that question, by building on earlier articles about use cases and use case scenarios. At the soundbite level, each use case has one or more scenarios, and each use case scenario would lead to the creation of one or more test cases.

Johanna Rothman recently wrote an article with a poignant introduction: “A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome.” Fixing it isn’t enough – how do we prevent it from happening?

Why run a test more than once? If it passed the first time, we don’t need to run it again – or do we? James Bach provides ten good reasons to run the same test more than once.

James Kovacs shares a great insight on software testing and the software testing process. His epiphany about test driven development makes it obvious to all of us why this technique is so powerful.

There’s a piece of North American folklore about John Henry, who was a manual laborer during the expansion of the railroads in our country. His job was being replaced by steam-driven heavy equipment, as the railroad industry applied technology to become more efficient. The same dynamics are happening today with manual testers. We need to make sure that manual testers avoid John Henry’s fate – read on to see why.

Quality writers are writing about requirements. Requirements writers are writing about quality. Just like the Reese’s Peanut Butter Cup – Two Great Tastes that Taste Great Together. You can’t have one without the other.

One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.

A detailed (15-page) article by Scott Sehlhorst showing how to incorporate test automation for complex software has been published at developer.*. This article shows the math, benefits, and weaknesses of traditional approaches to automating functional tests. The article also proposes improvements to the process, rethinking the problem to provide innovative solutions. This post discusses the background for the article and provides an overview, as well as links to related content.

We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…