There were a couple dozen people who showed up at the Fool, last night, for my presentation on A ”Lingua Franca” to Ensure You Get the Right System. I’d like to thank them all for coming and for such lively participation.
These are exciting times. The tools of acceptance testing and behavior-driven development are progressing beyond the domain of the techies. They are entering the realm where they can help the Whole Team. Read More
It’s a very common complaint, such as this one left on the Scrumdevelopment yahoogroup:
Usually in different phases, workload for tester and dev is different. E.g. when a project is coming to the end, most of the tasks will be test.
There are a couple of big red flags waving at me in those two sentences. One is “different phases.” Why should a software development project, especially one only a couple weeks to a couple months long, have phases? The other is, at “the end, most of the tasks will be test.” Postponing testing to a phase at the end has never worked very well. It always results in the testers being behind at the end.
Does this situation sound somewhat familiar to you? If so, what can we do about it?
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. Read More
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. Read More
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. Read More
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. Read More
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, Read More
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.” Read More
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. Read More