Quantity is not the key to success as a tester! Quality and high value bugs are!

Many testers think – quantity is the key to success as a tester.

“Delivering” bugs like a factory is of course one way to be successful at test IO but you will face several issues on your path that might be worth thinking about, before handing in so many bugs.

Here is a list of a few important points for testing with test IO:

  1. Scope of a testcycle
    >Make sure you read the scope of the test! If you accidentally miss the scope of a testcycle – your bugs will be rejected – sometimes many of them. The teamleaders will review your bug within a certain timeframe – not immediately.So before reporting many bugs – report the most important bugs to see if your understanding of the scope is correct.
  2. Duplicates within your own bugs
    > With many bugs, your chance to create duplicates rises.
    If you’re sure this bug is something different than your last reports – you’re good to go.If you report very similar bugs, the chance of rejections is pretty high – consider this before you invest your precious time.
  3. Tester Team
    > You’re part of a team while the test is running. That means, everything you do might affect the others. If you submit a trillion bugs in every testcycle, other testers may stop reporting bugs. If your bugs are then rejected it will result in a poor quality test, so remember only report bugs your are confident are new and valid!
    Customers are highly interested to receive reports from different testers, devices, browsers, set-up’s etc. So use the communication tool to talk to each other and reproduce each others bugs on different devices.

    You should concentrate on your most important or high value bugs and try to cover as many testcycles as possible.

  4. Known Bugs
    > If you’ve tested with us a few times, you may have already seen known bugs here and there.You might already have bugs rejected as known and if it was not listed on the known bug list this is OK (you still get paid), but don’t forget to check the known list before submitting a bug.

    BUT consider that our customers are not really interested to see the same bug over and over again.

    We will try to improve the testcycle description – but you can help us and the customer to avoid “Copy & Paste” reports and concentrate on new, not yet known bugs.

Practical tips:

  • concentrate on high value bugs (high & critical) rather than many low bugs
  • try to cover as many testcycles as possible
  • avoid many similar bug reports in the same testcycle
  • quality of bug reports is the most important thing – if you can report in a good quality, we and our customers will appreciate and reward it 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s