CHAPTER 7: OBJECT ORIENTED TESTING AND MAINTENANCE:

The Full Life Cycle Object-Oriented Testing (FLOOT) Method:

The Full-Lifecycle Object-Oriented Testing (FLOOT) methodology is a collection of testing

techniques to verify and validate object-oriented software. The FLOOT lifecycle is depicted
in Figure 1, indicating a wide variety of techniques (described in Table 1) are available to you
throughout all aspects of software development. The list of techniques is not meant to be
complete: instead the goal is to make it explicit that you have a wide range of options available
to you. It is important to understand that although the FLOOT method is presented as a
collection of serial phases it does not need to be so: the techniques of FLOOT can be applied
with evolutionary/agile processes as well. The reason why I present the FLOOT in a
"traditional" manner is to make it explicit that you can in fact test throughout all aspects of
software development, not just during coding.

Figure 1. The FLOOT Lifecycle.

Table 1. Testing techniques.

FLOOT
Description
Technique
Testing that verifies the item being tested when given the appropriate input
Black-box testing
provides the expected results.
Boundary-value
Testing of unusual or extreme situations that an item should be able to handle.
testing
Class testing The act of ensuring that a class and its instances (objects) perform as defined.
Class-integration The act of ensuring that the classes, and their instances, form some software
testing perform as defined.
A form of technical review in which the deliverable being reviewed is source
Code review
code.
Component
The act of validating that a component works as defined.
testing
Coverage testing The act of ensuring that every line of code is exercised at least once.
Design review A technical review in which a design model is inspected.
Inheritance- The act of running the test cases of the super classes, both direct and indirect,
regression testing on a given subclass.
Integration testing Testing to verify several portions of software work together.
64
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/
 Method testing Testing to verify a method (member function) performs as defined.
An inspection, ranging anywhere from a formal technical review to an
Model review informal walkthrough, by others who were not directly involved with the
development of the model.
The act of ensuring that all logic paths within your code are exercised at least
Path testing
once.
A process by which your users work through a collection of use cases, using a
Prototype review prototype as if it was the real system. The main goal is to test whether the
design of the prototype meets their needs.
The best way to determine if a model actually reflects what is needed, or what
Prove it with code should be built, is to actually build software based on that model that show
that the model works.
The acts of ensuring that previously tested behaviors still work as expected
Regression testing
after changes have been made to an application.
The act of ensuring that the system performs as expected under high volumes
Stress testing
of transactions, users, load, and so on.
A quality assurance technique in which the design of your application is
examined critically by a group of your peers. A review typically focuses on
Technical review
accuracy, quality, usability, and completeness. This process is often referred
to as a walkthrough, an inspection, or a peer review.
Usage scenario A testing technique in which one or more person(s) validate a model by
testing acting through the logic of usage scenarios.
The testing of the user interface (UI) to ensure that it follows accepted UI
User interface
standards and meets the requirements defined for it. Often referred to as
testing
graphical user interface (GUI) testing.
Testing to verify that specific lines of code work as defined. Also referred to
White-box testing
as clear-box testing.

Regression Testing: The acts of ensuring that previously tested behaviors still work as expected
after changes have been made to an application.

Software Quality Assurance:

Software Quality: Schulmeyer and McManus have defined software quality as “the fitness for
use of the total software product”. A good quality software does exactly what it is supposed to
do and is interpreted in terms of satisfaction of the requirement specification laid down by the
user.

Quality Assurance: Software quality assurance is “a methodology that determines the extent to
which a software product is fit for use”.

The activities that are included for determining software quality are:
 Auditing
 Development of standards and guidelines
 Production of reports
 Review of quality system

Quality Factors:
 Correctness: Correctness determines whether the software requirements are
appropriately met.

65
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/
  Usability: Usability determines whether the software can be used by different categories
of users (beginners, non-technical, and experts).
 Portability: Portability determines whether the software can operate in different
platforms with different hardware devices.
 Maintainability: Maintainability determines the ease at which errors can be corrected
and modules can be updated.
 Reusability: Reusability determines whether the modules and classes can be reused for
developing other software products.

Testing Your Source Code / Testing Your Software:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the
code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Source code analysis is the automated testing of source code for the purpose of debugging a
computer program or application before it is distributed or sold. Source code consists of
statements created with a text editor or visual programming tool and then saved in a file.

Testing Your System in its Entirety:

System Testing is a level of the software testing where a complete

and integrated software is tested. The purpose of this test is to
evaluate the system's compliance with the specified requirements.
System testing: The process of testing an integrated system to
verify that it meets specified.

System Testing is a testing process in which you aim to ensure that

your overall system works as defined by your requirements. System
testing is typically performed at the end of an iteration, enabling
you to fix known problems before your application is user tested.

System testing comprises the following techniques:

1. Function Testing:

Test every function, one by one. Test the function thoroughly, to the extent that you can say with
confidence that the function works. White box function testing is usually called unit testing and
concentrates on the functions as you see them in the code. Black box function testing focuses on
commands and features, things the user can do or select. It’s wise to do function testing before
doing more complex tests that involve several functions.

Functional Testing is a testing technique that is used to test the features / functionality of the
system or Software, should cover all the scenarios including failure paths and boundary cases.

2. Installation Testing:

Install the software in the various ways and on the various types of systems that it can be
installed. Check which files are added or changed on disk. Does the installed software work?
What happens when you uninstall?
66
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/
3. Operation Testing:

Operational acceptance testing (OAT) is used to conduct operational readiness (pre-release) of a

product, service or system as part of a quality management system. OAT is a common type of
non-functional software testing, used mainly in software development and software
maintenance projects. This type of testing focuses on the operational readiness of the system to
be supported, and/or to become part of the production environment.

4. Stress Testing:

Stress testing a Non-Functional testing technique that is performed as part of performance

testing. During stress testing, the system is monitored after subjecting the system to overload to
ensure that the system can sustain the stress.

The recovery of the system from such phase (after stress) is very critical as it is highly likely to
happen in production environment.

Reasons for conducting Stress Testing:

 It allows the test team to monitor system performance during failures.

 To verify if the system has saved the data before crashing or NOT.
 To verify if the system prints meaning error messages while crashing or did it print some
random exceptions.
 To verify if unexpected failures do not cause security issues.

Stress Testing - Scenarios:

 Monitor the system behaviour when maximum number of users logged in at the same
time.
 All users performing the critical operations at the same time.
 All users Accessing the same file at the same time.
 Hardware issues such as database server down or some of the servers in a server park
crashed.

5. Support Testing:

Manual Support means that certain functions will be

performed by people rather than automated IS.
Manual Support Testing is the testing of the
manual support functions. Manual support testing is best
done during the installation phase.

Manual testing technique that involves testing of all the

functions performed by the people while preparing the data
and using these data for automated system. It is conducted
by testing teams.

67
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/
Testing by Users:

User testing following Techniques:

1. Alpha Testing:

Alpha testing takes place at the developer's site by the

internal teams, before release to external customers.
This testing is performed without the involvement of
the development teams.

How do we run it?

In the first phase of alpha testing, the software is tested

by in-house developers during which the goal is to
catch bugs quickly.

In the second phase of alpha testing, the software is given to the software QA team for
additional testing.

Alpha testing is often performed for Commercial Off-The-Shelf software (COTS) as a form of
internal acceptance testing, before the beta testing is performed.

2. Beta Testing:

Beta testing also known as user testing takes place at the end users site by the end users to
validate the usability, functionality, compatibility, and reliability testing.

Beta testing adds value to the software development life cycle as it allows the "real" customer
an opportunity to provide inputs into the design, functionality, and usability of a product. These
inputs are not only critical to the success of the product but also an investment into future
products when the gathered data is managed effectively.

In SDLC: The above diagram explains the fitment of Beta testing in the software development
life cycle.

Beta Testing Dependencies:

There are number of factors that depend on the success of beta testing:
 Test Cost
 Number of Test Participants
 Shipping
 Duration of Test
 Demographic coverage

3. Pilot Testing:

Pilot testing is when a select group of end users try the system under test, before deployment, to
provide feedback about the product. Limited users use the product in pilot testing, and product
is installed at the end customer to validate once the product is ready for the production in
beta testing.
68
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/
4. User Acceptance Testing (UAT):

User acceptance testing, a testing methodology where the clients / end users involved in testing
the product to validate the product against their requirements. It is performed at client location
at developer's site.

For industry such as medicine or aviation industry, contract and regulatory compliance testing
and operational acceptance testing is also carried out as part of user acceptance testing. UAT is
context dependent and the UAT plans are prepared based on the requirements and NOT
mandatory to execute all kinds of user acceptance tests and even coordinated and contributed
by testing team.

User acceptance testing (UAT) consists of a process of verifying that a solution works for the
user. It is not system testing (ensuring software does not crash and meets documented
requirements), but rather ensures that the solution will work for the user (i.e., tests that the user
accepts the solution); software vendors often refer to this as "Beta testing".

This testing should be undertaken by a subject-matter expert (SME), preferably the owner or
client of the solution under test, and provide a summary of the findings for confirmation to
proceed after trial or review. In software development, UAT as one of the final stages of a
project often occurs before a client or customer accepts the new system. Users of the system
perform tests in line with what would occur in real-life scenarios.

User Acceptance Testing - In SDLC:

The following diagram explains the fitment

of user acceptance testing in the software
development life cycle:

The acceptance test cases are executed

against the test data or using an acceptance
test script and then the results are compared
with the expected ones.

Acceptance Criteria:

Acceptance criteria are defined on the basis of the following attributes:

 Functional Correctness and Completeness

 Data Integrity
 Data Conversion
 Usability
 Performance
 Timeliness
 Confidentiality and Availability
 Installability and Upgradability
 Scalability
 Documentation

**********

69
This page was created using Nitro PDF trial software.
To purchase, go to http://www.nitropdf.com/