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
