2.

Types of Testing
White-Box Testing:-
Definition:-
“White-box testing is a testing technique that examines the program
structure and derives test data from the program logic/code. The other names of
glass box testing are clear box testing, open box testing, logic driven testing or path
driven testing or structural testing.”
“White-Box Testing is the testing of a software solution's internal coding
and infrastructure. It focuses primarily on strengthening security, the flow of inputs
and outputs through the application, and improving design and usability. White
box testing is also known as clear box testing, open box testing, logic driven
testing or path driven testing or structural testing and glass box testing.”
White-box testing is based on the inner workings of an application and
revolves around internal testing. The term "white-box" was used because of the
see-through box concept. The clear box or white box name symbolizes the ability
to see through the software's outer shell (or "box") into its inner workings.
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. 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.
Classification of White-Box testing:-

Fig: 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.
Advantages of White Box Testing:
 Forces test developer to reason carefully about implementation.
 Reveals errors in "hidden" code.
 Spots the Dead Code or other issues with respect to best programming
practices.
Disadvantages of White Box Testing:
 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.

Static Testing:-“Static techniques are testing techniques in which the code is

not run. Its counter-part is Dynamic Testing which checks an application when
code is run. Code review, inspections, walkthroughs, and technical reviews are
some static testing methods. A review is the most important testing technique.”
What are the roles and responsibilities involved during a review
During a review four types of participants take part. They are:
1. The moderator:
The moderator (or review leader) leads the review process. His role is to
determine the type of review, approach and the composition of the review
team. The moderator also schedules the meeting, disseminates documents
before the meeting, coaches other team members, paces the meeting, leads
possible discussions and stores the data that is collected. Leads the possible
discussion and stores the data that is collected.

2. The author:
As the writer of the „document under review‟, the author‟s basic goal should
be to learn as much as possible with regard to improving the quality of the
document. The author‟s task is to illuminate unclear areas and to understand
the defects found.
3. The scribe:
The scribe (or recorder) has to record each defect found and any suggestions
or feedback given in the meeting for process improvement.
4. The reviewers:
The role of the reviewers is to check defects and further improvements in
accordance to the business specifications, standards and domain knowledge.
Walkthroughs:-

A walkthrough is conducted by the author of the „document under review‟

who takes the participants through the document and his or her thought processes,
to achieve a common understanding and to gather feedback. This is especially
useful if people from outside the software discipline are present, who are not used
to, or cannot easily understand software development documents. The content of
the document is explained step by step by the author, to reach consensus on
changes or to gather information. The participants are selected from different
departments and backgrounds If the audience represents a broad section of skills
and disciplines, it can give assurance that no major defects are „missed‟ in the
walk-through. A walkthrough is especially useful for higher-level documents, such
as requirement specifications and architectural documents.

 It is not a formal process/review.

 It is led by the authors.
 Author guide the participants through the document according to his or her
thought process to achieve a common understanding and to gather feedback.
 Useful for the people if they are not from the software discipline, who are not
used to or cannot easily understand software development process.
 Is especially useful for higher level documents like requirement specification.

The goals of a walkthrough:-

 To present the documents both within and outside the software discipline in
order to gather the information regarding the topic under documentation.
 To explain or do the knowledge transfer and evaluate the contents of the
document.
 To achieve a common understanding and to gather feedback.
 To examine and discuss the validity of the proposed solutions.

Technical review:-
A technical review is a discussion meeting that focuses on technical content
of a document. it is led by a trained moderator, but also can be led by a technical
expert. Compared to inspections, technical reviews are less formal and there is
little or no focus on defect identification on the basis of referenced documents. The
experts that are needed to be present for a technical review can be architects, chief
designers and key users. It is often performed as a peer review without
management participation.
 It is less formal review.
 It is led by the trained moderator but can also be led by a technical expert.
 It is often performed as a peer review without management participation.
 Defects are found by the experts (such as architects, designers, key users) who
focus on the content of the document.
 In practice, technical reviews vary from quite informal to very formal.

The goals of the technical review are:

 To ensure that an early stage the technical concepts are used correctly.
 To access the value of technical concepts and alternatives in the product.
 To have consistency in the use and representation of technical concepts.
 To inform participants about the technical content of the document.

Inspection:-

Inspection is the most formal review type. It is usually led by a trained

moderator (certainly not by the author).The document under inspection is prepared
and checked thoroughly by the reviewers before the meeting, comparing the work
product with its sources and other referenced documents, and using rules and
checklists. In the inspection meeting the defects found are logged. Depending on
the organization and the objectives of a project, inspections can be balanced to
serve a number of goals.

 It is the most formal review type.

 It is led by the trained moderators.
 During inspection the documents are prepared and checked thoroughly by the
reviewers before the meeting.
 It involves peers to examine the product.
 A separate preparation is carried out during which the product is examined and
the defects are found.
 The defects found are documented in a logging list or issue log.
 A formal follow-up is carried out by the moderator applying exit criteria.

The goals of inspection are:

 It helps the author to improve the quality of the document under inspection.
 It removes defects efficiently and as early as possible.
 It improves product quality.
 It creates common understanding by exchanging information.
 It learn from defects found and prevent the occurrence of similar defects.

Structural Testing:-
“Structural testing, also known as glass box testing or white box testing is
an approach where the tests are derived from the knowledge of the software's
structure or internal implementation.”

The other names of structural testing include clear box testing, open box
testing, logic driven testing or path driven testing.

Advantages:
 Forces test developer to reason carefully about implementation

 Reveals errors in "hidden" code

 Spots the Dead Code or other issues with respect to best programming
practices.

Disadvantages:
 Expensive as one has to spend both time and money to perform white box
testing.

 Every possibility that few lines of code is missed accidentally.

 In-depth knowledge about the programming language is necessary to
perform white box testing.

Functional Code Testing:-

In functional testing basically the testing of the functions of component or
system is done. It refers to activities that verify a specific action or function of the
code. Functional test tends to answer the questions like “can the user do this” or
“does this particular feature work”. This is typically described in a requirements
specification or in a functional specification.
Code Coverage:-
Code Coverage testing is determining how much code is being tested. It can be
calculated using the formula:
Code Coverage = (Number of lines of code exercised)/ (Total Number of lines of code) * 100%

Following are the types of code coverage Analysis:

 Statement coverage and Block coverage
 Function coverage
 Function call coverage
 Branch coverage
 Modified condition/decision coverage

What is Statement Coverage Testing?

Statement Coverage refers to writing test cases that execute each of the program
statements. Program constructs in most convenient 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
For a Sequential control flow statements test cases can be designed to run through
top to bottom. Even in this section, coverage for all statements may not be
achieved if there are any asynchronous exceptions that that code encounters(ex:
divide by zero error).
For Two way decision like if we have to cover all statements of then and else part.
Test cases can be written for each part of the decision.
In Multi way decision like switch statements, test cases can be written for all
switch cases to get better coverage.
A good percentage of defects in programs come about because of loops that don
not function properly. so we have to write test cases for the proper loop functioning
and termination.
Statement Coverage can be calculated by the formula
Total no. of statements exercised
__________________________ * 100
 Total no. of executable statements

What is Function Coverage Testing?

The requirement of a product is mapped into functions during the design phase and
each of the functions form a logical unit. The advantages of function coverage are
 Functions are easier to identify in a program hence it is easy to write test
case for it.
 it is easier to achieve 100% function coverage than any other coverage
we can also measure how many times a given function is called. This will indicate
which function is used most often and hence these functions become the target of
any performance testing. This will improve the performance as well as quality of
the product. The formula for Function Coverage:-

Total no. of functions exercised

_________________________ *100
Total no. of functions in a program

What is Branch Coverage Testing?

Every software program works with some set of branches in its code to perform
certain functions.100% branch coverage means that test data will ensure that every
branches of a program is executed at least once during testing.
For example, consider the following code:
if (a >= b)then
{printf(")}
else
{printf(")}
For this code the branch test will be taken according to the decisions and its
branches like if the condition is passed it will lead to one branch otherwise it leads
to another branch.
Black Box Testing:-
Black box testing is done from the customer's viewpoint. It does not require
examining the code of the program; it involves the looking at the specifications of
the application and focuses solely on the output. It is also called as Functionality
testing or Data driven testing or Behavioral testing. In this type of testing, tester
does not have the access to the source code. Based on the SRS document, test data
is prepared. The purpose of this testing is to cause failures in order to make faults
visible. Another purpose is to assess the overall quality level of the application.
There are various techniques to be used to generate test scenarios for effective
Black box testing:-
1. Requirement based testing
2. Positive and negative testing
3. Boundary value analysis
4. Decision tables
5. Equivalence partitioning
6. State based testing
7. User documentation testing
Advantages of Black box testing:-
 It helps in identifying any incomplete, inconsistent requirement.
 Tester tests the application in a user point of view.
 Tester needs no knowledge of code or its written language in this testing.
 Test cases can be designed as soon as the SRS is ready.
 It enables verification of the overall functionality of the application.
 It puts the system through the valid and invalid forms of user inputs.
 It finds the overall quality of the application.
Disadvantages of Black box testing:-
 If the specifications are not clear, test cases are hard to design.
 May leave many program paths untested.
 Exhaustive testing is not possible.
  We can find a failure not the root cause in this testing.

Requirement based testing:-

This black box testing is mainly deals with the requirements given in the
SRS of the system. It is helpful because some requirements are implicit and not
stated explicit. Implicit requirements are not mentioned in the SRS document and it
should be assumed by the tester. All implicit and explicit requirements are
mentioned in TRS (test requirements specifications) and this will be used for
testing. Requirements are tracked by Requirements Traceability Matrix (RTM).
Requirements-based testing is a testing approach in which test cases,
conditions and data are derived from requirements. It includes functional tests and
also non-functional attributes such as performance, reliability or usability.
Stages in Requirements based Testing:
 Defining Test Completion Criteria - Testing is completed only when all
the functional and non-functional testing is complete.
 Design Test Cases - A Test case has five parameters namely the initial state
or precondition, data setup, the inputs, expected outcomes and actual
outcomes.
 Execute Tests - Execute the test cases against the system under test and
document the results.
 Verify Test Results - Verify if the expected and actual results match each
other.
 Verifying Test Coverage - Verify if the tests cover both functional and non-
functional aspects of the requirement.
 Track and Manage Defects - Any defects detected during the testing
process goes through the defect life cycle and are tracked to resolution.
Defect Statistics are maintained which will give us the overall status of the
project.
Requirements testing process:
 Testing must be carried out in a timely manner.
 Testing process should add value to the software life cycle, hence it needs to
be effective.
 Testing the system exhaustively is impossible hence the testing process
needs to be efficient as well.
  Testing must provide the overall status of the project, hence it should be
manageable.

Positive and Negative testing:-

Positive Testing:-
Positive testing is done to verify the known test conditions. It proves that
product works as per the requirement and to check if the product is delivering the
error when it is expected to give the error. In this testing the system is tested with
valid inputs. This testing is aimed to show that the system works properly. So it is
called as “test to pass". For ex test for a text box, the user requirement is like it
should accept only the string inputs, we can test this as giving only string inputs
Example of positive testing is given below:
Considering example length of password defined in requirements is 6 to 20
characters, and whenever we check the application by giving alphanumeric
characters on password field “between” 6 to 20 characters than it is positive
testing, because we test the application with valid data/ input.
.
Negative Testing:-
Negative testing is done to verify the unknown test conditions. Negative
testing is testing the application with invalid or negative inputs. This testing is
aimed to show that the system does not work with negative values. So it is called
as "test to fail”. It covers the scenarios for which the product is not designed and
coded. Testing for behavior that is contrary to expected behavior. For ex test for a
text box, the user requirement is like it should accept only the string inputs, we can
test this as giving only non-string inputs.
Example of negative testing is given below:
Considering example as we know phone no field does not accept the
alphabets and special characters it obviously accepts numbers, but if we
type alphabets and special characters on phone number field to check it accepts the
alphabets and special characters or not than it is negative testing.
Boundary Value Analysis (BVA):-
It‟s widely recognized that input values at the extreme ends of input domain
cause more errors in system. More application errors occur at the boundaries of
input domain. „Boundary value analysis‟ testing technique is used to identify errors
at boundaries rather than finding those exist in center of input domain.
Boundary value analysis is a next part of Equivalence partitioning for designing
test cases where test cases are selected at the edges of the equivalence classes.

Test cases for input box accepting numbers between 1 and 1000 using
Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e.
values 1 and 1000 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values
0 and 999.
3) Test data with values just above the extreme edges of input domain i.e. values 2
and 1001.

Boundary value analysis is often called as a part of stress and negative testing.

Note: There is no hard-and-fast rule to test only one value from each equivalence
class you created for input domains. You can select multiple valid and invalid
values from each equivalence class according to your needs and previous
judgments.

E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you
can select test case values like: 1, 11, 100, 950 etc. Same case for other test cases
having invalid data classes.

This should be a very basic and simple example to understand the Boundary value
analysis and Equivalence partitioning concept.

As an example, consider a printer that has an input option of the number of copies
to be made, from 1 to 99. To apply boundary value analysis, we will take the
minimum and maximum (boundary) values from the valid partition (1 and 99 in
this case) together with the first or last value respectively in each of the invalid
partitions adjacent to the valid partition (0 and 100 in this case). In this example we
would have three equivalence partitioning tests (one from each of the three
partitions) and four boundary value tests. Consider the bank system described in
the previous section in equivalence partitioning.
Equivalence Partitioning:-
Equivalence partitioning is a software technique that involves identifying a
small set of representative input values that produce as much different output
condition as possible. This reduces the number of permutation & combination of
input, output values used for testing, thereby increasing the coverage and reducing
the effort involved in testing.
The set of input values that generate one single expected output is called a
partition. When the behavior of the software is the same for a set of values, then
the set is termed as equivalence class or partition.
Example: An insurance company that has the following premium rates based on
the age group. A life insurance company has base premium of $0.50 for all ages.
Based on the age group, an additional monthly premium has to pay that is as listed
in the table below. For example , a person aged 34 has to pay a premium=$0.50 +$
1.65=$2.15
Age group Additional Premium
Under 35 $ 1.65
35-59 $ 2.87
60+ $ 6.00

Based on the equivalence portioning technique, the equivalence partitions that are
based

On age are given below:

Below 35 years of age (valid input)

Between 35 and 59 years of age(valid input)

Above 6 years of age (valid input)

Negative age (invalid input)

Age as 0(invalid input)

Age as any three-digit number (valid input)

Decision Tables:-

The techniques of equivalence partitioning and boundary value analysis are

often applied to specific situations or inputs. However, if different combinations of
inputs result in different actions being taken, this can be more difficult to show
using equivalence partitioning and boundary value analysis, which tend to be more
focused on the user interface. The other two specification-based software
testing techniques, decision tables and state transition testing are more focused on
business logic or business rules.

A decision table is a good way to deal with combinations of things (e.g.

inputs). This technique is sometimes also referred to as a ‟cause-effect‟ table. The
reason for this is that there is an associated logic diagramming technique called
‟cause-effect graphing‟ which was sometimes used to help derive the decision table
(Myers describes this as a combinatorial logic network [Myers, 1979]). However,
most people find it more useful just to use the table described in [Copeland, 2003].

 Decision tables provide a systematic way of stating complex business rules,

which is useful for developers as well as for testers.
 Decision tables can be used in test design whether or not they are used in
specifications, as they help testers explore the effects of combinations of
different inputs and other software states that must correctly implement
business rules.
 It helps the developers to do a better job can also lead to better relationships
with them. Testing combinations can be a challenge, as the number of
combinations can often be huge. Testing all combinations may be impractical
if not impossible. We have to be satisfied with testing just a small subset of
combinations but making the choice of which combinations to test and which
to leave out is also important. If you do not have a systematic way of selecting
combinations, an arbitrary subset will be used and this may well result in an
ineffective test effort.
How to use decision tables for test case designing:

The first task is to identify a suitable function or subsystem which reacts

according to a combination of inputs or events. The system should not contain too
many inputs otherwise the number of combinations will become unmanageable. It
is better to deal with large numbers of conditions by dividing them into subsets and
dealing with the subsets one at a time. Once you have identified the aspects that
need to be combined, then you put them into a table listing all the combinations of
true and False for each of the aspects.
Let us consider an example of a loan application, where you can enter the amount
of the monthly repayment or the number of years you want to take to pay it back
(the term of the loan). If you enter both, the system will make a compromise
between the two if they conflict. The two conditions are the loan amount and the
term, so we put them in a table (see Table 4.2).

TABLE 4.2 Empty decision table:

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Repayment amount has
been entered:
Term of loan has been
Entered:

Next we will identify all of the combinations of True and False (see Table 4.3).
With two conditions, each of which can be True or False, we will have four
combinations (two to the power of the number of things to be combined). Note that
if we have three things to combine, we will have eight combinations, with four
things, there are 16, etc. This is why it is good to tackle small sets of combinations
at a time. In order to keep track of which combinations we have, we will alternate
True and False on the bottom row, put two Trues and then two Falses on the row
above the bottom row, etc., so the top row will have all Trues and then all Falses
(and this principle applies to all such tables).
TABLE 4.3 Decision table with input combinations:
Conditions Rule 1 Rule 2 Rule 3 Rule
4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

In the next step we will now identify the correct outcome for each combination
(see Table 4.4). In this example, we can enter one or both of the two fields. Each
combination is sometimes referred to as a rule.

TABLE 4.4 Decision table with combinations and outcomes:

Conditions Rule 1 Rule 2 Rule 3 Rule
4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

Actions/Outcomes
Process loan amount: Y Y
Process term: Y Y

At this point, we may realize that we hadn‟t thought about what happens if the
customer doesn‟t enter anything in either of the two fields. The table has
highlighted a combination that was not mentioned in the specification for this
example. We could assume that this combination should result in an error message,
so we need to add another action (see Table 4.5). This highlights the strength of
this technique to discover omissions and ambiguities in specifications. It is not
unusual for some combinations to be omitted from specifications; therefore this is
also a valuable technique to use when reviewing the test basis.
TABLE 4 . 5 Decision table with additional outcomes:
Conditions Rule 1 Rule 2 Rule 3 Rule
4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

Actions/Outcomes
Process loan amount: Y Y
Process term: Y Y
Error message:
Y

Now, we make slight change in this example, so that the customer is not allowed to
enter both repayment and term. Now the outcome of our table will change, because
there should also be an error message if both are entered, so it will look like Table
4.6.

TABLE 4 . 6 Decision table with changed outcomes:

Conditions Rule 1 Rule 2 Rule 3 Rule 4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

Actions/Outcomes
Process loan amount: Y
Process term: Y
Error message: Y Y
You might notice now that there is only one „Yes‟ in each column, i.e. our actions
are mutually exclusive – only one action occurs for each combination of
conditions. We could represent this in a different way by listing the actions in the
cell of one row, as shown in Table 4.7. Note that if more than one action results
from any of the combinations, then it would be better to show them as separate
rows rather than combining them into one row.

TABLE 4.7 Decision table with outcomes in one row:

Conditions Rule 1 Rule 2 Rule 3 Rule 4
Repayment amount has T T F F
been entered:
Term of loan has been T F T F
entered:

Actions/Outcomes:
Result: Error Process loan Process Error
message amount term message

The final step of this technique is to write test cases to exercise each of the four
rules in our table.

Credit card example:

Let‟s take another example. If you are a new customer and you want to open a
credit card account then there are three conditions first you will get a 15% discount
on all your purchases today, second if you are an existing customer and you hold a
loyalty card, you get a 10% discount and third if you have a coupon, you can get
20% off today (but it can‟t be used with the „new customer‟ discount). Discount
amounts are added, if applicable. This is shown in Table 4.8.

TABLE 4.8 Decision table for credit card example

In Table 4.8, the conditions and actions are listed in the left hand column. All the
other columns in the decision table each represent a separate rule, one for each
combination of conditions. We may choose to test each rule/combination and if
there are only a few this will usually be the case. However, if the number of
rules/combinations is large we are more likely to sample them by selecting a rich
subset for testing.

Now let’s see the decision table for credit card shown above:

 Note that we have put X for the discount for two of the columns (Rules 1 and
2) – this means that this combination should not occur. You cannot be both a
new customer and also holding a loyalty card as per the conditions mentioned
above. Hence there should be an error message stating this.
 We have made an assumption in Rule 3. Since the coupon has a greater

discount than the new customer discount, we assume that the customer will
choose 20% rather than 15%. We cannot add them, since the coupon cannot be
used with the „new customer‟ discount as stated in the condition above. The
20% action is an assumption on our part, and we should check that this
assumption (and any other assumptions that we make) is correct, by asking the
person who wrote the specification or the users.
 For Rule 5, however, we can add the discounts; since both the coupon and the

loyalty card discount should apply (that‟s our assumption).

 Rules 4, 6 and 7 have only one type of discount and Rule 8 has no discount, so

0%.
If we are applying this technique thoroughly, we would have one test for each
column or rule of our decision table. The advantage of doing this is that we may
test a combination of things that otherwise we might not have tested and that could
find a defect. However, if we have a lot of combinations, it may not be possible or
sensible to test every combination. If we are time-constrained, we may not have
time to test all combinations. Don‟t just assume that all combinations need to be
tested. It is always better to prioritize and test the most important combinations.
Having the full table helps us to decide which combinations we should test and
which not to test this time. In the example above all the conditions are binary, i.e.
they have only two possible values: True or False (or we can say Yes or No).

User Documentation Testing:-

Documentation testing is a non-functional type of software testing.

 It is a type of non-functional testing.

 Any written or pictorial information describing, defining, specifying,
reporting, or certifying activities, requirements, procedures, or results‟.
Documentation is as important to a product‟s success as the product itself. If
the documentation is poor, non-existent, or wrong, it reflects on the quality
of the product and the vendor.
 As per the IEEE Documentation describing plans for, or results of, the
testing of a system or component, Types include test case specification, test
incident report, test log, test plan, test procedure, test report. Hence the
testing of all the above mentioned documents is known as documentation
testing.
 This is one of the most cost effective approaches to testing. If the
documentation is not right: there will be major and costly problems. The
documentation can be tested in a number of different ways to many different
degrees of complexity. These range from running the documents through a
spelling and grammar checking device, to manually reviewing the
documentation to remove any ambiguity or inconsistency.
 Documentation testing can start at the very beginning of the software
process and hence save large amounts of money, since the earlier a defect is
found the less it will cost to be fixed.
 Objectives:
 To check if what is stated in the document is available in the product.
 To check if what is there in the product is explained correctly in the
document.
Benefits:
 User documentation testing aids in highlighting problems over looked during
reviews.
 High quality user documentation ensures consistency of documentation &
product, thus minimizing possible defects reported by customer. It also
reduces the time taken for each support call.
 Result in less difficult support call. When customer faithfully follows the
instruction given in a document but is unable to achieve to desire result, it is
frustrating and often this frustration shows up on the support staff. Ensuring
that a product is tested to work as per the document and that it works
correctly contributes to better customer satisfaction and better morale of
support staff.
 New programmers and testers who join a project group can use the
documentation to learn the external functionality of the product.
 Customers need less training and can proceed more quickly to advanced
training & product usage if the user documentation is of high quality & is
consistent with the product. Thus high-quality user documentation can result
in a reduction of overall training costs for user organization.

Graph Based Testing:-

State Based Testing: - State Based means change of sate from one state to
another. State based Testing is useful to generate the test cases for state
machines as it has a dynamic behavior (multiple state) in its system. We Can
explain this using state transition diagram. It is a graphic representation of a state
machine.

For example we can take the behavior of mixer grinder. The state transition for
this will be like

1. switch on -- turn towards 1 then 2 then 3 then turn backwards to 2 then 1

then off
 2. switch on - directly turn backwards to 3 then turn towards to off then turn
towards 1 then 2 then 3 then turn backwards to 2 then 1 then off

Each represents a state of machine. Like this we can draw state transition
diagram. Valid test cases can be generated by:

 Start from the start state

 Choose a path that leads to the next state
 If you encounter an invalid input in a given state, generate an error condition
test case
 Repeat the process till you reach the final state

Graph Based Testing: - Graph based testing is useful to represent a transaction or

work flows. Consider an example of a leave application by an employee. A typical
leave application process can be visualized as being made up of the following
steps.

1. Employee desires leave

2. He applies leave application form

3. HR verify eligibility for leave

4. If it is eligible manager ensures feasibility

If it is feasible manager approve leave

 If it is not feasible manager rejects leave

5. If it is not eligible manager rejects leave