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: complete testing is possible

There is a myth that complete testing is possible. The reality is given below.

– It becomes an issue when a client or a tester thinks that the complete testing is possible.
– It is possible that all paths have been tested by the team but the occurrence of complete testing is never possible. – There might be some scenarios that are never executed by the testing team or the client during the software development life cycle and may be executed once the project has been deployed.
– Even though the test automation has made it possible to test the software to a large extent but it does not offer a solution to the complete testing.
– When we test the software we might be able to provide it full coverage but then this cannot be taken as complete testing.
– Since the complete testing is not possible, enough good testing must be done.
– If the software can be tested completely, it means that after finishing the testing process, no errors exist which have not been discovered.

Reasons why complete testing is not possible?

1. The first reason is that the all possible inputs for the program cannot be tested.
– The domain of all the inputs that are possible is quite large.
– Therefore, it becomes impossible to test all the valid inputs (including optimizations), invalid inputs, edited inputs (these inputs have high complexity.
– Another question that arises here are how much editing should be done, variations on timing of the input (timing is a crucial factor in the client/ server world.

2. All the possible combinations of the inputs for the program cannot be tested.
– The variables in a program interact with each other and this can sometimes lead to program crashes.
– For example, crashing of the program on the print preview of an image with high resolution on a screen with high resolution.
– Another example is of crashing of a program while computing the sum of a series which is too large.

3. All the paths in the program cannot be tested.
– There might be trillions of paths in the program which might take hundred of years to be tested.

4. All the potential failures cannot be tested.
These failures include those caused by an incomplete analysis of the requirements or because of the errors in the design of the user interface.

– The amount of a particular type of testing done is measured in terms of the coverage.
– On one hand, the testing is for finding the errors, the coverage is for measuring the tester’s effort for detecting potential errors of a particular class.

There are three main types of coverage:

  • 100% line coverage: Involves testing every bug that can be caused by a line’s execution.
  • 100% branch coverage: Involves finding all the errors that can be found by execution of the branch.
  • 100% coverage: This implies that all the errors have been covered and this is impossible for the reasons we mentioned above.
  • So now the question that arises is that what sort of coverage level is appropriate?
    – As per the IEEE unit testing standard, line coverage and branch coverage should be 100%.
    – Most companies fail in achieving this.
    – On the other side, there are people who think that complete line and branch coverage also means complete testing or we can say sufficient testing but this is not so.

    In line and branch testing we do not test the following and so the testing remains incomplete:

  • Data flow
  • Tables determining the flow of control in the code that is driven by the tables
  • Disadvantages caused by the use of the interrupts
  • Interaction of the program with the tasks running in the background
  • Boundary cases
  • User interface errors
  • Bugs related to timings
  • Compliance with the regulations, requirements and the contracts
  • Failures of configuration and compatibility
  • Faults in hardware, volume and load.
  • Coverage is easy to be measured but this is not the only method available for the measurement of the extent of testing.

    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>