Last night when I came back from office, I saw the email from www.99tests.com about a one day contest on Android mobile. I joined the contest and observed that the max limit of bugs per tester was 15 instead of 25 (for 3 day contests). For every duplicate bug one logs, there is a -1 point. So, one has to be careful before logging bugs. And when I joined the contest, there were already 50+ bugs logged. I like to spend the initial few minutes of any contest, trying to understand the purpose of the application, the focus areas by the other testers and the validation strategy by the contest owner.
I wanted to go through every bug logged and at the same time understand the application quickly. I started with few bugs and then an idea struck me. Why not map the bugs and categorize the features too as parent nodes?
This is what I got after 25 mins:
I wanted to go through every bug logged and at the same time understand the application quickly. I started with few bugs and then an idea struck me. Why not map the bugs and categorize the features too as parent nodes?
This is what I got after 25 mins:
 |
| Mindmap of Bugs
This way, I went through every bug and still made a high level model of the entire application.
I liked it and after three hours of testing, I got the 7th position with 100% valid bugs. I logged 6 bugs.
Maybe, there is a better approach but I liked the approach of mapping out the bugs before testing. What do you think? Do you have a better way?
|
2 comments:
Great idea! I'm really visual, so graphics & maps help me a lot more than reading a list of bug descriptions. Nice!
One question -
By the time you go through the entire bug list, few more bugs would have been raised. So, do you think this is the right approach?
Post a Comment