SOFTWARE ENGINEERING

SOFTWARE TESTING - I
STATIC TESTING

Engr. Muhammad Haseeb Nasir

Contact Information
 Instructor: Engr. Muhammad Haseeb Nasir
Lecturer
Knowledge Unit of Systems and Technology
U.M.T Sialkot

 Email: [email protected]
 Office hours: Mon-Sat, 10:00AM - 01:00PM
Topics to Cover
 Software Testing
 Testing Process
 Testing Stages
 Principles of Testing
 Test Cases
 Testing Types
 Black Box testing
Software Testing
 Software testing is the process of analyzing a software item to detect the
differences between existing and required conditions (that is, bugs) and to
evaluate the features of the software item (IEEE, 1986; IEEE, 1990).
Testing Process
Who Tests the Software
Stages of Testing
 Unit testing

 Component Testing

 Module testing

 System testing

 Acceptance testing
Static Testing

 In software development, static testing, also called dry run testing, is a form of
software testing where the authors manually read their own documents/code to find
any errors.

 It is generally not detailed testing, but primarily syntax checking of the

code/document and/or manually reviewing the code or document to find logic errors
also.

 The term ―static‖ in this context means ―not while running‖ or ―not while executing‖
Objectives of Static Testing

 Static testing is the least expensive form of testing and has the largest
potential for reducing defects in software under development.

 The primary objective of static testing is defect reduction in the software by

reducing defects in the documentation from which the software is developed.
Static Testing Approach
 Consider using a two-step approach to static testing.

 For the first step, clean up the cosmetic appearance of the document: check spelling, check
grammar, check punctuation, and check formatting.

 The benefit of doing the first step is that when the document is cosmetically clean, the readers can
concentrate on the content.

 The liability of skipping the first step is that if the document is not cosmetically clean, the readers
will surely stop reading the document for meaning and start proofreading to the detriment of
content review.

For the second step, use whatever techniques seem appropriate to focus expert review on
document contents.

 Some popular and effective techniques used for content review are discussed in the next section
Static Testing Techniques
 Inspections
 Walk-throughs

 Desk checking
 Peer Ratings
Desk Checking

 Introduction

 Desk Checking Process

 Drawbacks
Desk Checking [6]

 Desk Checking is one of the older practice of human error-detection process. A desk
check can be viewed as a one-person inspection or walkthrough: A person reads a
program, checks it with respect to an error list, and/or walks test data through it.

 In other words you can say Manually testing the logic of a program.
Desk Checking Process [6]
 Desk checking involves first running a spellchecker,
grammar checker, syntax checker, or whatever tools
are available to clean up the cosmetic appearance
of the document.

 Then, the author slowly reviews the document trying

to look for inconsistencies, incompleteness, and
missing information.

 Problems detected in the contents should be

corrected directly by the author with the possible
advice of the project manager and other experts on
the project.

 Once all corrections are made, the cosmetic testing

is rerun to catch and correct all spelling, grammar,
and punctuation errors introduced by the content
corrections.
Desk Checking Drawbacks [6]

 Desk checking is the least formal and least time-consuming static testing technique.

 Of all the techniques, desk checking is the only one whereby the author is encouraged
to test his or her own document. The remaining techniques rely on independent eyes to
provide a more thorough and objective review.

 For most people, desk checking is relatively unproductive.

 One reason is that it is a completely undisciplined process.

 A second, and more important, reason is that it runs counter to a testing principle (―that
people are generally ineffective in testing their own programs‖). For this reason, you could
deduce that desk checking is best performed by a person other than the author of the
program.
Test Case
 A test case in software engineering is a set of conditions or variables under which a tester will
determine whether an application or software system meets specifications.
 A test case has components that describes an input, action or event and an expected response,
to determine if a feature of an application is working correctly.
 The mechanism for determining whether a software program or system has passed or failed
such a test is known as a test oracle.
 Test Suite: A collection of test cases.
 A test case may include many subsets.
Test Case
 Test Case ID: It is unique number given to test case in order to be identified.

 Test description: The description of test case you are going to test.

 Revision history: Each test case has to have its revision history in order to know when
and by whom it is created or modified.

 Function to be tested: The name of function to be tested.

 Test Setup: Anything you need to set up outside of your application for example
printers, network and so on.
Test Case

 Test Execution: It is detailed description of every step of execution.

 Expected Results: The description of what you expect the function to do.

 Actual Results: pass / failed

 If pass - What actually happen when you run the test.

 If failed - put in description of what you've observed.

Test Case
Test case for login creation? User name must be of type character and
password must be minimum of length 6.
Test case Pas
Case Test Execution Expected Results s/ Remarks
# Fail

1 Login Enter abcdef in user name

creation field
Enter the password, length of
6 or more
Enter the same password in
confirm password field Login page
Press enter created
2 Error message if Validator
check is there for check
Enter abcdef in user name confirm should be
field password visible
Enter the password, length of suggesting
6 or more that
Enter some other password in passwords
confirm password field not
Press enter matched
Dynamic Testing
 Testing is one of the most important parts of QA and the most commonly
performed QA activity

 Testing involves the execution of software and the observation of the

program behavior or outcome

 Testing is the process of executing a program or system with the intent of

finding errors

 If a failure is observed , the execution record is then analyzed to locate

and fix the faults that caused the failure
Dynamic Testing Types

 Black Box Testing

 White Box Testing

 Gray Box Testing

Black-Box Testing [5]

 What to test ? A

X
 black-box/functional testing
B

 verifies the correct handling of the external functions provided by the

software or whether the observed behavior conforms to user expectations
or product specifications

 When black box testing is performed failures related to specific external

functions can be observed, leading to corresponding faults being detected
and removed.

 The emphasis is on reducing the chances of encountering functional

problems by target customers.
Pros and Cons of Black-Box Testing
Black-Box Testing

 Tester can be non-technical.  Chances of having repetition of tests that

are already done by programmer.
 This testing is most likely to find
those bugs as the user would find.  It is difficult to identify all possible inputs
in limited testing time.
 Testing helps to identify the
contradiction in functional
specifications.

 Test cases can be designed as soon

as the functional specifications are
complete.
White-Box Testing [6]
 What to test ?
A
X
 white/clear-box/structural testing
B

 verifies the correct implementation of internal units, structures and relations

among them

 When white box testing is performed ,failures related to internal

implementations can be observed, leading to corresponding faults being
detected and removed.

 The emphasis is on reducing internal faults so that there is less chance for
failures later on no matter what kind of application environment the
software is subjected to.
Gray Box Testing
 Gray box testing is a software testing technique that uses a combination of black box testing
and white box testing. Gray box testing is not black box testing, because the tester does
know some of the internal workings of the software under test.

 In gray box testing, the tester applies a limited number of test cases to the internal workings
of the software under test. In the remaining part of the gray box testing, one takes a black
box approach in applying inputs to the software under test and observing the outputs.

 This is particularly important when conducting integration testing between two modules of
code written by two different developers, where only the interfaces are exposed for test.
 BLACK BOX TESTING TECHNIQUES

 Equivalence Class Partitioning Testing

 Boundary Value Testing
 Fuzzy Testing
 Omission Testing
 Integration Testing
 Sandwich Testing
Security Testing
 Compatibility Testing
 Null Case Testing
 Volume Testing
 Load Testing
 Stress Testing
 Resource Testing
 Requirements/Specification Testing
 Configuration Testing
 Documentation Testing
 Smoke Testing
 Usability Testing
 Exploratory Testing
 Button Press Testing
 State Transition Testing
 Installation Testing
Fuzzy Testing
 Fuzz testing or fuzzing is a software testing technique, often automated or
semi-automated, that involves providing invalid or unexpected data to the
inputs of a computer program. The program is then monitored for exceptions
such as crashes or failing built-in code assertions.

 The term first originates from a class project at the University of Wisconsin
1988 although similar techniques have been used in the field of quality
assurance, where they are referred to as robustness testing or negative
testing.
 Omission Testing
 Omission Testing (also called Missing Case Testing):

 Exposes defects caused inputting cases (scenarios) the developer forgot to

handle or did not anticipate
 A study by Sherman on a released Microsoft product reported that 30% of client reported
defects were caused by missing cases.

 Other studies show than an average of 22 to 54% of all client reported defects are caused by
missing cases.
Null Case Testing
 Null Testing: (a specific case of Omission Testing, but triggers defects extremely often)
 Exposes defects triggered by no data or missing data.
 Often triggers defects because developers create programs to act upon data, they
don’t think of the case where the project may not contain specific data types

 Example: X, Y coordinate missing for drawing various shapes in Graphics editor.

 Example: Blank file names

References
[1] LandMark Resource Software House testing content
[2] http://jamesmccaffrey.wordpress.com/2008/08/29/the-difference-between-unit-testing-and-
module-testing/
[3] http://www.faqs.org/faqs/software-eng/testing-faq/section-14.html
[4] http://en.wikipedia.org/wiki/White-box_testing
[5] http://agile.csc.ncsu.edu/SEMaterials/WhiteBox.pdf
For any query Feel Free to ask