A bug template to make everyone's life better

For logging a bug, the format that the data is in makes a huge difference in how fast someone can understand the problem.

This bug template has been created by iterative refinement via many many people across at least 5 companies.

Bug title:

[Area]: [operation] [causes/impacts] [type of failure (exception, log message)]

Bug body:

Environment (internal, cloud, local – add credentials if necessary)

-

Pre-Conditions

-

Steps to reproduce

-

Bug Description

-

Notes (Expected results, Workarounds, points of interest)

-

I hope that this gets used, and adopted and changed to make your life better.

Scrum testing - Is it a bug? Is the story "done"?

Someone on my team mentioned "I’m on the fence about some of the bugs I found today.[...]"

I immediately fired off the following questions:

Will an administrator be confused by this data?

Will it generate a support call?

Does it meet the greater goal of the feature?

I think these are useful, especially when evaluating a scrum story. 

What do you ask specific to scrum testing?

why do we ask the wrong questions?

Why do we ask does it work? let's be honest, we don't want to know "does it work" we want to know "will it work for me, to do what I want it to do?"

When someone goes to buy a used car, the first question is usually "does it run?" or "does it work?". When I buy a car, what I want to know is "will it work tomorrow?" and will it work on Friday, and will it break down when I get to Quebec and strand me in -30 weather in a province where all mechanics speak french, and I don't?
So, Why don't we ask the questions we care about?
Have we been trained by too many engineers or car salesmen that answered "I don't know if it will work tomorrow. The world might end at midnight tonight for all I know!" Is it because we inherited from our great great grandparents the thought that we are buying a horse, and it's been trained to do certain things, so a valid question is "does it know how to pull a cart?" Is it because we are unaware of our real desires and can't articulate what is actually important?

I propose that we start asking the questions that we actually care about. Questions like "Will it work for me?", "will it work for customer XYZ who uses Windows 2008", "will it run tomorrow? How do you know?"

-Joseph-

I'm reading at article I saw posted:
http://gigaom.com/collaboration/5-ways-to-keep-your-rockstar-employees-happy/
And they wrote:
"Yet earlier this year, when Google interviewed its employees about what they valued most at work, none of these extravagant benefits made the top of the list. Neither did salary. Instead, employees cited access to “even-keeled bosses who made time for one-on-one meetings, who helped people puzzle through problems by asking questions, not dictating answers, and who took an interest in employees’ lives and careers.”

My question is, How do we convince the people that have held one or two jobs since graduating that they don't need more money? They are the ones that have had a first success, and are now far too expensive relative to their experience to hire. Do we hire them at the high salary, with silly benefits and just take that as the cost to hire, Knowing that that the benefits won't keep people engaged, it will just get their attention in the first place?

Pitfalls of exploratory testing

Exploratory testing is hard... if the product is difficult to use

1.
A product or feature with many days worth of nitpicky bugs could be "at risk" because a tester might be distracted by all the easy bugs and not spot a workflow (usecase) that is important.

2.
Features that are hard to use or configure might get missed. Consider a product with 10 major features, and 9 of them take 1 day to configure and get real data back from. The 10th requires 10 days to configure (it requires the sum of all other features to work) plus another day to collect data. In this case the testing is probably going to be interrupted (a customer escalation, a project date boundary, etc.), making it easy to forget to come back to feature #10.

Here are some ideas to mitigate these risks, do you have others?
-Use written testcases for these features. (Might be hard to know that you will hit problem 1 ahead of time)
-Do use case based testing, and track your results by use case instead of by program feature. (I want to try this idea on my current project, but have not yet)
-Put the best most "bloodhound" minded tester on that one problem area, and assume that they are up to the challenge.

Empathy and Software Testing

I will start this blog with my thought I had at the end of a long day at CAST .

System testing is the task of melding Empathy with Intellect.

As a system tester you must be able to actually think they are the customer or stakeholder. Finding intelligent people in the software engineering world is easy. Finding socially empathetic intelligent people that want to test software, is hard.