What is the meaning of incident in software testing?

Question

What is the meaning of an "incident" in software testing?

Answer 1

At the time of executing/run a test, you sometimes found that the actual results vary from expected results.

When the actual result is differ from the expected result it is called incidents but incidents differs from bugs because it arise because of miss- configuration , corrupted data

incident is Any event occurring during testing that requires inspection or review.

Answer 2

It sounds like a term that is deliberately vague, to mean "something happened that someone needs to take a look at".

The point is probably that when a test (manual or automated) fails, it can be for various reasons:

• Requirements changed and the test is now outdated
• Something wrong with the test environment
• A tester made a mistake or misunderstood the test script
• A configuration error
• An actual bug in the code

Answer 3

It usually means something like "we found a defect or anomalous behavior of some kind". I'm not sure the terminology is universal.

Where's the confusion? What definitions have you been given?

Answer 4

Incident" in testing means unexpected behaviour of the software.

This also a type of bug but it may or may be reproduced.

This incident bugs will be raised due to Hard ware failures, external factors to the software application.

Answer 5

Testing is a check of relationship between three parties

• Functional specification (abbreviated to SPEC): what the user of the system wish the system to behave
• Software (abbreviated to SOFT): what the system really behaves
• Test case (abbreviated to TEST): what the test designer thinks that the system SHOULD behave.

"Incident" is the name of a situation when there is a difference between SOFT and TEST. If you use a tool to report the success of test case, then you would often see that an incident is marked with red, a non-incident with green.

Depending on the relationship between these 3 parties, there can be different situations for an incident to occur:

1. SOFT == SPEC and TEST == SPEC: it means TEST == SOFT, not any incident occurs.
2. SOFT != SPEC and TEST == SPEC: it means TEST != SOFT, and an "incident" occurs
3. SOFT == SPEC and TEST != SPEC: it means TEST != SOFT, and an "incident" occurs
4. SOFT != SPEC and TEST != SPEC and SOFT == TEST: it means not any incident occurs
5. SOFT != SPEC and TEST != SPEC and SOFT != TEST: it means this is an "incident"

Looking at these 5 situations, we see that

• When an "incident" occurs, it can be that the software is erroneous, the test case is erroneous, or both
• When there is no "incident", it can still be that both the test case and the software are erroneous, or both of them are "good" (they follow the specification).

So a green does not guarantee that your software is good, a red incident does not guarantee that your software is bad (here I use "good" and "bad" mean that the SOFT follows the SPEC or not)

Answer 6

An incident in Software Testing is basically any situation where the system exhibits questionable behaviour, but often we refer to an incident as a defect only when the root cause is some problem in the item we are testing.

Other causes of incidents includes mis-configuration or failure of the test environment, corrupted test data, bad tests, invalid expected results and tester mistakes.

This means to indicate the possibility that a specious behaviour is not necessarily a true defect.

When an incident is initially recognized, an incident report should be generated with a set of supporting information as:

• Identification of the incident, including unique number, heading, trigger event, proposed fix, if possible, and documentation (e.g., screen dumps).
• Identification of the environment, including hardware, software, vendor, item in which the incident was seen, and fix description, if any.
• Identification of the people involved, including originator and investigator.
• Related time information, for example, system time, CPU time, and wall time as appropriate.