QA Checklist: Best Ideas for Bug Hunting Process

We have already talked about the software testing levels, their role, and specifics. However, we skipped the part, where we explained how to perform them. There are at least two reasons to do so.

First of all, it is impossible to describe such a complex process in detail. Moreover, there are dozens of various “How to” tutorials.

Secondly, here, at Incora, we highly believe that there is no ultimate testing solution or strategy, that will be effective in each case. Additionally, we assume that it is important not only to consider the context of each project but to be creative, and find unordinary approaches to each of them. Thus, instead of the common and general tutorial, we prefer to share our experiences and some of the principles we relate to.

Finally, Bug is not only working issues or crashes. It is worth understanding that in each situation when the actual result differs from the expected one is considered a bug, i.e. the application may work correctly, yet slightly different from the way it was supposed to.

Top Testing Practices

Bug-Free Project is a Myth!

In fact, there is probably no such software product, which has no bugs in it. Bugs are an integrant part of software development. They may change, or be fixed. Yet, it does not guarantee that the new one won’t take its place. Bug hunting and fixing is a continuous process in constantly changed circumstances.

For instance, even if we have a hypothetical mobile application, which works as was supposed to, there are no guarantees that something will go wrong after the device OS update. Alternatively, if you will attach 2 different Quality assurance team members and order them to check the app for bugs, most likely they will find diverse bugs. As was mentioned before, a bug is when the actual result differs from the expected.

Be Unpredictable as a Monkey!

Actually, the best testing approach is the one, when the tester is not working to the plan. The best way is to make random decisions and use unpredicted scenarios. Such a chaotic approach allows us to check various app elements, sometimes even those, that are less important or paid attention to.

Moreover, if testing or bug hunting process is done in a certain sequence or plans repeatedly, the application may adapt to it, not to mention that checking the same components or units all the time won’t let to find bugs in other fields.

In fact, such a chaotic testing technique has its own name. It is known as Monkey testing. During the monkey testing, testers, users, or specified software makes random inputs and interactions with the application or website, checking how it impacts the overall working processes. As a great bonus, it increases the chances to find out some additional functional bugs or issues.

Hunt as if Your Life Depends on It!

Such psychological instruction not only increases the effectiveness of the testing process but helps to deal with routine. For instance, if the tester is willing to find a bug, considering such a process as a game, it will be easier to detect bugs and will be easier to accept the fact or the number of the final results.

Remember, that testing is not about fixing bugs and issues, but about finding them. Clearly, such an approach is related only to the testing team, because their main task is to find examples of errors and imperfections, not to fix them. However, it is true that the final result highly depends on the work of the testing team.

Therefore, going beyond the requirements result in a deeper understanding of what works not as was supposed to. It is undoubtedly better to have this data during the testing stage, not receive bad feedback directly from your audience.

Prioritize Your Bugs

It is obvious yet worth mentioning that you should always prioritize your tasks, especially when it comes to the bug hunting process or their fixing. Actually, bug fixing is not a direct responsibility of testers, however, they can also take part in such processes.

The best idea is to check for crucial or large issues first, moving forward to unimportant or obscure bugs, which do not impact the overall work of an app. Such an approach allows taking your time fixing the critical problems, leaving time for minor polishing if needed. On the contrary, if you start with the less important problems, you might run out of time and delay other activities to fix everything. The same situation may occur in the case when you start working with the bugs in the same sequence as they appear because it is impossible to predict their importance as well.

However, even better to consider the sequence with your customers first. They may have their own opinion and expectations from the project. Eventually, as we stated before, most bugs are very subjective and may be considered problematic, depending on the particular person, who is responsible for testing.

Do Not Rush

Frankly, probably all of us periodically postpone a few tasks till the deadline. There is no need to explain why is it wrong. Yet, we encourage you not to rush doing your job even in such circumstances. Sometimes, it is better to be late but do the job well. As a matter of fact, a job, done in a rush will definitely have mistakes and other imperfections. Thus, probably, it will anyway result in time delays.

Share Your Experience

Do not forget to communicate with your team. To tell the truth, good communication within or between various teams may cover various issues. Clearly, it will help to work faster and more effectively. High-quality communications impact the trust level, helping to easier and faster hunt or fix bugs.

We distinguish various communication and interaction types: QA to QA, QA to Developer, or Developer to QA. Each of them improves both the experience of the team and decreases the time, spent on tasks.

Write Clear and Detailed Reports

There is no such developer, who will argue with this statement. Poor reports are a regular problem, that results in an insufficient understanding of the bug. Besides, if developers can’t understand something in the report, they may simply reject it. So, the issue won’t be solved.

In order to avoid such unpleasant situations, testers have to learn how to write the report. For instance, various companies can have their own blanks or standards for bug reports. Yet, it doesn’t actually matter whether there is such a procedure, or not. Anyway, there are some utilitarian tips, that can be used in all scenarios.

First of all, make sure your report has a unique number. It can be marked automatically by various corporate tools, or manually, depending on the working policies. In any case, you should check if there is a unique number. This helps to identify, and track the progress of the solving process, as well as to find it if needed in the future.

Secondly, be gradual. If you have spotted a bug - you are only halfway there. To write a correct report and get it fixed, you have to make sure it is possible to reproduce it. In other words, write down all the steps you have performed before spotting the bug. Therefore, it will be possible to check whether it was an accident, or a real problem, worth solving. Additionally, it allows developers to check the bug themselves to better understand or clarify the concern.

Eventually, Be specific. Clearly, it is important to describe as many important details as possible. However, no one is going to read an essay on a single possible bug. Therefore, try to be as precise as possible and avoid unneeded information. Your final report must be detailed but still easy to understand. There are two questions you must fall in love with: “How it happened?” and “Where did it happen?”.

Also, it would be a great bonus if you notice some unique specifics and perform your own research. For example, you may try to find out whether the bug is repetitive. To check it you will have to “dig into history”, i.e. review previous reports or ask your team members. Besides, awareness of the known issues can help you to avoid duplicating an existing report.

It Is not a Bug, but a Feature!

Finally, the most uncommon advice, yet the best possible excuse. You may and assumably should try to turn various bugs into features. Clearly, we are not talking about such problems, that cause incorrect working of the application. Still, remember that bug is when something WORKS but not as it was SUPPOSED to.

So, if you notice such examples, when everything goes not as it is planned, don’t hurry to change it. Try to be more creative and examine it first, gather your team and discuss it, and notice to your customer that you have found something exceptional. At first, it may seem impossible to change the problem into a solution. Yet, history tells us, that it is indeed a very spread lifehack. If you google it, you will find out, that the most successful and noticeable attributes of various products and projects were not designed at the beginning. Let’s examine just a few cases for a better illustration.

Gmail, Please Undo!

Originally, it took about 5 seconds for the system to check the mail and its content, whether there is harmful software, what is the number of letters, if there are any files, etc. Probably anyone will agree, that such a period is too long and annoying.

To cover the waiting time, developers simply added an “Undo” option. Thus, instead of performance optimization, they gave an important and very useful feature, hiding the real reason for the waiting period.

Ctrl + Alt + Delete

Originally, it wasn’t an actual bug. One of the developers added such a combination to make the developer’s life easier. It allowed force quitting of a frozen application. Yet, probably they simply forgot to remove it after testing and this iconic combination become beloved among regular users as well. Thanks to the iconic “Ctrl+Alt+Delete”, thousands of users worldwide saved their nerves, managing resource-intensive apps in no time.

Surprisingly, this approach is most favorable in the GameDev industry.

Summary

Remember, that not each bug is harmful and must be fixed. Sometimes, they can show you an out-of-box solution or some unique ideas. As people sometimes say: If life gives you lemons - make lemonade.

Nonetheless, it is worth admitting that not everyone is able to see not a problem but an opportunity. Yet, such skills can be developed over time. In fact, the more experienced the QA team is, the easier it makes such untrivial decisions.