The document discusses various techniques for software testing including: 1) Software testing verifies that software meets requirements and identifies defects. It can be implemented at any stage but most occurs after coding. 2) There are various types of testing like unit, integration, system, and acceptance testing that check different parts of the software. 3) Testing approaches include white-box (examines internal structure) and black-box (examines external behavior) techniques. Common white-box techniques involve testing all paths and boundaries.

1. Software Testing & Its Techniques
By : Shah Rukh Rayaz

2. Software Testing
• Software testing is an investigation conducted to provide
stakeholders with information about the quality of the
product or service under test. Software testing can also
provide an objective, independent view of the software to
allow the business to appreciate and understand the risks of
software implementation.

3. • Software testing can be stated as the process of validating
and verifying that a software program/application/product.
• Meets the requirements that guided its design and
development.

4. Programmer Vs Tester

5. • 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.
• A good test has a high probability of finding an error.
• A good test should be neither too simple nor too complex.
• A good test is not redundant

6. • A study conducted by NIST in 2002 reports that software bugs cost
the U.S. economy $59.5 billion annually. More than a third of this
cost could be avoided if better software testing was performed.
• The software testing team
• software testing is a part of the software quality assurance (SQA)
process.

7. Functional vs non-functional testing
• Functional testing refers to activities that verify a specific action or function of
the code. These are usually found in the code requirements documentation,
although some development methodologies work from use cases or user
stories. Functional tests tend to answer the question of "can the user do this"
or "does this particular feature work."
• Non-functional testing refers to aspects of the software that may not be
related to a specific function or user action, such as scalability or other
performance, behavior under certain constraints, or security. Non-functional
requirements tend to be those that reflect the quality of the product,
particularly in the context of the suitability perspective of its users.

8. Static vs. dynamic testing
• There are many approaches to software testing. Reviews,
walkthroughs, or inspections are considered as static testing,
whereas actually executing programmed code with a given
set of test cases is referred to as dynamic testing

9. Software verification and validation
• Verification:
 Are we building the Product Right. or
 Have we built the software right? (i.e., does it match the
specification).
• Validation:
 Are we building the Right Product. Or
 Have we built the right software? (i.e., is this what the
customer wants).

10. Unit testing
Unit testing, also known as component testing, refers to tests
that verify the functionality of a specific section of code.
Integration testing.
Integration testing is any type of software testing that seeks
to verify the interfaces between components against a
software design.
1) Top-down integration.
i. Depth-first integration
ii. Breadth –first integration.
2) Bottom-up integration.

11. Top-down integration.
• Is an incremental approach to construction of the software
architecture.
• Modules are integrated by moving downwards by.
i. Depth-first integration
ii. Breadth –first integration.

13. – Depth-first integration would integrate all components on a
major control path of the structure
– Breadth-first integration incorporates all components directly
subordinate at each level, moving across the structure
horizontally .

14. Bottom-up integration testing
0. Low level components are combined in clusters that perform a specific software
function.
1. A driver (control program) is written to coordinate test case input and output.
2. The cluster is tested.
3. Drivers are removed and clusters are combined moving upward in the program
structure.

15. Regression testing
• Regression testing is the process of testing changes to
computer programs to make sure that the older programming
still works with the new changes.
• Smoke Testing
Smoke testing is done for the software in order to verify that
the software is stable enough for further testing. it has a
collection of written tests .

16. System Testing
• Series of different tests whose primary purpose is to full
exercise the computer based system.
1) Recovery Testing
– Software fails in various ways
– MTTR
2) Security Testing
 Hackers

17. 3) Stress Testing. (abnormal conditions)
Ten Interrupts per second, when one or two is the average
rate.
• 4) Performance Testing
– Coupled with stress testing

18. Alpha & Beta Testing
• Acceptance Testing
1. Alpha testing occurs before beta testing.
2. Alpha testing clears out most of the major bugs in a program while beta
testing is more like polishing the program.
3. Alpha testing is often not open to the public while beta testing can
often involve the public

19. Software Bug
• A software bug is the common term used to describe an
error, flaw, mistake, failure, or fault in a computer program.

20. The box approach
Software testing methods are traditionally divided into white-
and black-box testing. These two approaches are used to
describe the point of view that a test engineer takes when
designing test cases.
1)White-box testing
2)Black –box testing

21. White-box testing/Glass Box
• Using white-box testing method, the software engineer can
derive test cases that
i. Guarantee that all independent paths within a module have
been exercised at least once.
ii. Exercise all logical decision on their true & false sides
iii. Execute all loops at their boundaries vales.
iv. Exercise internal data structure.

22. Basis Path Testing
• Each circle, called a flow graph node, represents one or more
procedural statements..
• The arrows on the flow graph, called edges or links, represent
flow of control .
• An edge must terminate at a node, even if the node does not
represent any procedural statements.
• Areas bounded by edges and nodes are called regions. When
counting regions, we include the area outside the graph as a
region. Each node that contains a condition is called a
predicate node

23. Independent Program Path
• An independent path is any path through the program that introduces at least one
new set of processing statements or a new condition. When stated in terms of a
flow graph, an independent path must move along at least one edge that has not
been traversed before the path is defined.

24. • For example, a set of independent paths for the flow graph illustrated in above Figure is:
• path 1: 1-11
path 2: 1-2-3-4-5-10-1-11
path 3: 1-2-3-6-8-9-10-1-11
path 4: 1-2-3-6-7-9-10-1-11
• Note: The path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is not considered to be an independent path

25. how many paths ?

26. Simply computed in one of three
ways:
• The number of regions of the flow graph correspond to the
cyclomatic complexity.
• Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V(G) = E - N + 2 where E is the number of flow graph edges, N
is the number of flow graph nodes.
• Cyclomatic complexity, V(G), for a flow graph, G, is also
defined as V(G) = P + 1 where P is the number of predicate
nodes contained in the flow graph G.

27. • The flow graph has four regions.
• V(G) = 11 edges - 9 nodes + 2 = 4.
• V(G) = 3 predicate nodes + 1 = 4.

28. Black Box Testing
• Also called behavioral testing.
• Focuses on functional requirements for a software.
• BBT is not an alternative to WBT.
• It is complementary approach that is likely to uncover a
different class of errors than WBT.
• Black box Testing attempts to find errors in the following
categories.

29. Categories
1. Incorrect or missing functions.
2. Interface errors.
3. Errors in data structure or external data base access.
4. Behavior or performance errors.
5. Initialization & termination errors.

30. Testing Principles
1. All test should be traceable to customer requirements.
2. Tests should be planned long before testing begins.
3. The Pareto principle applies to software testing.
4. Testing should begin “in the small” and progress toward
testing “in the large”.
5. Exhaustive testing is not possible.

31. Reference
• Software Engineering (A Practitioner’s Approach Six Edition)
By Roger S. Pressman. (Chapter No 5,13,14).
• http://en.wikipedia.org/wiki/softwaretesting.

32. Q&A