George Dinwiddie's blog

I’ve had numerous discussions with Michael Bolton where he makes the claim that scripted testing (whether via automation or a person following written directions) is not testing but checking.  He quotes Cem Kaner‘s definition of testing: “testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.”  Running a script that validates certain desired behavior certainly fits this definition. (Continued)

Jim Shore posted a nice Introduction to Agile for QA People on his blog.   I thought it was great as far as it went, but it didn’t explicitly mention some of the things that I have found to be extremely important, at least, in the corporate IT environment.  I tried to leave a comment there, but I was too long-winded for his comment system.  (If you’ve not read his post, please do so now.  I’ll wait.)  Here’s the full text of my comment:

Jim, I think you’ve left out, or under-emphasized, an aspect here.  It’s perhaps not explicitly called out in the XP literature, and isn’t mentioned by Scrum (neither of which mention the QA department as an entity), but it’s an important aspect in successful Agile adoptions in corporate IT environments, in my experience.  That aspect is Defect Prevention. (Continued)

Amr Elssamadisy reports on InfoQ that automated acceptance tests are “only used by a small minority of the community.”  Is this true?  If you and your team don’t use automated acceptance tests, please let me know how you handle regression tests as the application grows larger.  You can leave a comment here or, if you’d rather not say it in public, email me directly. (Continued)

The term “non-functional requirements” has always bothered me. “Do you mean the software isn’t supposed to work?” ;-)

This post is about how I approach test-driving the solution to non-functional requirements such as performance, and how it differs from test-driving a functional user story requirement. (Continued)

I’ve often found that Developers and Testers misunderstand each other, even when they have a congenial relationship. (And in some shops, the relationship is anything but congenial.) Developers often don’t see the value of the Testers, or get annoyed that the Testers find issues that weren’t mentioned in the requirements. Testers often think Developers only consider the nominal cases, and don’t give enough attention to the edge conditions. Often, neither understands the others point of view. Michael Bolton, on the agile-testing list, said, (Continued)

I’ve been neglecting this blog, lately, partly because I’ve been busy working on a software development process assessment for a client. In doing this, one of the meetings I observed was a post mortem of a release failure. The developers involved noted that they’d seen some connection drops by the webserver on the integration environment. The developers, however, didn’t trust that the integration environment adequately represented the production environment. They’d seen a similar problem some months prior, and didn’t know if anyone had fixed it. Therefore they didn’t know whether these problems were the result of the code they were deploying, or, as one developer put it, “just one of those things.” (Continued)

On the Test Driven Development YahooGroup, Alan Baljeu asked, “It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature…. And by not considering those things, you introduce bugs into the software.” In response, he got two types of advice. One was specific suggestions of software construction techniques that can reduce the occurrence of errors by reducing the number of places that need to change when adding a new feature.

The second type was general testing advice. Alan admitted, “I don’t see a way to properly identify what new behaviour will need to be covered. I want to be sure I’m not forgetting cases, but currently I’m overlooking too many of these effects.” In other words, the current test coverage is not catching all the errors. (Continued)