Software testing

Why Testing is Important?

1. To discover defects.
2. To avoid user detecting problems
3. To prove that the software has no faults
4. To learn about the reliability of the software.
5. To avoid being sued by customers
6. To ensure that product works as user expected.
7. To stay in business
8. To detect defects early, which helps in reducing the cost of defect fixing

Testing methods
Static vs. dynamic testing
There are many approaches to software testing.
Reviews, walkthroughs, or inspections are referred to as static testing,
whereas actually executing programmed code with a given set of test
cases is referred to as dynamic testing.
Static testing can be omitted, and unfortunately in practice often is.
Dynamic testing takes place when the program itself is used. Dynamic
testing may begin before the program is 100% complete in order to test
particular sections of code and are applied to discrete functions or
modules. Typical techniques for this are either using stubs/drivers or
execution from a debugger environment.
The box approach
Software testing methods are traditionally divided into white- and black-
box testing.
White-Box testing
White-box testing (also known as clear box testing, glass box testing,
transparent box testing and structural testing) tests internal structures
or workings of a program, as opposed to the functionality exposed to the
end-user. In white-box testing an internal perspective of the system, as
well as programming skills, are used to design test cases.
While white-box testing can be applied at the unit, integration and
system levels of the software testing process, it starts at the unit level.
It can test paths within a unit, paths between units during integration,
and between subsystems during a systemlevel test. Though this method
of test design can uncover many errors or problems, it might not detect
unimplemented parts of the specification or missing requirements.
Techniques used in white-box testing include:
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 - intentionally introducing faults to gauge
the efficacy of testing strategies
Black-box testing

Black box diagram
Black-box testing treats the software as a "black box", examining
functionality without any knowledge of internal implementation. The
tester is only aware of what the software is supposed to do, not how it
does it.
One advantage of the black box technique is that no programming
knowledge is required.
Specification-based testing aims to test the functionality of software
according to the applicable requirements. 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
same or not as as the expected value specified in the test case.
Grey-box testing
Grey-box testing (American spelling: gray-box testing) involves
having knowledge of internal data structures and algorithms for purposes
of designing tests, while executing those tests at the user, or black-box
level. The tester is not required to have full access to the software's
source code. 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.

Visual testing
The aim of visual testing is to provide developers with the ability to
examine what was happening at the point of software failure by
presenting the data in such a way that the developer can easily nd the
information he requires, and the information is expressed clearly.
Visual testing provides a number of advantages. The quality of
communication is increased dramatically because testers can show the
problem (and the events leading up to it) to the developer as opposed to
just describing it and the need to replicate test failures will cease to exist
in many cases. The developer will have all the evidence he requires of a
test failure and can instead focus on the cause of the fault and how it
should be fixed.

Testing levels
Tests are frequently grouped by where they are added in the software
development process, or by the level of specificity of the test. The main
levels during the development process as defined by the SWEBOK
guide are unit-, integration-, and system testing that are distinguished by
the test target without implying a specific process model.
[30]
Other test
levels are classified by the testing objective.
[30]

Unit testing
Unit testing, also known as component testing, refers to tests that verify
the functionality of a specific section of code, usually at the function
level. In an object-oriented environment, this is usually at the class level,
and the minimal unit tests include the constructors and destructors.
[31]

These types of tests are usually written by developers as they work on
code (white-box style), to ensure that the specific function is working as
expected. One function might have multiple tests, to catch corner cases
or other branches in the code. Unit testing alone cannot verify the
functionality of a piece of software, but rather is used to assure that the
building blocks the software uses work independently of each other.
Integration testing
Integration testing is any type of software testing that seeks to verify the
interfaces between components against a software design. Software
components may be integrated in an iterative way or all together ("big
bang"). Normally the former is considered a better practice since it
allows interface issues to be localised more quickly and fixed.
Integration testing works to expose defects in the interfaces and
interaction between integrated components (modules). Progressively
larger groups of tested software components corresponding to elements
of the architectural design are integrated and tested until the software
works as a system.
[32]

System testing
System testing tests a completely integrated system to verify that it
meets its requirements.
[33]

Acceptance testing
At last the system is delivered to the user for Acceptance testing.

Top-down and bottom-up
Bottom Up Testing is an approach to integrated testing where the lowest level
components (modules, procedures, and functions) are tested first, then integrated
and used to facilitate the testing of higher level components. After the integration
testing of lower level integrated modules, the next level of modules will be formed
and can be used for integration testing.
The process is repeated until the components at the top of the hierarchy are tested.
This approach is helpful only when all or most of the modules of the same
development level are ready
]
This method also helps to determine the levels of
software developed and makes it easier to report testing progress in the form of a
percentage.

Top down Testing is an approach to integrated testing where the top integrated
modules are tested and the branch of the module is tested step by step until the end
of the related module.

Installation testing
An installation test assures that the system is installed correctly and working at
actual customer's hardware.

Compatibility testing
A common cause of software failure (real or perceived) is a lack of its
compatibility with other application software, operating systems (or operating
system versions, old or new), or target environments that differ greatly from the
original (such as a terminal or GUI application intended to be run on the desktop
now being required to become a web application, which must render in a web
browser). For example, in the case of a lack of backward compatibility, this can
occur because the programmers develop and test software only on the latest
version of the target environment, which not all users may be running. This results
in the unintended consequence that the latest work may not function on earlier
versions of the target environment, or on older hardware that earlier versions of the
target environment was capable of using. Sometimes such issues can be fixed by
proactively abstracting operating system functionality into a separate program
module or library.
Regression testing
Regression testing focuses on finding defects after a major code change has
occurred. Specifically, it seeks to uncover software regressions, or old bugs that
have come back. Such regressions occur whenever software functionality that was
previously working correctly stops working as intended. Typically, regressions
occur as an unintended consequence of program changes, when the newly
developed part of the software collides with the previously existing code


Destructive testing
Destructive testing attempts to cause the software or a sub-system to fail. It verifies
that the software functions properly even when it receives invalid or unexpected
inputs, thereby establishing the robustness of input validation and error-
management routines .Software fault injection, in the form of fuzzing, is an
example of failure testing. Various commercial non-functional testing tools are
linked from the software fault injection page; there are also numerous open-source
and free software tools available that perform destructive testing.
Further information: Exception handling and Recovery testing


Software performance testing
Performance testing is generally executed to determine how a system or sub-
system performs in terms of responsiveness and stability under a particular
workload. It can also serve to investigate, measure, validate or verify other quality
attributes of the system, such as scalability, reliability and resource usage.
Load testing is primarily concerned with testing that the system can continue to
operate under a specific load, whether that be large quantities of data or a large
number of users. This is generally referred to as software scalability. The related
load testing activity of when performed as a non-functional activity is often
referred to as endurance testing. Volume testing is a way to test software functions
even when certain components (for example a file or database) increase radically
in size. Stress testing is a way to test reliability under unexpected or rare
workloads. Stability testing (often referred to as load or endurance testing) checks
to see if the software can continuously function well in or above an acceptable
period.
There is little agreement on what the specific goals of performance testing are. The
terms load testing, performance testing, reliability testing, and volume testing, are
often used interchangeably.
Further information: Scalability testing
Usability testing
Usability testing is needed to check if the user interface is easy to use and
understand. It is concerned mainly with the use of the application.
Accessibility
Accessibility testing may include compliance with standards such as:
Americans with Disabilities Act of 1990
Section 508 Amendment to the Rehabilitation Act of 1973
Web Accessibility Initiative (WAI) of the World Wide Web Consortium
(W3C)
Security testing
Security testing is essential for software that processes confidential data to prevent
system intrusion by hackers.