The objective of software testing is to find greatest possible number of errors with a manageable amount of effort applied over a realistic time span

1. Software Testing

2. Software Testing
 The objective of software testing is to find
greatest possible number of errors with a
manageable amount of effort applied over a
realistic time span

3. Testing Objectives
1. Testing is a process of executing a program
with the intent of finding an error.
2. A good test case is one that has a high
probability of finding an as-yet undiscovered
error.
3. A successful test is one that uncovers an as-
yet-undiscovered error.

4. Testing Principles
 All tests should be traceable to customer
requirements
 Tests should be planned long before testing
begins.
 Testing should begin “in the small” and progress
toward testing “in the large.”
 Exhaustive testing is not possible.
 To be most effective, testing should be
conducted by an independent third party.

5. Characteristics of Testing
 Testability Software testability is simply how easily [a
computer program] can be tested.
 Operability. "The better it works, the more efficiently
it can be tested.“
 Observability. "What you see is what you test.“
 Controllability. "The better we can control the
software, the more the testing can be automated and
optimized.“
 Decomposability. "By controlling the scope of testing,
we can more quickly isolate problems and perform
smarter retesting."

6.  Simplicity. "The less there is to test, the more
quickly we can test it.“
 Stability. "The fewer the changes, the fewer the
disruptions to testing.“
 Understandability. "The more information we
have, the smarter we will test."

7. Testing Strategy
 Any Testing strategy must incorporate
 Test planning
 Test case design
 Test execution
 Resultant data collection and evaluation

8. Generic Characteristics of S/W Testing Strategy
 To perform effective testing, a software team should
conduct effective formal technical reviews. By doing this,
many errors will be eliminated before testing commences
 Testing begins at the component level and works
"outward" toward the integration of the entire computer-
based system.
 Different testing techniques are appropriate at different
points in time.
 Testing is conducted by the developer of the software
and (for large projects) an independent test group.
 Testing and debugging are different activities, but
debugging must be accommodated in any testing strategy.

9. Attributes of a “good” test:
 A good test has a high probability of finding an
error.
 A good test is not redundant.
 A good test should be “best of breed”
 A good test should be neither too simple nor
too complex.

10. Verification and Validation
 Verification refers to the set of activities that ensure
that software correctly implements a specific function.
 Validation refers to a different set of activities that
ensure that the software that has been built is traceable
to customer requirements.
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"

11. SQA activities of Verification and validation
 Formal Technical Reviews
 Quality And Configuration Audits
 Performance Monitoring
 Simulation, Feasibility Study
 Documentation Review
 Database Review
 Algorithm Analysis,
 Development Testing
 Qualification Testing
 Installation Testing

12. Developer versus Tester
 Who knows the program better than its developers?
 The software engineer creates a computer program, its
documentation, and related data structures.
 The role of an independent test group (ITG) is to remove the
inherent problems associated with letting the builder test
the thing that has been built.
 The developer and the ITG work closely throughout a
software project to ensure that thorough tests will be
conducted.
 While testing is conducted, the developer must be available
to correct errors that are uncovered.

15. Software Testing Strategy - Spiral

16. Spiral view of Testing Strategy
 Unit testing begins at the vortex of the spiral and
concentrates on each unit (i.e., component) of the
software as implemented in source code.
 Testing progresses by moving outward along the spiral
to integration testing, where the focus is on design and the
construction of the software architecture.
 Taking another turn outward on the spiral, we
encounter validation testing, where requirements
established as part of software requirements analysis
are validated against the software that has been
constructed.
 Finally, we arrive at system testing, where the software and
other system elements are tested as a whole

18. Procedural view of Testing Strategy

20. Strategic Issues
 Specify product requirements in a quantifiable manner
long before testing commences.
 State testing objectives explicitly.
 Understand the users of the software and develop a
profile for each user category.
 Develop a testing plan that emphasizes “rapid cycle
testing.”
 Build “robust” software that is designed to test itself.
 Use effective formal technical reviews as a filter prior to
testing.
 Conduct formal technical reviews to assess the test
strategy and test cases themselves.
 Develop a continuous improvement approach for the
testing process.

21. Unit Testing

25. Integration Testing Strategies
 Incremental Integration
 Top-down Integration
 Depth-First Integration
 Breadth-First Integration
 Bottom-Up Integration
 Non-Incremental Integration

26. Integration Process Steps
1. The main control module is used as a test driver and
stubs are substituted for all components directly
subordinate to the main control module.
2. Depending on the integration approach selected (i.e.,
depth or breadth first), subordinate stubs are replaced
one at a time with actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is
replaced with the real component.
5. Regression testing (Section 18.4.3) may be conducted
to ensure that new errors have not been introduced.

28. Depth-First IntegrationDepth-First IntegrationDepth-First Integration
Integrating Path : M1 – M2 – M5 – M8

29. Breadth-First Integration
Integrating Path : M2 – M3 – M4

30. Bottom-up Integration

31. Bottom-up Integration
A bottom-up integration strategy may be implemented
with the following steps:
1. Low-level components are combined into clusters
(sometimes called builds) that perform a specific software
sub-function.
2. A driver (a control program for testing) is written to
coordinate test case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving
upward in the program structure.

33. Regression Testing
 Each time a new module is added as part of
integration testing, the software changes. New
data flow paths are established, new I/O may
occur, and new control logic is invoked.
 Regression testing is the re-execution of some
subset of tests that have already been conducted
to ensure that changes have not propagated
unintended side effects.

34. Smoke Testing
 Smoke testing is an integration testing
approach that is commonly used when
“shrinkwrapped” software products are being
developed.
 It is designed as a pacing mechanism for time-
critical projects, allowing the software team to
assess its project on a frequent basis.

35. Benefits of Smoke Testing
 Integration risk is minimized.
 The quality of the end-product is improved.
 Error diagnosis and correction are simplified.
 Progress is easier to assess.

36. The following criteria and corresponding tests are applied
for all test phases:
 Interface integrity. Internal and external interfaces are
tested as each module (or cluster) is incorporated into
the structure.
 Functional validity. Tests designed to uncover
functional errors are conducted.
 Information content. Tests designed to uncover
errors associated with local or global data structures are
conducted.
 Performance. Tests designed to verify performance
bounds established during software design are
conducted.

37. Validation Testing
 Testing focuses on user-visible actions and user-
recognizable output from the system.
 Validation succeeds when software functions in
a manner that can be reasonably expected by the
customer.
 Reasonable expectations are defined in the
Software Requirements Specification - a document
that describes all user-visible attributes of the
software.

38. Validation Test Criteria
Validation should ensure
 Functional requirements are satisfied
 Behavioral characteristics are achieved
 Performance requirements are attained
 Documentation is correct
 Usability, Transportability, Compatibility,
Error recovery and Maintainability are met

39. Alpha and Beta Testing
 Software product builders use a process called
alpha and beta testing to uncover errors that only
the end-user seems able to find.
 The alpha test is conducted at the developer's
site by a customer.
 The beta test is conducted at one or more
customer sites by the end-user of the software.

40. System Testing
 System testing is actually a series of different
tests whose primary purpose is to fully exercise
the computer-based system.
 Software is incorporated with other system
elements (e.g., hardware, people, information),
and a series of system integration and validation
tests are conducted.

41. Types of System Testing
 Recovery testing is a system test that forces the
software to fail in a variety of ways and verifies
that recovery is properly performed.
 Security testing attempts to verify that
protection mechanisms built into a system will,
in fact, protect it from improper penetration.
 Performance testing is designed to test the
run-time performance of software within the
context of an integrated system.

42. Stress Testing
 Stress tests are designed to confront programs with
abnormal situations.
 Stress testing executes a system in a manner that
demands resources in abnormal quantity, frequency, or
volume.
 Examples:
(1) special tests may be designed that generate ten interrupts per
second, when one or two is the average rate
(2) input data rates may be increased by an order of magnitude
to determine how input functions will respond,
(3) test cases that require maximum memory or other resources
are executed,

43. Stress Testing
 Stress testing is done to evaluate a system beyond the
limits of specified requirements or resources, to ensure
that system does not break.
 The product is overloaded deliberately to simulate the
resource crunch and to find out the behavior
 Stress testing helps in understanding how the system
can behave under extreme situations (insufficient
memory, inadequate hardware)

44. Stress testing
 In stress testing, the load is generally increased through
various means such as increasing the number of clients, users
and transactions.
 When the load keeps on increasing, the product reaches a
stress point when some of the transactions start failing due
to resources not being available. The failure rate may go up
beyond this point.
 To continue the stress testing, the load is slightly reduced
below this stress point to see whether the product recovers
and whether the failure rate decreases appropriately
 This exercise of increasing/decreasing the load is performed
two or three times to check for consistency in behavior and
expectations.

45. MTTR (Mean Time to Recovery)
Stress point
Increasing load Decreasing load
Failure
rate
 The time required for the product to quickly recover from the
failures is represented as MTTR

46. Guidelines for Stress testing
 The following guidelines can be used to select
the tests for stress testing
 Repetitive tests
 Concurrency
 Magnitude
 Random variation

47. Debugging
 Debugging is not testing but always occurs as a
consequence of testing.
 Debugging occurs as a consequence of successful
testing.
 When a test case uncovers an error, debugging is
the process that results in the removal of the
error.

48. Debugging Process

49. Testing Types

50. WHITE-BOX TESTING
 White-box testing, sometimes called glass-box testing,
is a test case design method that uses the control
structure of the procedural design to derive test cases.
 The software engineer can derive test cases that
(1) guarantee that all independent paths within a
module have been exercised at least once,
(2) exercise all logical decisions on their true and false
sides,
(3) execute all loops at their boundaries and within their
operational bounds,
(4) exercise internal data structures to ensure their
validity.

51. WHITE-BOX TESTING
Static testing
Desk Checking
Code Walkthrough
Code Inspection
Structural Testing
Code Coverage
Statement coverage
Path coverage
Condition coverage
Function coverage
Code complexity
Cyclomatic complexity
Unit / code
Functional
testing

52. Static Testing
 Static testing is a type of testing which requires only the
source code of the product, not the binaries and
executables
 To find out whether
 The code works according to the functional requirements
 The code has been return in accordance with the design
developed
 The code for any functionalities has been missed out
 The code handles errors properly

53. Static testing by humans
 Sometimes human find errors that computers cannot. Ex: two
variables with similar names and the programmer used a wrong
variable by mistake in an expression
 Multiple humans read and evaluate identifies more problem
identified upfront than a computer could
 Human evaluation of the code can compare it against the
specification
 Human evaluation can detect many problems at one go and tries
to identify the root cause
 A proactive method of static testing minimizes the delay in
identification of the problem

54. Desk checking
 Manually done by the author of the code for correctness
checking
 Desk checking done before compiling and executing
 Done by comparing the code with the design or specification
 When error found, author applies the correctness for error on
spot
 Completely relies on author’s thoroughness and skills
 No structured method or formalism to ensure completeness
 No maintaining of a log or checklist
 Only effective for coding errors but not for incorrect
understanding of requirements. This is because the developers
might not have domain knowledge required to understand the
requirements.

55. Code walkthrough
 It is a group-oriented method
 It is a informal method
 Set of people look at the program and question
the author.
 The author explains the logic of the code and
answers the questions.
 Unanswered questions are noted down and
author finds the answer.

56. Code Inspection
 It is a formal method
 The focus is to detect all faults, violations and other side
effects
 Code inspection starts when author made sure the code
is ready after desk checking and walkthrough.
 Members of the meeting:
 The author of the code
 Moderator: formally runs the inspection according to the
process
 Inspectors: Provides review comments for the code
 Scribe: takes detailed notes during the meeting and circulates
them to the inspection team

57. Structural testing
 Structural testing takes into account the code, code
structure, internal design and how they are coded
 Structural testing run by computer on the built product
whereas in static testing is done by humans just using
the source code.
 A given portion of the code is exercised if a test case
causes the program to execute that portion of the code
when running the test

58. Unit/code functional testing
 Quick check by developer before subjecting the code to more
extensive code coverage testing or code complexity testing.
 Developer performs this tests knowing the input variable and
the corresponding expected output variables
 Developer can build a “debug version” of the product by
putting “intermediate print statements” and making sure
the program is passing thro the right loops and iterations the
right no. of times
 Testing the product under a debugger or an IDE by setting
“break points” at any functions or instructions.
 All the above fall under the “debugging” category rather than
“testing” category

59. Code coverage testing
 Code coverage testing involves designing and
executing test cases and finding out the
percentage of code that is covered by testing.
 Program constructs
 Sequential control flow
 Two-way decision statements (if then else)
 Multi-way decision statements ( switch)
 Loops ( while do, repeat until and for)

60. Statement coverage
 Refers to writing test cases that execute each of the program
statements
 More the code is covered, the better is the testing of the
functionalities
 Test cases can be designed to run through top to bottom
 Exceptions might make the test case not covering all the
statements
 To cover all the statements for “if constructs”, one test case
for then part and one for else part should be designed
 Switch statement is reduced as multiple “if constructs”

61. Statement coverage ( cont…)
 For better statement coverage for loop
constructs, test cases should be
 Skip the loop completely, so that the situation of the
termination condition being true before starting the
loop is tested
 Exercise the loop between once and the maximum
number of times, to check all possible “normal”
operations of the loop.
 Try covering the loop, around the boundary of n –
that is, just below n, n and just above n

62. Path coverage
 In path coverage, program is split into number
of distinct path
 A program can start from the beginning and
take any paths to its completion
 Path coverage provides a stronger condition of
coverage than statement coverage as it relates to
the various logical paths in the program rather
than just program statements

63. Condition coverage
 All the conditions may not get evaluated, even
though the right path is chosen.
 Example:
If (mm<1 || MM>12)
true
false
Valid month
invalid month
No. of Paths = 2
A – B
A – C
The path A – B has two conditions to be tested and
therefore need two test cases

64. Function coverage
 Identifies how many program functions are
covered by test cases
 The requirements of the product are mapped
into functions during the design phase and each
of the functions form a logical unit.
 Example: Inserting a row in a database

65. BASIS PATH TESTING
 Basis path testing is a white-box testing technique
 The basis path method enables the test case
designer to derive a logical complexity measure
of a procedural design and use this measure as a
guide for defining a basis set of execution paths.
 Test cases derived to exercise the basis set are
guaranteed to execute every statement in the
program at least one time during testing.

66. Flow Graph Notation
 Flow graph is a simple notation for the representation of
control flow.
 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 and are analogous to flowchart
arrows.
 Areas bounded by edges and nodes are called regions.
 When counting regions, we include the area outside the
graph as a region

67. Cyclomatic Complexity
 Cyclomatic complexity is a software metric that provides a
quantitative measure of the logical complexity of a
program.
 Cyclomatic complexity defines the number of
independent paths in the basis set of a program and
provides us with an upper bound for the number of
tests that must be conducted to ensure that all
statements have been executed at least once.
 An independent path is any path through the program that
introduces at least one new set of processing
statements or a new condition.

68. Flow graph Example

69. Independent Path
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

70. Cyclomatic complexity
Complexity is computed in one of three ways:
1. The number of regions of the flow graph correspond to the
cyclomatic complexity.
2. 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.
3. 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.

71. Computing Cyclomatic complexity
1. The flow graph has four regions.
2. V(G) = 13 edges - 11 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.

72. Graph Matrices
 A graph matrix is a square matrix whose size (i.e.,
number of rows and columns) is equal to the
number of nodes on the flow graph. Each row
and column corresponds to an identified node,
and matrix entries correspond to connections
(an edge) between nodes.

73. Graph Matrices

74. Graph Matrices

75. CONTROL STRUCTURE TESTING
 Condition Testing
 Condition testing is a test case design method that exercises the
logical conditions contained in a program module.
E1 <relational-operator> E2
where E1 and E2 are arithmetic expressions and <relational-
operator> is one of the following: <, ≤, =, ≠ (nonequality),
>, or ≥.
 A compound condition is composed of two or more simple
conditions, Boolean operators, and parentheses.

76. Loop Testing

77. BLACK-BOX TESTING
 Black-box testing, also called behavioral testing,
focuses on the functional requirements of the
software.
 Black-box testing enables the software engineer
to derive sets of input conditions that will fully
exercise all functional requirements for a
program.

78. BLACK-BOX TESTING
 Black-box testing attempts to find errors in the
following categories:
(1) incorrect or missing functions,
(2) interface errors,
(3) errors in data structures or external database
access,
(4) behavior or performance errors,
(5) initialization and termination errors.

79. Equivalence Partitioning
 Equivalence partitioning is a black box testing technique
to minimize number of permutation and combination of
input data.
 In equivalence partitioning, data is selected in such a way
that it gives as many different out put as possible with the
minimal set of data.
 If software behaves in an identical way for a set of value,
then the set is termed as equivalence class or a partition.
 It can be assumed safely that functionality of the software
will be same for any data value from the equivalence class
or partition.

80. Equivalence Partitioning
 Steps in Equivalence Partitioning
 Identifying equivalence classes or partition
 Picking one value from each partition for the complete
coverage.
 Equivalence classes may be defined according to the
following guidelines:
1. If an input condition specifies a range, one valid and two invalid
equivalence classes are defined.
2. If an input condition requires a specific value, one valid and two
invalid equivalence classes are defined.
3. If an input condition specifies a member of a set, one valid and
one invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and one invalid class
are defined.

81. Example
 For example, consider a very simple function for
awarding grades to the students. This program
follows the following guideline to award grades
 Marks 00 – 39 ------------ Grade D
 Marks 40 – 59 ------------ Grade C
 Marks 60 – 70 ------------ Grade B
 Marks 71 – 100 ------------ Grade A

82. Example
 Based on the equivalence partitioning techniques,
partitions for this program could be as follows
 Marks between 0 to 39 - Valid Input
 Marks between 40 to 59 - Valid Input
 Marks between 60 to 70 - Valid Input
 Marks between 71 to 100 - Valid Input
 Marks less than 0 - Invalid Input
 Marks more than 100 - Invalid Input
 Non numeric input - Invalid Input
Now even if you take only one data value from these partitions,
your coverage will be good.

83. Boundary Value Analysis
 Boundary value analysis leads to a selection of test cases
that exercise bounding values.
 Boundary value analysis is a test case design technique
that complements equivalence partitioning.
 Rather than selecting any element of an equivalence class,
BVA leads to the selection of test cases at the "edges" of
the class.
 Boundary value analysis is the technique of making sure
that behavior of system is predictable for the input and
output boundary conditions.
 Defects could be introduced at the boundaries very easily.

84. Example
 " Input should be greater than equal to 10 and
less than 50"
 Probably you will write something like
if (input >=10 AND input <50) then
do some
else
do some thing else.

85. Example
According to this input values from 10 to 49 are valid, but if
you make mistake in specifying the conditions, following
things can happen
 input >10 AND input <50 -------> Input value 10 in invalid now.
 input <=10 AND input <50 -------> Input value 9 is valid now.
 input >=10 AND input <=50 -----> Input value 50 is valid now
 input >=10 AND input >50 -----> Input value 49 is invalid now.
we should have following test cases for boundaries
9, 10, 11 and 48, 49, 50
lower_boundary - 1, lower_boundary, lower_boundary + 1 and
upper_boundary - 1, upper_boundary, upper_boundary + 1

86. Guidelines for BVA
1. If an input condition specifies a range bounded by
values a and b, test cases should be designed with values
a and b and just above and just below a and b.
2. If an input condition specifies a number of values, test
cases should be developed that exercise the minimum
and maximum numbers. Values just above and below
minimum and maximum are also tested.
3. If internal program data structures have prescribed
boundaries (e.g., an array has a defined limit of 100
entries), be certain to design a test case to exercise the
data structure at its boundary.

87. Testing for Specialized Environment

88. Testing for Specialized Environment
 Testing GUI
 Testing Client / Server Architecture
 Testing Documentation and Help facilities
 Testing Real-time Systems.
 Testing Websites

89. Testing GUI
 Graphical user interfaces (GUIs) present interesting
challenges for software engineers.
 Because of reusable components provided as part of
GUI development environments, the creation of the
user interface has become less time consuming and
more precise.
 The complexity of GUIs has grown, leading to more
difficulty in the design and execution of test cases.
 Finite state modeling graphs may be used to derive a
series of tests
 Due to the large number of permutations associated
with GUI operations, testing should be approached
using automated tools.

90. Testing Client/Server Architecture
 Difficulties of C/S Testing
 Distributed nature of client/server environments,
 The performance issues associated with transaction
processing,
 The potential presence of a number of different
hardware platforms,
 The complexities of network communication,
 The need to service multiple clients from a
centralized (or in some cases, distributed) database,
 The coordination requirements imposed on the
server

91.  Testing of C/S occurs at three levels
1. Individual client applications are tested in a
“disconnected” mode; the operation of the server and
the underlying network are not considered
2. The client software and associated server applications
are tested in concert, but network operations are not
explicitly exercised.
3. The complete Client/Server architecture, including
network operation and performance, is tested.

92. Testing approaches for C/S
 Application function test
 The functionality of client application is tested
 Server tests
 Co-ordination and data management functions of the server are
tested
 Database tests
 The accuracy and integrity of data stored by the server is tested
 Transaction tests
 A series of tests are created to ensure that each class of
transactions is processed according to the requirement
 Network communication tests
 These tests verify that communication among the nodes of the
network occurs correctly and that message passing, transactions,
and related network traffic occur without error.

93. Testing Documentation and Help Facility
 Errors in documentation can be as devastating
to the acceptance of the program as errors in
data or source code.
 Nothing is more frustrating than following a
user guide or an on-line help facility exactly and
getting results or behaviors that do not coincide
with those predicted by the documentation

94. Phases of documentation testing
 Documentation testing can be approached in two
phases.
1. review and inspection, examines the document for
editorial clarity.
2. live test, uses the documentation in conjunction with
the use of the actual program.

95. The following questions should be answered during both
phases:
 Does the documentation accurately describe how to
accomplish each mode of use?
 Is the description of each interaction sequence
accurate?
 Are examples accurate?
 Are terminology, menu descriptions, and system
responses consistent with the actual program?
 Is it relatively easy to locate guidance within the
documentation?
 Can troubleshooting be accomplished easily with the
documentation?

96. Questions (cont…)
 Are the document table of contents and index accurate
and complete?
 Is the design of the document (layout, typefaces,
indentation, graphics) conducive to understanding and
quick assimilation of information?
 Are all software error messages displayed for the user
described in more detail in the document? Are actions to
be taken as a consequence of an error message clearly
delineated?
 If hypertext links are used, are they accurate and
complete?
 If hypertext is used, is the navigation design appropriate
for the information required?

97. Testing for real-time systems
 Many real-time applications are time-dependent,
asynchronous nature
 The test case designer have to consider white-
and black-box test cases but also
 event handling (i.e., interrupt processing),
 the timing of the data,
 the parallelism of the tasks (processes) that handle
the data.

98. Strategy for Real-Time testing
 Task testing.
 Testing of real-time software is to test each task
independently.
 Task testing uncovers errors in logic and function but not
timing or behavior.
 Behavioral testing
 Inter-task testing.
 System testing.
 Software and hardware are integrated and a full range of
system tests (Chapter 18) are conducted in an attempt to
uncover errors at the software/hardware interface.

99. Testing Web applications
 Dimension of Quality
 Content
 Function
 Structure
 Usability
 Navigability
 Performance
 Compatibility
 Interoperability
 Security

100. Testing Strategy
 The content model for the web application is reviewed
to uncover errors
 The interface model is reviewed to ensure that all use-
case can be accommodated
 The design model for the Webapp is reviewed to
uncover navigation errors
 The user interface is tested to uncover errors in
presentation and navigation mechanics
 Selected functional components are unit tested
 Navigation throughout the architecture is tested

101.  The WebApp is implemented in a variety of
different environmental configurations that is
tested for compatibility with each configuration
 Security tests are conducted in an attempt to
exploit vulnerabilities in the WebApp or within
the environment
 Performance tests are conducted
 The WebApp is tested by a controlled and
monitored population of end-users

102. Test Planning
 A WebApp test plan identifies
 A task set to be applied as testing commences
 The work products to be produced as each testing
task is executed
 The manner in which the results of testing are
evaluated

103. Testing Process
 The testing process for WebApp begins with
tests that exercise content and interface
functionalities that id immediately visible to end-
users
 As testing proceeds, aspects of the design
architecture and navigation are exercised
 Finally the focus shifts to tests that exercise
technological capabilities that are not always
apparent to end-users

104. Testing Process
Component design
Architecture design
Navigation design
Content design
Aesthetic design
Interface
design Component
Testing
Navigation
Testing
Interface
Testing
Content
Testing
Configuration
Testing
Performance
Testing
Security
Testing
User
Technology

105.  Content Testing
 attempts to uncover errors in content
 Interface Testing
 exercises interaction mechanisms and validates aesthetic
aspects of the user interface
 Navigation Testing
 applies use cases, derived as part of the analysis activity, in
the design of test case
 Component Testing
 Exercise content and functional units within the WebApp.

106.  Configuration Testing
 Attempts to uncover errors that are specific to a particular
client or server environment
 Security Testing
 Incorporates a series of tests designed to exploit
vulnerabilities in the WebApp and its environment
 Performance Testing
 Encompasses a series of tests that are designed to assess
 How WebApp response time and reliability are affected by increased
user traffic
 Which WebApp components are responsible for performance
degradation and which usage chracteristics cause degradation to occur
 How performance degradation impacts overall WebApp objectives
and requirements

107. Testing Interface Mechanism
 Links
 Forms
 Client-side scripting
 Dynamic HTML
 Pop-up windows
 CGI scripts
 Streaming content
 Application specific interface mechanism

108. Usability Test
 Usability testing evaluates the degree to which
users interact effectively with the WebApp and
the degree to which the WebApp guides users’
action, provides meaningful feedback, and
enforces a consistent interaction approach

109. Usability Test categories
 Interactivity
 Layout
 Readability
 Aesthetic
 Display characteristics
 Time sensitivity
 Personalization
 Accessibility

110. Component level Testing
 Also called function testing
 Focuses on a set of tests that attempts to
uncover errors in WebApp functions
 Equivalence Partitioning
 Boundary value analysis
 Path testing

111. Navigation Testing
 Navigation links
 Redirects
 Bookmarks
 Frames
 Site maps
 Internal search engines

112. Security Testing
 Security elements
 Firewalls
 Authentication
 Encryption
 Authorization

113. Performance Testing
 Load Testing
 Real world loading is tested at a variety of load levels
and in a variety of combinations
 Stress Testing
 Loading is increased to the breaking point to
determine how much capacity the WebApp
environment can handle