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

There are two methods used:

Glassbox testing/white box testing:- two methods are used Basic path and control structure testing
techniques

Black box testing: consists of three methods, exhaustive testing, random testing and random value
analysis.

Glass-box testing (or white-box testing) is based on knowing the internal structure of the software.
The testing goal is to determine whether all components of the software do what they are designed
for. Glass-box testing assumes that the tester knows everything about the software. In this case, the
software is like a glass box in which everything inside the box is visible. Glass-box testing is done by
the software engineer or a dedicated team.

Several testing methodologies have been designed in the past. We briefly discuss two of them: basis
path testing and control structure testing.

Basis path testing was proposed by Tom McCabe. This method creates a set of test cases that
executes every statement in the software at least once. Basis path testing is a method in which each
statement in the software is executed at least once.

Control structure testing is more comprehensive than basis path testing and includes it. This method
uses different categories of tests that are listed below.

❑ Condition testing
❑ Data flow testing
❑ Loop testing
Black box testing gets its name from the concept of testing software without knowing what is inside it
and without knowing how it works. In other words, the software is like a black box into which the
tester cannot see. Black-box testing tests the functionality of the software in terms of what the
software is supposed to accomplish, such as its inputs and outputs

Several methods are used in black-box testing, discussed below.

Exhaustive testing: The best black-box test method is to test the software for all possible values in
the input domain. However, in complex software the input domain is so huge that it is often
impractical to do so.

Random testing: In random testing, a subset of values in the input domain is selected for testing. It is
very important that the subset be chosen in such a way that the values are distributed over the domain
input. The use of random number generators can be very helpful in this case.

Six Types of Testing

1. Unit Testing
Unit testing is the testing of individual hardware or software units or groups of related units .
Using white box testing techniques, testers (usually the developers creating the code
implementation) verify that the code does what it is intended to do at a very low structural
level.

2. Integration testing

Integration test is testing in which software components, hardware components, or both are
combined and tested to evaluate the interaction between them . Using both black and white
box testing techniques, the tester (still usually the software developer) verifies that units work
together when they are integrated into a larger code base. Just because the components work
individually, that doesn’t mean that they all work together when assembled or integrated. For
example, data might get lost across an interface, messages might not get passed properly, or
interfaces might not be implemented as specified. To plan these integration test cases, testers
look at the design documents.

3. Functional and system testing

. Functional testing involves ensuring that the functionality specified in the requirement
specification works. System testing involves putting the new program in many different
environments to ensure the program works in typical customer environments with various
versions and types of operating systems and/or applications.

System testing is testing conducted on a complete, integrated system to evaluate the system
compliance with its specified requirements. Because system testing is done with a full
system implementation and environment, several classes of testing can be done that can
examine non-functional properties of the system. It is best when function and system testing
is done by an unbiased, independent perspective (e.g. not the programmer).

o Stress testing – testing conducted to evaluate a system or component at or beyond the

limits of its specification or requirement . For example, if the team is developing software to
run cash registers, a non-functional requirement might state that the server can handle up to
30 cash registers looking up prices simultaneously. Stress testing might occur to check
whether this server can handle one or two more registers.

. o Performance testing – testing conducted to evaluate the compliance of a system

or component with specified performance requirements . To continue the above example, a
performance requirement might state that the price lookup must complete in less than 1
second. Performance testing evaluates whether the system can look up prices in less than 1
second (even if there are 30 cash registers running simultaneously).

o Usability testing – testing conducted to evaluate the extent to which a user can
learn to operate, prepare inputs for, and interpret outputs of a system or component. While
stress and usability testing can be and is often automated, usability testing is done by human-
computer interaction specialists that observe humans interacting with the system.

4. Acceptance testing
After functional and system testing, the product is delivered to a customer and the customer
runs black box acceptance tests based on their expectations of the functionality.

Acceptance testing is formal testing conducted to determine whether or not a system

satisfies its acceptance criteria (the criteria the system must satisfy to be accepted by a
customer) and to enable the customer to determine whether or not to accept the system. These
tests are often pre-specified by the customer and given to the test team to run before
attempting to deliver the product. The customer reserves the right to refuse delivery of the
software if the acceptance test cases do not pass.

5. Regression testing

Throughout all testing cycles, regression test cases are run. Regression testing is selective
retesting of a system or component to verify that modifications have not caused unintended
effects and that the system or component still complies with its specified requirements.
Regression tests are a subset of the original set of test cases. These test cases are re-run often,
after any significant changes (bug fixes or enhancements) are made to the code. The purpose
of running the regression test case is to make a “spot check” to examine whether the new
code works properly and has not damaged any previously-working functionality by
propagating unintended side effects.

6. Beta testing

When an advanced partial or full version of a software package is available, the development
organization can offer it free to one or more (and sometimes thousands) potential users or
beta testers. These users install the software and use it as they wish, with the understanding
that they will report any errors revealed during usage back to the development organization.
These users are usually chosen because they are experienced users of prior versions or
competitive products.

The advantages of running beta tests are

• Identification of unexpected errors because the beta testers use the software in unexpected
ways.
• A wider population search for errors in a variety of environments (different operating
systems with a variety of service releases and with a multitude of other applications running).
• Low costs because the beta testers generally get free software but are not compensated.

The disadvantages of beta testing are as follows

• Lack of systematic testing because each user uses the product in any manner they choose.
• Low quality error reports because the users may not actually report errors or may report
errors without enough detail.
• Much effort is necessary to examine error reports particularly when there are many beta
testers.
GANTT AND PERT CHARTS FOR PROJECT MANAGEMENT

Gantt charts and PERT charts are visualization tools that breakdown the project tasks along
with the time it takes to do the particular task. These are time management tools that are used
by managers and administrators to display tasks that are required for project completion. The
charts schedule, control and administer the tasks that are set by the manager.

A Gantt chart is a bar graph that shows the start dates, end dates and individually breaks
down the project into smaller tasks. Gantt charts also show the dependency relationships
between activities.
The chart shows a horizontal bar which represents the task, while the length of the bar shows
the time required to complete the task. On an x-y axis, the x axis represents the time for
project completion. A limitation of the Gantt chart is that they do not efficiently represent the
dependency of one task to another. Gantt charts are also limited to small projects and are not
effective for projects with more than 30 activities.

PERT CHART

The Program Evaluation and Review Technique (PERT) chart is statistical tool that is used in
project management that is similar to the Gantt chart. This chart is a flow chart. PERT charts
are also designed to analyze and represent the tasks involved in completing a given project.
PERT charts can manage large projects that have numerous complex tasks a very high inter-
task dependency. The charts have an initiation node, which further stems into a network of
individual tasks. PERT chart show the relationship between different tasks that are required
to complete the project. The events in a PERT chart are in logical sequence so that no other
task can begin until the previous task is completed. PERT chart is useful when trying to
manage multiple tasks that will occur simultaneously. This chart is a bit complicated to use
and are often used with Gantt charts in order to simplify the tasks better.
. gathering user requirements-2 weeks
2. analysis and design-3 weeks
3. coding and testing-2 weeks
4. implementation-1 week

Rules: Task 1 and 2 can be done concurrently and the rest sequentially

S/N TASKS Week1 Week2 Week3 Week4 Week5 Week6

1 Gathering user
requirements

2 analysis and design

3 coding and testing

4 implementation
 gathering user
requirements
coding and testing implementation

analysis and design