Module2 white box testing

WHAT IS WHITE BOX TESTING?

• Every software product is realized by means of a program code.
• White box testing is away of testing the external functionality of the code
by examining and testing the program code that realizes the external
functionality.
• This is also known as clear box, or glass box or open box testing.
• This testing is usually done at the unit level.
• White box testing takes into account the program code, code structure, and
internal design flow.
• A number of defects come about because of incorrect translation of
requirements and design into program code.
• Some other defects are created by programming errors and programming
language idiosyncrasies.
• The program code represents what the product actually does (rather than
what the product is intended to do).
• Testing by looking at the program code makes us get closer to what the
product is actually doing.
• white-box testing: Testing based on an analysis of the internal structure of
the component or system.
• white-box test design technique: Procedure to derive and/or select test
cases based on an analysis of the internal structure of a component or
system.
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.

1|Page
Module2 white box testing

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.
• Reveals errors in "hidden" code.
• Spots the Dead Code or other issues with respect to best programming
practices.
• Disadvantages of White Box Testing:
Disadvantages
• Expensive as one has to spend both time and money to perform white box
testing.
• Every possibility that few lines of code are missed accidentally.
• In-depth knowledge about the programming language is necessary to
perform white box testing.
What do you verify in White Box Testing?
• White box testing involves the testing of the software code for the
following:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis
• The testing can be done at system, integration and unit levels of software
development.
• One of the basic goals of white box testing is to verify a working flow for
an application.

2|Page
Module2 white box testing

• It involves testing a series of predefined inputs against expected or desired

outputs so that when a specific input does not result in the expected output,
you have encountered a bug.
How do you perform White Box Testing?
• Two steps.
STEP 1) UNDERSTAND THE SOURCE CODE.
Step 2) CREATE TEST CASES AND EXECUTE.
STEP 1) UNDERSTAND THE SOURCE CODE.
• The first thing a tester will often do is learn and understand the source code
of the application.
• Since white box testing involves the testing of the inner workings of an
application, the tester must be very knowledgeable in the programming
languages used in the applications they are testing.
• Also, the testing person must be highly aware of secure coding practices.
• Security is often one of the primary objectives of testing software.
• The tester should be able to find security issues and prevent attacks from
hackers and naive users who might inject malicious code into the
application either knowingly or unknowingly.
Step 2) CREATE TEST CASES AND EXECUTE
• The second basic step to white box testing involves testing the application's
source code for proper flow and structure.
• One way is by writing more code to test the application's source code.
• The tester will develop little tests for each process or series of processes in
the application.
This method requires that the tester must have intimate knowledge of the code
and is often done by the developer.

3|Page
Module2 white box testing

WhiteBox Testing Example

• Consider the following piece of code

• The goal of White Box testing in software engineering is to verify all the
decision branches, loops, statements in the code.
• To exercise the statements in the above code, White Box test cases would
be
 A = 1, B = 1
 A = -1, B = -3

4|Page
Module2 white box testing

Classification of white box testing

STATIC TESTING
• Static testing is a type of testing which requires only the source code of the
product, not the binaries or executables.
• Static testing does not involve white box testing executing the programs on
computers but involves select people going through the code to find out
whether:
o The code works according to the functional requirement;
o The code has been written in accordance with the design developed
earlier in the project life cycle;
o The code for any functionality has been missed out;
o the code handles errors properly.
• Static testing can be done by humans or with the help of specialized tools.
Static Testing by Humans
• These methods rely on the principle of humans reading the program code
to detect errors rather than computers executing the code to find errors.

5|Page
Module2 white box testing

This process has several advantages.

• 1. Sometimes humans can find errors that computers cannot. For example,
when there are two variables with similar names and the programmer used
a "wrong" variable by mistake in an expression, the computer will not
detect the error but execute the statement and produce incorrect results,
whereas a human being can spot such an error.
• 2. By making multiple humans read and evaluate the program, we can get
multiple perspectives and therefore have more problems identified up front
than a computer could.
• 3. A human evaluation of the code can compare it against the specifications
or design and thus ensure that it does what is intended to do. This may not
always be possible when a computer runs a test.
• 4. A human evaluation can detect many problems at one go and can even
try to identify the root causes of the problems. More often than not,
multiple problems can get fixed by attending to the same root cause.
Typically, in a reactive testing, a test uncovers one problem (or, at best, a
few problems) at a time. Often, such testing only reveals the symptoms
rather than the root causes. Thus, the overall time required to fix all the -
problems can be reduced substantially by a human evaluation.
• 5. By making humans test the code before execution, computer resources
can be saved. Of course, this comes at the expense of human resources.
• 6. A proactive method of testing like static testing minimizes the delay in
identification of the problems. As we have seen in Chapter 1, the sooner a
defect is identified and corrected, lesser is the cost of fixing the defect.
• 7. From a psychological point of view, finding defects later in the cycle
(for example, after the code is compiled and the system is being put
together) creates immense pressure on programmers. They have to fix
defects with less time to spare. With this kind of pressure, there are higher
chances of other defects creeping in.

6|Page
Module2 white box testing

Methods To Achieve Static Testing By Humans

• There are multiple methods to achieve static testing by humans.
• Since static testing by humans is done before the code is compiled and
executed, some of these methods can be viewed as process-oriented or
defect prevention-oriented or quality assurance-oriented activities rather
than pure testing activities
• They are (in the increasing order of formalism) as follows.
1. Desk checking of the code
2. Code walkthrough
3. Code review
4. Code inspection
Desk checking
• Normally done manually by the author of the code, desk checking is a
method to verify the portions of the code for correctness.
• Such verification is done by comparing the code with the design or
specifications to make sure that the code does what it is supposed to do and
effectively.
• This is the desk checking that most programmers do before compiling and
executing the code.
• Whenever errors are found, the author applies the corrections for errors on
the spot.
• This method of catching and correcting errors is characterized by:
o 1. No structured method or formalism to ensure completeness
o 2. No maintaining of a log or checklist.
• In effect, this method relies completely on the author's thoroughness,
diligence, and skills.
• There is no process or structure that guarantees or verifies the
effectiveness of desk checking.
• This method is effective for correcting" obvious" coding errors but will not
be effective in detecting errors that arise due to incorrect understanding of
requirements or incomplete requirements.

7|Page
Module2 white box testing

• This is because developers (or, more precisely, programmers who are

doing the desk checking) may not have the domain knowledge required to
understand the requirements fully.
Advantage
❖ The main advantage offered by this method is that
❖ the programmer who knows the code and the programming language very
well is well equipped to read and understand his or her own code.
❖ Also, since this is done by one individual, there are fewer scheduling and
logistics overheads.
❖ Furthermore, the defects are detected and corrected with minimum time
delay.
Disadvantages
❖ 1. A developer is not the best person to detect problems in his or her own
code. He or she may be tunnel visioned and have blind spots to certain
types of problems.
❖ 2. Developers generally prefer to write new code rather than do any form
of testing
❖ 3. This method is essentially person-dependent and informal and thus may
not work consistently across all developers.

Code Walkthrough
• This method is a group-oriented methods.
• Walkthroughs are less formal than inspections.
• The line drawn in formalism between walkthroughs and inspections is very
thin and varies from organization to organization.
• The advantage that walkthrough has over desk checking is that it brings
multiple perspectives.
• In walkthroughs, a set of people look at the program code and raise
questions for the author.
• The author explains the logic of the code, and answers the questions.
• If the author is unable to answer some questions, he or she then takes those
questions and finds their answers.
8|Page
Module2 white box testing

• Completeness is limited to the area where questions are raised by the team.
Formal Inspection
• Code inspection-also called Fagan Inspection is a method, normally with a
high degree of formalism.
• The focus of this method is to detect all faults, violations, and other side-
effects.
• This method increases the number of defects detected by
o 1. demanding thorough preparation before an inspection/review;
o 2. enlisting multiple diverse views;
o 3. assigning specific roles to the multiple participants;
o 4. going sequentially through the code in a structured manner.
• A formal inspection should take place only when the author has made sure
the code is ready for inspection by performing some basic desk checking
and walkthroughs.
• When the code is in such a reasonable state of readiness, Software Testing
an inspection meeting is arranged.
There are four roles in inspection
1. First is the author of the code.
2. Second is a moderator who is expected to formally run the inspection
according to the process.
3. Third are the inspectors.
• These are the people who actually provides, review comments for the code.
• There are typically multiple inspectors. Finally, there is a scribe, who takes
detailed notes during the inspection meeting and circulates them to the
inspection team after the meeting.
Working of Formal Inspection
The author or the moderator selects the review team. The chosen members
have the skill sets to uncover as many defects as possible. In an
introductory meeting, the inspectors get copies (These can be hard copies
or soft copies) of the code to be inspected along with other supporting

9|Page
Module2 white box testing

documents such as the design document, requirements document, and any

documentation of applicable standards.
The author also presents his or her perspective of what the program is
intended to do along with any specific issues that he or she may want the
inspection team to put extra focus on. The moderator informs the team
about the date, time, and venue of the inspection meeting.
The inspectors get adequate time to go through the documents and
program and ascertain their compliance to the requirements, design, and
standards. The inspection team assembles at the agreed time for the
inspection meeting (also called the defect logging meeting).
The moderator takes the team sequentially through the program code,
asking each inspector if there are any defects in that part of the code. If any
of the inspectors raises a defect, then the inspection team deliberates on the
defect and, when agreed that there is a defect, classifies it in two
dimensions —mitior/major and systemic/mis-execution.
A mis-execution defect is one which, as the name suggests, happens
because of an error or slip on the part of the author. It is unlikely to be
repeated later, either in this work product or in other work products.
An example of this is using a wrong variable in a statement. Systemic
defects, on the other hand, can require correction at a different level. For
example, an error such as using some machine-specific idiosyncrasies may
have to removed by changing the coding standards. Similarly, minor
defects are defects that may not substantially affect a program, whereas
major defects need immediate attention.
A scribe formally documents the defects found in the inspection meeting
and the author takes care of fixing these defects. In case the defects are
severe, the team may optionally call for a review meeting to inspect the
fixes to ensure that they address the problems. In any case, defects found
through inspection need to be tracked till completion and someone in the
team has to verify that the problems have been fixed properly.

10 | P a g e
Module2 white box testing

Challenges Formal Inspections

• Formal inspections have been found very effective in catching defects
early.
• Some of the challenges to watch out for in conducting formal inspections
are as follows.
o These are time consuming. Since the process calls for preparation as
well as formal meetings, these can take time.
o The logistics and scheduling can become an issue since multiple
people are involved.
• It is not always possible to go through every line of code, with several
parameters and their combinations in mind to ensure the correctness of the
logic, side-effects and appropriate error handling.
• It may also not be necessary to subject the entire code to formal inspection.
• In order to overcome the above challenges, it is necessary to identify,
during the planning stages, which parts of the code will be subject to formal
inspections.
• Portions of code can be classified on the basis of their criticality or
complexity as "high," "medium," and "low.“
• High or medium complex critical code should be subject to formal
inspections, while those classified as "low" can be subject to either
walkthroughs or even desk checking.
• Desk checking, walkthrough, review and inspection are not only used for
code but can be used for all other deliverables in the project life cycle such
as documents, binaries, and media.

11 | P a g e
Module2 white box testing

Static Analysis Tool

• There are several static analysis tools available in the market that can reduce
the manual work and perform analysis of the code to find out errors such as
those listed:
1. whether there are unreachable codes (usage of GOTO statements
sometimes creates this situation; there could be other reasons too)
2. variables declared but not used
3. mismatch in definition and assignment of values to variables
4. Illegal or error prone typecasting of variables
5. use of non-portable or architecture-dependent programming constructs
6. Memory allocated but not having corresponding statements for freeing
them up memory
7. Calculation of cyclomatic complexity below.
• These static analysis tools can also be considered as an extension of compilers
as they use the same concepts and implementation to locate errors.
• A good compiler is also a static analysis tool.
• For example, most C compilers provide different "levels" of code checking
which will catch the various types of programming errors given above
CODE REVIEW CHECKLIST
• While following any of the methods of human checking-desk checking,
walkthroughs, or formal inspections-it is useful to have a code review
checklist.
• Given below is checklist that covers some of the common issues.
• Every organization should develop its own code review checklist.
• The checklist should be kept current with new learning as they come
about

12 | P a g e
Module2 white box testing

13 | P a g e
Module2 white box testing

14 | P a g e
Module2 white box testing

• In a multi-product organization, the checklist may be at two levels-first, an

organization-wide checklist that will include issues such as
• organizational coding standards, documentation standards, and so on;
• second, a product or project-specific checklist that addresses issues specific to
the product or project.

STRUCTURAL TESTING

■ Structural testing takes into account the code, code structure, internal
design, and how they are coded.
■ The fundamental difference between structural testing and static testing is
that :
■ In structural testing tests are actually run by the computer on the built
product,
■ Whereas in static testing, the product is tested by humans using just the
source code and not the executables or binaries.
■ Structural testing entails running the actual product against some
predesigned test cases to exercise as much of the code as possible or
necessary.

15 | P a g e
Module2 white box testing

■ 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
Classification Of Structural Testing
Structural testing can be further classified into :
1. Unit/code functional testing.
2. Code coverage.
3. Code complexity testing.
Unit/Code Functional Testing
■ This initial part of structural testing corresponds to some quick checks that
a developer performs before subjecting the code to more extensive code
coverage testing or code complexity testing.
This can happen by several methods:
■ 1. Initially, the developer can perform certain obvious tests, knowing the
input variables and the corresponding expected output variables. This can
be a quick test that checks out any obvious mistakes. By repeating these
tests for multiple values of input variables, the confidence level of the
developer to go to the next level increases. This can even be done prior to
formal reviews of static testing so that the review mechanism does not
waste time catching obvious errors.
■ 2. For modules with complex logic or conditions, the developer can build
a “ debug version" of the product by putting intermediate print statements
and making sure the program is passing through the right loops and
iterations the right number of times. It is important to remove the
intermediate print statements after the defects are fixed.
■ 3. Another approach to do the initial test is to run the product under a
debugger or an integrated development environment (ide).These tools
allow single stepping of instructions (allowing the developer to stop at the
end of each instruction, view or modify the contents of variables, and so
on), Setting break points at any function or instruction, and viewing the
various system parameters or program variable values.

16 | P a g e
Module2 white box testing

All the above fall more under the "debugging" category of activities than
under the "testing" category of activities. All the same, these are intimately
related to the knowledge of code structure and hence we have included
these under the "white box testing" head. This is consistent with our view
that testing encompasses whatever it takes to detect and correct defects in
a product.

Code Coverage Testing

■ Since a product is realized in terms of program code, if we can run test
cases to exercise the different parts of the code, then that part of the product
realized by the code gets tested.
■ Code coverage testing involves designing and executing test cases and
finding out the percentage of code that is covered by testing.
■ The percentage of code covered by a test is found by adopting a technique
called Instrumentation of code.
■ There are specialized tools available to achieve Instrumentation.
■ Instrumentation rebuilds the product, linking the product with a set of
libraries provided by the tool vendors.
■ This instrumented code can monitor and keep an audit of what portions of
code are covered.
■ The tools also allow reporting on the portions of the code that are covered
frequently, so that the critical or most-often portions of code can be
identified.

Types Of Coverage: Code Coverage Testing

■ Code coverage testing is made up of the following types of
coverage:
1. Statement coverage
2. Path coverage
3. Condition coverage
4. Function coverage

17 | P a g e
Module2 white box testing

Statement coverage
■ Statement coverage Program constructs in most conventional
programming languages can be classified as :
1. Sequential control flow
2. Two-way decision statements like IF then ELSE
3. Multi-way decision statements like Switch
4. Loops like while do, repeat ,until and for
■ Statement coverage refers to writing test cases that execute each of the
program statements.
■ One can start with the assumption that more the code covered, the better
is the testing of the functionality, as the code realizes the functionality.
■ Based on this assumption, code coverage can be achieved by providing
coverage to each of the above types of statements.
Sequential Control Flow
■ For a section of code that consists of statements that are sequentially
executed
■ (that is, with no conditional branches), test cases can be designed to run
through from top to bottom.
■ A test case that starts at the top would generally have to go through the
full section till the bottom of the section.
■ However, this may not always be true.
■ First, if there are asynchronous exceptions that the code encounters (for
example, a divide by zero),
■ then, even if we start a test case at the beginning of a section, the test case
may not cover all the statements in that section.
■ Thus, even in the case of sequential statements, coverage for all statements
may not be achieved.
■ Second, a section of code may be entered from multiple points.

18 | P a g e
Module2 white box testing

■ Even though this points to not following structured programming

guidelines, it is a common scenario in some of the earlier programming
languages.

Two-way decision statements like if then else

■ When we consider a two-way decision construct like the if statement, then
to cover all the statements, we should also cover the then and else parts of
the if statement.
■ This means we should have, for each if then else, (at least) one test case to
test the Then part and (at least) one test case to test the else part.

Multi-way decision statements like Switch

■ The multi-way decision construct such as a Switch statement can be
Reduced to multiple two-way if statements.
■ Thus, to cover all possible switch cases, there would be multiple test
cases.

Loops like while do, repeat until and for

■ Loop constructs present more variations to take care of.
■ A loop-in various forms such as for, while, repeat, and so on-is
characterized by executing a set of statements repeatedly until or while
certain conditions are met.
■ A good percentage of the defects in programs come about because of loops
that do not function properly.
■ More often, loops fail in what are called "boundary conditions."
■ One of the common looping errors is that the termination condition of the
loop is not properly stated.
■ In order to make sure that there is better statement coverage for statements
within a loop, there should be Test cases that:
1. Skip the loop completely, so that the situation of the termination
condition being true before starting the loop is tested.
2. Exercise the loop between once and the maximum number of times,
to check all possible "normal" operations of the loop.

19 | P a g e
Module2 white box testing

3. Try covering the loop, around the "boundary" of n-that is, just
below n, n, and just above n.
■ The statement coverage for a program, which is an indication of the
percentage of statements actually executed in a set of tests, can be
calculated by the formula :
Statement coverages=(𝑇𝑜𝑡𝑎𝑙 𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡 𝐸𝑥𝑒𝑟𝑐𝑖𝑠𝑒𝑑/𝑇𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓
𝑒𝑥𝑒𝑐𝑢𝑡𝑎𝑏𝑙𝑒 𝑠𝑡𝑎𝑡𝑒𝑚𝑒𝑛𝑡𝑠 𝑖𝑛 𝑝𝑟𝑜𝑔𝑟𝑎𝑚)∗100

■ The type of statement progresses from a simple sequential statement to if

then else and through to loops,
■ the number of test cases required to achieve statement coverage increases.
■ Even if we were to achieve a very high level of statement coverage, it does
not mean that the program is defect-free.
■ First, consider a hypothetical case when we achieved 100 percent code
coverage.
■ If the program implements wrong requirements and this wrongly
implemented code is "fully tested,"
■ with 100 percent code coverage, it still is a wrong program and hence the
100percent code coverage does not mean anything.

Path coverage
■ In path coverage, we split a program into a number of Distinct paths.
■ A program (or a part of a program) can start from the beginning and take
any of the paths to its completion.
Path coverage =(Total paths Exercised/Total number of path in
program)*100

20 | P a g e
Module2 white box testing

Let us take an example of a date validation routine. The date is accepted as three
fields mm, dd and yyyy. We have assumed that prior to entering this routine, the
values are checked to be numeric. To simplify the discussion, we have assumed
the existence of a function called le a pye a r which will return TRUE if the given
year is a leap year. There is an array called Dayo (Month which contains the
number of days in each month. A simplified flow chart for this is given in Figure
3.2 below.
As can be seen from the figure, there are different paths that can be taken through
the program. Each part of the path is shown in red. The coloured representation
of Figure 3.2 is available on page 459. Some of the paths are

21 | P a g e
Module2 white box testing

■ Path coverage provides a stronger condition of coverage than statement

coverage as it relates to the various logical path in program rather than just
program statements.

Condition coverage
■ Condition coverage is also known as Predicate Coverage in which each one
of the Boolean expression have been evaluated to both TRUE and FALSE.

Result
■ In order to ensure complete Condition coverage criteria for the above
example, A, B and C should be evaluated at least once against "true" and
"false".
■ So, in our example, the 3 following tests would be sufficient for 100%
Condition coverage testing.

■ Condition coverage =(Total decisions exercised/Total number of

decisions in program)*100
■ Condition coverage is a much stronger criteria than path coverage which
in turns is a much stronger tan statement coverage.

22 | P a g e
Module2 white box testing

Functional Testing
■ This is a new addiction in structure testing to identify how many program
functions are covered by test cases.
■ The requirements of a products are mapped into functions during the
design phase and each of the functions form a logical unit.
■ Functional testing ensures that the requirements or specifications are
properly satisfied by the application.
■ This type of testing is particularly concerned with the result of processing.
■ It focuses on simulation of actual system usage but does not develop any
system structure assumptions.
■ While providing function coverage test cases can be written so as to
exercise each of the different functions of the code.
Advantages of functional testing
■ Functions are easy to identify in a program hence it is easier to write test
cases to provide function coverage.
■ Since functions are at a much higher level of abstraction than code ,it is
easier to achieve 100 percent function coverage than 100 percent coverage
in any of the easier methods.
■ Functions have a more logical mapping to requirements and hence can
provide a more direct correlation to the test coverage of the product.
■ Function coverage provide a natural transition to black box testing.
■ We can also measure how many times a given function is called, This will
indicate which functions are used most often and hence these function
become the target of any performance testing and optimization.
■ The function coverage can help in improving the performance as well as
quality of the product.
■ Function coverage =(Total functions Exercised/Total number of
functions in program)*100

23 | P a g e
Module2 white box testing

Other uses of code coverage testing

❖ Performance analysis and optimization
❖ Resource usage analysis
❖ Identifying memory leaks
❖ Checking critical sections or concurrency related parts of code.
❖ Dynamically generated codes

Cyclomatic Complexity
■ Cyclomatic complexity is a software metric used to measure the
complexity of a program. Thomas J. McCabe developed this metric in
1976.
■ McCabe interprets a computer program as a set of a strongly connected
directed graph.
■ Nodes represent parts of the source code having no branches and arcs
represent possible control flow transfers during program execution.
■ The notion of program graph has been used for this measure, and it is used
to measure and control the number of paths through a program. The
complexity of a computer program can be correlated with the topological
complexity of a graph.
How to Calculate Cyclomatic Complexity ?
■ McCabe proposed the cyclomatic number, V (G) of graph theory as an
indicator of software complexity.
■ The cyclomatic number is equal to the number of linearly independent
paths through a program in its graphs representation.
■ For a program control graph G, cyclomatic number, V (G), is given as:
V (G) = E - N + 2 * P
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.

24 | P a g e
Module2 white box testing

Use of Cyclomatic Complexity

■ Determining the independent path executions thus proven to be very
helpful for Developers and Testers.
■ It can make sure that every path have been tested at least once.
■ Thus help to focus more on uncovered paths.
■ Code coverage can be improved.
■ Risk associated with program can be evaluated.
■ These metrics being used earlier in the program helps in reducing the risks.
Challenges in white box testing
■ White box testing requires a sound knowledge of the program code and the
programming language.
■ This means that the developers should get intimately involved in white box
testing.
■ Developers, in general, do not like to perform testing functions.
■ This applies to structural testing as well as static testing methods such as
reviews.
■ In addition, because of the timeline pressures, the programmers may not
"find time" for reviews (an euphemism for wanting to do more coding).

25 | P a g e
Module2 white box testing

■ Human tendency of a developer being unable to find the defects in his

or her code As we saw earlier, most of us have blind spots in detecting
errors in our own products.
■ Since white box testing involves programmers who write the code, it is
quite possible that they may not be most effective in detecting defects in
their own work products
■ Fully tested code may not correspond to realistic scenarios
Programmers
■ generally do not have a full appreciation of the external (customer)
■ perspective or the domain knowledge to visualize how a product will be
deployed in realistic scenarios.
■ This may mean that even after extensive testing, some of the common user
scenarios may get left out and defects may creep in.

26 | P a g e