Month: May 2015

How to Classify Bug Severity in Your Bug Reports

This is the fourth article in the series on Bug Reports. Click here to read the next article: reporting related bugs.  —————————— So you’ve found a bug – now what? Well, after you’ve documented its details, the next step is to evaluate the bug severity. While it can be summed up in one word, severity is a very integral part of the overall bug report. Get it right and the development team can allocate the appropriate amount of time and effort to each issue. Get it wrong and you risk hampering the development life cycle. Though the exact terminology may differ between organizations and projects, there are some general guidelines to follow when determining whether a bug is trivial, minor, major or critical. Trivial Trivial bugs are common and probably the easiest to identify. As a general rule, they have no real impact on the functionality of the application you’re testing. Trivial defects often come in the form of cosmetic or design errors, such as a text block exceeding its boundaries or an image out of alignment. This would be classified as minor on the bug severity scale. Minor Minor defects are a little trickier to classify. While they still should not impede an application’s […]

Posted in: Bug reports, Quality assurance testing by: CheyleneT on:

The Full Life Cycle of a Bug

Every defect or bug that’s discovered goes through a process before it can be closed. Different organizations will often have slightly different approaches, but the overall life cycle is usually similar. A number of people may be involved in the life cycle of a bug at various stages along the way. It’s important to have a clear process in place. New bugs or defects A bug can be found by anyone. The majority of defects will hopefully be uncovered by testers during development. However, some will be found by developers and some will inevitably be found by end users. The first stage is to write up a bug report. Testers and developers should understand the importance of writing clearly about what they encountered. However, if an end user reports a bug, it may require verification before it enters the database. For a defect report to be useful, it must include steps to reproduce. It’s unlikely that an end user will spend time recreating a bug and then write-up a clear bug report. There’s no harm in offering guidelines. Make it clear that a thorough bug report is more likely to result in a quick fix. In some circumstances, it might prove impossible to recreate […]

Posted in: Bug reports, Quality assurance testing by: Simon Hill on:

A/B Testing Tips To Improve Your Mobile Apps and Games

The use of A/B testing is quite widespread for web design, but it’s not really new. You may know it as split or bucket testing. However, the basic idea is the same. You try out two or more variations and see how the target audience reacts. With A/B testing, the choices are always narrowed down to two, and it has proven especially useful for honing the website user experience. It’s commonly used to find the best title for a hyperlink, because you can measure which one gets more clicks from the same amount of traffic. Nonetheless, it can also be used to work out the best placement for navigation, ad layouts and more. Can the same approach be usefully applied to improve your mobile apps and games? Yes, yes it can. However, there are some unique challenges to overcome. You have to be careful about how you do it. Advantages of using A/B testing for apps There are lots of possible benefits that can come out of A/B testing. It can tell you loads about the way people use your app or game. It produces solid statistics. You’re not asking people to give an opinion, which relies on their memory, and […]

Posted in: Mobile and video games trends, Web and software development by: Simon on:

Bug Reports: How to Write the Steps to Reproduce a Bug

This is the second article in the series on Bug Reports. Click here to read the next article of the series on the topic of: the life-cycle of a bug. ————————- As a QA tester, a bug report is one of your most important forms of communication. There is a lot of information to pack into each one, including details about the test environment, description, expected outcome and actual income. However, without providing the instructions on how recreate the issue, developers have little chance of getting to the root of the problem and fixing things. That’s why writing the steps to reproduce a bug are so crucial. For those who are new to the process, here are a few tips for effectively writing instructions on how to reproduce a bug. Know your audience Before you begin writing your bug report on how to reproduce a bug, think about who will be reading it. While developers are almost always the primary target audience, business analysts and other non-technical stakeholders may also review bug reports on certain projects. You will need to cater your language and terminology accordingly. As a general rule, avoid abbreviations and highly-technical terms without explanation when writing instructions for non-technical […]

Posted in: Bug reports, Quality assurance testing by: CheyleneT on:

How to write a good bug report?

This is the first article in the series on Bug Reports. Click here to read the next article on: Tips for Writing the Steps to Reproduce a Bug.  ——————- One of the most important skills that you need to have in your tester’s tool box is the ability to write a good bug report. Finding defects is only part of the job. If developers can’t reproduce the bugs you find, they’re going to have a very tough time fixing them. Your bug tracking software should include a number of mandatory fields to ensure that testers give a complete account of the defect they encountered. And testers should hone their descriptive skills. A good bug report contains: A descriptive title Everything starts with a title. It must be clear and descriptive so that you can get an idea of what the report is about at a glance. It also has to be clearly differentiated from all other bugs in the database. A good way to think about bug titles are to use the PAL system: [P]roblem [A]ction [L]ocation. This means that a title must answer 3 questions: 1. What is the problem? 2. What action must the user perform to trigger the problem? […]

Posted in: Bug reports, Quality assurance testing by: Simon Hill on: