Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1. Introduction
In a software development project, errors can be creeping at any stage during the
development. For each phase we have discussed different techniques for detecting and
eliminating errors that originates in that phase.
During testing, the program to be tested is executed with a set of test cases, and the
output of the program for the test case is evaluated to determine if the program is
performing as it is expected to. Due to its approach, dynamic testing can only as certain
the presence of error in the program; the exact nature of the error is not usually decided
by testing. Testing forms the first step in determining the errors in a program. Clearly
the success of testing revealing errors in programs depends critically on the test cases.
Page | 1
Software Testing
Communication gaps between the developer and the business decision maker.
Time provided to a developer to complete the project.
Over commitment by the developer.
Thought processes
Background and experience
Interests
Priorities
Language
Page | 2
Software Testing
Assuming the best, previously unknown problems may present themselves during
development and testing. This can lead to problems maintaining the schedule. Failing to
adjust the feature set or schedule when problems are discovered can lead to rushed work
and flawed systems.
Testing assures the organization of the quality and integrity of the e-commerce solution.
modified. Test values and boundary conditions must both be verified. Next, the module
should undergo interface testing to check for functional errors. Only after the module
works correctly can it be released for testing to the larger system. Early detection of
errors saves rework and prevents a problem from becoming more complex in nature. As
a result, error detection during the operation of a system incurs greater direct and
indirect costs.
At a higher level, the interaction of individually correct components must be tested. For
example, if a customer enters the details of their credit card payment and are
disconnected before the order confirmation, the software must indicate the status of the
transaction when the customer reconnects to the e-commerce site. If the software
functions otherwise, it does not meet organization requirements. Another instance of
the quality of software is that of accurate tax and shipping calculations. Because all
states have different tax systems and some of them are complex, it becomes difficult for
the developer to integrate all the tax structures with multi-location shipping. This raises
the complexity of the software and increases the chance of errors.
Page | 4
Software Testing
handle this, the e-commerce solution must be able to handle the anticipated load with
minimal degradation.
The following list suggests some of the potential fallouts of an untested or under-tested
any system:
Legal suits against the entrepreneur due to a faulty transaction system. This
type of system may not have been tested for transaction software
functionality.
Loss of critical data from the database can result in untraceable
transactions. This could again invite legal action and losses due to the
digression of the site visitors to competitors sites.
Insecure transactions can cause losses to customers and may result in the
withdrawal of certification by the security certification agency.
System may breakdown if the system has not been tested. A system
breakdown results in loss of time due to restoration of service. Fixing the
error can involve both direct and indirect costs.
Prepare comprehensive test plan specifications and test cases for each level of
testing. Supplement these with the test data and test logs. Test plans for system
testing may involve operators and test plans because acceptance testing
involves customers.
Design the test cases to test system restrictions, such as file and database size
(stress testing).
Develop the data to test specific cases. Copies of live files must not be used
except for Acceptance testing.
Page | 5
Software Testing
3. Heuristics of Software
Testing
Software testability is how easily, completely and conveniently a computer program
canbe tested.Software engineers design a computer product, system or program keeping
in mind theproduct testability. Good programmers are willing to do things that will help
the testingprocess and a checklist of possible design points, features and so on can be
useful in negotiating with them.
Page | 6
Software Testing
3.1 Visibility
Visibility is our ability to observe the states and outputs of the software under test.
Page | 7
Software Testing
3.2 Control
Control refers to our ability to provide inputs and reach states in the software under
test.The features to improve controllability are:
Test Interfaces: Interfaces may be provided specifically for testing e.g. Excel
and Xconq etc. Existing interfaces may be able to support significant testing e.g.
Install Shield, AutoCAD, Tivoli, etc.
Page | 8
Software Testing
3.3.1 Observability
What we see is what we test.
Distinct output should be generated for each input
Current and past system states and variables should be visibleduring testing
All factors affecting the output should be visible.
Incorrect output should be easily identified.
Source code should be easily accessible.
Internal errors should be automatically detected (through self-testingmechanisms)
and reported.
3.3.2 Controllability
The better we control the software, the more the testing process can be automated and
optimized.
Check that
All outputs can be generated and code can be executed throughsome combination of
input.
Software and hardware states can be controlled directly by thetest engineer.
Inputs and output formats are consistent and structured.
Test can be conveniently, specified, automated and reproduced.
3.3.3 Decomposability
By controlling the scope of testing, we can quickly isolate problems and perform
effective and efficient testing. The software system should be built fromindependent
modules which can betested independently.
3.3.4 Simplicity
Page | 9
Software Testing
The less there is to test, the more quickly we can test it.The points to consider in this
regard are functional (e.g. minimum set of features), structural (e.g. architecture is
modularized) and code (e.g. a codingstandard is adopted) simplicity.
3.3.5 Stability
The fewer the changes, the fewer are the disruptions to testing.The changes to software
should be infrequent, controlled and not invalidating existing tests. The software should
be able to recover well from failures.
3.3.6 Understandability
The more information we will have, the smarter we will test.The testers should be able
to understand the design, changes to the design and the dependencies between internal,
external and shared components.Technical documentation should be instantly
accessible, accurate, well organized, specific and detailed.
Suitability
The more we know about the intended use of the software, the better we can organize
our testing to find important bugs.The above heuristics can be used by a software
engineer to develop a software configuration (i.e. program, data and documentation)
that is convenient to test and verify.
4. Types of Testing
Testing is usually applied to different types of targets in different stages of the
softwares delivery cycle. The stages progress from testing small components (unit
testing) to testing completed system (system testing).
Page | 10
Software Testing
Unit test, implemented early in the iteration, focuses on verifying the smallest testable
elements of the software. Unit testing is typically applied to components in the
implementation model to verify that control flow and data flow are covered and
function as expected. These expectations are based on how the components participate
in executing a use case. The implementers perform unit test as the unit is developed.
The detail of unit test is described in the implementation work flow.
System testing is done when the software is functioning as a whole or when- defined
subsets of its behavior are implemented. The target in this case is the whole
implementation model for the system.
Acceptance testing is the final test action prior to deploying the software. The goal of
Acceptance testing is to verify that the software is ready and can be used by the end-
users to perform those functions and tasks the software was built to do.
In the introduction to Test, it was stated that there is much more to testing software than
testing only the functions, interface and response time characteristics of a target-of-test.
Additional test must focus on characteristics/ attributes such as the target-as-test:
Integrity (resistance to failure)
Page | 11
Software Testing
Often individual tests are categorized, implemented and executed in groups, most
commonly arranged by similarities in their test objectives or the quality dimension they
address, such as:
5. Test cases
A Test case a set of test inputs execution conditions and expected results developed for
a particular objective such as to exercise a particular program path or to verify
compliance with a specific requirement.
Unit testing is implemented against the smallest testable element(units) of the software
and involves testing the internal structure such logic and data flow and the unit function
Page | 14
Software Testing
and observable behaviors. Designing and implementing tests focused on a unit internal
structure relies upon the knowledge of the units implementation (white- box approach).
The design and implementation of test s to verify the units observable behaviors and
functions does not rely upon knowledge of the implementation and therefore is known
as black-box approach.
The purpose of a black-box test is to verify the units specified function and observable
behavior without knowledge of how the unit implements the function and behavior.
Block-box tests focus and relay upon the units input and output.Deriving unit test
based upon the black-box approach utilized the input and output arguments of the units
operation and / or output state for evolution. For example,the operation may include an
algorithm (requiring two values as input and return a third as output) or initiate change
in an objects or components state such as adding or deleting a database record. Both
must be tested completely. To test an operation you should derive sufficient test cases to
verify the following:
For each valid used as input .an appropriate value was returned by the operation
For each valid input state , an appropriate output state occur
For each invalid input state , an appropriate output state occur
Page | 15
Software Testing
Remember to treat the object state as an input argument. If, for example, test an
operation add on an object Set, test add with values from all of Sets equivalence
classes, that is, with a full Set, with some element in Set, and with an empty Set.
Ideally, you would like all the test cases inone iteration to be used as test cases
in the later iterations. The following guidelines should be used to identify, design, and
implement test cases that maximize the value of regression testing and re-use. While
minimizing maintenance:
Ensures the test case identify only the critical data elements(those needed to
create/support the condition being tested).
Ensure each test case describes or represents a unique set of inputs or sequence of
events that result in a unique behavior by the target-of-test.
Page | 16
Software Testing
Page | 17
Software Testing
6. Finding Faults
It is commonly believed that the earlier a defect is found the cheaper it is to fix it. For
example, if a problem in the requirements is found only post-release, then it would cost
10100 times more to fix than if it had already been found by the requirements review.
Program testing and fault detection can be aided significantly by testing tools and
debuggers. Testing/debug tools include features such as:
Automated functional GUI testing tools are used to repeat system-level tests
through the GUI.
Performance analysis (or profiling tools) that can help to highlight hot spots and
resource usage.
Page | 18
Software Testing
A test specification is called a test plan. The developers are well aware what test plans
will be executed and this information is made available to management and the
developers. The idea is to make them more cautious when developing their code or
making additional changes. Some companies have a higher-level document called a test
strategy.
A traceability matrix is a table that correlates requirements or design documents to test documents. It is
used to change tests when the source documents are changed, or to verify that the test results are
correct.
The test script is the combination of a test case, test procedure, and test data. Initially
the term was derived from the product of work created by automated regression test
tools. Today, test scripts can be manual, automated, or a combination of both.
The most common term for a collection of test cases is a test suite. The test suite often
also contains more detailed instructions or goals for each collection of test cases. It
definitely contains a section where the tester identifies the system configuration used
Page | 19
Software Testing
during testing. A group of test cases may also contain prerequisite states or steps, and
descriptions of the following tests.
In most cases, multiple sets of values or data are used to test the same functionality of a
particular feature. All the test values and changeable environmental components are
collected in separate files and stored as test data. It is also useful to provide this data to
the client and with the product or a project.
6.3.6Test harness
The software, tools, samples of data input and output, and configurations are all referred
to collectively as a test harness.
Page | 20
Software Testing
7. Conclusion
Software testing is an art. Most of the testing methods and practices are not very
different from 20 years ago. Good testing also requires a tester's creativity, experience
and intuition, together with proper techniques.
Testing is more than just debugging. Testing is not only used to locate defects and
correct them. It is also used in validation, verification process, and reliability
measurement.
Testing is expensive. Automation is a good way to cut down cost and time. Testing
efficiency and effectiveness is the criteria for coverage-based testing techniques.
Complete testing is infeasible. Complexity is the root of the problem. At some point,
software testing has to be stopped and product has to be shipped. The stopping time can
be decided by the trade-off of time and budget. Or if the reliability estimate of the
software product meets requirement.
Page | 21
Software Testing
8. Bibliography
Books
An Integrated Approach to Software Engineering by Pankaj Jalote
Websites
www.4shared.com
www.google.com
www.scribd.com
www.wikipedia.org
Page | 22