If you’ve ever worked on a large IT project which has it’s own testing department, then you know it can be quite time consuming work. What’s worse you can sometimes be seen as a hindrance to the project rather than something that creates a quality product. Often you’ll see project managers who are more consumed with meeting their timelines than releasing a quality product. The irony is that bug ridden software never made any project a success irrespective of whether it was released in time. You can usually tell a product which has experienced proper testing compared with those who don’t. For example, if you look at an amateur installed proxy server configured in a hurry compared to one delivered by an experienced residential IP provider you’ll notice the difference even on a performance level.
Nevertheless, we need to understand a little more about how computer software testing works in practice before we could think about how to implement successful testing. Testing and debugging are different kinds of activity, both of these of which are very important. Debugging is the procedure which developers undergo to determine the cause of bugs or defects in code and undertake adjustments. Ideally some check of the correction is produced, but this may not extend to checking that other areas of the system have actually not been unintentionally affected by the correction. Testing, on the other hand, is a methodical exploration of a component or system with the major objective of finding and documenting defects.
Testing does not incorporate correction of defects– all of these are passed on to the web developer to correct. Testing does, nevertheless, guarantee that changes and corrections are examined for their effect on other parts of the component or system. Effective debugging is vital before testing begins to raise the degree of quality of the component or system to a level that is worth testing, i.e. a level that is sufficiently durable to make it possible for rigorous testing to be carried out. Debugging does not provide confidence that the component or system fulfills its requirements completely. Testing makes a rigorous examination of the behaviour of a component or unit and reports all flaws discovered for the development team to correct. Testing then repeats enough tests to make sure that issue corrections have been successful. So both are needed to accomplish a quality result. Static testing and dynamic testing Static testing is actually the term used for testing where the code is not actually exercised. This might sound strange, but remember that failures commonly start with a human error, specifically a mistake in a document for example, a specification. We have to evaluate these due to the fact that errors are much cheaper to fix than defects or failures (as you will see). That is the reason that testing ought to commence as early as achievable, another basic principle discussed in more detail later in this chapter. Static testing involves techniques such as reviews, which can be effective in avoiding defects, e.g. by removing ambiguities and errors from specification documents; this is a topic in its own right and is covered in detail in Chapter 3.
Dynamic testing is actually the type that exercises the program under test along with some test data, therefore we mention test execution in this framework. The technique of software testing encompasses both static and dynamic testing. Testing as a procedure We have actually already observed that there is a lot more to testing than test execution. Before test execution there is some preparatory work to perform in order to design the tests and set them up; after test execution there is some work required to record the results and check whether or not the tests are complete. Maybe even more essential than this is determining what we are trying to achieve with the testing and setting crystal clear objectives for each and every test.
A test designed in order to give confidence that a program functions according to its specification, for example, will be really quite different from one designed to find as many different defects as possible. We define a test process to guarantee that we do not miss crucial steps and also we carry out things in the correct order. We will return to this important topic later, where we explain the fundamental test process in detail. Testing as a set of strategies The final obstacle is to ensure that the testing we do is effective testing. It might seem paradoxical, but a good test is one which finds a problem if there is one present.
A test that finds no defect has consumed useful resources but added no value; a test that finds an issue has created an opportunity to improve the quality of the product. Just how do we develop tests which find defects? We actually undertake 2 things in order to optimize the overall performance of the tests. We use well-proven test design techniques, and a selection of the most important of these is explained in detail in Chapter 4. The techniques are all based upon specific testing principles that have been identified and documented over the years, and these principles are the next mechanism we use to ensure that tests are effective.
