Tutorials Hut

Tutorials Hut

  • Testing Foundation

      Basics of Software Testing
       What is Software Testing?
       Objective of Testing
       Why is testing necessary?
       Common Terms used in Testing
       Verification Vs Validations
       QA Vs QC
       Debugging Vs Testing
       Seven Testing Principles
       SDLC Vs STLC
       Fundamentals of Test Process
       Software quality Factors
       Software Development Models
       Waterfall Model
       V models
       Iterative Model
       Test Levels
       Component Testing
       Integration Testing
       System Testing
       Acceptance Testing
       Strategies for Integration Testing
       Big Bang
       Stubs and Driver
       Top Down Testing
       Bottom Up Testing
       Test Types
       Functional Testing
       Non- Functional Testing
       Structural Testing
       Re-testing & Regression Testing
       Static AND Dynamic Techniques
       Static Technique
       Dynamic Technique
       Static Analysis by Tools
       White Box Techniques
       Statement Coverage Testing
       Branch Coverage Testing
       Decision Coverage Testing
       Path Coverage
       Black Box Techniques
       Equivalence Partitioning
       Boundary Value Analysis
       Decision Table testing
       State Transition testing
       Experience Based TestingTechniques
       Random Testing
       Exploratory Testing
       Error Guessing
       Functional Testing
       Integration Testing
       Unit Testing
       System Testing
       Smoke testing
       Sanity testing
       Regression Testing
       Usability Testing
       Security Testing
       User Acceptance Testing
       White Box & Black Box Testing
       Globalization & Localization Testing
       Non Functional Testing
       Compatibility testing
       Endurance testing
       Load testing
       Performance testing
       Recovery testing
       Scalability testing
       Stress testing
       Volume testing
       Test Planning and Estimation
       Test Planning
       Test Strategies Vs Test Plan
       Test Approaches
       Risk and Testing
       Product Risks
       Project Risks
       Defect Management
       Defect LifeCycle
       Severity Vs Priority



  • Severity and priority in Software Testing

    In the Defect Tracking system Priority and Severity are used to share the importance of a bug among the team and to fix it accordingly.

    Severity

        • The degree of impact that a defect has on the development or operation of a component or system.
        • Severity defines how severe will be the impact of a defect on the performance of the system.
        • Defect Severity is one of the most common causes of disputes between Testers and Developers.
        • Severity means how severe it is affecting the functionality.
        • Severity is associated with standards.
        • The Test Engineer can decide the severity level of the bug.
        • Based on Bug Severity the product fixes are done.
    Severity and Priority

    Severity Type

     

    Description

    S1

    Critical

    Cannot able to test application further. (Show stopper)

    S2

    Major

    Major functionality not working but able to test application

    S3

    Minor

    Bug in Functionality but in the sub module or one under the other module.

    S4

    Trivial

    Issues in location of the object or the look and feel issue (Cosmetic)

     Priority

        • Priority means how fast it has to be fixed.
        • Product manager is to decide the Priority to fix a bug
        • Priority means how urgently the issue can be fixed.
        • Priority status is set based on the customer requirements
        • Priority actually tells the developer the order in which defects should be resolved.  

    Priority

     

    Description

    P1

    High

    immediate attention and should be resolved as soon as possible.

    P2

    Medium

    should be resolved soon after the defects with higher priority have been resolved.

    P3

    Low

    does not require immediate attention and should be rectified after the defects with higher priority have been resolved.

    High priority and High severity

        • Basic functionality of the system is affected and user is blocked as user is unable to use this application
        • Such defects should be rectified immediately.

    High priority and Low severity

        • For example Spelling mistake in the company’s name or issues with logo.
        • Such defects are of low severity
        • But these needs to be fixed immediately and should be considered as high priority defect.

    Low priority and High Severity

        • Major defect in some module but user would not be using it immediately
        • This can be fixed later

    Low priority and Low severity

        • Generally cosmetic in nature
        • Doesn’t affect the functionality of the system
        • Can be fixed later
    Recommended Articles:

















  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    Scroll to Top