You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

All posts tagged Bug Reports

 

Testing Isn’t Always Easy…

Once upon a time, in a testing lab far, far away was a young tester who sat each and every day testing his company’s apps.

(For the sake of argument) let’s call our tester Bill.

Bill was young and relatively new and had been assigned what he thought was the most repetitive and boring of all test plans.

However, Bill was not deterred and each day he would start anew and add every single problem, flaw, defect or bug in function, UI, UX, Load, Stress or against spec he could find to the company bug tracking system.

Bill’s greatest joy was adding these bugs to the bug tracking system and assigning severity. As Bill was still learning his job he was concerned not every bug would be fixed and so he marked each and every one as “critical”.

Bill Learns A Tough Testing Lesson…

After several days Bill was drinking his coffee and thinking how many times the Developers had come running over to talk to him about his bugs and strangely how many times they left with a grumpy look on their faces after claiming the bug was a feature, or worked according to spec, wasn’t critical at all or simply only happened under the rarest of conditions.

Bill was a little confused and didn’t really understand the negativity about his bugs or their severity.

Just then, Bill’s boss, the QA Manager walked in, gave him a big smile and sat down with his double espresso opposite Bill.

“So Bill, I hear you’ve been keeping our Developers busy with lots of bugs, right?” Bill’s boss gave him a huge grin.

“I guess so…” Bill replied.

“Well, I wanted to talk to you about the fact that I’m pleased that you are so dedicated and I know the bugs are all important but are they really all critical?”

Bill thought about this for a moment.

“How do I know?”

Bill’s boss sipped his espresso, “Well Bill, ask yourself what does the bug do to the App, to the user or to the system it’s running on. Once you look at the impact you can get a better idea of severity. Do you know why I’m telling you this?”

“Umm” Bill scratched his head, puzzled.

Bill’s boss put his finished espresso down, “If we mark every bug as critical then the Developers won’t take the really critical bugs seriously because we overused the definition and made them drop new work to fix some bugs that could wait. Luckily the Product Owner and I discuss the bugs and he sets priority with the R&D Manager but we need to check the spec to be sure if something is a bug or not as well… You know the story of the boy who cried Wolf right Bill?”

Bill nodded.

“As you get more experience you’ll learn not to be the boy who cries bug and be more confident about what severity each bug is. Today we are going to test together and see whether we agree on each bug or its severity. Let’s see how the Developers respond to that.”

From that day Bill worked harder than ever to learn what was and wasn’t a bug and to report each bug with the right severity. The QA Manager continued to be happy with Bill’s work, even had Bill train new testers and the Developers would treat each bug reported by Bill with seriousness.

… and they all worked happily ever after.

The Warptest POV

Learning how to write bug reports other than the uncompromising brevity derived from using Twitter also involves knowing if your observation is truly a bug and how to define its severity.

So the next time you are about to hit save on that bug, think of Bill and just review what you are reporting.

(This Grim tale is based on past, real life events. Names have been changed to protect the innocent).

 

What Can Twitter Possibly Teach Testers?

When working with testers who are still learning (all of us, right?), one of the challenges is finding a common language between testers and with Developers. This came up today and sparked this post:

This is especially important when it comes to writing test cases and reporting bugs.

In an age of “You had me at …” it’s crucial to get the point across rapidly and efficiently without compromising the information.

So.. Twitter Huh?

Twitter with its 140 character restriction on tweets is a natural teaching tool for anyone who needs to learn the discipline of brevity.

Twitter logo - testers

The thing is when reporting a bug it’s important to remember that you are imparting a story; a story that allows the Developer to know what should be fixed and under what scenario(s).

Imagine an ALM that was built on Twitter functionality: –

  • User stories, spec, test cases and bug reports all limited to 140 characters
  • Hashtags to make all of the above searchable by keywords.
  • Groups and Lists based on teams (e.g. QA, Dev, Product, Sales) and team members with usernames prefixed by the Twitter @.
  • Retweet, favorite or Direct Message (DM) other users.
  • Attachable images and URL shortening.
  • Trending subjects based on traffic within the ALM.
  • Analytics (of course).

The Warptest POV

As you read this keep one eye on the Agile Manifesto and see how Twitter Teaches Testers in an Agile manner. If you don’t see it, then it’s time to reread the manifesto:

agile manifesto - testers

The beauty of this method is not just the brevity but the rapid manner that it allows your testing to progress as everyone gets onboard with this manner of communication.

Obviously, there are exceptions, intricate or complex issues that require greater detail but the rule of thumb is,

“If you can’t sum up your bug or test case in 140 characters then it might be more than one issue.”

Does this speak to you? Feel free to offer your own experiences and ideas on the subject.