Lecture 30 & 31

Software Testing
 Topics covered
l Introduction
l Validation vs verification
l Software testing model
l Development testing
l Release testing
l Requirements-based testing
l Scenario testing
l Performance testing
l User testing
l Conclusion
 Software Testing
l Software Testing is intended to
• Show that a program does what it is intended to do and
• Discover program defects before it is put into use
l The testing process has tow goals
• To demonstrate to the developer and the customer that the
software meets requirements (Validation Testing )
• To discover situations in which the behavior of the software is
incorrect, undesirable or does not conform to its specification
(Defect testing)
• Example : System crashes, unwanted interactions with other
systems, incorrect computations and data corruptions
 Validation & Verification
l Testing is part of a broader process of software verification and
validation
l Barry Boehm, a pioneer of software engineering, succinctly the
difference between validation and verification
• Validation : Are we building the right product?
• Verification: Are we building the product right ?
l Verification vs Validation
• The aim of verification is to check that the software meets its stated
functional and non-functional requirements
• The aim of validation is to ensure that the software meets the
customer’s expectations
l Software testing, verification and validation process may involve
software inspections and reviews
l Inspections and reviews analyze and check the system requirements,
design models, the source code and even proposed system tests
 Test Cases
l Test cases
• These are specifications of the inputs to the test and the expected
output from the system plus a statement of what is being tested
l Testing is expensive and time consuming, it is important that
we choose effective unit test case
• Test cases should show the component that you are testing and
what it is supposed to do
• If there are defects in the component, these should be revealed
by test cases
l Example
• if the test scenario is “Validate the Admin login functionality” –
This would yield in 3 test cases (or conditions) –
• Login (successful),
• Login-unsuccessful when incorrect username is entered,
• Login-unsuccessful when 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.
 Model of software testing process

Test Test Test Test

Cases Data Results Reports

Design Test Design Test Run program with Compare

Cases data test Data Results to Test
Cases
 Stages of testing
l Commercial software system has to go through
three stages of testing
• Development Testing :
• the system is tested during development to discover bugs and
defects
• System designers and programmers are likely to be involved
• Release Testing :
• A separate testing team tests a complete version of the system
before it is released to users
• The aim of release testing is to check that the system meets the
requirements of the system stakeholders
• User testing :
• Users and potential users of a system test the system in their own
environment
 Development Testing
l Development testing may be carried out at three
level
• Unit Testing :
• Individual program units or object classes are tested
• It should focus on testing the functionality of objects or methods
• Component Testing :
• Several individual program units are integrated to create composite
component
• It should focus on testing component interfaces
• System Testing :
• Some or all of the components in a system are integrated and the system is
tested as a whole
• It should focus on testing component interactions
l It is primarily a defect testing process, where the aim
is to discover bugs in the software
 Unit Testing
l It is the process of testing program components, such as
methods or object classes
l We should design our tests to provide coverage of all of the
features of the objects, i.e., we should
• Test all operations associated with the object
• Set and check the value of all attributes associated with the
object
• Check all possible state of object class
l Generalization or inheritance makes object class testing more
complicated
• We have to test the inherited operations in all of the contexts
where it is used
l Sometimes the object that we are testing has dependencies on
other objects that may not have been written or which slow
down the testing process
• We may use mock object
 Release Testing
l It is the process of testing a particular release of a system that
is intended for use outside of the development team
• That are developing related systems
l The distinctions of release testing and system testing
• A separate team that has not been involved in the system
development should be responsible for release testing
• System testing by the development team should focus on
discovering bugs in the system
l The primary goal of the release testing is to convince the
supplier of the system that it is good enough for use
l If so, it can be released as a product or delivered to the
customer
l It should take into account all of the system requirements, not
just the requirements of the end-users of the system
 Release Testing
l It is usually a black-box testing process where tests
are derived from the system specification
l Black Box testing
• Whose behavior can only be determined by studying its
inputs and related outputs
• It is also called functional testing the tester is only
concerned with functionality and not the implementation
of the software
l White Box Testing
• It tests the internal structure of the system
• It can be applied at the unit, integration and system levels
of the software testing process
Requirements based Testing
l General principle of good requirements engineering practice
• Requirements should be testable
• The requirement should be written so that a test can be
designed for the requirement
• A tester can then check that the requirement has been satisfied
l Requirements-based testing
• It is a systematic approach to test case design where you
consider each requirement and derive a set of tests for that
requirement
 Scenario Testing
l Scenario testing is an approach to release testing where you
• devise typical scenarios of use and
• Use these to develop test cases for the system
l A scenario
• is a story that describes one way in which the system might be
used
• Should be realistic
 Performance Testing
l Once a system has been completely integrated, it is possible to
test for emergent properties such as performance and
reliability
l Performance tests have to be designed to ensure that the
system can process its intended load
 User Testing
l User or customer testing is a stage in the testing process in
which users or customers provide input and advice on system
testing
l It is essential, because influences from the user’s working
environment have a major effect on the
• Reliability
• Performance
• Usability
• Robustness of a system
l Three types of User testing
• Alpha testing
• Beta Testing
• Acceptance Testing
 User Testing
l Alpha Testing :
• Where users of the software work with the development team to test the
software at the developer’s site
• Users and developers work together to test a system being used
l Beta Testing
• Where a release of the software is made available to users to allow
them to experiment and to raise problems
• Beta testers may be a selected group of customers who are early
adopters of the system
• The software may be made publicly available for use by anyone who is
interested in
l Acceptance Testing
• Where customers test a system to decide whether or not it is ready to be
accepted from the system developers and deployed in the customer environment
• It involves a customer formally testing a system to decide whether or not it should
be accepted from the system developer
• Acceptance implies that payment should be made for the system