Dynamic Testing

• Done through executing the code

• Involves the foll. steps
– Review work products
– Identify test objectives
– Identify test specifications & carry out test design
– Design test cases
– Document test cases
– Execute test cases
– Generate incident report
– Log the defects
 Review Work Products
• The work products include
– SRS document
– Design document
– Source code
– User manual (if available)
• From these documents develop test cases
• The entity based on which test specification is
developed is called test basis
• Test basis can be a functional specification, design
strategy or a portion of the code
 Identify test objectives
• Study the details of the quality requirements of the
product & identify what quality parameters need to
be tested
• Some quality parameters are
- Usability
- Reliability
- Performance
- Code coverage
- Portability
- Security
- Safety
- Conformance to a standard
- External interfaces
• If the s/w to be tested is a commercial off-the-shelf
s/w, then, you need to only test whether it meets
your needs or not
• If an in-house s/w is to be tested, then, your testing
objective is to help the developers in bringing out a
quality product that meets user requirements
 Test Specifications & Test Design
• Test Specifications describe what to test
• They are obtained based on knowledge about s/w,
documentation available for s/w and the risks to be covered
• A list of Test Specifications can be prepared based on answers
to the foll. questions
– In addition to functional requirements what non-functional tests have
to be done?
– Is it necessary to do structural testing
– Any testing other than Black Box and White Box testing required?
– If conformance testing is required, what are the details of
conformance requirements?
– What type of acceptance testing is required?
– If operational acceptance testing is required, how long the field trial or
beta testing has to be conducted? In which location it has to be done?
– You need to identify tests that need to be done on a top priority and
tests that may need to be done if time/budget permits
– Eg. If portability is a requirement and if there is a time constraint, the
s/w can be tested on one platform & later portability testing can be
taken up
 Test Design
• The next step is Test Design which involves
– Identification of test environment
– In case of embedded s/w, identification of h/w platform on
which s/w has to be tested
– Identification of test instruments like oscilloscope,
frequency meter etc.
– Identification of the necessary tools required for testing
– Working out test case specifications and test data
– Generating test scripts
– Working out which test cases need to be used in
regression testing
 Design Test Cases
• Test cases have to be designed for each test
specification
• A test specification may have 1 or more test cases
• Test case design involves the foll. Steps
– Identify test inputs
– Identify test data
– Work out test procedure
– Write test scripts if required
– Write if any driver/stub s/w required
– Identify entry criteria
– Identify exit criteria
– Identify expected results(with error messages)
• Test case has to be designed based on 2
criteria : reliability and validity
• A set of test cases are said to be reliable if it
detects all errors
• A set of test cases are said to be valid if at
least one test case reveals the errors
• If the test scenario is “Validate the Admin login
functionality”
• This would yield in 3 test cases (or conditions) – Login
(successful)
• Login-unsuccessful when an incorrect username is entered
• Login-unsuccessful when the incorrect password is entered.
• Each test case would, in turn, have steps to address how we
can check a particular test condition is satisfied or not.
• Test Case 1: Check results on entering valid User Id &
Password
• Test Case 2: Check results on entering Invalid User ID &
Password
• Test Case 3: Check response when User ID is Empty & Login
Button is pressed, and many more
• Guidelines to be followed while designing test cases
– It should be simple which means for an input there should
be only one expected output
– Test case should reveal errors
– There should be no redundancy
– Take valid and invalid inputs
– Test cases should closely match with s/w usage
– Design test cases for quality parameters also
– For designing test cases checklists are useful
• Test case design techniques are classified into foll.
Categories
– Black box test case design techniques
– White box test case design techniques
– Experience based test case design techniques
 Test Cases for an IVR
• An IVR system consists of a h/w(PC add on
card) and an associated application s/w
• Assume that 2 users can access the IVR system
simultaneously through their landline/mobiles
• This system can be used to obtain train
arrival/departure information by keying in the
train number
• The various test cases are listed
Test Type Description
• Functional testing  Test the system for valid train numbers
 Test the system for invalid train numbers
• State transition  Dial IVR no., get IVR response & disconnect
testing  Dial IVR no. & disconnect
 Dial IVR no., key in train no. & disconnect
[After the tests ensure that IVR system gets
back to its normal state]
• Structural testing  Draw complete menu structure of IVR &
test all possible paths
• Performance testing  Test the system when 2 users access
simultaneously from their landlines
 Test the system when 2 users access
simultaneously from their mobiles
 Test the system when 2 users access
simultaneously one from landline & the
other from mobile phone
• Stress testing  Test the system when 3 users access the
system simultaneously, 2 users should get
IVR response and 3rd user should get an
engage tone
 Dial IVR number & key in digits randomly–
• Gorilla testing Does the system withstand random inputs
or does it hang?
• Experience based  When you use IVR system repeatedly, you
testing get used to the messages. So you may like
to key in the train no. without waiting for
the long message to be completed. The
IVR system should be capable of accepting
the digits even while a message being
displayed and it should be capable of
giving the arrival/departure information
• Reliability testing  Keep the IVR system on throughout the
night and test the next day by using
functional testing test cases
• Interface testing  The train arrival/departure information is
stored in a d/b. Suppose it was earlier
tested with MS Access d/b. Replace it with
oracle d/b and repeat the test case
execution
• Portability testing  Check whether the driver for PC add-on
card for the other OS is available
• Security testing  A user can dial IVR number, listen to the
message & then he does not key in the train
number nor does he disconnect. You need
to check whether the IVR s/w will
automatically detect this type of ‘misuse’. If
2 users do such a thing intentionally, the IVR
system is not available to anybody else. This
is called ‘Denial of Service’ attack. The s/w
has to be tested whether it is vulnerable to
this type of attack

• Conformance
testing  As IVR system is connected to telephone
n/w, it should meet requirements specified
by telecommunication authorities. H/W
specifications like voltage levels, impedance
etc. will be tested
 Test cases for Fingerprint Recognition System
• This system is used to allow entry to authorized persons
• At the entry point, fingerprint taken is compared with the pre-stored
fingerprint d/b. The test cases are
 Test the system for valid cases(authorized users)
 Test the system for invalid cases(unauthorized users)
 Test the performance by checking time taken to allow authorized
users & reject unauthorized users
 Test accuracy rate by testing for 100 users to calculate % of false
recognitions------How many unauthorized users are allowed entry &
how many authorized users are denied entry
 Test the tolerance level of the system by applying ink to the finger of
user
 Check the overriding feature: If an authorized person is disallowed
entry, what is the procedure to override that decision?
 Check the security of the computer in which the fingerprint data is
stored by checking the password screen to access the d/b