Writing the perfect bug title

Often the bug title is easily overlooked as simply a necessary way of separating your bug from another bug, but hold on as you are missing a great opportunity to make your bug great. If you write a good bug title another tester or QA engineer should have a very good idea exactly what the issue is, how severe of an issue it may be and how likely they are to truly value your bug.

So let’s get down to the task of defining a good bug title. The title should be as concise as possible but contain all of the necessary information. Ask yourself what is the actual bug (tip: this is often not the result of the bug!) and put this information first. You also want to include some location information so another user can locate your issue. Finally, add any additional information to support your bug.

So if we use this approach with a real bug we get something like this:

[Issue] Location / additional information

[Broken button] Buy now button on summer savings page / Error #123 displayed.

[Crash] Sort menu / App crashes while opening the menu

[Infinite loading] Video on “know our product” page / When trying to play the video

Now go forth and make your bug titles as good as they can be!

Content bug rules have changed

We changed the rules regarding Content Bugs.
A detailed description can be found here.

Changed was for example:

  • Content bugs are not in Scope of any tests any more, as long as not explicitly requested in the test description, by the customer.
  • There is no 5 content bug rule any more
  • Reproductions of broken links are not of interest and will be rejected

Please take a good look at the changes, so all of your bugs can still be accepted in the future.

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 🙂

Update 01/2016

We hope you had a successful start to the new year!

With the new year we would like to announce some changes that will affect your testing and bug reports.

We will also provide some tips to improve your testing experience with us and answer some of the frequently asked questions from our tester support team.

Important changes

  • Screencasts
    These will only be accepted as .mp4 files. Please make sure that your screencast can be played with Firefox & Chrome!
    (We had several issues with other formats in the past)
  • Your screencast should only show the reported bug +/- 10 seconds – try to avoid screencasts that are longer than 1 minute.

    Note: Video converter tools can create not playable/usable videos!

    You can find a selection of tools that creates a .mp4 video directly here:
  • Tip:
    Screenshots are the best as PNG files. Make sure that your screenshot contains the bug highlighted. It’s easier to review and accept these bugs for our team leaders and customers.

Other changes / bug fixes

  • Bugs can’t be deleted anymore after they were reviewed by our team leaders.
  • You shouldn’t see already finished testcycles in your tester interface anymore.
  • The amount of testcase executions per tester is set to 1 per default.
  • Issues with uploading attachments should be fixed.
  • We’ve added new tablets & smartphone devices to the devices list.

Answer to frequently asked questions

Recover your password as a tester

That’s it for now – we hope this article helps you with your daily testing.

test IO – Community Team

New stuff for testers – reproducing bugs

We’ve implemented a new exciting feature!!

Reproduction of Bugs

Bildschirmfoto 2015-09-17 um 16.41.50

If you’re able to reproduce the bug of other testers, you can submit this in the bugdetails of the bug.

  • up to 10 reproductions per bug
  • 10% of the original bug payout per reproduction (max 0,50€)
  • You can’t reproduce your own bugs (by now)
  • You can’t reproduce rejected or customer accepted bugs
  • The final payout will be triggered with the acceptance/rejection of the original bug
  • Good opportunity to earn some extra payout for fresh testers and experienced / fast testers too.

If you have questions ask them here.

We hope you like the new feature!



In the following pages you will find everything you need to be a successfull tester with testcloud.

All rules and hints are listed on these pages.

We may edit some parts or add some content here and there but the main aspects should be covered.

We hope you enjoy our new academy!

Your test.io team!