Signatory Bug Report Made Easy

Esign bug report

hi everyone this is swathi from software testing health.com team and today we are back with another how-to kind of a series on how to create a defect report now before we get there let's talk about what exactly is a defect since we are talking about the defect report in the context of software systems and software projects any application where the result requirement that was supposed to be there and that's missing we can consider that as a defect when there is an incorrect requirement that also becomes a defect when there is something on the site that is not supposed to be there that wasn't meant to be there but it's right it is it exists that also becomes AB defect any kind of enhancement suggestions that a tester has to make this is the right medium to go ahead and you know raise a red flag and say hey this is what I think will make the system better you may or may not want to take an action on that environment outages or any problems with the you know environment followed by documentation related errors now a lot of times I mean the missing incorrect extra requirement are things that you know do not require a lot of explanation that are pretty clear from the beginning but it's usually the things like you know how come an environment outage becomes a defect how come a documentation related problem becomes a defect now one thing that we have to really understand is defects doesn't do not necessarily mean that you know something is wrong with only the application now if something is wrong with the application yes that clearly is a defect but that was not have to be the only situation defect is a way for the QA code team so its defects is a privilege that the QA team has to raise a red flag and say some work here needs to be done a lot of times beginners have trouble identifying bugs because they are under the impression that if it is a defect there will be something very obvious like you know the page will not be found out the link gets broken or you know something that is very very clear for us to discern but that does not have to be so defects are in fact the best effects are the ones that are subtle hard to see then a kind are not so obvious so I'm going to first show you what a very you know not the normal you know page not found that kind of errors just probably sell you know much more subtle defects I'm going to show you that so we are going to first go through and create the process of encountering a defect once we encounter the defect we'll also talk about how to create the defect report that means how to lock that defect in there and I will also show you because defect management is usually carried out with the help of a tool so I will show you if you were to create a defect report in a tool like bugzilla how would you do so so that is what we will do right now yeah but before that you before you create a bug it's a good idea to make sure that you know that defect is indeed a valid defect that means it's a good idea to have a very thorough understanding of the requirements so that a tester will be able to make informed decision you know an educated decision on whether or not a certain behavior can be construed as a defect or not and there are other things that we'll talk about about the defect report as we go forward so let me actually first go ahead and create a defect you know show you how to encounter a defect now for that I'm going to use an application called open EMR and open EMR is actually an open source product that is you know that is actually that facilitates hospitals to you know do some hospital management again it does not matter what application is it this is what I'm going to use as an example today but if you want to like you know and try this tool more just do a Google search open your mind and you'll find all the content and you know instructions to download it so what I'm going to do now is I'm going to show you how to create a new patient so this is basically a system patients and doctors hospital staff they all interact they have they can set up appointments and you know they can actually follow up on the appointments if following the appointment they can actually make a record of you know all the statistics that were collected during the appointment and things like that so long story short we'll just create a new patient and what I'm going to do you do right here is I am going to create a patient and then for the date of birth I am going to create today's state and choose today state and all I'm going to do is I'm going to edit this to take like February 31st which is a date that does not exist or 0-0 31st for that matter that's a date that does not exist so I'll go ahead and now create a new patient with this particular statistics so what is supposed to happen is either the system should prompt us that you know either the system should prompt us that the date zero is incorrect or it should you know you know it should just let us know that or it should not allow us to actually type into the database date of birth field but none of that is happening the date of birth it takes it it creates a user and it says it's two months old so neither of them is right so I'm thinking the zero zero is assuming this appeared to be January but nonetheless it's not the right way the system should behave now when you look at this this is a very very subtle bug this is not something that is like you know very obvious it's not causing any disruption but it's also a bug at the same time so let's go ahead and create this issue or log this issue in a bug report now bug reports typically should have like a template like all QA artifacts too so bug report template it starts with a defect ID then we go on to creating the defect title steps to reproduce severity and then a screenshot now defect ID is usually serial number most often in most projects we always recommend it to be serial number now the logic behind using a serial number as a defect idea is when it comes to defects it does not matter what module they are in or you know what feature they are in it really does not make a lot of sense because defects are defects no matter where you find it it's a good idea to address them their work to be done so it's the simpler the defect idea the better so defect IDs are usually serial numbers defect title is basically like a description or you know a one-line definition of what the problem is so here you know try to fit your problem you know in would try to fit you know the description of your bug in about a line or so so try to give it a concise title so this is like you know you're giving the gist of what exactly is happening here so the different title for our defect is new patient creation accepts invalid date for the TOB field and the date that we have chosen is 2015 zero zero and 31 so this is actually you know the defect description again you know take your time with that make sure that it is not ambiguous make sure that it is not ambiguous make sure that it is defining the problem now a lot of times I see definitions like this your patient creation takes wrong data so again this is also okay to a certain extent sometimes what happens is I see something like this home page not working now I mean it's understandable that in a defect report you are trying to report a problem but it's a good idea to make sure that you exactly explain what the problem is see homepage not working is a very vague is very ambiguous nobody can say exactly what's happening so instead of probably you can say homepage when clicked this place of page not found so that is much more you know descriptive of the problem unambiguous and there is not a lot of I mean not a lot of information that is left to imagination so take your time with this try to actually find the right words to describe the problem that you're encountering accurately next coming two steps to reproduce this is where you will go ahead and give a list of all the activities that are you know all the sequence of steps that you have performed on the 80 that has led you to this particular bug so steps to reproduce again try to write it in the form of how you would normally write your test case steps again this have to be instruction based and when it comes to a defect report one general principle that is advice to be followed is that the more information you provide the better now you must have heard this a lot of times on how QA QA is or you know people who are in the QA field need excellent communication and we always tend to think that communication stops at being able to talk well or being able to compose an email well or you know being able to do some presentation well but communication starts when you are trying to send an information to another team and defect report is one of the most critical you know data that you will share with an external team for example the development team so make sure that when you're providing the information you're communicating the exact intent and you're communicating you know and also make sure that you are at least over communicating and not under communicating so do not ever send a bug report that has less information than necessary so go ahead and start with the absolute first step so this is open iam our launch it and second step is login as so if there is any data that you have provided be sure to provide the user ID and password because sometimes even though we assume that developers might know all their log login credentials since testing usually happens in the QA environment they might not always know that you know what credentials have been used and here click on new patient enter the following details from the calendar and edited it to by typing in the field so after this go ahead and mention what you've expected now after this step we have actually clicked on create new patient and confirm new patient and now what is it that we have expected either an error message or a non editable DOB field would have prevented the creation of a user of a patient with invalid date that's what you are expecting and what is actually happening the patient is created and the age is showing to be two months right so that is what you are expecting and that is what is happening so make sure that you're providing all the information and coming to severity severity is a field that is normally present in your defect report to denote how serious the problem is so it's something that will you know try to give us an indication of how critical the problem is now again as is a general rule with any template if you just leave it up to people leave it up to your team members and say just assign a severity value somebody might say this is you know detrimental somebody might say this is just ezm in not a big deal so you will never get a you know a uniform a uniform sort of you know assigning of severity value when this kind of information is left to the you know left to the choice of the user so certain guidelines have to be created on how to assign the severity value and those guidelines are things that you will find in your test plan document now this is something that I typically use now please keep in mind that this might not be the case for all you know this might not be the exact same thing that is used for all projects now let's look at the definition so if if I have to say that the bug is critical the bug has to be critical enough to crash the system or cause an abnormal return or the application to Hank so none of that is happening and number two it causes a lack of vital functionality with workaround that's not happening either so this bug will degrade the quality of the system however there is an intelligent workaround this prevents other areas of the product from being tested that's not it either there's an insufficient or unclear error message which has minimum impact on product use that may be right so there is an insufficient or unclear error message that has no impact on product use now see right now if a patient is created with an invalid date of birth it will affect the age of the patient which means if the doctor has to if a doctor assignment has to happen like you know if you know like for people who are less than 13 years of age if they are assigned a pediatrician now for when you when you assign an I mean when a patient is created with an invalid date of birth all of these things might get affected so I would say it's a low impact but then you know some some times in the class I've had you know students argue that it could be cosmetic now try to go with a definition you know try to find the severity value that you feel as a tester is right and you know that defines the problem to the correct extent so again there might be differences of opinion but you know whatever you feel so use your judgment as a tester and try to assign a value that it is that is as close to being accurate as possible and then go ahead and try and assign a screenshot so what I would do here is this is the part I would want to highlight so I just print the screen normally I would attach it to a Word document and then I will attach it to the bug one best practice the reason I mean I'm sure you all know how to create a screenshot but the reason why I'm showing this part is another thing that I recommend doing is try to give it an appropriate you don't name so that you know if the developer saves it onto the desktop they will not have trouble finding them so if you keep it a gendered name like untitled or you know new document it might you know probably not be you know not make a lot of logical sense so try to give a name that it is there is a profit so go ahead and attach that to your screenshot document so let's assume that this is the problem I mean this is the bug I'm just going to attach that as a screenshot so now I have created a bug report now status is a column that will be added once the bug report you know goes out and the bug life cycle is followed by bug life cycle is for another section we will treat that in another segment another few guidelines that you will have to follow before you log the bug is that as I said make sure that you understand the bug correctly you understand the system behavior correctly and if you need any help please always say clarification either from your team members or your team lead or from the business analyst or from the development team make sure that the all the steps are there and make sure that all the data and all the steps are a correct and once you have this defect report then you you can actually you know you can use the status column to track both the ownership and the actual work that is being carried out but this is basically how you create a very very simple bug and you know eventually when all the bugs get added the cumulative document is then called the bug report now coming to Bugzilla will show you how to create the same bug how to create the same bug report in Bugzilla so the option that you would use is file a bug you will pick a product that is the project under which this is going then you would choose a component that's like you know the sub modules and all so you would choose a similarity so as the severity as you can see typical values that you will be our following are seen here although you know there might be a difference and this that's because this this kind of fields are completely customizable by the administrator so choose like I'm going to choose trivial because it's very simple use the summary column for the defect title use the comments column for the steps to reproduce use the attachment to upload a screenshot document and when you provide the description provide an appropriate name and you submit a bug the bug ID gets automatically created and that also is a you know serial number so that is how a simple bug report can be created I hope this session has been useful to you all and also one more time I reiterate when you're giving out information from the QA team's perspective give generously make sure that you include everything make sure that you're accurate you do a spell check on your defect report like you would on any other QA artifact because a document that contains spelling and grammar and you know small inconsistence issues that we do not care enough about our work which is not which is not true at all so do your due diligence to the extent possible and communicate clearly communicate articulately make sure that you know the other team does not have to get back to us just because they need some information because you know that will be a waste of time waste of effort for everybody so defect reports are pretty much you know a day to day activity of a testers job and we really sincerely hope I sincerely hope that this session has helped you at least a little bit with the process as always please let you know let us know your comments and questions in the you know comments below thank you all for being here thanks