Exhaustive testing not possible.., Why?

Exhaustive testing, where every possible input and scenario is tested, is practically impossible for most software systems due to the infinite number of potential combinations and variations.

What Exactly Exhaustive Testing Is?

Exhaustive testing, also called complete testing, is a software testing technique in which all possible combinations of scenarios and inputs are tested to confirm that a software system functions properly under every possible situation.

Exhaustive testing is a time-consuming testing technique but the result is a robust application with minimum or no defects.

Let's consider a simple example to illustrate this:

Example 1:

Imagine, you are testing a basic login system that requires a username and password. The username can be any combination of letters and numbers, and the password can also be any combination of characters. Now, let's say the username can be up to 10 characters long, and the password can be up to 8 characters.

If we wanted to perform exhaustive testing on this login system, we would need to test every possible combination of usernames and passwords within these length limits.

For simplicity, let's assume we only use lowercase letters and numbers in our usernames and passwords.

1. For the username, if each position can be a letter (26 possibilities) or a number (10 possibilities), and we have 10 positions, the total number of possible usernames is 36^10, which is an extremely large number. Similarly, for the password with 8 positions, the total number of possible passwords is 36^8.
2. Multiplying these two numbers together would give us the total number of possible combinations for the username and password. This is an astronomical number, and it's not practical or feasible to test each combination.

Example 2: 

Let's think about the Ariane 5 rocket launch.

A particular software module was reused from the Ariane 4 programme. Only part of the functionality of the module was required, but the module was incorporated without changes.

The unused functionality of the reused module indirectly caused a directional nozzle to move in an uncontrolled way because certain variables were incorrectly updated.

In an Ariane 4 rocket the module would have performed as required, but in the Ariane 5 environment this malfunction in an area of software not even in use caused a catastrophic failure. 

The failure is well documented, but what is clear is that conditions were encountered in the first few seconds after the launch that were not expected, and therefore had not been tested. If every possible test had been run, the problem would have been detected.

However, if every test had been run, the testing would still be running now, and the ill-fated launch would never have taken place; this illustrates one of the general principles of software testing, which are explained below. With large and complex systems it will never be possible to test everything exhaustively; in fact it is impossible to test even moderately complex systems exhaustively. In the Ariane 5 case it would be unhelpful to say that not enough testing was done; for this particular project, and for many others of similar complexity, that would certainly always be the case. 

In the Ariane 5 case the problem was that the right sort of testing was not done because the problem had not been detected.

Conclusion:

In reality, software testing involves using strategies like equivalence partitioning, boundary value analysis, and other testing techniques to focus on critical and representative test cases rather than trying to test every possible combination, which would be time-consuming and impractical.