DevelopsenseLogo

Problem, Example, Oracle: A Quick Checklist for Bug Reports

Our principal job as testers is to discover the actual status of the product. Remember: everyone else on the project is focused on Success, Preventing Problems, Building Quality In, Adding Value, and all that. Those are all good things, and there’s nothing wrong with them. But there is a catch. The optimistic focus required to build the product can direct people’s attention away from problems that threaten its quality and … Read more

Talking About Coverage

A while back I wrote a post on coverage. In fact, I’ve written a few posts about coverage, but I’m talking about this one. A question came up recently on LinkedIn that helped me to realize I had left out something important. In that post, referring to coverage as “the proportion of the product that has been tested”, I said A software product is not a static, tangible thing; it’s a … Read more

When Management Asks “Why Didn’t You Find That Bug?”

A tester asks… How do we handle production bugs? When management asks “Did you test this?”. how do I respond? When management asks “Why didn’t you find that bug?”, the first step is to accept in your own mind responsibility for looking for bugs, but not a commitment to finding every bug. The latter is a great aspiration, but an unreasonable commitment, and management shouldn’t be holding you to it. … Read more

Expected Results

Klára Jánová is a dedicated tester who studies and practices and advocates Rapid Software Testing. Recently, on LinkedIn, she said: I might EXPECT something to happen. But that doesn’t necessarily mean that I WANT IT/DESIRE for IT to happen. I even may want it to happen, but it not happening doesn’t have to automatically mean that there’s a problem. The point of this post: no more “expected results” in the … Read more

Breaking the Test Case Addiction (Part 10)

This post serves two purposes. It is yet another installation in The Series That Ate My Blog; and it’s a kind of personal exploration of work in progress on the Rapid Software Testing Guide to Test Reporting. Your feedback and questions on this post will help to inform the second project, so I welcome your comments. As a tester, your mission is to evaluate the product and report on its … Read more

Breaking the Test Case Addiction (Part 8)

Throughout this series, we’ve been looking at an an alternative to artifact-based approaches to performing and accounting for testing: an activity-based approach. Frieda, my coaching client, and I had been discussing how to manage testing without dependence on formalized, scripted, procedural test cases. Part of any approach to making work accountable is communication between a manager or test lead and the person who had done the work. In session-based test … Read more

Breaking the Test Case Addiction (Part 7)

Throughout this series, we’ve been looking at an an alternative to artifact-based approaches to testing: an activity-based approach. In the previous post, we looked at a kind of scenario testing, using a one-page sheet to guide a tester through a session of testing. The one-pager replaces explicit, formal, procedure test cases with a theme and a set of test ideas, a set of guidelines, or a checklist. The charter helps … Read more

I Represent the User! And We All Do

As a tester, I try to represent the interests of users. Saying the user, in the singular, feels like a trap to me. There are usually lots of users, and they tend to have diverse and sometimes competing interests. I’d like to represent and highlight the interests of users that might have been forgotten or overlooked. There’s another trap, though. As Cem Kaner has pointed out, it’s worth remembering that … Read more

Very Short Blog Posts (35): Make Things Visible

I hear a lot from testers who discover problems late in development, and who get grief for bringing them up. On one level, the complaints are baseless, like holding an investigate journalist responsible for a corrupt government. On the other hand, there’s a way for testers to anticipate bad news and reduce the surprises. Try producing a product coverage outline and a risk list. A product coverage outline is an … Read more

Very Short Blog Posts (33): Insufficient Information and Insufficient Time

Here’s a question I get from testers quite a lot: “What do I do when the developers give me something to test with insufficient information and time to test it?” Here’s my quick answer: test it. Here’s my practical answer: test it with whatever time and information you have available. (Testing is evaluating a product by learning about it through exploration and experimentation.) When your time is up, provide a … Read more