Bug Triaging

Bug Triaging [also called as Bug council]
Bug Triaging is a project meeting on bugs in the project,where the open bugs are classified as follows
- Bugs to fix now
- Bugs to fix later
- Bugs that will never be fixed

There is a secondary purpose of bug triaging in checking
- The bug are valid,they have correct description for developers and other team member to understand it
- The mentioned bugs are at the right place to track
- The Priority and Severity levels associated with a bug are appropriate w.r.t the upcoming and future releases
Something on Priority and Severity,
The best statement that explains it would be "Priority is business while Severity is Technical"

Assigning Severity is a straightforward approach, Severity implies how serious the identified/discovered issue is? It in a way explains the technical offset from the specification and its degree.

Assign Priority is more of business focused approach. Priority implies how important it is for the business/client that the bug be fixed.

Scales:
Priority Scales: Many companies use their own scale to define this , However they are all on same lines
3- Point Scale
1. P1/ High/Must fix as soon as possible
2. P2/Medium/ Fix soon , maybe next release
3. P3/ Low/ Fix later when we have sufficient time

Severity Scales :
3- point scale is similar to the one mentioned above , but there is variation in 5-point scale
5 - Point Scale
1. Blocking/Critical/P1-Crash [Data crash,application crash,Blocking path or Major functionality missing or wrong ]
2. Major/P2 [Major functionality not implemented properly, Give errors on certain cases ]
3. Medium/P3 [Functionality missing at certain scenario or gives wrong results]
4. Minor / P4 [Issues with UI, alignment, System fails for a negative test case or for an unrealistic scenario]
5. Trivial/Cosmetic / P5 [Issue being too trivial or of just an observation type ]

Requirement Tracebility Matrix

Please click on the image above to see the comprehensive RT matrix.

Traceability Matrix is a document wherin the Requirements can be traced to test cases and vice- verca. The matrix ensures that all the test cases cover the entire functionalities as specified in SRS/Customer requirements/Business requirements. Simply put "RTM is a document that shows the relationship between Test Requirement and Test Cases at various levels in Unit/Integration/System and Acceptance tests ."
Apart from Requirement ID and Test cases which form the main skeletal of RTM , it has few other columns to make traceability complete in all aspects.
A sample RTM [Every company/project would have their own flavour of RTM's]

1st Column : Reqmt ID
2nd Column : Reqmt Ref.
3rd Column : Reqmt Des
4th Column : HLD or Design Ref
5th Column : LLD or Feature/Module Name
6th Column : Unit Test Case#
7th Column : Integration/System Test Case#
8th Column : Acceptance Test Case #
9th Column : Requirement Type
10th Column : Priority
11th Column : Status

Test Plan

Test Plan:

Testing activity requires a through planning right from the start of the project. Test plan is prepared as early as possible in the project. Test plan is derived while keeping in the organization's test policy,organizational goals,scope of testing, objectives,risks,constraints and client expectations(or product),product's complexity in mind.

Test Plan according to IEEE 829.

1.Test Plan Identifier

2. Introduction

3. Items to be tested

4. Features to be tested

5. Features not to be tested

6. Test Approach or Strategy

7. Acceptance criteria [Item Pass/Fail criteria or test exit criteria]

8. Suspension or resumption criteria

9. Test Deliverables

10. Testing tasks

11. Test environment and infrastructure

12. Responsibilities

13. Staffing and Training needs

14. Scheduling

15. Risk and Contingencies

16. Approval

It answers/defines many aspects of testing , like
- Defines overall strategy for testing
- Deciding upon the test environment
- Define test levels
- Defines and describes how to evaluate test results
- Selecting metrics for monitoring and controlling work, as well as defining test exit criteria
- Level of documentation required
- Deciding/Designing templates
- "What", "When", "Who" and "How much" testing
- Estimation of test effort and test cost, re-estimation and

Test planning is a continuous activity throughout all stages of SDLC.