Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Myth: Missed defects are due to testers

There is a myth that missed defects are due to testers but the reality is discussed and mentioned below.

– It is not a correct approach to blame testers for bugs that remain in the application even after testing has been performed.
– This myth relates to time, cost, requirements, and changing constraints.
– However, the test strategy may also result in bugs being missed by the testing team.
– One thing about software engineering is that it is a very inexact process but uses very exact techniques.
– In software, a unit with binary states i.e., 0 or 1 is the most precise thing.
– No doubts, defects always exist in the software system throughout its existence.
– Now the only option left with us is to accept the defects while managing the situation in the best way possible.
– Many times the deployment of the application is done in the live environment which means the environment consists of defects.
– These defects are not easily detectable and hence cannot be discovered by the testers during the process of testing.
– This is one of the major reasons why the defects in the live environment are missed out.

Below we list the other factors because of which the testers tend to miss more of the defects.
1. Misunderstanding the requirements:
– This condition is very rare to happen since the system under testing have been through a number of iterations during the testing process before it was actually deployed in the live environment.
– There might be some requirements that the testers often do not understand properly right from the start and continue to test them under wrong conditions until the software is deployed in the live environment.

2. Not testing the SUT as per the conditions of the live environment:
– In the last stage of the testing process before the software is deployed in the live environment, testing is not always performed in the environment that resembles the live domains which are namely related performance, use cases, workflows, hardware, integration with other software (mainly 3rd party software) etc.

3. Using non – similar data for testing:
– Another mistake committed by the testers is that they do not use data similar to the one used by the users working in the live domain.
– This happens so because every set of the data combination cannot be tested. This is almost impossible!
– So what happens when the application is used by the users in the live environment the data that they enter sometimes creates defects in the application.

4. Leaving some parts of the application untested:
– In some cases, the testers leave one or more parts of the software untested because of shortage of time or fast approaching deadline and a greater workload.
– Or it may also happen that the programmers took more time in writing the software and so the software testers could not get enough time for testing the application.

5. Difference between the steps that are followed:
– A detailed and lengthy script might be written by the software testers consisting of the steps which they think are correct as per their vision of the properly working application.
– But the way of working of the users might be different from what was thought by the testers.
– This can give rise to a number of defects.
– Here, the possible paths or the workflows can be identified with the help of the state transition diagrams.

6. Communication failure:
– Mis-communication is another common reason why the defects are left in the software system.
– Communication failure might occur between developers as well as testers during various stages such as the requirement gathering and analysis stage, documentation stage, implementation stage and so on.
– Think of a case where there incomplete or vague environments.
– This could even make the problem because the testers might not be able to understand where the root cause of the problem actually is.
– Another common example of a situation where communication failure is frequent is when code written by one programmer is modified by another.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>