Week 14 last

2. Software testing is a formal process carried out by a
specialized testing team in which a software unit,
several integrated software units or an entire software
package are examined by running the programs on a
computer. All the associated tests are performed
according to approved test procedures on approved
test cases.
Software Tests - Definition

3. The purpose of running tests is to find errors in
software that is to be delivered or released to
customers.
Software released to customers must be free of
bugs or errors, that is, it has to be as robust as
possible.
Software Testing
Software testing is the process of Evaluating deliverable to find
errors and detect differences between given input and expected
output.

4. Testing Goals
•Verification: Have we built the software right?
•Validation: Have we built the right software?
Bug-free, meets specs
Meets customers’ needs

5. Direct objectives
a. To identify and reveal as many errors as possible in the
tested software
b. To bring the tested software, after correction of the
identified errors and retesting, to an acceptable level of
quality.
c. To perform the required tests efficiently and effectively,
within the limits budgetary and scheduling limitation.
Indirect objectives
a. To compile a record of software errors for use in error
prevention (by corrective and preventive actions)
Software Testing Objectives

6. Testing approaches
• Formal: scheduled in advance; central in the development
process; not ad hoc.
• Specialized Testing Team: independent test team or external
consultancy. Unit tests by developers/programmers.
• Running the program – a must; nothing static.
• Approved Test Procedures: use a plan approved.
• Approved Test Cases: All planned; all tests undertaken.

7. Testing Strategies
• Incremental testing strategies:
- Test incrementally:
•Bottom-up testing
•Top-down testing
• Big bang testing
Test entire software at one time.

8. M9
M8
M1 M2 M3 M4 M5 M6 M7
M10
M11
Integration A
Integration B Integration c
Stage 2
Stage 4
Stage 3
Stage 1
Bottom-up testing
Explain sequence
Bottom-up testing is a specific type of integration testing that tests the
lowest components of a code base first.

9. M9
M8
M1 M2
M3 M4 M5
M6 M7
M10
M11
Integration C
Integration A
Integration B
Stage 3
Stage 1
Stage 2
Stage 5
Integration D
Stage 4
Stage 6
Top-down testing
The top integrated elements are tested first

10. Top-down testing of module M8 Bottom-up testing of module M8
Module
on test
M9
Stub
of M2
Stub
of M1
M8 Module
on test
Drive
of M9
M2M1
M8
Module
tested in an
earlier
stage
Modules
tested in an
earlier
stage
Use of Stubs and Drivers
for Incremental Testing

11. Comparison: Bottom-Up versus Top Down
Bottom-Up Top Down
Advantages  Ease of its performance
 It is possibilities to demonstrate the
entire program functions shortly
 Can show early analysis and design flaws
 Easy to add functionality via stubs and
drivers
Disadvantage
s
 Lateness at which the program as a whole
can be observed.
 Structure may be off
 Sometimes awkward to pass dummy data
and to accept returned data
 Requires complicated programming and
relative difficulty of analyzing the results
of tests
• Developer can select any strategy – top down or bottom up.
• The testing strategy needs to follow the development strategy.

12. Big Bang Approach vs Incremental
• Big Bang: In general, not a good approach, unless program is very small
and not terribly complicated.
– Difficult to identify errors and where they are located.
– Simply way too much code / functionality to evaluate at one time.
• Incremental testing provides a number of advantages
– Test on usually small hunks of code, like unit or integration tests.
– Easier to identify errors than with whole project
– Correction is much simpler and requires far fewer resources too.
– Find errors much earlier in process.
– Prevents migration of errors into later, more complex stages.
– But you do have overhead of developing drivers and stubs and drivers for integration
testing.
– Also, you carry out many testing operations on the same program vice only a single testing
operation.
• Best: generally incremental approach is preferred despite its
disadvantages.

13. • Black boxBlack box
• White boxWhite box
• Gray boxGray box

14. BLACK BOX TESTING, also known as Behavioral Testing, is a software testing
method in which the internal structure/design/implementation of the item
being tested is not known to the tester. These tests can be functional or non-
functional, though usually functional.
Example
Test an app without the knowledge of the internal structures of standalone
application, for instance, run the app and use its window forms without checking its
internal code and verifying the outputs against the expected outcome.

15. Levels Applicable To
Black Box Testing method is applicable to the following levels of software testing:
1. Integration Testing
2. System Testing
3. Acceptance Testing
The higher the level, and hence the bigger and more complex the box, the more black-box
testing method comes into use

16. Techniques
Following are some techniques that can be used for designing black box tests.
 Equivalence Partitioning: It is a software test design technique that involves
dividing input values into valid and invalid partitions and selecting
representative values from each partition as test data.
 Boundary Value Analysis: It is a software test design technique that involves
the determination of boundaries for input values and selecting values that are
at the boundaries and just inside/ outside of the boundaries as test data.
 Cause-Effect Graphing: It is a software test design technique that involves
identifying the cases (input conditions) and effects (output conditions),
producing a Cause-Effect Graph, and generating test cases accordingly

17. Advantages
1.Tests are done from a user’s point of view and will help in exposing discrepancies in the
specifications.
2.Tester need not know programming languages or how the software has been
implemented.
3.Tests can be conducted by a body independent from the developers, allowing for an
objective perspective and the avoidance of developer-bias.
4.Test cases can be designed as soon as the specifications are complete.
Disadvantages
1.Only a small number of possible inputs can be tested and many program paths will be left
untested.
2.Without clear specifications, which is the situation in many projects, test cases will be
difficult to design.
3.Tests can be redundant if the software designer/developer has already run a test case.

18. WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing or Structural Testing)
•It is a software testing method in which the internal structure/design/implementation of
the item being tested is known to the tester.
•The tester chooses inputs to exercise paths through the code and determines the
appropriate outputs. Programming know-how and the implementation knowledge is
essential.
•Testing based on an analysis of the internal structure of the component or system.
•Statement testing, decision testing, condition coverage all of them uses white box
technique.

19. Example
A tester, usually is a developer/programmer as well, studies the implementation code of a
certain field on applications, determines all legal (valid and invalid) AND illegal inputs and
verifies the outputs against the expected outcomes, which is also determined by studying
the implementation code.
Levels Applicable To
White Box Testing method is applicable to the following levels of software testing:
 Unit Testing: For testing paths within a unit.
 Integration Testing: For testing paths between units.
 System Testing: For testing paths between subsystems.
However, it is mainly applied to Unit Testing

20. Advantages
 Testing can be commenced at an earlier stage. One need not wait for the GUI to
be available.
 Testing is more thorough, with the possibility of covering most paths.
Disadvantages
 Since tests can be very complex, highly skilled resources are required, with a
thorough knowledge of programming and implementation.
 Test script maintenance can be a burden if the implementation changes too
frequently.
 Since this method of testing is closely tied to the application being tested, tools
to cater to every kind of implementation/platform may not be readily available.

21. GRAY BOX TESTING is a software testing method which is a combination of Black Box
Testing method and White Box Testing method. In Black Box Testing, the internal structure
of the item being tested is unknown to the tester and in White Box Testing the internal
structure is known.
In Gray Box Testing, the internal structure is partially known. This involves having access to
internal data structures and algorithms for purposes of designing the test cases, but
testing at the user, or black-box level.

22. Example
An example of Gray Box Testing would be when the codes for two units/modules are
studied (White Box Testing method) for designing test cases and actual tests are
conducted using the exposed interfaces (Black Box Testing method).
Levels Applicable To
Though Gray Box Testing method may be used in other levels of testing, it is primarily
used in Integration Testing.

23. TEST PLAN DEFINITION
A Software Test Plan is a document describing the testing scope and activities. It is the
basis for formally testing any software/product in a project.
Pre-Requist
Project plan should be available before developing a Test Plan
TEST PLAN TYPES
One can have the following types of test plans:
1.Master Test Plan: A single high-level test plan for a project/product that unifies all other test
plans.
2.Testing Level Specific Test Plans: Plans for each level of testing.
 Unit Test Plan
 Integration Test Plan
 System Test Plan
 Acceptance Test Plan
3.Testing Type Specific Test Plans: Plans for major types of testing like
 Performance Test Plan
 Security Test Plan

24. Test Plan Identifier:
• Provide a unique identifier for the document. (Adhere to the Configuration
Management System if you have one.)
Introduction:
• Provide an overview of the test plan.
• Specify the goals/objectives.
• Specify any constraints.
References:
• List the related documents, with links to them if available, including the
following:
• Project Plan
• Configuration Management Plan

25. Test Items:
• List the test items (software/products) and their versions.
Features to be Tested:
• List the features of the software/product to be tested.
• Provide references to the Requirements and/or Design specifications of the
features to be tested
Features Not to Be Tested:
• List the features of the software/product which will not be tested.
• Specify the reasons these features won’t be tested.
Approach:
• Mention the overall approach to testing.
• Specify the testing levels [if it’s a Master Test Plan], the testing types, and the
testing methods [Manual/Automated; White Box/Black Box/Gray Box]
Item Pass/Fail Criteria:
• Specify the criteria that will be used to determine whether each test item
(software/product) has passed or failed testing.

26. Suspension Criteria and Resumption Requirements:
• Specify criteria to be used to suspend the testing activity.
• Specify testing activities which must be redone when testing is
resumed.
Test Deliverables:
•List test deliverables, and links to them if available, including the following:
• Test Plan (this document itself)
• Test Cases
• Test Scripts
• Defect/Enhancement Logs
• Test Reports
Test Environment:
• Specify the properties of test environment: hardware, software,
network etc.
• List any testing or related tools.
Estimate:
• Provide a summary of test estimates (cost or effort) and/or provide a
link to the detailed estimation.

27. Schedule:
• Provide a summary of the schedule, specifying key test milestones, and/or
provide a link to the detailed schedule.
Staffing and Training Needs:
• Specify staffing needs by role and required skills.
• Identify training that is necessary to provide those skills, if not already acquired.
Responsibilities:
• List the responsibilities of each team/role/individual.
Risks:
• List the risks that have been identified.
• Specify the mitigation plan and the contingency plan for each risk.
Assumptions and Dependencies:
• List the assumptions that have been made during the preparation of this plan.
• List the dependencies.
Approvals:
• Specify the names and roles of all persons who must approve the plan.
• Provide space for signatures and dates. (If the document is to be printed.)

28.  Make the plan concise. Avoid redundancy and superfluousness. If you think you do
not need a section that has been mentioned in the template above, go ahead and
delete that section in your test plan.
 Be specific. For example, when you specify an operating system as a property of a
test environment, mention the OS Edition/Version as well, not just the OS Name.
 Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
 Have the test plan reviewed a number of times prior to baselining it or sending it for
approval. The quality of your test plan speaks volumes about the quality of the
testing you or your team is going to perform.
 Update the plan as and when necessary. An out-dated and unused document stinks
and is worse than not having the document in the first place.