What is a defect?
What exactly is a defect? In the context of software systems and software projects, any application where the result requirement that was supposed to be there, but is missing is considered as a defect. An incorrect requirement can also become a defect. Or when there is something on the site that is not supposed to be there, also becomes a defect.
From QA engineer point of view, any kind of enhancement suggestions that a QA has to make in order to improve the system is called as defect or bug.
A lot of times, the missing, incorrect, or extra requirement are things that do not require a lot of explanation or are pretty clear from the beginning. Defects do not necessarily mean that something is wrong with only the application. Beginners usually have trouble identifying bugs because they are under the impression that if it is a defect there will be something very obvious about it, like the page will not be found out; the link gets broken; or something like that. But that is not always the case. In fact, the best effects are the ones that are hard to see and are not so obvious.
Writing an effective software defect report-guideline:
Before starting off, make sure that the defect you found is indeed a valid defect. It is a good idea to have a very thorough understanding of the requirements so that a QA engineer will be able to make informed and educated decision on whether or not a certain behaviour can be construed as a defect.
Some of the important features of an effective software defect report shall be:
Defect ID: Defect ID should ideally be serial numbered because when it comes to defects, it does not matter what module they are in or what feature they have.
Defect Title: Defect title is basically like a description or a one-line definition of what the problem is. Hence, try to fit your problem or the description of your bug in about a line or so. Give a concise title to your defect because title reflects the gist of what exactly is happening here. Make sure that it is not ambiguous and defining the problem clearly.
Severity of the problem: Based on the severity of the problem, you should rank the defect or bug as critical, subtle, major, minor, or trivial. You can also set the priority/severity of the bug from 1 to 5 so that most critical or important ones are corrected first.
Defect Description: As for the defect description, it should also be clear, concise and detailed. Avoid making vague or ambiguous statements. For instance, the description "home page not working" seems incomplete and incomprehensible. While writing the problem in your defect report, it is always a good idea to make sure that you exactly explain what the problem is. "Homepage not working" is a very vague statement and nobody can say exactly what is happening. So, instead of that, you can report like this: "Homepage when clicked at this place of page cannot be found". Always take your time to actually find the right words to describe the problem that you are encountering.
Platform: Mention the Browser configuration and operating system because it will help the developers to amend the defect in the same environment in which QA engineer has tested it. So, it is advisable to mention your test environment in detail.
Steps to reproduce: This is where you will go ahead and give a list of all the activities and the sequence of steps that you have performed on the software/system and that has led you to this particular bug. Try to write it in the form of how you would normally write your test case. This portion has to be instruction based and when it comes to a defect report one general principle to be followed is that the more information you provide the better it would be.
Expected vs actual results: Your software defect should clearly reflect the expected results of testing versus the actual results. It should outline the results that ought to be as compared to the ones that are actually happening.
Attach the screenshot: Screenshot shall give more clarity to the bug/defect you are reporting about. Give a specific name to your screenshot, so that if the developer saves it onto the desktop, they will not have trouble finding them.
Conclusion:
We always tend to think that communication stops at being able to talk well, compose an email or to do some presentation well- but communication actually starts when you are trying to send an information to another team and defect report is one of the most critical of all. Why? Because you will be sharing information or data with an external team, So, make sure that when you're providing the information with the exact intent and are using your words accurately. Do not ever send a bug report that has less information than necessary. That is why QA engineers or people associated with QA field need excellent communication skills.
