Introduction of s/w testing

Software testing is an investigation conducted to provide stakeholders with

information about the quality of the product or service under test. Software testing
also provides an objective, independent view of the software to allow the business
to appreciate and understand the risks of software implementation. Test techniques
include, but are not limited to, the process of executing a program or application
with the intent of finding software bugs (errors or other defects).

Software testing can also be stated as the process of validating and verifying that a
software program/application/product:

1. meets the business and technical requirements that guided its design and
development;
2. works as expected; and
3. can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented

at any time in the development process. However, most of the test effort occurs
after the requirements have been defined and the coding process has been
completed. As such, the methodology of the test is governed by the software
development methodology adopted.

Different software development models will focus the test effort at different points
in the development process. Newer development models, such as Agile, often
employ test driven development and place an increased portion of the testing in the
hands of the developer, before it reaches a formal team of testers. In a more
traditional model, most of the test execution occurs after the requirements have
been defined and the coding process has been completed.

Testing methods
White box testing
Black box testing
Grey box testing
White box testing is when the tester has access to the internal data
structures and algorithms including the code that implement these.
white-box testing enables you to see what is happening inside the
application.

Types of white box testing

The following types of white box testing exist:
 API testing (application programming interface) - testing of the
application using public and private APIs
 Code coverage - creating tests to satisfy some criteria of code
coverage (e.g., the test designer can create tests to cause all
statements in the program to be executed at least once)
 Fault injection methods - improving the coverage of a test by
introducing faults to test code paths
 Mutation testing methods
 Static testing - White box testing includes all static testing

White box testing methods can also be used to evaluate the

completeness of a test suite that was created with black box testing
methods. This allows the software team to examine parts of a system
that are rarely tested and ensures that the most important function
points have been tested.

Two common forms of code coverage are:

 Function coverage, which reports on functions executed
 Statement coverage, which reports on the number of lines
executed to complete the test
They both return a code coverage metric, measured as a percentage.
Black box testing

Black box testing treats the software as a "black box"—without any knowledge of
internal implementation.

This testing methodology looks at what are the available inputs for an application
and what the expected outputs are that should result from each input. It is not
concerned with the inner workings of the application, the process that the
application undertakes to achieve a particular output or any other internal aspect of
the application that may be involved in the transformation of an input into an
output.

Black box testing methods include: equivalence partitioning, boundary value

analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and
specification-based testing.

Specification-based testing: Specification-based testing aims to test the

functionality of software according to the applicable requirements. Thus, the tester
inputs data into, and only sees the output from, the test object. This level of testing
usually requires thorough test cases to be provided to the tester, who then can
simply verify that for a given input, the output value (or behavior), either "is" or "is
not" the same as the expected value specified in the test case.
Specification-based testing is necessary, but it is insufficient to guard against
certain risks.

Grey box testing

Grey box testing involves having knowledge of internal data structures and
algorithms for purposes of designing the test cases, but testing at the user, or black-
box level.

Manipulating input data and formatting output do not qualify as grey box, because
the input and output are clearly outside of the "black-box" that we are calling the
system under test.
This distinction 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. However, modifying a data repository does qualify
as grey box, as the user would not normally be able to change the data outside of
the system under test. Grey box testing may also include reverse engineering to
determine, for instance, boundary values or error messages.

White-box:
There are distinct advantages to white-box testing. Here are a few of the most
commonly are:
Introspection. Introspection, or the ability to look inside the application, means
that testers can identify objects programmatically. This is helpful when the GUI is
changing frequently or the GUI is yet unknown as it allows testing to proceed.

2. Stability. In reality, a by-product of introspection, white-box testing can deliver

greater stability and reusability of test cases if the objects that comprise an
application never change.

4. Thoroughness. In situations where it is essential to know that every path

has been thoroughly tested, that every possible internal interaction has been
examined, white-box testing is the only viable method.
As such, white-box testing offers testers the ability to be more thorough in terms of
how much of an application they can test.

Drawbacks.
Complexity. Being able to see every constituent part of an application means that
a tester must have detailed programmatic knowledge of the application
in order to work with it properly. This high-degree of complexity requires a much
more highly skilled individual to develop test case.

2. Fragility. While introspection is supposed to overcome the issue of application

changes breaking test scripts the reality is that often the names of objects change
during product development or new paths through the application are added. The
fact that white-box testing requires test scripts to be tightly tied to the underlying
code of an application means that changes to the code will often cause
white-box test scripts to break. This, then, introduces a high degree of script
maintenance into the testing process.
3. Integration. For white-box testing to achieve the degree of introspection
required it must be tightly integrated with the application being tested. This
Creates a few problems. To be tightly integrated with the code you must install the
white-box tool on the system on which the application is running. This is okay, but
where one wishes to eliminate the possibility that the testing tool is what is causing
Either a performance or operational problem, this becomes impossible to resolve.
Another issue that arises is that of platform support. Due to the highly Integrated
nature of white-box testing tools many do not provide support for more than one
platform, usually Windows®. Where companies have applications that run on
other platforms, they either need to use a different tool or resort to manual testing.

Black-box:

There are many advantages to black-box testing. Here are a few of the most
commonly cited:

1. Ease of use. Because testers do not have to concern themselves with the inner
workings of an application, it is easier to create test cases by simply working
through the application, as would an end user.

2. Quicker test case development. Because testers only concern themselves with
the GUI, they do not need to spend time identifying all of the internal paths that
may be involved in a specific process, they need only concern themselves with the
various paths through the GUI that a user may take.

3. Simplicity. Where large, highly complex applications or systems exist black-

box testing offers a means of simplifying the testing process by focusing on valid
and invalid inputs

Drawbacks

Script maintenance. While an image-based approach to testing is useful, if the

user interface is constantly changing the input may also be changing. This makes
script maintenance very difficult because black-box tools are reliant on the method
of input being known.
2. Fragility. Interacting with the GUI can also make test scripts fragile. This is
because the GUI may not be rendered consistently from time-to-time on different
platforms or machines. Unless the tool is capable of dealing with differences in
GUI rendering, it is likely that test scripts will fail to execute properly on a
consistent basis.
3. Lack of introspection. Ironically, one of the greatest criticisms of black-box
testing is that it doesn’t know how to look inside an application and therefore can
never fully test an application or system. The reasons cited for needing this
capability are often to overcome the first two issues mentioned. The reality is quite
different.

Life Cycle of Testing Process

This article explains about different steps in Life Cycle of Testing Process. in Each
phase of the development process will have a specific input and a specific output.
Once the project is confirmed to start, the phases of the development of project can
be divided into the following phases:

 Software requirements phase.

 Software Design
 Implementation
 Testing
 Maintenance
When to Stop Testing

Often, testing stops when the schedule runs out. A more efficient testing plan provides for a stop
to testing when no further errors are found with existing tests, or when the number of errors
found is below an acceptance threshold.

Scope
A primary purpose of testing is to detect software failures so that defects may be
discovered and corrected. This is a non-trivial pursuit. Testing cannot establish that
a product functions properly under all conditions but can only establish that it does
not function properly under specific conditions.[12] The scope of software testing
often includes examination of code as well as execution of that code in various
environments and conditions as well as examining the aspects of code: does it do
what it is supposed to do and do what it needs to do. In the current culture of
software development, a testing organization may be separate from the
development team. There are various roles for testing team members. Information
derived from software testing may be used to correct the process by which
software is developed.[13]