Blog Posts from January, 2015

Very Short Blog Posts (23) – No Certification? No Problem!

Wednesday, January 28th, 2015

Another testing meetup, and another remark from a tester that hiring managers and recruiters won’t call her for an interview unless she has an ISEB or ISTQB certification. “They filter résumés based on whether you have the certification!” Actually, people probably go to even less effort than that; they more likely get a machine to search for a string of characters. So if you’re looking for a testing job, you don’t have a certification, and you have no interest in paying an employment tax to the rent-seekers here’s one way to get around the filter. At the bottom of your CV, add this sentence:

I do not have an ISEB or ISTQB certification, and I would be pleased to explain why.

An automated filter will put your résumé on the “read it” pile. Then the sentence should attract the attention of anyone who bothers to read it and who is genuinely interested in hiring a tester, at which point they’ll start looking at your real qualifications. And if they don’t contact you, you probably don’t want to work with them anyway.

Very Short Blog Posts (22): “That wouldn’t be practical”

Saturday, January 24th, 2015

I have this conversation rather often. A test manager asks, “We’ve got a development project coming up that is expected to take six months. How do I provide an estimate for how long it will take to test it?” My answer would be “Six months.”

Testing begins as soon as someone has an idea for a new product, service, or feature, and testing ends, for the most part when someone decides to release or deploy it. Testing happens at the same time as development does. Testing starts when development starts, and when development is done, testing ends.

In reply to that, the test manager sometimes says, “That wouldn’t be practical.”

That answer used to confuse me—it seems pretty impractical to develop something without exploring it, experimenting with it, and checking it pretty much continuously. But I now believe that “that” refers not to testing, but to the test manager’s fear of having a conversation with a development manager—one with a factory-oriented model of software development and testing—who is asking for the estimate.

So, some time ago, I wrote this post, to help people to work through the problem and to offer some solutions for it. The core message is that thinking of a project in terms of “a coding phase and then a testing phase” is like thinking of programming in terms of a “typing phase and then a thinking phase”. If reframing a misbegotten model of development is impractical, to me it seems vastly more impractical to live with the consequences of that model.

Taking Severity Seriously

Wednesday, January 14th, 2015

There’s a flaw in the way most organizations classify the severity of a bug. Here’s an example from the Elementool Web site (as of 14 January, 2015); I’m sure you’ve seen something like it:

Critical: The bug causes a failure of the complete software system, subsystem or a program within the system.
High: The bug does not cause a failure, but causes the system to produce incorrect, incomplete, inconsistent results or impairs the system usability.
Medium: The bug does not cause a failure, does not impair usability, and does not interfere in the fluent work of the system and programs.
Low: The bug is an aesthetic (sic —MB), is an enhancement (ditto) or is a result of non-conformance to a standard.

These are serious problems, to be sure—and there are problems with the categorizations, too. (For example, non-conformance to a medical device standard can get you publicly reprimanded by the FDA; how is that low severity?) But there’s a more serious problem with models of severity like this: they’re all about the system as though no person used that system. There’s no empathy or emotion here; there’s no impact on people. The descriptions don’t mention the victims of the problem, and they certainly don’t identify consequences for the business. What would happen if we thought of those categories a little differently?

Critical: The bug will cause so much harm or loss that customers will sue us, regulators will launch a probe of our management, newspapers will run a front-page story about us, and comedians will talk about us on late night talk shows. Our company will spend buckets of money on lawyers, public relations, and technical support to try to keep the company afloat. Many capable people will leave voluntarily without even looking for a new job. Lots of people will get laid off. Or, the bug blocks testing such that we could miss problems of this magnitude; go back to the beginning of this paragraph.

High: The bug will cause loss, harm, or deep annoyance and inconvenience to our customers, prompting them to flood the technical support phones, overwhelm the online chat team, return the product demanding their money back, and buy the competitor’s product. And they’ll complain loudly on Twitter. The newspaper story will make it to the front page of the business section, and our product will be used for a gag in Dilbert. Sales will take a hit and revenue will fall. The Technical Support department will hold a grudge against Development and Product Management for years. And our best workers won’t leave right away, but they’ll be sufficiently demoralized to start shopping their résumés around.

Medium: The bug will cause our customers to be frustrated or impatient, and to lose faith in our product such that they won’t necessarily call or write, but they won’t be back for the next version. Most won’t initiate a tweet about us, but they’ll eagerly retweet someone else’s. Or, the bug will annoy the CEO’s daughter, whereupon the CEO will pay an uncomfortable visit to the development group. People won’t leave the company, but they’ll be demotivated and call in sick more often. Tech support will handle an increased number of calls. Meanwhile, the testers will have—with the best of intentions—taken time to investigate and report the bug, such that other, more serious bugs will be missed (see “High” and “Critical” above). And a few months later, some middle manager will ask, uncomprehendingly, “Why didn’t you find that bug?”

Low: The bug is visible; it makes our customers laugh at us because it makes our managers, programmers, and testers look incompetent and sloppy—and it causes our customers to suspect deeper problems. Even people inside the company will tease others about the problem via grafitti in the stalls in the washroom (written with a non-washable Sharpie). Again, the testers will have spent some time on investigation and reporting, and again test coverage will suffer.

Of course, one really great way to avoid many of these kinds of problems is to focus on diligent craftsmanship supported by scrupulous testing. But when it comes to that discussion in that triage meeting, let’s consider the impact on real customers, on the real people in our company, and on our own reputations.