This tutorial explains the Sample Bug Report Template field with examples and explanations to give you an exact idea of how to report a Bug.
Bug or Defect reports are part and parcel of a tester’s day-to-day life. We create defects, assign defects, retest fixed defects, find defect root causes, categorize defects per functionality, reference defects in our conversations, etc.
A Good defect report is one of the most important deliverables in software testing, yet it’s often written poorly.
In this guide, you’ll learn what a defect (bug) report is, how to write an effective defect (bug) report, understand each field in the report, and use a practical sample template that QA teams follow in real projects.
Whether you are a beginner tester or an experienced QA professional, this guide will help you create clear, actionable bug reports that developers can understand and fix without confusion.
Table of Contents:
What is a Sample Bug Report: All That You Need to Know
A sample bug report is an example of a filled-out form that demonstrates an actual bug report written using a general bug report form. Instead of just describing what fields are included, it is an example of what kind of information is included for fields such as the summary, steps to reproduce, expected and actual results, and so on.
Sample bug reports can be very useful for new users because they help remove any uncertainty about what a good, effective bug report looks like.
They can also be useful for veteran users as a reminder of what a good, effective bug report looks like, helping to ensure that developers get it right and fix bugs quickly and efficiently.
Let’s get started.
What is a Bug Report
A bug report is a document or log that describes a particular unexpected software defect. This document helps testers and users to communicate and reproduce defects and helps in resolving them.
This way, developers will be able to understand exactly what needs to be corrected in the application without any confusion.
A typical bug report includes key details such as a clear title, steps to reproduce the bug, expected and actual results, severity, priority, environment details, and attachments like screenshots or logs.
An effective bug report saves time, reduces back-and-forth communication, and helps teams deliver stable, high-quality software faster.
How Templates and Sample Reports Help Testers
Defect or bug report templates for software testing may contain standard information such as defect ID, summary, steps to reproduce the defect, expected results, actual results, severity, priority, and environment.
In a nutshell, it behaves like a checklist that helps testers avoid missing crucial details and ensures that all defect reports are formatted consistently.
On the other hand, a sample report is a completed copy of the template with actual or mock data representing a defect. This helps to demonstrate how each field should be populated with written information and what level of detail should be provided in the report.
Together, templates and sample reports facilitate testers in creating precise, complete, and comprehensible defect reports, avoiding confusion on the part of software developers, speeding up the process of fixing bugs, and enhancing communication and quality.
Defect (Bug) Report Template Fields Explained with Examples
Many elements go into a good bug report. In this section, we will first describe and list all of the constituent elements of a bug report and then we will follow that up with examples.
As per the industry standard, these are the constituent elements of the defect report/template:
#1) Defect ID
If you use defect tracking software, the tool generates an ID automatically. However, if you are using excel sheets or other forms of non-tool-based defect tracking, then you may have to come up with a nomenclature for descriptive identifiers.
Defect Title DO- Defect IDs have to be unique
Example: bug_1
Obviously, it is super hard to keep this unique. Unless there is some list that you only add to the end, this kind of singular numbering is not sustainable.
Defect Title DON’T- Create a somewhat flexible but complex ID mechanism
Example: bug_login_sanity_001
Manually keeping track of unique IDs is almost next to impossible but something like this example has the potential to categorize per functionality and testing stage and will expand and contract the list (to an extent.)
#2) Defect Title
This is like the headline for your bug. A succinct, one-liner that highlights the problem. Granted, this is not a newspaper or one-liner for a Netflix show that lures its audience; it is no less important.
Defect Title DO- Be clear and to the point.
Example: 404 on accessing the purchase order report page as a sales manager
While the example above may not be perfect, it is a starting point. It is clear what report is failing and with what error and who the user was.
Defect Title DON’T- Avoid too many detailed and long complex sentences
Example: Sales Manager tried to generate a list of all the purchase orders placed by users in the last 2 years filtered by purchase price and items bought and were unsuccessful because the system failed.
It is easy to discern what’s wrong with the above example – it is too wordy, it gives too much info (some may not even be pertinent), it is inconclusive if it did not work at all or the particular filtering failed and does being Sales Manager have anything to do with this failure.
#3) Defect Description
This is the “meat” or essence of our defect report. All the details, the nitty gritty, the woes, your grievances caused by the misbehaving software feature, and your hopes and dreams for the perfect functioning of the feature can all go in here.
On a serious note, the defect description contains lots more information about how the problem occurred, how it impacted what you wanted to do with the software, what action resulted in the bug, who the user was, what data was used, etc.
In order for you to add all the information, you will have to test thoroughly and narrow down the exact sequence of steps that are causing this issue.
Defect Description DO – Include as many details as you can
Example: I logged in to the order management site as a sales manager and when I clicked on the purchase order report page, it opened the page where I could choose the filter criteria.
Once I selected all the filter criteria and clicked the ‘Show Report’ button, I got a 404 error. I tried other filtering criteria with the same result. I also tried logging into the site as a non-sales manager user and I still see the issue.
As you can see, not only does this description describe the problem accurately, but it also gives additional details to the developers to narrow down what is causing the problem. It is clear that the user being a sales manager or other users do not make any difference.
It is also clear that the filtering criteria is not causing this problem. A developer reviewing this will have an easier time starting to investigate if the purchase order report might be down or unavailable for some reason.
Defect Title DON’T- Not provide enough information
Example: The purchase order report failed to generate for me at 10am this morning and I tried again at noon with the same result.
Are you thinking, who would write a defect description like that? Unfortunately, many people. If you were at the receiving end of a defect report with this defect description, would you even begin analyzing the problem or its root cause?
This description fails to convey the problem effectively and misses any actionable information that the developers can use for debugging.
#4) Steps to Reproduce
This is a composite element of a bug report because it has 3 parts:
- Steps: As the name indicates, the steps to reproduce is a step-by-step listing of the sequence of actions followed until the problem is encountered.
- Expected Results: The behavior of the system that was expected by the user.
- Actual Results: The actual behavior observed by the user.
Note: Some teams include steps to reproduce in the defect description while others have it as a different section. To avoid redundancy of information and to not overload the testers with the defect reporting activity, either step to reproduce or detailed descriptions can be used. Avoid using both.
Steps to reproduce DO- Include all setup and navigation steps
Example:
#1) Login as Sales Manager
#2) Go to the Reports page and choose Purchase Order Report
#3) Select any filter criteria
#4) Click the ‘Show Report’ button.
Expected Result: The report should show as per the criteria selected
Actual Result: 404 not found error
The above example sets the user info, lists the navigation steps, and clearly describes what was expected and what happened. Many developers find this format better than a paragraph-based defect description. When describing actual results, include the exact error messages seen.
Defect Title DON’T- Exclude any setup or navigation steps
Example:
- Select purchase price and order numbers
- Generate report.
Result: report failed
It is apparent what is missing from the above example. It neither starts at the beginning nor does it explain the intermediary steps and resulting error conclusively. Exercise caution to avoid these kinds of steps to reproduce.
#5) Environment
Context plays a critical role in testing. The same application feature might behave differently on a Windows 32-bit OS versus a Windows 64-bit OS. If the application is sensitive to OS, browser, network, etc. that information has to be included in the defect report.
Defect Title DO- Provide exact versions
Example: Operating System: Windows 10, Browser: Chrome 109.0.5414.122
For some applications, you may also have to specify devices/HW used, API versions, firmware versions, additional settings changed, etc.
Defect Title DON’T- Remove exact versions
Example: Chrome
The above example is self-explanatory on why this is not the way to go. The more accurately we provide details, the easier and quicker the debugging/troubleshooting becomes.
#6) Severity and Priority
Severity: Severity field in a bug report communicates how serious a problem is to the effective functioning of the software applications. Usually, teams define a set of predefined standards that they use along with their definitions so that the teams are clear about how to set this field.
Example Severity: The following is a limited example of what a certain team might use to rank their bugs.
#1) High or 1: Causes crash or serious user/customer data loss. No workaround for the problem.
#2) Medium or 2: Prevents users from the ability to perform the most commonly used actions. Workaround exists.
#3) Low or 3: Cosmetic problems or minor issues that don’t pertain to the critical features of the product
Priority: Priority field in a bug report communicates how quickly the bug encountered has to be fixed. Just like severity, priority is also predefined by the team so there is no confusion about setting this field appropriately.
Example Priority: The following is a limited example of what a certain team might use to schedule their bugs for fixing:
#1) Urgent, P1: It need to be fixed immediately.
#2) Medium Priority, P2: Can wait but needs to be fixed fairly quickly.
#3) Low Priority, P3: Not so urgent, could be deferred and addressed later.
Severity and Priority are related but there are some key differences and nuances to deeply understanding the defect ranking mechanism.
=> Click here to read more on Defect Severity and Priority
Defect Title DO- Assess the bug deeply before setting Severity or Priority
Example: 404 error for the report (Severity= High, Priority= Medium)
In the above example, the severity is high but it’s not super urgent to fix it because the report is only accessed by the sales managers, so not a lot of people are impacted. However, it is severe (high) because there is no workaround for managers who need to access the report.
Defect Title DON’T- Rank Severity or Priority just to get the developers’s attention
Example: 404 error for the report (Severity= High, Priority= P1, Urgent)
If you have just set the priority of this bug as P1 just to get someone to work on it quickly, then this field loses all meaning because then we will have to log all bugs as P1s. So rely on data and evidence to get things to be addressed and not bump up the priority falsely.
#7) Evidence
A picture is worth a thousand words. A short video or a quick screen capture can convey the exact problem and its seriousness. It is especially important to capture those bugs that aren’t always consistently reproducible. We have evidence that the bug has occurred even though we may not always know what to do to recreate it.
Defect Title DO- Add clear images and short videos(if need to be) with annotations
Example:
Not only does this screenshot highlight the problem, it shows the user who encountered this error, the URL, and the exact error message seen
Defect Title DON’T- Add low-quality images/videos or add too many screenshots
Example:
As you can see, all the critical information that the developers might need to troubleshoot is missing. Except for the error message, nothing else is useful information for the developers. Avoid this pitfall.
=> Check out our list for a good screen capture tool
#8) Other Fields
Defects are not static. They don’t just get reported and stay in one state. Nor do they just get all lumped into one obscure group. We need a way to track history (who reported an issue, who updated it, who is going to fix it, etc.) We also need a way to understand what business areas/functionalities this bug affects(functional area, module, business area, etc.)
Therefore, defects can and do have the following additional data fields:
- Reported by
- Date Reported
- Assigned to
- Status
- Module/Business Area
These fields aid in tracking the defect through its various stages and statuses so we can easily keep it up to date. This entire process is also referred to as a bug or defect life cycle. Large-scale teams use different kinds of defect management software to make this process easier and more efficient.
Some examples include:
- JIRA
- Bugzilla
- TestRail
- Micro Focus ALM
- IBM Rational ClearQuest
For a quick refresher on the defect life cycle and defect management tools, follow these links:
=>Defect Tracking Tools Of 2023
Sample Bug/Defect Template with Example
Below is an example of all the fields and their example values for quick reference. If using a bug tracking tool, the fields will be the same except they are filled out on the tool defect submission page.
| Defect ID | D_AppXYZ_Module1_001 |
| Defect Title | Manager Dashboard is not allowing adding newly reports types- history, work completion trends |
| Defect Description/Steps to reproduce | 1. Login in as a manager (include manager credentials only if not confidential) 2. Click on the dashboard 3. Click on + icon to add a new report 4. Select History/Work completion report trends report type 5. Click “Add to dashboard button” |
| Expected Result | The new report should add and the manager should be able to view it on the dashboard |
| Actual Result | An error with the message “No report exists with that name” error message shows |
| Evidence/attachment | < Add image or a word doc with multiple images showing sequence of steps or a quick/short video > |
| Severity | High |
| Priority | Medium |
| Module affected | Dashboards and Manager reporting |
| Environment | FireFox version 32.4 |
| Reported by | Tester XYZ |
| Reported on | 03-02-2023 |
| Status | New |
| Assigned To | Developer ABC |
There, it’s that easy!
Conclusion
We hope this article provides a detailed refresher for experienced testers and acts as a detailed tutorial/elaborate example for new testers. Defect/bug reporting is an important life skill for testers and should be cultivated for long-term professional success.
Good bug reports lead to smooth communication between developers and testers.
Suggested Reading => How To Write A Good Bug Report? Tips And Tricks
Research Process:
- This topic was researched by examining how testers actually report bugs, rather than just how it is done in theory. Commonly used defect report formats, which are used in tools like JIRA and Bugzilla, have also been reviewed, and actual sample reports have been used to understand which fields are most important and how they are actually filled in.
- Based on this, a simple template and sample reports have been created to illustrate how proper reporting of bugs can lead to better communication, reduction in back-and-forth discussions, and resolution of issues.
- Total time taken to research and publish this article: 50 Hours (Approx)
Finally, please let us know your thoughts, feedback, and questions in the comments below.
Was this helpful?
Recommended Reading
-
On request from may readers I am updating sample bug report on separate page. Here are couple of sample bug reports and treat them as samples only. You can always make the changes in bug report format as per your requirements. It's not mandatory to use same fields in same…
-
Bugzilla is a open-source Bug tracking tool. Many companies are using this open source tool for managing the software development process. After a long break finally Bugzilla project announced a new version of bugzilla 3.0.
-
Weekly report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis. Evenusin these reports you can track the team performance to some extent.
-
Introduction to the Defect Life Cycle In this tutorial, we will talk about the life cycle of a defect to make you aware of the various stages of a defect which a tester has to deal with while working in a testing environment. We have also added the most frequently…
Vishali,
We can automate the functional testing, regression testing and performance testing.
Regards,
Kavita
superb VIJAY KEEP IT UP
Hi
What type of testings we can automate
Very nice ! Thanks for the report !
Incredible update of captcha solution software “XEvil 5.0”:
Captchas breaking of Google (ReCaptcha-2 and ReCaptcha-3), Facebook, BitFinex, Bing, Hotmail, SolveMedia, Yandex,
and more than 12000 another size-types of captchas,
with highest precision (80..100%) and highest speed (100 img per second).
You can use XEvil 5.0 with any most popular SEO/SMM software: iMacros, XRumer, SERP Parser, GSA SER, RankerX, ZennoPoster, Scrapebox, Senuke, FaucetCollector and more than 100 of other programms.
Interested? There are a lot of impessive videos about XEvil in YouTube.
FREE DEMO AVAILABLE!
See you later!
Hi i am anjali.
I have confusion between test case and test scenario. can anybody explain.
Thanks
Test Case is the small part of test scenario. Test case confirm that each module and each actions are working properly or not in low level testing. Whereas, Test scenario is the process of testing collection of test cases in a bulk. Test Scenario confirms that, product is working as per end users requirements or not as a whole as per their need.
Suresh,
The answers that you have given were easily understandable and remembrable….
Thanks!
Regards,
Smitha
very Nice..Article!!!!!
Hi ,
This post is really helpful to imporve the way of reporting bug. Can you also explain a Bug Life cycle ?
very nice and Essayly Understanding The Report….Thank U Vijay.
HI vijay
Nice effort by u.
Thanks
hi Sai/ Vidya,
please check my comment also.
severity : how sever the bug affected the software system.(Testing Team)
1-Showstopper System severely impacted/not available – no workaround
2-Critical System available but certain function fails
3-Major Certain function fails with low impact, workaround available
4-Minor Minimal impact on system function, or cosmetic error
priority : Giving preference to severity .. say SEV1 should be done first, SEV2 should be done 2nd etc. (Developer Team)
thanks
venkat
eesan652@hotmail.com
Hi,
I am looking for jobs in testing .so anyone can clear my question.
In bug report tool the bugs can notified to assigned developer . But how will be sending excel template bug report to developer ??
hi sandy i want experience certificate in software testing.. plz contact me by mail. champdyuti@gmail.com
Hi Prasad, #111
If you are looking for bug tracking tool, then you can go for some open-source tools like Mantis or Bugzilla. They are very easy to understand and use.
Otherwise you can create your own kind of tracking sheet using MS-excel.
Major elements which should present in your tracker are,
Bug ID, Test Case ID, Date of Reporting, Date of Resolved, Summary, Description, Steps-to-reproduce, Assigned to, Status, Severity, Priority and comments.
what is Reason field here?
as you wrote
Reason : Defect
can you elaborate it..?..
Thank You…
Severity is the impact of the bug on the application
priority is to say how important the bug is to fix.
It’s very useful with me. Thanks Vijay
Hi ,
This post is really helpful to imporve the way of reporting bug. Can you also explain a Bug Life cycle ?
Rashmi
hi all, i got a wonderful info from u, & i want to know about Test bed, kindly help us
if i found bug & reported to developer then he assign to me i did regression testing , after that for release 1 it has no bug but in second release there is bug then what should i do …? is regression or retesting?
plz explain me
my id is pratibha.patil30@gmail.com
Hi everyone,
Can you please tell me the difference between a bug report and a test cases report
Thanks in advance
hello everyone i want test cases plan for defect tracking and bug fixing system project , if anyone knows tell me…..
dont know
Hi vijay,
how can i improve in writing a bug report,
can you pls help me
Vijay Nice Articles. Very Important.
Hi Divya ,
Once we report a bug , then in the next stage it will be analyzed as to whether it is actually a bug , i.e It will either be accepted or Reject .
If accepted then it is assigned to Developer and Status will be Assigned or Fix In progress .
Hi freinds,
Muthu,
QC has very vast scope..you can work as a manual test engineer (black box = testing without checking code), Manual test engr. (white box= testing checking code), Automation test engineer by automating the scripts & performance test engineer using performance testing tools.
There are a no. of certifications which you can go for e.g. CSTE, CSQA etc…
Priya
I have a lil doubt on ur question…do u mean reporting bug for a website??
Can anyone tell me what is a test case, and send me some examples of Bug Reporting in manual testing.
Well this is nice effort done by Vijay. It’s simple & easily understandable Bug Report.
Can you pls write for BUG Tracking tool like wise Bugzilla, Matins i mean the complete installation about these Bug Tools.
Nice write up all you guys!!
Simple and easily understand bug report and very useful
Hi could you pls any one share your experience in testing of Antivirus Testing scenarious ? that would be greatly appriciated
Regards,
Ramesh
Useful Information for Test Enggs
Hi,
Thanks for your posting. I am learning QA testing. I want to know how to report bug from a website?
try to give a more complex scenario
Hi Anuradha,
This is suresh working as a Test Engineer i have mentioned Testing Process as below:
1.Test Requirements:
• Requirement Specification documents
• Functional Specification documents
• Design Specification documents (use cases, etc)
• Use case Documents
• Test Trace-ability Matrix for identifying Test Coverage
2.Test Planning:
• Test Scope, Test Environment
• Different Test phase and Test Methodologies
• Manual and Automation Testing
• Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc
• Evaluation & identification – Test, Defect tracking tools
3.Test Environment Setup:
• Test Bed installation and configuration
• Network connectivity’s
• All the Software/ tools Installation and configuration
• Coordination with Vendors and others
4.Test Case Design:
• Test Traceability Matrix and Test coverage
• Test Scenarios Identification & Test Case preparation
• Test data and Test scripts preparation
• Test case reviews and Approval
• Base lining under Configuration Management
5.Test Case Execution and Defect tracking:
• Executing Test cases
• Testing Test Scripts
• Capture, review and analyze Test Results
• Raised the defects and tracking for its closure
6.Test Report and Acceptance:
• Test summary reports
• Test Metrics and process Improvements made
• Build release
• Receiving acceptance
Thanks,
Suresh Balakrishnan.
bsuresh7282@gmail.com
This is a perfect example of bad practice when reporting a failure: “Actual (Observed) Result”, Preconditions and test case ID / requirement ID are totally missing.
Actually, steps 5, 6 and 7 from Steps to Reproduce are “Actual Result”.
See below the right version:
Test ID: abc_123
Requirement ID: uwv_19191
Bug Name: Application crashes upon clicking the SAVE button while creating a new user.
Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug).
Area Path: USERS menu -> New Users
Build Number: Version Number 5.0.1
Severity: HIGH (High/Medium/Low) or 1
Priority: HIGH (High/Medium/Low) or 1 -> this is not to be set by reporter, but by the software PM or Error Manager
Assigned to: Developer-X -> this is not to be set by reporter, but by the software PM or Error Manager
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 2003/SQL Server 2005
Description: Application crashes upon clicking the SAVE button while creating a new the user, hence unable to create a new user in the application.
Steps to Reproduce:
Precondition:
– user 1 exists
– user 2 does not exist
Procedure:
1) Login into the Application -> using user 1
2) Navigate to the Users Menu -> New User -> user 2
3) Filled out all the user information fields.
4) Clicked on the ‘Save’ button.
Expected Result:
On clicking the SAVE button, you should be prompted to a successful message “New User has been created successfully”.
Actual Result:
Failed at step 4 – could not save the new added user and an error page is displayed “ORA1090 Exception: Insert values Error…”
Notes:
* See the attached logs for more information (Attach more logs related to the bug..IF any)
** Also see the attached screenshot of the error page.
hi guys
Am Sandy here if anybody needs manual testing real time project for job reference, experience certificate in software testing with reliable background as well as other field also pl feel free to contact me
Hello Vijay,
Your post really simple and understandable.
Thanks…
can any one explain about priority and severity ?
hi,
this is irfan… i am very happy because you people providing or helping in our field with the good material whatever we need…
thank you.
Please anyone give idea , how can i get free demo version of QTP (or ) Winrunner.
Hi suresh ,
Thanks a lot for ur information.
Bye,
Hi Vijay sir,
This is reporing of very simple bug. But nice and easy to understand….
THANX……
Hi, i read your bug reporting, i can easily understand,
How i can write bug reporting.
And i can easily understand of the severity and priority.
I want to more examples for Severity and priority.
Can you please send my email .
Thanks. It’s very useful.
this very useful site..it can be very easily understandable …
thanks..
hi vijayd
m going to upload my CV.m frresher so how much chances for getting me job.please help me…
Hi,
this is very useful. i have a doubt. if we open a bug and it will report to the developer. then what is the next stage?
Is they fixed the bug?
Hi Ramesh,
Thank u for ur information.
Bye,
The information given about bug report is very useful to every tester .I want to know about the other bug tracking tool like Bugzilla.I want to know about the features of Bugzilla and what are the differences between Quality Center and Bugzilla.Cant we use Quality centre as a bug tracking toll
bye
Hi..Everybody..!
I am Satish working on Manual testing. I want to help the freshers and new testers by explaining the real time concepts of testing.
Add me to your messengers:satish_157@yahoo.com
157.satish@gmail.com
Regards,
Satish
I am Mohsin Riaz Please send me a bugs report .i cannot understand bugs.mohsinriaz051@gmail.com
hai this is murali,
is manual testing of a application covers all the errors(100%) ?
Hi Prasad, #111
You can also check,
https://www.softwaretestinghelp.com/sample-bug-reports-for-web-and-product-applications/
Hi Vijay Sir,
Thank you so much for updating such crispy knowledge
on this web site. i am avid reader for your article past one year .
Hi Vijay….!
Nice to ur see artical, its Very easy to understant for bignners …. can any body explain me about Test Acceptance Plan…..
Thanks
With Rgards….!
ILIYAS
S/W Test Engineer
iliyas@writesoon.com
Neha,
following is the difference between Severity & Priority:
Severity :
it shows the impact of a bug on the application. If any bug is there which is crashing the application then its a HIGH severity bug. If the bug is just a cosmic bug like spelling mistake or font size, color issue, then its a low severity bug.
Priority:
Priortity is time given to dev team to fix the bug. “HIGH” Priority means “bug to be fixed at the earliest”
Hope this’ll help u.
can anyone tell me how I start my career in Automation testing?
what is an expansion of QTP in testing tool.when we need for QTP test?
its minecraft its not working
Hey Guys,
I’m back again, its been quite long time posting articles here. I am glad if I can help you guys.
I came across your text Sample Bug Report: Format, Template And Examples (UPDATED May 8, 2023) and I have a few doubts about the text. I hope you can help me.
1. For the Defect ID part, I’m not sure if writing bug_1 or bug_login_sanity_001 is a good example? I didn’t understand which is actually the correct way of writing, because the subtitles with DO (bug_1) and DON’T (bug_login_sanity_001) confuse me.
2. In part #3) Defect Description shouldn’t it say Defect Description DON’T- Not provide enough information instead of Defect Title DON’T- Not provide enough information?
Are the section subheadings correct as well? I mean parts of the text #5) Environment and #6) Severity and Priority and #7) Evidence that refer to the subtitles Defect Title DO and Defect Title DON’T?
Good example.
Hi vijay Thyanks for giving me this valuable information.
Its very simple to understand will u give details of DOT NET TESTING.
hai vijay,
Thanks for ur information. It was short & informative. Can you plz tell me what all are the status having in QC? And who and all are been assigned to?
When actually automation comes in to testing process
Thanks Vijay….
U have provided such a good article for reporting a bug…..
If u have a time, u can also provide that how many ways do we have to find the bug in Web Application.
Thanks & Regards,
Suresh Sanga
High Priority & Low Severity Bug
When on Home page of a website Name of site is wrong , it is low severity bug as it is not going to affect the major functionality but since its the home page of the website it may create bad impression on customers.
Here it should be High Priority.
High Priority & Low Severity
If we want to take a printout of a page or any document then if Printer doesn’t allow us take prinout , it is a High Priority Bug as it is related to Functionality but since we can take the prinout from another Printer or we if can change the configuration then it is Low Severity Bug as we are getting our work done anyways without letting it affected by malfunctioning of Printer.
Can U Give breif about “How to test in DOTNET TESTING”
Hi Nisha,
You can’t estimate the number of bugs a tester can find in a day. There are so many factors on which the bug count is dependent such as: The complexity of AUT, Type of testing if it is functional, regression, load or UI testing.
How developer understood the requirements, developers coding ability, testers skill, level of application testing i.e if the application is being tested for first time or later versions. and so on..
So don’t judge your daily work on number of bugs unless you are getting paid on bug count 😉
Hi Vijay,
You are really putting lots of efforts in providing these sort of help in Software Testing to all. Keep it up.
Can i get your email id, so that whatever question and quesries i have, i can mail you. if possible Revert pls…
this is great to see ur explanation…….bt my question….is who is a good tester?
thanks but sir my qest is how to lock a bug?
Hi sir,
Its really helpful for us .
i am very thankful to u,
could you share us also selenium and jira tutorial..like installations steps and how to use it…????
Hi Reema Karande,
This is suresh Working as a Test Engineer i have mentioned severity and Priority as below:
Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair
1. High Severity & Low Priority: Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.
2. Low Severity & High Priority: Suppose there is a spelling mistake or content issue on the homepage of BT.com website which has daily laks of hits all over UK. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.
3. High Severity & High Priority: Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently.
4. Low Severity & Low Priority: Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Thanks,
Suresh Balakrishnan.
bsuresh7282@gmail.com
Hi Friends,
Currently i am working in Non-IT field and planned to switch my career to testing.I had learned the basics of testing,and now i am very eager to learn testing practically with real time projects.
If any one interested to teach testing personally with real time projects , i will be more grateful, or else show me the right place in chennai.
Thanks & regards
selvam.ba@rediffmail.com
Hi vijay
its very simple to understand will u give details of Bugzilla installation
can anyone tell me about scope of web testing?
hi,
if any one can send me the BUG REPORTING template for any application.
means, the structure of the bug reporting template
thank u
Hello anoo raadha..
first go infront of the calendar..and put ur hands in calendar leaves and then remove one by one.
Hi
I dont have clear idea about Software Testing Life Cycle.Can any one explain in detail with example.
software testing life cycle is the procedure to test software.
In the software testing life cycle, there are many phases like,
1-Requirements analysis: Requirement analysis refers to the step where the Software Testing Lifecycle begins, In requirement analysis, we analyze the requirement means how to test, whom to test and in this phase, we gather the requirements
2-Test planning: During this phase, the test strategy is outlined in a test plan document. This strategy includes tools needed, testing steps, and roles and responsibilities. Part of determining this strategy is a risk and cost analysis and an estimated timeline for testing.
3-Test environment setup: During this phase, testing environments are configured and deployed. This phase may include a variety of testing tools, including TestComplete, Selenium, Appium, or Katalon Studio. Sometimes, this phase also includes setting up test servers. Once environments are deployed, smoke tests are performed to ensure that environments are working as expected with all intended functionality.
4-Test execution: During this phase, features are tested in the deployed environment, using the established test cases. Expected test results are compared to actual and results are gathered to report back to development teams.
5- Test closure: This is the last phase of the STLC, during which a test result report is prepared. This report should summarize the entire testing process and provide comparisons between expected results and actual. These comparisons include objectives met, time taken, total costs, test coverage, and any defects found.
Hi
A document in easy language.
Easy to understand and solve queries.
Thanks a lot for this.
May God Bless U
Check out BugRem tool for good response of customers.
Hi
This example is very easy to understand and I understand it very clearly.
Thanks a lot for this.
Thanking U
Hi Vijay,
This is reporing of very simple bug. But nice and easy to understand….
THANX……
Please open my note app.I abide
all conditions.
Hi All,
Please answer me for the following question
1. In bangalore where i can get the training on Banking Domain?
2. Which Automation tool used to Testing Banking domain application?
Thanks & Regards
Subrahmanya Nayak
9886877192
subrahmanyadnayak@gmail.com
what is difference between system integration testing and system testing? ….plz anyone gives the exact answers
Thank you for your information TEster.
I had done it already.
I was asking about Google calendar or Microsoft outlook calendar.Not the Daily calendar.
My application is very related to Google calendar.I need some good test cases on that.If you can help please that I can apply those testcases to my application.
hii friends,
when i’m testing some websites i found some bugs but i don’t know whether it is a proper bug or not please conform it the bug is
when i restore down the browser i did’t get after screen fit tabs and images showing blank in some area whether it is a bug or not please clarify me
Very use full information .Thnaks.
hi
Hi friends can anyone give me some sample testcases for Calendar(For example Google calendar).
is automation tools are compulsary for testing?
this really helps! although, it is in the same manner of how we log our defects but your explanation teaches me how to be a better defect – logger:)
Hello,
Good artical on bug report.
How can QA report bug to dev if he/she has a video file(.swf,mp4)?
sometimes screenshot is not enought to explain bug,I have record screen using jing.
but how to send it to dev??(Except email)
Is there any bug tracking tool??
hii,
You can use awesome screenshot as well,where you can take the screenshot along with the video recording option as well..And when ever you will record video or take screenshot so the app will create a link for that particular bug and even you can use that link in excel and can easily send the url at any environment e.g-excels,mails,whatsapp etc
Hi
It is really very useful and easy to understand
thanks for giving this information and i expect that u will continue to sharing your knowledge and experience with us.
thanks 🙂
Quality Center is also a management and defect tracking tool like Test Director. There is one Tab called Defect Tab in it Which is used for Defect Trcking and Defect Reporting. It has Four tabs – Requirement, Test Plan, Test Lab and Defect which are similar to Four tabs of Test Director.
hai sonia,
still if you have doubts on testing mail me at
below id okay.
lukcy
boldrps1479@gmail.com
Hi,
Thanks all for giving useful informations. I need to know how to create a bug report if the same bug occur again?
Ex: A while testing an application X, and report a bug about it in the A section (or category) of bug reports. Now I am testing application Y and get the same error .
Hi, myself Shweta, I completed BscIT and passout in 2008. Currently working as a Software Tester and having nearby 7 months experience.
I like your all the articles.
Will u please suggest me any career opportunities in Software Testing. In Testing, I want to become on a top list but I don’t have way to reach their.
So, waiting for your reply.
Thanks,
Shweta
Who sets the severity and priority for the bug?
hi vijay.
The report is of great help for begginers like me. it’s easy to understand. Thanks. Keep providing such help.
Hi,
Sandy i want Exp certificate as Test Engineer. This is my Gmai: lingaraju.qa.99@gmail.com
Hi guys
For the above Scenario, how to report a Bug in JIRA
hello
Am a test engg fresher.
want to know more about quality control and scope it has?
what all certification should i do to get quality control job.
Hi vijay,
It’s very nice. I hope everyone will get a standard bug report. thanks for your work
thanks,
Dilip.M
Hi vijay,
Thanks for your work. This was a very helpful sample for bug reporting.
Hie……..
thanks for giving this information ,it is very usefull and easy to understand
Hi Vijay,
Can u give idea how to do “WHITEBOX TESTING” without knowing program. Kindly reply me.
My Doubt is Built-in Exceptions like ArrayIndexOutOfBoundException,NullPointerException etc displayed while we are testing(Manually) a web application should be considered as bugs or not.If we Consider them as bugs what priority and severity must be given to that bug.
Pls Can anyone answer?
Hi Friends
All the information’s are useful specially Bug Report
Regrads,
Vikas
Hi Friends,
I have prepared one testing report. it covers bug tracking report and summary matrix, test case report. hereafter any other reports will need for manual testing?
Hi Vijay,
This was a very helpful sample for bug reporting.
Thanks,
Neha
Hi Rashmi,
This is suresh Working as a Test Engineer i have mentioned Bug life cycle as below:
The different states of a bug can be summarized as follows:
1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed
Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
Thanks,
Suresh Balakrishnan.
bsuresh7282@gmail.com
Its very simple and easy to understand
Thanks
Hi Vijay,
Can u give idea how to do “WHITEBOX TESTING” without knowing program.
hi all,
this is srikanth jaligama working as software testengineer in hyd,
If all of u have any realtime queries, let us share knowledge, thanking u
What is the difference between Test Cases, Test Scenario, Test Script, Test Strategy & Test Plan.
hi vijay u r bug report post is easily understandable and helpful thanks
Hi Vinoth
I have mentioned Whitebox Testing and its types as given below:
White box testing strategy deals with the internal logic and structure of the code. White box testing is also called as glass, structural, open box or clear box testing. The tests written based on the white box testing strategy incorporate coverage of the code written, branches, paths, statements and internal logic of the code etc.
In order to implement white box testing, the tester has to deal with the code and hence is needed to possess knowledge of coding and logic i.e. internal working of the code. White box test also needs the tester to look into the code and find out which unit/statement/chunk of the code is malfunctioning.
Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.
Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application.
Types of testing under White/Glass Box Testing Strategy:
Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code is working fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is developed or a particular functionality is built.
Static and dynamic Analysis:
Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic analysis involves executing the code and analyzing the output.
Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the application is executed at least once. It helps in assuring that all the statements execute without any side effect.
Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need to branch out the code in order to perform a particular functionality. Branch coverage testing helps in validating of all the branches in the code and making sure that no branching leads to abnormal behavior of the application.
Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application. This type of testing needs sophisticated testing techniques.
Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a particular bug/defect. It also helps in finding out which code and which strategy of coding can help in developing the functionality effectively.
Besides all the testing types given above, there are some more types which fall under both Black box and White box testing strategies such as: Functional testing (which deals with the code in order to check its functional performance), Incremental integration testing (which deals with the testing of newly added code in the application), Performance and Load testing (which helps in finding out how the particular code manages resources and give performance etc.) etc.
Thanks,
Suresh
bsuresh7282@gmail.com
Very Useful Report Thank u
Hi Vijay ,
Give breif about “How to test in DOTNET TESTING”
hi
I am Nisha.
I need to see a standard terminology of Bug Report which is mostly used in IT/Computer firms nowadays.
Please, can you provide me?
Is there any certification I can take on Software Testing? Give me the details of the certifications and any relevant materials to read?
Thanks for the good job WELL DONE 🙂
I have kept and wrote some notes of writting a professinal bug report.Before i used to use only an excel sheet with a few columns, but thanks to you today i can write a professional Bug Report.
Thank you once again.
Hi Vijay, Really thanks to say u for ur helpsssss…………
I can understand this and getting easily. could u please send me bug report and defect track and what are all include in testing. if u possible to mail me means really saying thanks……………
hello vijay..
very good we r pleasure to read.thanks
Difference between mutation testing and regression testing????please help
The bug report is very easy to under stand and it is very useful.
hi, good articles. how many bugs (average) a tester can find in a day. i am getting an average of 10 to 11 bugs a day.
@Mahalakshmi,
Please provide the email ID.
Regards,
VijayD
Hi…
Its really easy to understand..thanks
Hiiiii
I’m Anil
Is available any tool for crash any web page?
And pls tell me about DB testing…..
Thanksss
Excel sheet for sending
Hi,
Thanks for all
Good explanation.Easy to understand.
hii vijay sir
What is the testing process followed in ur company?
@rana
You can check this
softwaretestinghelp.com/what-is-actual-testing-process-in-practical-or-company-environment/
Hi vijay,
what is the field that can be modified ,when status changes from open to new in QC.
You have 19 advertisements on this ONE page! Holy crap. This is absolutely sickening. Guys C’mon! Good Content but Jesus.
I know this is an example, but i can not avoid make you an observation about your report that always has been a problem for us, is the fact that in the bug report is not included the data used for the test, in several ocasions some bugs cannot be reproduced by the developers because it occurrs with data with specific characteristics, then the developer try to reproduce the bug with any data and maybe he will not able to reproduce it, and will mark the bug as not reproduced or something else, wasting time in the process until the bug is reproduced, and finally fixed. The recomendation here, is always that it be possible, include in the bug report the basic data used for the test.
very nice bug report
In simple terms, Severity is business (how severe is the damage to the company) and priority is technical.
hi all ,
i just want to know about the situation with the help of an example : where there are
high Severity&high priority bugs
high Severity & low priority bugs
High priority & low severity bugs
low priority & low severity bugs
really it is elegant and intuitive report. thanks!
1. Basically if build given by development team
2. Testing team will start the test
3. either start with installation test or general smoke test is done , to make sure that major functionality works fine as per the requirement & Regression testing is done I’ll continue in tomorrow
bye
Very fruitful for us
This info is very useful ..thanks for the info mate ….
Thank you so much lucky, I got it.
Please help me to write the test startegy for the Enterprise Architecture system
Hi,
vijay the bug report is very easy to under stand and it is very useful
I want some infermation please tell me,what is difference between QC and Test Director.
Hi Everyone, can u helpme out in getting any free trail version of bug reporting tool, i try’d a lot but i didnot get anything, its better if u send a browser link
Hi Vijay,
Very useful artical. I have learned all these things from my friend, if I read this artical earlier then there was no need to ask to friends. Anyway thanks a lot!!
Can we report bug report without using any tracking tools?
tell me the clear answer with example?
Hi Vijay,
Could you please explain the difference between Severity and Priority. These two terms seem very confusing to me while reporting the bug?
Thanks,
Neha
Hello Vijay,
Your post really simple and understandable…
it is really useful and interesting
@sonia
in this case you report the same bug in application Y
giving a reference to previous bug which was observed in application X.
if both applications belong same master application then you are suppose to give reference, other wise you need report the same bug in details with respect to application y as it is a different application than applicaton X.
hope you got it
still need clarification mail me at boldrps1479@gmail.com
we can discuss online
Hi Reema Karande,
This is Yolisa Ramokolo working as a Test Engineer at National Treasury. I have mentioned severity and Priority as below:
Defect severity determines the defect criticality whereas defect priority determines the defect immediacy or urgency of repair
1. High Severity & Low Priority: Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.
2. Low Severity & High Priority: Suppose there is a spelling mistake or content issue on the homepage of BT.com website which has daily laks of hits all over SA. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.
3. High Severity & High Priority: Suppose there is an application which gives some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will hamper the functionality of the application immediately within a week. It should be fixed urgently.
4. Low Severity & Low Priority: Suppose there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Thank You,
Yolisa Ramokolo.
Hi vijay Thanks for giving me this valuable information.
Its very simple to understand will u give me details of DOT NET TESTING.
thanks for providing such a simple and useful bug report.
your article on how to write a good bug report is also very informative and useful.
It’s very simple
Thank you for giving this information
hi..
thankQ for ur bug reporting its very useful for me.
see there is always said for the making of the GUI.Could u please tell me briefly about it.
Hi Friends ,
can anyone tell me process of testing procedure with example from starting the process till bug reporting.?
Hi,
Vijay,
The bug Cycle Report was very simple and easy to understand.
thanks for posting/
12 Given the following code, which is true about the minimum number of test cases required for full statement and branch coverage: Read P Read Q IF P+Q > 100 THEN Print “Large” ENDIF If P > 50 THEN Print “P Large” ENDIF
a) 1 test for statement coverage, 3 for branch coverage b) 1 test for statement coverage, 2 for branch coverage c) 1 test for statement coverage, 1 for branch coverage d) 2 tests for statement coverage, 3 for branch coverage e) 2 tests for statement coverage, 2 for branch coverage
please explain
hi
It was very useful friend.Thank u so much to all…………..
Hi
Nice described the example the only thing that is missing is the Actual Result:
This site is very usefull.Its very simple and easy to understand
it is very easy to understand,thank you very much