ISTQB Foundation Level Exam Crash Course Part-14
This is Part 14 of 35 containing 5 Questions (Q. 66 to 70) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 66: How much testing is enough, and how do we decide when to stop testing?
We know that we cannot test everything, even if we would wish to. We also know that every system is subject to risk of one kind or another and that there is a level of quality that is acceptable for a given system. These are the factors we will use to decide how much testing to do.
The most important aspect of achieving an acceptable
result from a finite and limited amount of testing is prioritization. Do the most important tests first so that at any time you can be certain that the tests that have been done are more important than the ones still to be done. Even if the testing activity is cut in half it will still be true that the most important testing has been done. The most important tests will be those that test the most important aspects of the system: they will test the most important functions as defined by the users or sponsors of the system, and the most important non-functional behavior, and they will address the most significant risks.The next most important aspect is setting criteria that will give you an objective test of whether it is safe to stop testing, so that time and all the other pressures do not confuse the outcome. These criteria, usually known as completion criteria, set the standards for the testing activity by defining areas such as how much of the software is to be tested.
Priorities and completion criteria provide a basis for planning. In the end, the desired level of quality and risk may have to be compromised, but our approach ensures that we can still determine how much testing is required to achieve the agreed levels and we can still be certain that any reduction in the time or effort available for testing will not affect the balance – the most important tests will still be those that have already been done whenever we stop.
<<<<<< =================== >>>>>>
Q. 67: What is the difference between Testing and Debugging?
Testing and debugging are different kinds of activity, both of which are very important. Debugging is the process that developers go through to identify the cause of bugs or defects in code and undertake corrections. Ideally some check of the correction is made, but this may not extend to checking that other areas of the system have not been inadvertently affected by the correction.
Testing, on the other hand, is a systematic exploration of a component or system with the main aim of finding and reporting defects. Testing does not include correction of defects – these are passed on to the developer to correct. Testing does, however, ensure that changes and corrections are checked for their effect on other parts of the component or system.
Effective debugging is essential before testing begins to raise the level of quality of the component or system to a level that is worth testing, i.e. a level that is sufficiently robust to enable rigorous testing to be performed. Debugging does not give confidence that the component or system meets its requirements completely.
Testing makes a rigorous examination of the behavior of a component or system and reports all defects found for the development team to correct. Testing then repeats enough tests to ensure that defect corrections have been effective. So both are needed to achieve a quality result.
<<<<<< =================== >>>>>>
Q. 68: What is the difference between Static Testing and Dynamic Testing?
Static testing is the term used for testing where the code is not exercised. Remember that failures often begin with a human error, namely a mistake in a document such as a specification. We need to test these because errors are much cheaper to fix than defects or failures. That is why testing should start as early as possible.
Static testing involves techniques such as reviews, which can be effective in preventing defects, e.g. by removing ambiguities and errors from specification documents; this is a topic in its own right.
Dynamic testing is the kind that exercises the program under test with some test data, so we speak of test execution in this context. The discipline of software testing encompasses both static and dynamic testing.
<<<<<< =================== >>>>>>
Q. 69: What is the impact of software errors detected at different stages of development?
It is difficult to put figures on the relative costs of finding defects at different levels in the SDLC, following table is just an approximate indicator
| Stage error is found | Comparative cost |
| Requirements |
$1 |
| Coding | $10 |
| Program testing | $100 |
| System testing | $1000 |
| User acceptance testing | $100,00 |
| Live running | $100,000 |
This is known as the cost escalation model.
What is undoubtedly true is that the graph of the relative cost of early and late identification/correction of defects rises very steeply as shown in the following graph.
The earlier a defect is found, the less it costs to fix.
The objectives of various stages of testing can be different. For example, in the review processes, we may focus on whether the documents are consistent and no errors have been introduced when the documents were produced. Other stages of testing can have other objectives. The important point is that testing has defined objectives.
<<<<<< =================== >>>>>>
Q. 70: What is Defect Clustering?
It is a fact that problems do occur in software. Once testing has identified the defects in a particular application, it is at first surprising that the spread of defects is not uniform. In a large application, it is often a small number of modules that exhibit the majority of the problems. This can be for a variety of reasons, some of which are:
1) System complexity.
2) Volatile code.
3) The effects of change upon change.
4) Development staff experience.
5) Development staff inexperience.
This is the application of the Pareto principle to software testing: approximately 80 per cent of the problems are found in about 20 per cent of the modules. It is useful if testing activity reflects this spread of defects, and targets areas of the application under test where a high proportion of defects can be found. However, it must be remembered that testing should not concentrate exclusively on these parts. There may be fewer defects in the remaining code, but testers still need to search diligently for them.
Part – 15 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.