Wednesday, July 30, 2014

Statement Coverage, Branch Coverage and Path Coverage



Simple Explanation for Statement , Branch and Path Coverage :



Statement Coverage:

In this the test case is executed in such a way that every statement of the code is executed at least once

Branch/Decision Coverage:

Test coverage criteria requires enough test cases such that each condition in a decision takes on all possible outcomes at least once, and each point of entry to a program or subroutine is invoked at least once. That is,every branch (decision) taken each way, true and false. It helps in validating all the branches in the code making sure that no branch leads to abnormal behavior of the application.

Path Coverage:

In this the test case is executed in such a way that every path is executed at least once. All possible control paths taken, including all loop paths taken zero, once, and multiple (ideally, maximum) items in path coverage technique, the test cases are prepared based on the logical complexity measure of a procedural design. In this type of testing every statement in the program is guaranteed to be executed
at least one time. Flow Graph, Cyclomatic Complexity and Graph Metrics are used to arrive at basis path


How to calculate Statement Coverage, Branch Coverage and Path Coverage?


Draw the flow in the following way
- Nodes represent entries, exits, decisions andeach statement of code.
- Edges represent non branching and branching links between nodes.

Example:


Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF

Calculate statement coverage, branch coverage and path coverage.


Solution:

The flow chart for the above example will be as below



 

Statement Coverage (SC) :


To calculate Statement Coverage, find out the shortest number of paths following which all the nodes will be covered. Here by traversing through path 1A-2C-3D-E-4G-5H all the nodes are covered. So by traveling through only one path all the nodes 12345 are covered, so the Statement coverage in this case is 1.

Branch Coverage(BC)/Decision Coverage (DC):

To calculate Branch Coverage, find out the minimum number of paths which will ensure covering of all the edges. In this case there is no single path which will ensure coverage of allthe edges atone go. By following paths 1A-2C-3D-E-4G-5H, maximum numbers of edges (A, C, D, E, G and H) are covered but edges B and F are left.To cover these edges we can follow 1A-2B-E-4F. By the combining the above two paths we can ensure of traveling through all the paths. Hence Branch Coverage is 2. The aim is to cover all possible true/false decisions.

Path Coverage (PC) :

Path Coverage ensures covering of all the paths from start to end.All possible paths are
1A-2B-E-4F 

1A-2B-E-4G-5H

1A-2C-3D-E-4G-5H

1A-2C-3D-E-4F
So path coverage is 4.
Thus for the above example SC=1, BC=2 and PC=4






Monday, July 28, 2014

Defect Life Cycle

What is a Defect Life Cycle or a Bug life cycle in software testing?


Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is related to the bug found during testing.
The bug has different states in the Life Cycle. The Life cycle of the bug can be shown diagrammatically as follows:

http://istqbexamcertification.com/wp-content/uploads/2011/12/Bug-life-cycle1.jpg
Bug or defect life cycle includes following steps or status:

New:  When a defect is logged and posted for the first time. It’s 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 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:  When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

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 do the retesting of the changed code which 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 thebug 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.

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 priority of the bug may be low, lack of time for the release or the bug may not have 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 customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.

Testing Techniques

The Testing is mainly classified into two types - Static testing and Dynamic testing.

Among them there are different testing techniques. Below diagram is the pictorial representation of Testing techniques.



Differences between Static and Dynamic Testing


Differences between Static Testing and Dynamic Testing :





Wednesday, July 23, 2014

Online Practice exams Sites

Please find the below sites which has practice online exams  :

http://www.testingexcellence.com/istqb-quiz/istqb-foundation-practice-exam-1/

http://www.proprofs.com/quiz-school/story.php?title=istqb-foundation-level-practice-test-1_1

http://www.patshala.com/istqbtest/istqb_test1.html


Friday, July 18, 2014

Sample Question Paper 1


1. Which of the following is true
a. Testing is the same as quality assurance
b. Testing is a part of quality assurance
c. Testing is not a part of quality assurance
d. Testing is same as debugging

2. Why is testing necessary?
a. Because testing is good method to make there are not defects in the software
b. Because verification and validation are nto enough to get to know the quality of the
software
c. Because testing measures the quality of the software system and helps to increase the
quality
d. Because testing finds more defects than reviews and inspections.

3. Integration testing has following characteristics
I. It can be done in incremental manner
II. It is always done after system testing
III. It includes functional tests
IV. It includes non-functional tests
a. I, II and III are correct
b. I is correct
c. I, III and IV are correct
d. I, II and IV are correct


4. A number of critical bugs are fixed in a software. All the bugs are in one module, related to
reports. The test manager decides to do regression testing only on the reports module.
a. The test manager should do only automated regression testing.
b. The test manager is justified in her decision because no bug has been fixed in other
modules
c. The test manager should only do confirmation testing. There is no need to do regression
testing
d. Regression testing should be done on other modules as well because fixing one module
may affect other modules

5. Which of the following is correct about static analysis tools?
a. Static analysis tools are used only by developers
b. Compilers may offer some support for static analysis
c. Static analysis tools help find failures rather than defects
d. Static analysis tools require execution of the code to analyze the coverage


6. In a flight reservation system, the number of available seats in each plane model is an input. A plane may have any positive number of available seats, up to the given capacity of the plane.
Using Boundary Value analysis, a list of available – seat values were generated. Which of the
following lists is correct?
a. 1, 2, capacity -1, capacity, capacity plus 1
b. 0, 1, capacity, capacity plus 1
c. 0, 1, 2, capacity plus 1, a very large number
d. 0, 1, 10, 100, capacity, capacity plus one

7. For the code fragment given below, which answer correctly represents minimum tests required
for statement and branch coverage respectively?
Discount rate=1;
Fare = 1000;
If ((person == “senior citizen”) and (“travel month = January”))
Bonuspoints = 100+Bonuspoints
If (class==”first”)
discountRate = .5;
Fare = fare * discountRate;
a. Statement Coverage = 1
Branch Coverage = 2
b. Statement Coverage = 2
Branch Coverage = 2
c. Statement Coverage = 1
Branch Coverage = 3
d. Statement Coverage = 2
Branch Coverage = 4

8. Which of the following is correct about static analysis tools
a. They help you find defects rather than failures
b. They are used by developers only
c. They require compilation of code
d. They are useful only for regulated industries

9. Acme Inc. decides to use functional test execution automation tool for testing GUI of their
product. The GUI is expected to change frequently. Acme Inc. has put some of the manual testers through a 3 day training program on how to use the tool. Which of the following is likely to be true?
a. Automation is likely to fail because of frequent changes and lack of experience
b. Automation is likely to fail because of GUI automation is not the right way to automate
c. Automation is likely to succeed because automation is very useful for frequent changes
d. Automation is likely to succeed because the team has been trained on tool.

10. In foundation level syllabus you will find the main basic principles of testing. Which of the
following sentences describes one of these basic principles?
a. Complete testing of software is attainable if you have enough resources and test tools
b. With automated testing you can make statements with more confidence about the
quality of a product than with manual testing
c. For a software system, it is not possible, under normal conditions, to test all input and
output combinations.
d. A goal of testing is to show that the software is defect free.

11. Which of the following statements contains a valid goal for a functional test set?
a. A goal is that no more failures will result from the remaining defects
b. A goal is to find as many failures as possible so that the cause of the failures can be
identified and fixed
c. A goal is to eliminate as much as possible the causes of defects
d. A goal is to fulfil all requirements for testing that are defined in the project plan.

12. In system testing...
a. .. Both functional and non-functional requirements are to be tested
b. ... Only functional requirements are tested; non-functional requirements are validated in
a review
c. ... Only non-functional requirements are tested; functional requirements are validated in
a review
d. ... Only requirements which are listed in the specification document are to be tested

13. Which of the following activities differentiate a walkthrough from a formal review?
a. A walkthrough does not follow a defined process
b. For a walkthrough individual preparation by the reviewers is optional
c. A walkthrough requires meeting
d. A walkthrough finds the causes of failures, while formal review finds the failures

14. Why does the boundary value analysis provide good test cases?
a. Because it is an industry standard
b. Because errors are frequently made during programming of the different cases near the
‘edges’ of the range of values
c. Because only equivalence classes that are equal from a functional point of view are
considered in the test cases
d. Because the test object is tested under maximal load up to its performance limits

15. Which of the following list contains only non-functional tests?
a. Interoperability (compatibility) testing, reliability testing, performance testing
b. System testing, performance testing
c. Load testing, stress testing, component testing, portability testing
d. Testing various configurations, beta testing, load testing

16. The following list contains risks that have been identified for a software product to be developed.
Which of these risks is an example of a product risk?
a. Not enough qualified testers to complete the planned tests
b. Software delivery is behind schedule
c. Threat to a patient’s life
d. 3rd party supplier does not supply as stipulated

17. Which set of metrics can be used for monitoring of the test execution?
a. Number of detected defects, testing cost;
b. Number of residual defects in the test object.
c. Percentage of completed tasks in the preparation of test environment; test cases
prepared
d. Number of test cases run / not run; test cases passed / failed

18. Which of the following statements is correct?
a. Static analysis tools produce statistics during program execution
b. Configuration management systems allow us to provide accurate defect statistics of
different configurations
c. Stress testing tools examine the behaviour of the test object at or beyond full load
d. Performance measurement tools can be used in all phases of software life-cycle

19. What makes an inspection different from other review types?
a. It is led by a trained leader, uses formal entry and exit criteria and checklists
b. It is led by the author of the document to be inspected
c. It can only be used for reviewing design and code
d. It is led by the author, uses checklists, and collects data for improvement

20. Which of the following is a valid collection of equivalence classes for the following problem: An
integer field shall contain values from and including 1 to and including 15
a. Less than 1, 1 through 15, more than 15
b. Negative numbers, 1 through 15, above 15
c. Less than 1, 1 through 14, more than 15
d. Less than 0, 1 through 14, 15 and more

21. Which of the following is a valid collection of equivalence classes for the following problem:
Paying with credit cards shall be possible with Visa, Master and Amex cards only.
a. Visa, Master, Amex;
b. Visa, Master, Amex, Diners, Keycards, and other option
c. Visa, Master, Amex, any other card, no card
d. No card, other cards, any of Visa – Master – Amex

22. Which of the following techniques are black box techniques?
a. State transition testing, code testing, agile testing
b. Equivalence partitioning, state transition testing, decision table testing
c. System testing, acceptance testing, equivalence partitioning
d. System integration testing, system testing, decision table testing

23. A defect management system shall keep track of the status of every defect registered and enforce
the rules about changing these states. If your task is to test the status tracking, which method
would be best?
a. Logic-based testing
b. Use-case-based testing
c. State transition testing
d. Systematic testing according to the V-model

24. If a program is tested and 100% condition coverage is achieved, which of the following coverage
criteria is then guaranteed to be achieved?
a. 100% branch coverage
b. 100% condition coverage and 100% statement coverage
c. Equivalence class and boundary value coverage
d. No other white box coverage criterion is guaranteed to be fulfilled 100%

25. This part of a program is given:-
WHILE (condition A) Do B
END WHILE
How many decisions should be tested in this code in order to achieve 100% decision coverage?
a. 2
b. Indefinite
c. 1
d. 4

26. Why can be tester dependent on configuration management?
a. Because configuration management assures that we know the exact version of the
testware and the test object
b. Because test execution is not allowed to proceed without the consent of the change
control board
c. Because changes in the test object are always subject to configuration management
d. Because configuration management assures the right configuration of the test tools

27. What test items should be put under configuration management?
a. The test object, the test material and the test environment
b. The problem reports and the test material
c. Only the test object. The test cases need to be adapted during agile testing
d. The test object and the test material

28. Why is successful test execution automation difficult?
a. Because the tools for automated testing require too much effort for learning
b. Because the maintenance of the test system is difficult
c. Because the test robot tools are restricted in their ability to recognize outputs
d. Because the test robot needs to be supported by a test management.

29. Which of the following can be root cause of a bug in a software product? (I) The project had
incomplete procedures for configuration management. (II) The time schedule to develop a certain
component was cut. (III) the specification was unclear (IV) Use of the code standard was not
followed up (V) The testers were not certified
a. (I) and (II) are correct
b. (I) through (IV) are correct
c. (III) through (V) are correct
d. (I), (II) and (IV) are correct

30. Which of the following is most often considered as components interface bug?
a. For two components exchanging data, one component used metric units, the other one
used British units
b. The system is difficult to use due to a too complicated terminal input structure
c. The messages for user input errors are misleading and not helpful for understanding the
input error cause
d. Under high load, the system does not provide enough open ports to connect to

31. Which of the following project inputs influence testing? (I) contractual requirements (II) legal
requirements (III) Industry standards (IV) application risk (V) project size
a. (I) through (III) are correct
b. All alternatives are correct
c. (II) and (V) are correct
d. (I), (III) and (V) are correct

32. If a program is tested and 100% branch coverage is achieved, which of the following coverage
criteria is then guaranteed to be achieved?
a. 100% Equivalence class coverage
b. 100% Condition coverage and 100% Statement coverage
c. 100% Statement coverage
d. 100% Multiple condition coverage

33. This part of a program is given:-
WHILE (condition A) Do B
END WHILE
How many paths should be tested in this code in order to achieve 100% path coverage?
a. One
b. Indefinite
c. Two
d. Four

34. What is the purpose of test exit criteria in the test plan?
a. To specify when to stop the testing activity
b. To set the criteria used in generating test inputs
c. To ensure that the test case specification is complete
d. To know when a specific test has finished its execution

35. Which of the following items need not to be given in an incident report?
a. The version number of the test object
b. Test data and used environment
c. Identification of the test case that failed
d. The location and instructions on how to correct the fault

36. V-Model is:
a. A software development model that illustrates how testing activities integrate with
software development phases
b. A software life-cycle model that is not relevant for testing
c. The official software development and testing life-cycle model of ISTQB
d. A testing life cycle model including unit, integration, system and acceptance phases
37. Why is incremental integration preferred over “big bang” integration?
a. Because incremental integration has better early defects screening and isolation ability
b. Because “big bang” integration is suitable only for real time applications
c. Incremental integration is preferred over “Big Bang Integration” only for “bottom up”
development model
d. Because incremental integration can compensate for weak and inadequate component
testing

38. Maintenance testing is:
a. Testing management
b. Synonym of testing the quality of service
c. Triggered by modifications, migration or retirement of existing software
d. Testing the level of maintenance by the vendor

39. A test engineer is testing a Video Player (VCR), and logs the following report:
Title: Fast Forward stops after 2 minutes. It happens every time
Expected result: Fast forward continues till the end of the tape
Severity: High
Priority: Urgent
What important information did the engineer leave out?
a. Identification (Software and hardware) of the VCR
b. Actual result
c. History of the report
d. Ideas for the test case improvement

40. Why is it necessary to define a Test Strategy?
a. As there are many different ways to test software, thought must be given to decide what
will be the most effective way to test the project on hand.
b. Starting testing without prior planning leads to chaotic and inefficient test project
c. A strategy is needed to inform the project management how the test team will schedule
the test-cycles
d. Software failure may cause loss of money, time, business reputation, and in extreme
cases injury and death. It is therefore critical to have a proper test strategy in place.

KEY: 1 - B2 - C3 - C4 - D5 - B6 - B7 - A (Not sure abt the answer)8 - A9 - A (Not sure)10 - C11 - B12 - A13 - B14 - B15 - C16 - C17 - D18 - C19 - A20 - A21 - D (Not sure)22 - B23 - C24 - B25 - A26 - A (Not sure)27 - A28 - B (Not sure)29 - B30 - A31 - B32 - B33 - C34 - A35 - D36 - A37 - A38 - C39 - B40 - D (Not Sure)

Defect Priority and Severity

The two main parameters that form the basis for effective defect tracking and resolution are:
  • Defect priority
  • Defect Severity
These are often a confused concept and are almost used interchangeably amongst not only test teams but also development teams. There’s a fine line between the two and it’s important to understand that there are indeed differences between the two.
Let’s understand briefly the theoretical definitions of the two parameters in the next section.

What is Defect Priority and what is Defect Severity?

Priority by the English definition is used in the comparative of two things or conditions, where one has to be given more importance than the other(s) and has to be tackled with/resolved first before proceeding to the next one(s). Therefore in the context of defects, priority of a defect would indicate the urgency with which it would need to be fixed.
Severity by the English definition is used to describe the gravity of an undesirable occurrence. Hence when it comes to bugs, severity of a bug would indicate the effect it has on the system in terms of its impact.
Priority and Severity levels
Priority and Severity have some classifications amongst them that aid in determining how the defect must be handled. A lot of different organizations have different defect logging tools, so the levels might vary.
Let’s take a look at the different levels for both Priority and Severity.
Priority:
As already discussed priority determines how quickly the defect turnaround time must be. If there are multiple defects, the priority decides which defect has to be fixed and verified immediately versus which defect can be fixed a bit later.
While opening a defect, the tester generally assigns the priority initially as he views the product from the end user perspective. In line with these, here are different levels:
  • Priority 1 – Critical (P1): This has to be fixed immediately within 24 hours. This generally occurs in cases when an entire functionality is blocked and no testing can proceed as a result of this. Or in certain other cases if there are significant memory leaks, then generally the defect is classified as a priority -1 meaning the program/ feature is unusable in the current state.
  • Priority 2 – High (P2): Once the critical defects have been fixed, a defect having this priority is the next candidate which has to be fixed for any test activity to match the “exit” criteria. Normally when a feature is not usable as it’s supposed to be, due to a program defect, or that a new code has to be written or sometimes even because some environmental problem has to be handled through the code, a defect may qualify for a priority 2.
  • Priority 3 – Medium (P3): A defect with this priority must be in contention to be fixed as it could also deal with functionality issues which is not as per expectation. Sometimes even cosmetic errors such as expecting the right error message during the failure could qualify to be a priority 3 defect.
  • Priority 4 – Low (P4): A defect with low priority indicates that there is definitely an issue, but it doesn’t have to be fixed to match the “exit” criteria. However this must be fixed before the GA is done. Typically, some typing errors or even cosmetic errors as discussed previously could be categorized in here. Sometimes defects with priority low are also opened to suggest some enhancements in the existing design or a request to implement a small feature to enhance user experience.

Defect Priority and Severity levels
Severity:
Severity is a parameter to denote the implication of defect on the system – how critical defect is and what is the impact of the defect on the whole system’s functionality? The severity is a parameter set by the tester while he opens a defect and is mainly in control of the tester. Again different organizations have different tools to use for defects, but on a generic level these are the following severity levels:
  • Critical / Show Stopper (S1): A defect that completely hampers or blocks testing of the product/ feature is a critical defect. An example would be in case of UI testing where after going through a wizard, the UI just hangs at one pane or doesn’t go further to trigger the function. Or in some other cases, when the feature developed itself is missing from the build.
  • Major or Severe (S2): A major defect occurs when the functionality is functioning grossly away from the expectations or not doing what it should be doing. An example could be: Say that a VLAN needs to be deployed on the switch and you are using a UI template that triggers this function. When this template to configure VLAN fails on the switch, it gets classified as a severe functionality drawback.
  • Moderate/ Normal (S3): A moderate defect occurs when the product or application doesn’t meet certain criteria or still exhibits some unnatural behavior, however the functionality as a whole is not impacted. For example in the VLAN template deploy above, a moderate or normal defect would occur when the template is deployed successfully on the switch however there is no indication being sent to the user.
  • Low or Minor (S4): A minor bug occurs when there is almost no impact to the functionality, but is still a valid defect that should be corrected. Examples of this could include spelling mistakes in error messages printed to user or defects to enhance the look and feel of a feature.
Defect Priority and Severity

Examples of sorting defects with priority and severity

  • High priority, high severity: Any defects due to which the testing cannot continue at any cost or causes a severe system failure fall under this category. Say for example clicking on a particular button doesn’t load the feature itself. Or performing a particular function brings down the server consistently and causes data loss. The red lines in the above figure indicate these kind of defects.
  • High priority, low severity:Defects which have to be fixed but do not affect the application come under this category. Say for example the feature is expected to display a particular error to the user with respect to its return code. In this case, functionally the code will throw an error, but the message will need to be more relevant to the return code generated. The blue lines in the figure indicate these kinds of defects.
  • High Severity, low priority: Defects which have to be fixed but not immediately. This can specifically occur during ad-hoc testing. It means that the functionality is affected to a large extent, but is observed only when certain uncommon input parameters are used. Say for example a particular functionality can be used only on a later version of the firmware, so in order to verify this – the tester actually downgrades his system and performs the test and observes a serious functionality issue which is valid. In such a case the defects will be classified in this category denoted by pink lines, as normally end users will be expected to have a higher version of firmware.
  • Low severity, low priority:These defects are classified in the green lines as shown in the figure and occur when there is no functionality impact, but still not meeting the standards to a small degree. Generally cosmetic errors or say dimensions of a cell in a table on UI are classified in here.

Setting the defect priority and severity

As already mentioned, since different organizations use different kinds of tools for defect tracking and its related processes- it becomes a common tracking system between various levels of management and the technical personnel.
Since defect severity is more within the purview of the functionality, the test engineer sets the severity of the defect. At times the developers part-take in influencing the defect severity, but mostly it’s dependent on the tester as he evaluates how much a particular feature can impact the overall functioning.
On the other hand when it comes to setting defect priority, although initially the defect originator sets the priority, it is actually refined by the Product Manager as he has an overall view of the product and how quickly a particular defect has to be addressed. A tester is not the most ideal person to set the defect priority.
Shocking as this may seem, here are two distinct examples as to why:
Example #1: Consider that there is a situation where the user finds a mistake in the naming of the product itself, or some problem with the UI documentation. A tester would normally open a minor / cosmetic defect and may be very simple to fix, but when it comes to the product look and feel / User experience, it could cause a serious impact.
Example #2: There could be certain conditions under which a particular defect occurs which may be an extremely rare or no possibility to hit in the customer environment. Even though functionality-wise this may seem like a high priority defect to a tester, considering it’s rarity of occurrence and high cost to fix – this would be classified as a low priority defect.
Hence in effect, the defect priority is generally set by the product manager in a “defect triage” meeting, which is discussed in the next segment.

Defect Triage

A commonly heard and experienced situation in test teams is limited availability of resources. Defect triage is a process which tries to do some re-balancing as a result of this phenomenon. So when there are a large number of defect and limited Developers/testers to fix/verify them, defect triage helps trying to get as many defects resolved as possible by balancing these technical personnel based on defect parameters like priority and severity.
Typically, a defect triage session is attended by the Product Manager, a development lead, a test lead and sometimes business analysts. In some cases, certain other members may also be invited to give their opinions and perspectives regarding certain defects. These are collectively called a triage team.
Defect Triage Process:
Defect Triage Process
Most systems use priority as the main criteria to assess the defect, however a good triage process considers the severity as well.
Let’s take a closer look at the triage process with two examples that we’ve talked about in the previous section. In both the examples above, it would actually be the first defect that would be given a very high priority. Despite it being only a cosmetic defect, the impact of not fixing would be huge.
The second one on the other hand is a surely functionality defect, however its occurrence is in only certain conditions which is a seldom practiced customer scenario. Fixing it may need more time and people, which could be better utilized for other defects. Hence it would deem lower priority than that of the first and maybe deferral candidate to another release.
Thus the triage process involves triage team siting down together, reviewing all the defects including rejected defects. They draw an initial assessment on the defects based on its content, their respective priority and severity settings; with each person in the triage team presenting their perspective on how to prioritize the defects. The product manager then sets the priority based on all the inputs and assigns the defect to the correct release I.e. in the current release or any future release. He also redirects the defect to the correct owner/team for further action. Rejected defects also are put through a similar analysis. Based on the reason for rejection, the futuristic action of whether it needs to be deferred or cancelled is determined.

Suggestions to choose defect severity and priority correctly

As we’ve already discussed, the severity parameter is assessed by the tester whereas the priority parameter is mainly assessed by the Product Manager or basically the triage team. Even while this is the case, the severity of a defect is definitely one of the governing and influencing factors for the prioritizing the defect. Hence it’s important as a tester to select the right severity to avoid confusion with development teams.
Below are certain guidelines that every tester must try to follow:
  • Firstly, understand the concepts of priority and severity well. Avoid confusing one with the other and using them interchangeably. In line with this, follow the severity guidelines published by your organization / team so that everyone is on the same page.
  • Always choose the severity level based on the issue type as this will affect its priority. Some examples are :
    (I) For an issue which is critical, such as the entire system goes down and nothing can be done – this severity should be not be used to address program defects.
    (ii) For an issue which is major, such as in cases where the function is not working as expected – this severity could be used to address new functions or improvement in the current working.
    Remember, that choosing the right severity level will in turn give the defect, it’s due priority.
  • As a tester – understand how a particular functionality, rather drilling down further – understand how a particular scenario or test case would affect the end user. This involves a lot of collaboration and interaction with development team, Business Analysts, architects, Test lead, Development lead. In your discussions you also need to factor in how much time it would take to fix the defect based on its complexity and time to verify this defect.
  • Finally, it’s always the product owner who possesses the veto power of the release the defect should be fixed. However since the defect triage sessions contain varied members to present their perspective on the defect on a case basis, at such a time if the developers and testers are in sync, it surely helps in influencing the decision.

Conclusion

While opening defects it’s a tester’s responsibility to assign the right severity to the defects. Incorrect severity and hence priority mapping can have very drastic implications on the overall STLC process and the product as a whole. In several job interviews – there are several questions that are asked on priority and severity to ensure that as a tester you have these concepts impeccably clear in your mind.