ISTQB Exam Chapter 1

Chapter 1. Fundamentals of testing

Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.

Defect, bug or fault are same.

Not all defects result in failures; some stay dormant in the code and we may never notice them.

Rigorous testing is necessary during development and maintenance to identify defects, in order to reduce failures in the operational environment and increase the quality of the operational system. This includes looking for places in the user interface where a user might make a mistake in input of data or in the interpretation of the output, and looking for potential weak points for intentional and malicious attack.

Software engineering software product quality – ISO 9126

Deciding how much testing is enough should take account of the level of risk, including technical and business risks related to the product and project constraints such as time and budget.

The software code is executed to demonstrate the results of running tests (often called dynamic testing).We can also test and find defects without executing code. This is called static testing. This testing includes reviewing of documents (including source code) and static analysis. This is a useful and cost effective way of testing.

Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.

Once the code is written, programmers and testers often run a set of tests so that they can identify and fix defects in the software.

In this 'development testing' (which includes component, integration and system testing), the main objective may be to cause as many failures as possible so that defects in the software are identified and can be fixed.

Following that testing, the users of the software may carry out acceptance testing to confirm that the system works as expected and to gain confidence that it has met the requirements.

When maintaining software by enhancing it or fixing bugs, we are changing software that is already being used. In that case an objective of testing may be to ensure that we have not made errors and introduced defects when we changed the software. This is called regression testing - testing to ensure nothing has changed that should not have changed.

We have to carry out root cause analysis to prevent defects and failures happening again and perhaps to identify the cause of clusters and potential future clusters.

When a test finds a defect that must be fixed, a programmer must do some work to locate the defect in the code and make the fix. In this process, called debugging, a programmer will examine the code for the immediate cause of the problem,Repair the code and check that the code now executes as expected. The fix is often then tested separately (e.g by an independent tester) to confirm the fix.

Notice that testing and debugging are different activities.

Testing can show that defects are present, but cannot prove that there are no defects.

Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

Project and test plans should include time to be spent on planning the tests, designing test cases, preparing for execution and evaluating status

Test policy gives rules for testing, e.g. 'we always review the design documents';

Test strategy is the overall high-level approach, e.g. 'system testing is carried out by an independent team reporting to the program quality manager.

Test control is an ongoing activity. We need to compare actual progress against the planned progress, and report to the project manager and customer on the current status of testing, including any changes or deviations from the plan. We'll need to take actions where necessary to meet the objectives of the project. Such actions may entail changing our original plan, which often happens.

Test control has the following major tasks:

• Measure and analyze the results of reviews and testing:
• Monitor and document progress, test coverage and exit criteria:
• Provide information on testing:
• Initiate corrective actions:
• Make decisions:

A test suite is a logical collection of test cases which naturally work together.

Compare actual results (what happened when we ran the tests) with expected results (what we anticipated would happen). Where there are differences between actual and expected results, report discrepancies as incidents

We test corrected software again to ensure that the defect was indeed fixed correctly. It’s called confirmation test. Remember, independent testing may be carried out at any level of testing and the choice of independence level depends on the risk in the particular context.