Software Testing & Quality Assurance Slides - Week 3
Date Published: 05/05/2019
In third week slides, we will learn about Snagit tool that can be used to take a screenshot and short videos of defects. What is Defect Report and how to write it? What is the defect life cycle where we will learn different phases of defect resolution? In the end, we will briefly understand the basic web architecture i.e. when we write the website URL in the browser's address bar, how it is being served from the server.

Summary of the Last Class
  • Software Requirements Specification [SRS]
  • Test Scenario
  • Test Case

    Agenda
    • Snagit Tool
    • Test Cases Execution
    • Defect Report
    • Defect Life Cycle
    • Simple Web Architecture

      Snagit
      • Snagit is a software used to take screenshots
      • You can also make screen movie using Snagit
      • It is already installed on Fairfax QA Lab machine
      • Download from here

        Defect Report
        • Also called as Bug Report
        • If the expected result and the actual result in a test case differ, it is referred to as a defect, bug or issue.
        • While reporting a bug to the developer, a bug report should contain the following information
        • 1. Defect ID – A Unique identification number for the defect.
        • 2. Defect Description - Detailed description of the defect including information about the module in which defect was found.
        • 3. Version - Version of the application in which defect was found.
        • 4. Steps - Detailed steps along with screenshots with which the developer can reproduce the defects.

          Defect Report
          • 5. Date Raised - Date when the defect is raised
          • 6. Reference - Provide a reference to the documents like requirements, design, architecture or maybe even screenshots of the error to help understand the defect
          • 7. Detected By - Name/ID of the tester who raised the defect
          • 8. Status - Status of the defect, more on this later
          • 9. Fixed by - Name/ID of the developer who fixed it
          • 10. Date Closed - Date when the defect is closed
          • 11. Severity/Priority - which describes the impact of the defect on the application

            Defect Report - Severity

            Severity/Priority: This categorization helps developers to prioritize their tasks. Defects are usually categorized by the Test Manager.

              Defect Report - Severity
              Bug Priority
              1) The website performance is too slow
              2) The login function of the website does not work properly
              3) The GUI of the website does not display correctly on mobile devices
              4) The website could not remember the user login session
              5) Contact Us and About Us links don’t work

                  Defect Report - Severity
                  No Bug Priority Explanation
                  1 Website performance is very slow. High The performance bug can cause huge inconvenience to the end user.
                  2 The login functionality of the website is not working properly. Critical Login is one of the main function of the banking website if this feature does not work,  it is serious bugs
                  3 The GUI of the website does not display correctly on mobile devices Medium The defect affects the user who use a Smartphone to view the website.
                  4 The website could not remember the user login session High This is a serious issue since the user will be able to log in but not be able to perform any further transactions
                  5 Contact Us and About Us links don’t work Low This will not stop the user to browse the galleries and by the photos.

                    Defect Report
                    • A bug report can be created in Microsoft Word document, Microsoft Excel or any other type of text writer. 
                    • Once the report is created, it is usually placed in a central repository where all team members can access it.
                    • It can also be sent to the development team via email.
                    • It can also be attached in an automated tool
                    • Exercise – let's create a bug report for at least one bug that you found

                      Defect Life cycle
                      • Defect Life Cycle is a cycle in which a defect goes through during a lifetime.
                      • It starts when a defect is found and ends when a defect is closed, after ensuring it’s not reproduced.
                      • The bug has different states in the Life Cycle.

                        Defect Life Cycle

                          Defect Life Cycle
                          • New: When a defect is logged and posted for the first time. Its state is given as new.
                          • Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to the corresponding developer and the developer team. It’s state given as assigned.
                          • Open: At this state, the developer has started analyzing and working on the defect fix.
                          • Fixed: After making the necessary code changes developer changes the status of the bug to “Fixed” and bug is passed to the testing team.

                            Defect Life Cycle
                            • Pending retest:  After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
                            • Retest:  At this stage, the tester does the retesting of the changed code which the developer has given to him to check whether the defect got fixed or not.
                            • Verified:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.
                            • Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.

                              Defect Life Cycle
                              • 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.
                              • 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“.
                              • 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”.
                              • 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 a priority of the bug may be low, lack of time for the release or the bug may not have a major effect on the software. 
                              • Not a bug: The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If a customer asks for some change in the look and feel of the application like a change of color of some text then it is not a bug but just some change in the looks of the application.

                                Simple Web Architecture

                                  Question?


                                      Keywords: snagit, defect report, defect report tutorial, defect life cycle, web architecture