Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.

Similar presentations


Presentation on theme: "University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish."— Presentation transcript:

1 University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish

2 Outlines Why is testing necessary? What is testing? Testing principles Fundamental test process The psychology of testing

3 WHAT IS TESTING? The driving test - an analogy for software testing In a driving test, the examiner critically assesses the candidate's driving, noting every mistake, large or small, made by the driver under test. The examiner takes the driver through a route which tests many possible driving activities

4 WHAT IS TESTING? The driving test - an analogy for software testing Some of the activities must be tested. For example, in the UK, an emergency stop test is always carried out At the end of the test, the examiner makes a judgment about the driver's performance The examiner bases the judgment on the number and severity of the failures identified, and also whether the driver has been able to meet the driving requirements.

5 Defining software testing the ISTQB ( International Software Testing Qualifications Board ) definition of software testing.  Process - Testing is a process rather than a single activity - there are a series of activities involved.  All life cycle activities - testing is a process that takes place throughout the software development life cycle  Both static and dynamic - as well as tests where 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.

6 Defining software testing the ISTQB definition of software testing.  Planning - Activities take place before and after test execution. We need to manage the testing; for example, we plan what we want to do; we control the test activities; we report on testing progress and the status of the software under test.  Preparation - We need to choose what testing we'll do, by selecting test conditions and designing test cases.

7 Defining software testing the ISTQB definition of software testing.  Evaluation - As well as executing the tests, we must check the results and evaluate the software under test and the completion criteria, which help us decide whether we have finished testing and whether the software product has passed the tests.  Software products and related work products - We don't just test code. We test the requirements and design specifications, and we test related documents such as operation, user and training material

8 Defining software testing The second part of the ISTQB definition covers some of the objectives for testing  Determine that (software products) satisfy specified requirements  Demonstrate that (software products) are fit for purpose  Detect defects We can clearly see now why the common perception of testing (that it only consists of running tests, i.e. executing the software) is not complete. This is one of the testing activities, but not all of the testing process.

9 When can we meet our test objectives? Testing Principle - Early testing Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.

10 When can we meet our test objectives? We can use both dynamic testing and static testing as a means for achieving similar test objectives. testing can have different goals and objectives, which often include:  finding defects;  gaining confidence in and providing information about the level of quality;  preventing defects.

11 When can we meet our test objectives? Fixing the defects may not always be the test objective or the desired outcome. Sometimes we simply want to gather information and measure the software. (attribute measures) such as mean time between failures to assess reliability, or an assessment of the defect density in the software to assess and understand the risk of releasing it.

12 When can we meet our test objectives? 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

13 When can we meet our test objectives? We may continue to test the system once it is in operational use. In this case, the main objective may be to assess system characteristics such as reliability or availability.

14 When can we meet our test objectives? Testing Principle - Defect clustering A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures

15 Focusing on defects can help us plan our tests many testers have observed that defects tend to cluster. This can happen because an area of the code is particularly complex and tricky.

16 The defect clusters change over time Testing Principle - Pesticide paradox If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

17 The defect clusters change over time A typical test improvement initiative will initially find more defects as the testing improves and then, as the defect prevention kicks in, we see the defect numbers dropping, as shown in Figure 1.3.

18 The defect clusters change over time A typical test improvement initiative will initially find more defects as the testing improves and then, as the defect prevention kicks in, we see the defect numbers dropping, as shown in Figure 1.3.

19 Debugging removes defects 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.

20 Debugging removes defects The fix is often then tested separately to confirm the fix. Notice that testing and debugging are different activities. following the debugging cycle the fixed code is tested independently both to retest the fix itself and to apply regression testing to the surrounding unchanged software.

21 Is the software defect free? Testing Principle - Testing shows presence of defects 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.

22 If we don't find defects does that mean the users will accept the software? Testing Principle - Absence of errors fallacy Finding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations.

23 TESTING PRINCIPLES Principle 1: Testing shows presence of defects Principle 2: Exhaustive testing is impossible Principle 3: Early testing Principle 4: Defect clustering Principle 5: Pesticide paradox Principle 6: Testing is context dependent Principle 7: Absence-of-errors fallacy

24 Class work List three of the test principles

25 FUNDAMENTAL TEST PROCESS we can divide the activities within the fundamental test process into the following basic steps:  planning and control;  analysis and design;  implementation and execution;  evaluating exit criteria and reporting;  test closure activities.

26 FUNDAMENTAL TEST PROCESS These activities are logically sequential, but, in a particular project, may overlap, take place concurrently and even be repeated. This process is particularly used for dynamic testing, but the main headings of the process can be applied to reviews as well the detail and naming of the activities will be different for static testing.

27 Test planning and control Test planning has the following major tasks, given approximately in order, which help us build a test plan:  Determine the scope and risks and identify the objectives of testing  Determine the test approach (techniques, test items, identifying and interfacing with the teams involved in testing)  Implement the test policy and/or the test strategy  Determine the required test resources (e.g. people, test environment, PCs)  Schedule test analysis and design tasks, test implementation, execution and evaluation  Determine the exit criteria:

28 Test planning and control Management of any activity does not stop with planning it. We need to control and measure progress against the plan. Test planning takes into account the feedback from monitoring and control activities which take place through out the project.

29 Test planning and control 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 or enable others to make decisions: to continue testing, to stop testing, to release the software or to retain it for further work


Download ppt "University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish."

Similar presentations


Ads by Google