Lecture 11 Testing and Debugging SFDV Principles of Information Systems

2 Recap of the Implementation phase  Hardware Acquisition  Software Acquisition  Make or buy decision  Build: Database, programming and user interface  User preparation  Documentation  Ongoing training and user support  Deployment  Site preparation  Data preparation  Installation and start-up  Testing and quality assurance  User Acceptance

3

4 Overview  Verification versus Validation  Insuring quality software  Reviewing software  Testing software  Debugging  Tips and Strategies  Techniques

5 Verification versus Validation  Verification:  “Are we building the product right?” Checking that the system meets its specified functional and non-functional requirements.  Validation:  “Are we building the right product?”  checking that the software meets the expectations of the customer.  Techniques  Reviews/Peer reviews  Testing - “The process of executing a program with the intent of finding errors” [Source: Boehm, 1979]

6 Reviews  Reviews:  Peers looking at all elements of the system/project searching for problems  Types of reviews  Managerial  Technical  Purpose of reviews, in particular technical reviews  Types of technical reviews  Walkthrough  Code readings  Inspections Objectives of Technical Reviews (Pressman) To uncover errors in function, logic, or implementation for any representation of the software To verify that the software under review meets it requirements To ensure that the software has been represented according to predefined standards To achieve software that is developed in a uniform manner To make projects more manageable

7 Walkthroughs  “… a static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a software product, the participants ask questions and make comments about possible errors, violation of development standards, and other problems” [Source: Stair and Reynolds, 2003] [Source: IEEE., 1997] Participants Developer Implementer Manager responsible for the product Representative from SQA group

8 Testing vs. Debugging  Software testing  “… is a process that can be systematically planned and specified. Test case design can be conducted, a strategy can be defined, and results can be evaluated against prescribed expectations”  Debugging  “… occurs as a consequence of successful testing. That is, when a test case uncovers an error, debugging is the process that results in the removal of the error” [Pressman, 1997]

9 Testing Definitions  Defect, failures and errors (observe failure caused by defect)  Test cases  Statement (event), input, and output  Test suite  Collection of test cases  Defect testing – expose the defect  Functional testing - focusing on result  Structural testing – focusing on how the result is produced

10 Defect and failure Defect: is the result of an error made in the systems construction Failure: is an instance of an defect observed by the user (“symptom”) Errors: “so we observe failures, which are caused by defects, which result from errors” Test cases Input to the test Expected output from the system Statement of what is being tested Example: Statement (squaring function) input 2 expected output 4 Statement (function: getting the first name from the whole name) input: full name “Lance Elder” expected output: first name “Lance” Use test cases to test the system Test suite Is a collection of test cases (both inputs and outputs) Defect testing The goal of defect testing is to expose the latent defects on a software system before the system is delivered A successful defect test is when the system performs incorrectly and hence exposes a defect Functional testing focusing on the result Structural testing focusing on how the result is produced

11 Structural Testing  Also known as white-box, glass-box or clear-box testing  Test cases can derived for:  Operators, variables, constants, etc.  Statements  Branches  Paths  Functions  Test can device that All independent paths within the module have been exercised at least once (path testing) Exercise all logical decisions on their true and false sides Execute all loops at their boundaries and within their operational bounds Exercise internal data structures to assure their validity

12 Functional Testing  Also known as black-box testing “functional” testing because the tester is only concerned with the functionality and not the implementation of the software Attempts to find the following categories of errors: Incorrect or missing functional Interface errors other external elements.

13 Other Testing Issues  Management issues  Testing prioritisation  Testing cost  Developers  Other forms of testing  Stress (volume) Testing - Test to see if a system performs under load  Regression Testing - Rechecking to uncover bugs introduced in the testing/debugging process  Usability testing - for measuring how well people can actually use something

14 Debugging Techniques  Commenting out suspicious lines of code  Best to minimize to small sections  Uncomment one section before commenting out another  Displaying messages  MessageBox.Show()  MsgBox()  Debugger  When a program crashes – a debugger helps the developer to locate the problem

15 Debugging Techniques Examples Dim x, y As Integer x = 0 x = x + 1 ‘x = y * 10 ‘y = y * (x + 2) Comment MethodMessage Box Method Dim x, y As Integer x = 0 MsgBox(x) x = X + 1 MsgBox(x) x = y * 10 MsgBox(x & space(1) & y) y = y * (x + 2) MsgBox(x & space(1) & y)

16 References  Sommerville, Software Engineering, 7 th Edition, Addison Wesley, 2004  Stazinger, et al., Systems Analysis and Design in a changing world, 4 th Edition, Thomson, 2007  Pressman, Software Engineering: A Practitioner’s Approach, 4 th Edition, 1997  Stair and Reynolds, Principles of Information Systems, 7 th Edition, 2006  Sprague, Microsoft Visual Basic.NET: Introduction to Programming, 2 nd Edition, 2003   Note : End ot Tutorial 4 & Practical Sessions 5