Software

Testing Techniques
(100+ Testing Approaches)

HARIPRASATH P
 PREFACE
Writing a book is not an easy task at all. It requires more magnitude and
kind co-operation from many, for its successful completion.
I would like to give my sincere thanks to our honourable Founder and
Chairman, Col. Dr. JEPPIAAR, M.A., B.L., Ph.D., for his sincere endeavour in
educating us in his premier institution.
I would like to express our deep gratitude to our beloved Secretary and
Correspondent, Dr. P. CHINNADURAI, M.A., M.Phil., Ph.D., for his
enthusiastic motivation which helped us a lot in completing this book and our
sincere thanks to our dynamic Directors, Mrs. C. VIJAYA RAJESWARI and
Mr. C. SAKTHI KUMAR, M.E., M.Phil., for providing the necessary facilities
to complete this book.
I wish to express gratefulness to our Principal, Dr. K. MANI, M.E.,
Ph.D., for his encouragement and sincere guidance. I wish to convey our special
thanks and gratitude to the Head of the Department, Dr. Mrs. S.
MURUGAVALLI, M.E., Ph.D., for their encouragement.

HARIPRASATH P
Contents at the Peek
S.No Topic

1 Introduction to Software
Testing

2 Testing Methods under ‘A’

(Adhoc, Acceptance, Alpha,
All Pairs, API, Age,
Accessibility, Adaptive,
Active, Agile, Assertion,
Automation)

3 Testing Methods under ‘B’

(Beta, Black box, Backward
Compatibility, Big Bang,
BVA, Binary Portability,
Branch, Breadth, Bench
Mark, Basic Path)

4 Testing Methods under ‘C’

(Code driven, Compatibility,
Comparison, Component,
Configuration, Condition
Coverage, Compliance,
Concurrency, Conformance,
Context Driven,
Certification)

5 Testing Methods under ‘D’

(Decision Coverage,
Destructive, Dependency,
Dynamic, Domain)

6 Testing Methods under ‘E’

 (Error Handling, End to
End, Endurance,
Exploratory, Equivalence
Class)

7 Testing Methods under ‘F’

(Fault Injection, Formal
Verification, Functional
Testing, Fuzz)

8 Testing Methods under ‘G’

(Gorilla Testing, Grey Box,
Glass Box, GUI,
Globalization)

9 Testing Methods under ‘H’

(Hybrid Integration)

10 Testing Methods under ‘I’

(Integration, Interface,
Install/Uninstall,
Internationalization, Inter
System)

11 Testing Methods under ‘K’

(Keyword Driven Testing)

12 Testing Methods under ‘L’

(Load, Localization, Loop)

13 Testing Methods under ‘M’

(Manual, Model Based,
Mutation)

14 Testing Methods under ‘N’

(Negative, Non-functional
Testing)
15 Testing Methods under ‘O’
(Operational, Orthogonal
Array Testing)

16 Testing Methods under ‘P’

(Pair, Passive, Path,
Parallel, Penetration,
Performance)

17 Other Testing Methods

 1
Introduction to
Software Testing
Introduction:
Software testing is a very essential and important activity that should be carried out
during and after the development of the software. Software that has been developed may
have several bugs (errors). The process of testing the software will reveal the errors that
are invisible to the developer during the development of the system.
Software testing is the activity carried out by the testers. The testers will test the
software using various different mechanisms with the intention of finding the errors. The
main goal of the software testing is to identify the errors that are possible.
An effective software design will be achieved with the help of software testing
operation. Without testing, we cannot able to find the errors that are embedded within the
system.
The possibility of errors while developing the code will be relatively high for any
system. Developers may not be aware of the various categories of inputs and
circumstances that cause the error to the system. It is the role of the tester to identify the
conditions that the system will encounter the error.
The quality of the software is a very important and essential aspect. To develop any
quality product the application of testing principles to test the software is essential.
Software testing not only identifies the logical bugs and it checks whether the system is
consistent or not.
This book helps you to understand 100+ software-testing methods that are followed by
the software testers in order to find the worth-vileness of the system. This book is
embedded with 5 different sub-topics under each testing process. They are
(1) Definition – Brief note to the testing methodology.
(2) Testing Process – Brief note on how the testing will be carried out.
(3) Practical Example – A real time example which states the importance
of the particular testing methodology.
(4) Merits – Advantages of the testing methodology.
(5) Demerits – Disadvantages of the testing methodology if any.
This book will take you to the internal concepts of software testing.
This book provides guidance to the various software testing methodologies and its
importance along with the merits and de-merits.
This book is organized in such a way that the testing methodologies are arranged
in alphabetical sequence.

Why many testing approaches?

There are many testing approaches (100+ techniques) available to test the software.
Why so? The reason is that, each every testing approach has its own merits and demerits.
Some testing approaches holds good for some sort of software development and some
testing methodologies deals with requirement satisfaction, some deals with code
complexity some deals with efficiency and so on. Hence, different testing approaches
should be used to test the software in order to ensure the 100% satisfaction with the
software efficiency.

Bugs:
Bugs are nothing but errors. The error of the software that was developed is due to not
only logical errors and syntactic errors. The bug may be due to inconsistency during
implementation. A bug free software production is the ultimate goal of software
engineering.

SELF EVALUATION
1. What are the goals of software testing?
2. Write the needs of different testing mechanisms.
3. Explain about bugs.
4. What are the roles and responsibilities of tester?
5. Write the reasons for error.
 2
Testing Methods
[A]

Introduction:
Under the alphabetical letter ‘A’, there are 12 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Adhoc Testing
2. Acceptance Testing
3. Alpha Testing
4. All-Pairs Testing
5. Application Interface Testing
6. Age Testing
7. Accessibility Testing
8. Adaptive Testing
9. Active Testing
10. Agile Testing
11. Assertion Testing
12. Automated Testing

Adhoc Testing:
Definition:
Adhoc Testing is a testing mechanism, which is performed without any proper planning
and documentation. It is very similar to guessing the possibility of error just by seeing the
system. Even tester will not go through the entire code; they will be guessing the errors
that may be possible with the system.
Testing Process:
(1) No Procedure followed.
(2) Guessing by seeking through the certain parts of the system.
Example:
Assume that, one module of the system is designed for displaying the contents of the
entire table named X. However, the developer developed the code for displaying the entire
contents of table named Y instead of X.
 In such case, the tester need not to follow any difficult testing approaches, pre-planning
in order to find such silly errors and bugs. Such type of errors is easily rectified by the
Adhoc testing mechanism. No need for going through internal codes to check the system.
The only job of the tester in the above scenario is to identify what is the table to be
extracted.

If the expected output = arrived output:

Success;
System is free from error;
Else:
System has some error with it;
Merits:
Adhoc testing is very useful identify simple errors that does not require any
documentation and planning to find out it.
Less time consuming.
No complexity on planning.
0% complexity on the documentation activity.
Simple Method of Testing.
Falls under the category of Black Box Testing
Demerits:
Adhoc testing reveals only simple errors.
Not suitable for bigger systems.
Probability of error revealing is very less.
No assurance for rectification of entire errors that are hidden with the
system.
Adhoc testing mechanism is similar to error guessing hence it is in-efficient.

Test by yourself
1. Write the Merits and Demerits of Adhoc Testing.
2. When and why it is essential to perform Adhoc Testing?
3. How will you say whether the system failed or passed in the Adhoc Testing?
Explain.
4. Comment on ‘Testing with no pre-planning and documentation’.
5. Explain the Adhoc testing with a real time scenario.
Acceptance Testing:
A system should be developed as per the customer or client’s requirements. Meeting all
the functional requirements (Requirements that are stated by the user) is very important
aspect that has to be considered while designing the system.
Such considerations are tested using the approach of acceptance testing. As the name
implies, after the software development, when it is given to the customer, he will check
whether the requirements stated by him are satisfied or not. If it is not satisfied, it will lead
to reconstruction of the entire system.
The cost of reconstruction is very higher than the development, which makes the
company to lose large amount of money.
Hence, the procedure of testing the acceptance criteria is essential activity. Such
acceptance criteria of the system will be tested by using the method of acceptance testing.
Testing Procedure:
(1) Identify the user stated requirements.
(2) Tabulate all requirements stated by user.
(3) Test whether the stated requirements are implemented in an effective
way.
(4) If step (3) yields output as YES, then the software is effective and
PASS with the testing approach.
(5) If step (3) yields output as NO, then the software is to be redesigned
and it fails in this testing method.

Example:
Consider the customer need a system to display the date, time, day and the date should
be strictly in the format of (DD/MM/YYYY). But the developer designed the system
which prints
(1) Date : 21-June-1995
(2) Day : Monday
(3) Time : 09.45 PM
In the above scenario, the system is consistent with the user quoted information
but it fails in meeting the syntax that was quoted by the user. The client really wants the
system which displays the date in the format (DD/MM/YYYY). But the developer
designed for (DD-MM-YYYY) which is inconsistent from the user point of view.
In this case, the system will fail in the acceptance testing since the user will not
accept the design of the system. From the user’s perspective, if we test the system we can
identify that the system fails in meeting the requirement.
 If(System fails in user quoted requirement):
System has bug from user’s view;
Redesign the system;
else:
System has no error from user’s view;
Merits:
(1) Very effective since the user requirement (the important thing) is taken into
consideration.
(2) User satisfaction is tested.
(3) Testing from the user point of view.
(4) Reveals unknown defect at the greater extend.
Demerits:
(1) There is no internal code checking.
(2) The tester’s thinking will be only from user perspective.
(3) No possibility of logical error deduction.
(4) No focus to the logic
(5) Acceptance Criteria checking is the only goal.
Test by yourself
1. Write the merits and demerits of Acceptance Testing.
2. Explain the testing procedure of Acceptance Testing.
3. When will you say that the system failed in Acceptance Testing? Derive the
testing procedure.
4. What are the aspects that you will consider in acceptance testing? Explain in
detail.
5. Assume that, the user stated the requirements to design a website with the
guidelines ‘a’ to ‘e’.
1. The page should contain a frame.
2. The page should not contain marquee.
3. The page should not contain any coloured text.
4. The page should not contain any fonts rather than Times New
Roman.
5. The page should be free from advertisements.
The software engineers designed the website with the following features
referred by ‘f’ to ‘j’:
6. Effective Interconnections among the different pages.
7. Different running texts overall website.
 8. Static and default font provided by HTML.
9. Free from advertisement.
10. Unique and default colour (provided by HTML).
Identify whether the user given guidance’s are satisfied or not with the help of
suitable testing methodology.

Alpha testing:
Alpha testing is the testing methodology in which the testing takes place at the
developer site.
Alpha testing is the final testing activity which is conducted before the delivery of the
software. It is the final testing that was done at the developer side.
In this approach, the software is going to be tested by the SQA team members
(Software Quality Assurance Team) to find the possible bugs that are available within the
system.
The developer side testing procedure actually includes the method of giving random
valid and invalid set of inputs (black box) and checking internal logics in order to check
the effectiveness of the system.
If the system handles the both valid and invalid inputs in effective way, then it is said to
be worth vile and bug free system. If the system shows any bugs during this process, then
the system fails in the alpha testing.
The main theme of the Alpha testing is checking the effectiveness of the system at the
developer side. The developer has to ensure the effectiveness property before delivery.
Hence, alpha testing is important type of software testing that states the
correctness of the system from the developer terminal.
Conduction Period:
The alpha testing methodology is actually conducted at the end of the development
process. Actually, it is conducted before the delivery of the system.

Why Alpha Testing?

Testing system with both valid and invalid sample inputs at developer side before
delivery in order to ensure the correctness. It includes both white box and black box
testing.

Testing Process: (Alpha Testing – Black Box)

(1) Test the system with sample valid and invalid inputs. (Only Random
Sample Input at developer terminal)
(2) If (system reacts in an effective way for both valid and invalid input):
 1. System succeeds the testing.
2. System is effective to deliver.
(3) Else
1. System is Inconsistent
Testing Process: (Alpha Testing – White Box)
(1) Test the system with internal logics (Loops, Conditions, Path Coverage
etc..)
(2) If (system reacts in an effective way):
1. System succeeds the testing.
2. System is effective to deliver.
(3) Else
1. System is Inconsistent
2. Redesign the system.
Real Time Example:
Assume the LOGIN functional module of online examination software. The Alpha
Testing of the particular module involves black box and white box testing.
Alpha - Black Box Testing:
Give a sample (random) valid and invalid login. Here, am going to make an assumption
that USER ID and Password should be entered in order to start the test.
Let we see how the system reacts for both positive (Valid Test Case) and negative
inputs (Invalid Test Case)
TESTING WITH INVALID INPUTS:
System Handling Invalid Input(s):
Case (i) Handling NULL Inputs:

Figure (a): System Handles the Invalid Input

Case (ii) Handling INVALID Login:

 Figure (b): Message shown by system if login credentials are invalid

TESTING WITH VALID INPUTS:

Figure (c): If the USER ID and Password are correct, then the system that displays
Welcome Message.
Alpha – White Box Testing:
In the Alpha – White Box Testing, internal loops, logics, conditions are tested. [Refer
White Box Testing Section for more information].
Merits:
(1) Using the alpha testing, the developer can identify how the system reacts
for both valid and invalid data.
(2) Effective method for ensuring quality before the delivery.
(3) Simpler Method of Testing.
(4) Final Testing Procedure which is important before delivery process.
(5) Both White Box and Black Box testing employed.
Demerits:
(1) More importance given to customer satisfaction.
(2) Dealing with random sample inputs.
(3) Takes more time.
Test by yourself
1. Explain the different categories of testing at the developer site.
2. Write the merits and demerits of Alpha Testing.
3. The software engineers want to develop the software for online examination
with 30 MCQ’s each with four alternatives – explain how the alpha testing is to
be conducted for this scenario.
4. Compare the differences between Alpha Black Box and Alpha White Box
Testing.
5. Why the Alpha testing is essential?
6. Illustrate the testing algorithm for Alpha Testing.
7. A software developer wants to develop the Graphical User Interface (GUI) for
billing system – What is the role of Alpha Testing in this scenario?
8. How test cases are generated in the Alpha Testing? Explain in detail.
9. Give the real time example for Alpha Testing and explain the same.
All Pairs Testing:
All Pairs Testing Approach follows the testing mechanism in which the all combination
of inputs will be tested. It follows the combinatorial testing methodology in which the
possible pairs of inputs are tested in this method.
Assume that, the system has n input fields and n possible inputs can be entered with
each input field. At such cases, the system uses n2 cases are designed to test the
effectiveness of the system.
As the name implies, all possible pair of inputs are combined to check the effectiveness
of the system according to various inputs. It actually examines how the system behaviour
will be depends upon the combination of the input.

If (s/w reacts well for all possible combinations):

System succeeds the All – Pair testing;
It yields effective result for any combo;
else:
System fails with certain input combo;
Redesign the system;

As shown in the above code, if system reacts well for entire possible combination of
inputs it is efficient else the system is in-effective.

Testing Procedure:
(1) Start the Testing Process.
(2) Identify the number of input fields. (x)
(3) Identify the number of combination of (y) input that is possible for each
field x
(4) Design various test cases, with the different combination
(5) Test for the entire combinations.
(6) If (System Reacts well for all combo):
1. System is efficient
(7) Else
1. System is In-efficient.
Testing conductance Period:
 The all pair testing will be conducted either at the finishing stage of a particular module
or at the finishing stage of the entire system.
If the system module requires any input to process further at such instance, all pair
testing is essential.
Why All – Pairs Testing?
All – Pairs testing states whether any combination of input fails to react in effective
way or not.
It checks whether the system is effectively reacting with all combinatorial parametric
measures of input.
Real Time Example:
Consider the login module for the Chatting Server
System. Assume that, the login module requires the User
ID as the only input to login in.
Here, am going to make an assumption that possible
number of input to the field User ID is number ranges from
[301 to 305].
Hence, we can state that there are only 5 possible
combination of valid input is possible to the text field User ID.
As per the rule of All Pair Software testing methodology, the possible combination of
test cases are.,
5 ^ 1 = 5 different inputs to be given and the efficiency of the system has to be tested.
For effective All Pair Testing, we can also embed the testing with negative inputs (invalid
testing).
For the above scenario, assume the process of giving Alphabets and other numbers
which are not belonging to range [301-305] as two invalid test cases.
The following table illustrates the reaction of the system due to valid and invalid inputs.

INPUT TYPE Expected

Result

301 V Logged In

302 V Logged In

303 V Logged In

304 V Logged In

305 V Logged In

ABC IV Error
 532 IV Error

In the above table the inputs ‘ABC’ and ‘532’ are considered as the invalid input since
the text box is designed only to accept the numerals as the inputs.
Hence, the effective system should show error for the wrong inputs that are passed by
the end-user.
Case (i): Giving valid Input (301 as USER ID)

Fig: System shows the chatting page as the result of VALID input
Case (ii) : Giving Invalid Input (532 as ID)

Fig: System shows the Invalid Login message as a result of INVALID input.
Thus, by giving various combination of input to the input fields and ensuring the
effectiveness of the system will be encountered using the approach of All Pairs Testing.
Merits of All Pairs Testing:
(1) It displays how the system works for various combination of input.
(2) Very effective testing mechanism since each combination of input is tested
in a detailed manner.
(3) The test summary of All Pairs testing is useful to identify the internal errors
which are difficult to identify.
(4) All Possible Combinations are tested and hence it ensures 100% efficiency
of the software.
(5) The main parameter for any system is input, that parameter is tested hence
it is essential to apply this testing approach to any system.
De Merits of All Pairs Testing:
(1) All Pairs Testing may holds good for the system which has less number of
input fields.
(2) Assume that the systems will n input fields with n input combination –
 hence n ^ n valid and n invalid test cases are essential to test effectiveness.
(3) Very time consuming.
(4) Impossible to apply with larger systems.
(5) Application for the modules which are processing with the user inputs.
(6) Increases overload to the tester.
(7) Time allocated for testing is very short. Testing all combos of inputs within
short period is difficult task.
Hints for effective All Pairs Testing:
(1) Use all possible combination of valid inputs to test the system efficiency. In
addition to that, add some invalid combinations in order to ensure efficiency.
(2) Do not go for All Pair Testing if your software has n input fields, if n is
larger.
(3) Design test cases carefully.
(4) Ensure whether all pairs (combinations) of inputs are tested.
(5) Use mathematical combinations in order to identify the possible pairs of
inputs.

Test by yourself
1. A test web page named ‘dec.html’ contains the form which is designed to allow
the user to register for an event. The elements of the form include user name,
unique ID (issued by the organization), password, and mobile number.
Construct the All Pair Testing Scenario for testing the form.
2. Write the testing procedure of All Pairs Testing.
3. Why it is essential to test all pair of inputs? Give its advantages.
4. Construct the All Pair Testing for webpage with four text fields. The first field
only accepts integer, second text box only accepts the strings, third and fourth
accepts both integer and strings.
5. Write the formula for All Pair Testing Approach. What is the drawback behind
this method?
6. A form named x, consist of 100 text boxes, 200 drop down list and 260
password fields. Derive how many positive test cases are needed for effective
all pair testing.
7. Compare the positive and negative test cases in all pair testing.
8. Give few hints that help in effective all pair testing.
Application Interface Testing:
The application interface testing is also called as user interface testing. The client will
measure the effectiveness of the software only by considering the user interface.
Designing the user interface is an essential thing that enhances the quality of the
software that has to be designed. Testing the interface for its correctness is also an
important aspect.
System from user’s perspective:
From the user’s perspective, the system is 80% efficient, if its user interface (Front –
End Design) is good. If the front end shows in-efficient design, then the system was not
accepted by the customer / client.
Hence, testing the application / user interface is an essential task that has to be
performed as one of the testing methodology.
Types of user interface:
Generally, there are two different categories of user interface.
(1) Graphical User Interface (GUI)
(2) Web User Interface (WUI)
Testing the front – end design is simply said to be User Interface. Invalid design
of user interface will yield the system redesign. Hence it is very important testing. No
software will get delivered to client without UI Testing.
Whatever the interface type may be, the tester has to test its efficiency. The testing
of user interface design ensures the following:
(1) Checking whether the front and back end are fixed in an effective way or not.
Assume the simple web application with the text box as a front end as shown in
the figure given in the next page:
The code for the front – end which was created in
HTML is given below: (which is the code for the
user – interface)

Login.html:
<center>LOGIN FORM</center>
<br><br>
<center>
<form
method = “post”
action = “validate.php”
 <p>Enter your Name</p>
<input type=“text”
name = “user_name”
autocomplete=“off”
placeholder = “Your Name”>
<input type =“submit”
name = “submit”
value =“submit”>
</center>
</form>
Assume that the database that was connected to store the user name is defined with the
data-type integer (which can hold only numeric data). But as per the user interface, the
layman can only enter the user name (string data type) instead of user id (integer data
type).
The reason is that, the end user doesn’t know the logic. He will work with the system
based on the user interface design. In the above case, user interface, fails to be consistent
and cause the user to misunderstand regarding the input specification.
(2) The User Interface Testing also ensures whether the system is efficiently designed
with effective UI or not.

If(User Interface of System is Effective):

The system will be user friendly;
P(acceptance by client) = high;
Else
P(acceptance by client) = low;
It is advisable to follow certain guidelines while designing the user interface.
Guidelines for Effective User Interface:
(1) Make the user interface simple.
(2) Use icons instead of images.
(3) Do not include much graphics, which may increase the loading time.
(4) Design the system in such a way that it shows the response for each user
activity.
(5) Design the user interface with HELP menu
(6) Embed shortcuts with the User Interface.
 (Example: Ctrl + O – Opening Window)
(7) Design user interface in such a way that it shows the various messages
depends on the user action.
(Example: If users perform any restricted activity with the system, the system
should the show alert message)
(8) Place the form elements in the user interface screen in a consistent way /
organized way that gives good look and feel.
(9) Embed pop up’s that helps to work with the system.
(10) Design user interface in such a way that it also validates the user input
before working with the back – end.
Testing Procedure:
(1) Open the User Interface.
(2) Perform Valid and Invalid Actions with the Interface.
(3) Test whether the following happens:
1. System throws errors and alert messages for illegal actions.
2. System shows the pop – up messages if needed / necessary.
3. System back – end and front – end connectivity holds good.
4. Interface is faster, responsible, interactive and simple.
(4) If (a & b & c & d) holds the result as true:
1. User Interface of the system is consistent;
2. System succeeded with the UI Testing;
(5) Else:
1. Redesign the User Interface;
2. Instruct to design user friendly UI;
(6) End the testing method.
Merits:
(1) Users judge the system only by interface; hence user interface testing is
essential.
(2) If user interface is not effective, then the other internal process will also
affect. Hence for any system, the consistency of user interface should be tested.
(3) Allowing good user interaction is the important quality that software should
acquire. To ensure this quality, UI testing is very essential.
(4) Avoids the drawback of unwanted actions performed by end-user due to
lack of UI Design.
Demerits:
(1) Testing the user interface doesn’t deal with security constraint(s) at most
cases.
 (2) The efficiency of the front-end only tested by this method.
(3) In many cases, the testers who are performing the UI testing don’t bother
about the internal logic’s, unwanted codes etc.
(4) More importance given only to user’s perspective rather than the internal
logic.
Examples for Consistent and Inconsistent UI
(Mark entering system):
Fig: (a) and (b) shows
consistent and
inconsistent user
interface design
strategies
Can you able
to distinguish among
figure (a) and figure (b)
?, even though both
User Interface instructs
the users to perform
same operation, the good look and feel increases the interest of the users to work with the
system.

Test by yourself
1. What is User Interface? Write the essential guidelines for effective User
Interface design.
2. Derive algorithmic procedure for User Interface Design.
3. Why it is essential to test the interface?
4. Compare and contrast between virtue UI design and poor UI design standards.
5. How will you identify that the Interface is inconsistent? Explain.
6. Explain the outcomes of the user interface design.
7. Estimate the consistency level of the following user interface by considering
your own assumptions:

Age Testing:
Age testing is the testing mechanism which illustrates how the operations of the system
will be in the future. It is the future considerations about the system.
Normally, software is reliable and the rate of failure due to the aging factor is very less
when compared to the hardware. Assume that, when we get a keyboard and if we used it
for more than 2-3 years, then the efficiency of keys in the keyboard will gets reduced. The
typing speed and other factors are greatly affected and they produce very poor
performance due to aging factor.
But, in the case of software, it is the opposite case. Aging factor affects the software at
the lower rate. Even though the degree of influence is very less, it is essential for a good
software engineer to develop the system that should with stand for longer time.

Hardware and Software Reliability:

The factors of hardware and software reliability can be explained by using the bath tub
curve and saw tooth curve.
Bath tub curve:

Fig: Showing reliability of the Hardware due to the aging

The above figure illustrates the measure of performance by the hardware due to the
aging factor. The curve is said to be bath tub curve.
Initially, when we buy and use the hardware the performance is high and the degree of
failure is very less. In the middle period, (useful life period), the rate of failure will be
gradually increasing. Whenever the age of the hardware reaches to maximum, the failure
curve increases exponentially and makes the failure at the greater extent.
Matching the curve with the real time scenario is more helpful in understanding the
concepts of Bath-tub curve.
Real Time Example:
John bought a keyboard for Rs.150/- during the year of 2004. He used it for about 4
years and he experienced the failure by the end of 2007. Plot the bath-tub curve that shows
reliability of the keyboard.

In the above graph, the failure rate of the keyboard will be gradually increases. During
2004, the failure rate curve will get decreases (since the hardware is newer during that
time). After the useful-life period, the hardware reaches the wear out period which leads to
the failure of the hardware by the year of 2007 (due to aging factor). Thus the hardware
failure can be explained by using the Bath-Tub Curve.
Similarly, the saw-tooth curve explains how the software will gets affected due to the
aging factor.
Saw Tooth curve:
The following figure shows the reliability of the software. Actually the reliability
of the software is measures in 3 phases. They are testing phase, useful life phase and wear
out phase.

In the testing phase, the reliability of the software is very high. The probability of
identifying the bugs and errors are relatively high. After testing, (testing will remove the
bugs in the system) the system remains error – free. Hence, the system is free from failure
occurrences when it reaches the useful – life period. In the figure, it is defined as a down-
ward slope, but actually the useful life period may consist of many updates and upgrades,
hence it seems to be saw-tooth shaped structure. The failure rate is very less in the useful
life period.
In the case of wear out period, the system shows very slight failure occurrences. For
many software systems, the wear-out period reaching time is very high. The software
doesn’t affect from the aging factor at the greater extent.
Assume the real time scenario of buying a software named X and X has the versions
A,B,C defined by X – A, X – B and X – C. The reliability of system due to the aging factor
can be well defined by constructing the saw tooth curve.
Assume that the software initial version released by the year of 2007. The successive
versions are released in the year of 2008, 2009. The wear out period to be 2020. The saw
tooth curve that shows reliability due to age factor will be
 The saw tooth in the useful – life period represents various different version updates
(X-A), (X-B) and (X-C). The system efficiency is high in useful life period when
compared to testing phase. At the end of testing phase, the rate of defects will be very less.
Defect Age – Phases:
In the age testing identification of the age, probably the defect may occur is estimated.
The phases are classified into two categories one is defect injection and another one is
defect identification phase.
The formula to estimate the defect age is
Defect age = Defect Identification – Defect Injection
The above formula is helpful in identifying the defect age in which the system may tend
to fail. But actually, the rate of failure of software is very less and comparatively zero
when compared to the hardware.
It is important to identify for the age factor of system that states how the system
will be stable.
Test by yourself
1. What is age testing?
2. How will you measure the age stability of the hardware? Explain.
3. Draw the graph and explain the age stability of software.
4. Jochen bought a printer by the year of 1990. The printer was degraded with its
performance by the year of 2004. Estimate the useful life period of the printer
by constructing the bath tub curve.
5. Roy installed the software named one by zero by the year of 2000. The various
versions of OBZ are released in the successive year 2001, 2002 and 2003. He
updated his software with version OBZ – 1 by the year of 2003. He updated his
software with version OBZ – 3 by the year of 2004. Sketch the saw tooth curve
to identify the reliability of the software.
6. Compare the differences between bath-tub and saw tooth curve.
7. If defect identification phase is unit testing and defect injection phase is
happened during analysis phase, identify the defect age.
8. Explain defect injection and defect identification.

Accessibility Testing:
Accessibility testing is the testing mechanism which ensures whether the system is
suitable for all users. The developed system may be used by various sorts of people.
Hence accessibility testing is very essential to ensure whether it is designed in such a way
that it is effective for all users.
People with disabilities may also interact with the system. Hence, the system should be
consistent with them also. According to the census, about 20-22% of the population have
various disability issues.
Designing the system by considering various people will leads to increase in the
standard of the system. If the product is global, then the accessibility testing is essential.
Disabilities of People:
The software system that is to be developed should also provide the accessing support
to the people who suffer from the following disabilities:
1. Visual Disability
2. Physical Disability
3. Cognitive Disability
4. Grasping Disability
5. Hearing Disability
Visual Disability:
The visual disability deals with the eye-vision. The people with different eye disorders
fall under the category of visual disability. The simple and general disorders of vision such
as myopia, hypermetropia are not taken to consideration since they can be rectified by
wearing lenses, so that the persons having such disorders can access the system in
effective manner. The complex eye disorder that includes blindness, colour blindness is
taken into consideration while designing the system.
Guidelines to design the system for visually disabled persons:
(1) The visually disabled persons cannot able to see the system screen. Hence,
the system should have sound effects to interact with the persons.
(2) Different new technologies and sensors should be used in order to help the
visually challenged persons.
(3) Consider the colour contrast while designing the user interface. The people
who are having colour blindness cannot able to see some colours. Hence,
consider colour intensities while designing UI.
Physical Disability:
The physical disability includes the persons with physical disorders which includes the
persons who cannot able to operate their hands and who cannot able to move their
muscles.
Guidelines to design the system for physically challenged persons:
(1) Voice recognizers should be used to perform operations instead of mouse
operations and keyboard operations.
(2) The persons with the physical disabilities can able to speak, but they cannot
able to do actions with input devices such as mouse, keyboard, joystick etc.
The only another way to give instruction to computer is by speech. Hence
speech recognizers should be used to recognize the instructions.
Cognitive Disability:
The cognitive disability personalities are one who are having memory related problems.
Some people cannot understand and they may have memory loss. If the operations are
very complex, they cannot able proceed with the system.
 People with the learning disability are also fall under this category. The design of
system should also focus on such people.
Guidelines to design the system for Cognitive Disabled Persons:
(1) Design the system operations in a simple manner.
(2) Do not embed complex actions into the system.
(3) Use Simple User Interface Design.
Grasping Disability:
The grasping disabled persons are one who is having reading problems. They cannot
understand the words and sentences which are complex. Hence the design of the system
should be in such a way that it should be free from the complex instructions and words.
Guidelines:
(1) Do not use complex words.
(2) Words that are related to software field (technical words) should not be
used, while designing the system.
(3) Use icons to implement the operations.
Example:

Fig: Usage of Printer icon

In the above figure, rather than implementing the words (or) instructions to represent
operations, representing them in a iconic format helps the persons with grasping disability
at the greater extent.
Standard Icons and Operations:

S.NO Icon Operation

1 Used for illustrating the

operation ‘New’.
By clicking the icon, user can
open NEW file.

2 Used for illustrating the

operation ‘Open’
By clicking the icon, user can
open the file.

3 Generally floppies are used to

 illustrate save operation.
By clicking the icon, user can
perform save operation,

4 Scissors are used for

representing the operation ‘Cut’.
By clicking the icon, user can
perform cut operation.

5 This icon represents copy.

By clicking the icon, user can
perform cut operation.

6 This icon represents pasting

activity.
By clicking the icon, user can
perform cut operation.

7 This icon represents

Minimize Activity.
By clicking the icon, one can
minimize (reduce the size) the screen.

8 This icon represents

Maximize Activity.
By clicking the icon, one can
maximize (increase the size) the screen.

9 Close operation is performed

with the help of the icon.
One can close the screen by
clicking the icon.

The above table illustrates the standard icons used for performing the operations. For
effective accessing, icons are very essential.
Hierarchy of User Accessing the System:
The System that is going to be developed may be accessed by various categories of
people. The category includes
(1) Experts and Professionals : Programmers, developers, testers
(2) End Users Level I : The persons who doesn’t have any disabilities
but doesn’t have any technical knowledge.
 (3) End Users Level II : The persons with disabilities and who are not
having any technical skills fall under this category.
Accessing Modes:
The variations of the users lead to variations in the accessing too. The experts and
professionals can interact with the system via CLI. Command Line Interface (CLI) is used
for querying the operations of the system.
In order to retrieve the data from the table, the experts uses the query select * from
table; which retrieves contents of the table. The experts and professionals have technical
knowledge and hence they access the system via CLI.
It is quite opposite in the case of level I end users. They access the system via Graphical
or Web User Interface. The design of user interface is essential. The end users (level I)
access the content of the table just by clicking button which triggers query internally to
select and display contents from the table.
The level II end users need additional support such as voice support (speech
recognisors) and other sensor supports to access the system.
Testing Procedure:
Accessibility testing ensures whether the system is accessible by all categories of users
or not. It is just conducted to verify the following.
(1) Shortcuts are implemented / not
(2) Iconic Representations are implemented / not
(3) Interface colour is consistent / not
(4) Voice and Audio Embeddings are supported
(5) System is flexible with the design and transitions / not.
Shortcut Implementation:
Short cut implementation deals with the keyboard equivalents. By clicking the mouse,
performing operations may be tedious and not comfortable for many users. Hence
keyboard equivalents are essential.
Guideline to design Keyboard Equivalents:
(1) Simple and easy memorisable.
(2) Should not involve in pressing more than 2 – 3 keys.
Example: Ctrl + O to open, Ctrl + P to Print
(3) Use the first letter of the operation to make keyboard equivalent.
Example: Ctrl + P for printing the content.
(4) In the labels, highlight the shortcut. Example: Print
Such shortcut implementations are also evaluated in the accessibility testing to ensure
the effectiveness of access.
Interface Colour Consistency:
 The interface colour consistency refers to how consistent the interface colour is. Usage
of dark colours and dark backgrounds make the users to feel bad. Hence use contrasting
colour for background and texts. Such colour consistency should also be evaluated in the
accessibility testing.
Test by yourself
1. Explain in detail about various types of disabilities.
2. What are the guidelines to be followed while designing the system for
various sorts of users?
3. Comment on hierarchy of users who can interact with the system.
4. Illustrate the usage of iconic representation.
5. Explain in detail about any seven standard icons in detail.
6. Why keyboard equivalents are essential? Justify.
7. What are all the scenarios evaluated by accessibility testing? Explain with
the testing procedure.
8. Discuss in detail about importance of accessibility testing.

Adaptive Testing:
Adaptive testing is very similar to all pair testing. The only difference is that in all pair
testing the system efficiency will be estimated by giving both valid and invalid inputs. The
testing combinations are very high in the all pair testing.
It is because of considering all possible pair of positive inputs and randomly selected
negative inputs. In the case of adaptive testing, the system efficiency is calculated based
on how system gets reacted on the various different negative inputs.
The number of negative inputs is only used in order to determine the efficiency of the
system. The outcomes of various negative inputs are used to test how the system adapts to
that inputs.
In general, the adaptive testing mechanism deals with how effectively the system can
handle the negative inputs (Error Input Handling). The adaptive testing is very important
because in many cases, the end-users unknowingly give the invalids.
Testing Procedure:
 (1) Open the interface of the system.
(2) Give set of all possible negative inputs.
(3) IF (System reacts and handles the inputs in an effective way)
1. System succeeds the Adaptive testing;
(4) ELSE
1. System fails to handle the negative inputs;
2. Reconstruct the system;
(5) Note the result into test log.
The above algorithm illustrates the adaptive testing.
Real Time Scenario:
The adaptive testing is well explained with the help of scenario given below. The exam
results publication system that asks for input (register number) to get the result.
In order to pass the adaptive testing mechanism, the system should works good (ie, it
should be capable of handing negative inputs). In our case, the system should take only
integer numbers as the input.
It should also take only the valid inputs. If the invalid inputs are given to it, then it
should show the error.

Fig: User Interface of Online Examination System

In the case, the adaptive testing is conducted by giving the negative test cases. The test
cases are here formed based two criteria.
(1) Giving the invalid data type
(2) Giving the valid data but the data doesn’t match with user ID.
If the system handles the both scenario gently, then the system is said to be very
consistent else the system is inconsistent and re-design is essential.
The adaptive testing is generally considered as an optional testing methodology because
the system operations are actually deals with positive inputs.
Case (i): Giving Invalid Data Type to the text field:
Input:

Outcome:
 In this case, when the end user tries to give the invalid data type (string ABXY in our
case), the system shows the message to the end user as: “User ID should contain
NUMBERS only”.
The system doesn’t show the result as ‘Invalid Data type’ because data type is the
technical words the end user doesn’t know much information about the word. Hence as
simple, the alert message is intimated to the user. Hence, the system passed in the phase I
of adaptive testing.
Guideline for Alert Messages:
(1) Alert message should be simple, short and precise.
(2) Alert message should be displayed whenever the user tries to given
the invalid inputs.
Case (ii): Invalid Input of Same Data Type:
This scenario is further classified into two categories for our example. The User ID
pattern should contain only 6 digits. More than 6 and less than 6 digits number are
considered as negative inputs. In the adaptive testing, it is very essential to consider both
cases.
(i) Giving Input less than specified range r
(ii) Giving Input greater than specified range r
Giving Input less than range r:
For this case, let we try to give the input as ‘343’ to the user ID field. Now the effective
system should throw error as ‘Length of the User ID is very shorter. It must contain 6
digit(s). The following figures illustrates this scenario,

Figure: Input given to the field User ID (343)

Figure: Output received as the result of shorter input given to User ID

The system is very effective since it shows the correct error message to the users
instead of general error message.
Giving input greater than the specified range r:

In the above case, the system again shows the error because the input digits are greater
than that of specified / restricted range. In this case also the system is handling the input
effectively.
Additional Case:
Giving input within the specified range but not a valid one:
Assume that the system is handling with six digit inputs ranges from [631500 –
631900]. If the user tries to give any 6 digit input that is out of range (eg: 866421) but
satisfies with the number of input digits. The system should also able to handle this
scenario in a peaceful manner.

The system shows the general message ‘Invalid register number’ as the consequence of
such inputs.
If system handles the above scenario’s effectively by showing alert messages to end
user in a meaningful way depends upon the situation, then the system is said to be
effective.
Merits of Adaptive Testing:
(1) Deals with negative inputs.
(2) Alerts the user in case of negative inputs.
(3) Evaluates another side of the system. Hence efficiency of the system
is increased with the help of this testing

Demerits of Adaptive Testing:

(1) Adaptive testing is always optional.
(2) Many testers consider that it is time consuming task.
(3) Writing general message to all possible negative inputs technique
makes this testing to be worthless.

Test by yourself
1. What is adaptive testing? Write its merits.
2. Differentiate between adaptive testing and all pair testing.
 3. Justify: Adaptive testing is optional.
4. Derive the testing procedure of adaptive testing.
5. By considering any one module of e-ticket booking system, explain the
importance of adaptive testing.
6. How test cases are generated in adaptive testing? Explain.
7. What is alert message? When to display it? How to display the alert
messages in effective manner?
8. Write the drawbacks of Adaptive testing.

Active Testing:
Active testing is the testing strategy in which a conceptual model of the system to be
developed is built and using that the testing operations will be performed.
Needs of Active Testing:
(1) Active testing builds a conceptual model which is similar to the system that
has to be developed.
(2) During the end of each and every operation that was performed, the
efficiency of the system was measured.
Testing Procedure:
(1) Create the conceptual model of the system
(2) Perform various operations with the system
(3) IF(system reacts in a meaningful manner)
1. System is active;
(4) ELSE
1. Redesign the system;
(5) Note down the success / failure report into test log.
(6) Continue Step (2) to (5) until all test case variations are tested.
Merits of Active Testing:
(1) Testing using conceptual model.
(2) Checking worth vileness at the end of each and every operation.
(3) Test data’s are introduced in order to test the efficiency.
Demerits of Active Testing:
(1) Testing at the end of each and every operation leads to wastage of time.
Test by yourself
1. Write the importance of active testing.
 2. Discuss in detail about the merits and demerits of active testing.
3. Write the testing algorithm for Active Testing.

Puzzle

Agile Testing:
Agile Testing is the effective testing methodology which uses the principles of agile
software development. Agile follows the effective mechanism of software development. It
varies from traditional method of Software Development.
In the agile testing mechanism, both tester and developer involve in the activity of
testing the system. In traditional testing methodology, the testing is the phase which will
be usually done after the development.
If any problems with the system encountered while testing, the system will be
reconstructed and the duration for reconstruction of the system is probably very less. The
agile testing avoids the drawback of the traditional SDLC.
Assume that system encounters the defect during the activity of testing; now the tester
will intimate the test to the developer. The developer has to rectify and reframe the
software within small duration. If the defect that was happened is very tedious, then it is
very difficult to solve and rectify the defect within the given period of time.
For the above shown scenario, the software development activity duration will
relatively increases and causes the customer / client to wait for longer period. To avoid
such drawbacks, agile testing methodology suggests the term ‘Test Forward’.
At the end of each and every phase, the agile testing will be conducted in order to
measure the efficiency of the system. If the system shows greater degree of efficiency,
then the system will be moved to the further stage of development. It is also said to be
iterative development and testing activity.
If the system encounters any failures or defects, then the testing intimates clearly that
the particular module causes the defect and that model will be reframed.
After constructing entire system and testing them as a whole leads to the problem such
as
(1) Complexity in testing.
(2) Higher order defect rectification problems
(3) Many defects may not be encountered.
(4) Testing will be inefficient
To avoid above drawbacks, the agile testing moves the system forward if and only
if current module ensures the efficiency. In simple, agile testing takes the system forward
for further development after testing.
The agile testing involves test and then implement operation. Before
implementation of system, testing will be done.
Agile Testing Procedure:
In the activity of agile testing, the system efficiency will be tested by following steps.
(1) Identify the module likely to be developed.
(2) Classify the requirements and other specifications that are essential
for development:
1. Test the Requirements
2. IF (Requirements are clear)
Develop the module of system
Perform unit, integration, system testing.
Test the module to get feedback
If(Feedback of Module is good)
Go to Step (1)
Else
 Reconstruct the module

3. ELSE
Reconstruct the requirements

(3) End the activity if all modules are developed and tested.
From the above code, it is clear that at each and every process the testing plays a
major role.
The further proceedings with the system are carried out only after the
identification of efficiency of the previously developed modules.
This type of testing methodology overcomes the longer testing duration. As we
discussed above, in the case of traditional software development method, the testing will
be conducted very later. Assume that the development starts by Jun 2010 and if the
delivery assurance date given to the client is by Jun 2013.
The testing activity actually begins after then process of development (probably
by Feb of 2013). Hence the tester as well as developer will gets starved with the time of
reconstruction if any error encountered.
In the case of Agile testing, the testing only leads to further development. Hence,
there is no problem with shorter feedback period.
The developer can get about the system feedback within shorter duration. The
agile testing mechanism also overcomes the drawback of documentations.
The following figure illustrates how testing and development activities are
embedded in the agile testing process. After every short interval, testing will be done so
that to conform the efficiency of the system.

The above figure shows how the agile testing implements the continuous checking of
the efficiency of the system.
Merits of Agile Testing:
(1) Testing is not a phase. It is a part of every module development.
(2) Testing only extends the further module / activity of software
development.
(3) No documentation complexity.
(4) Both testers as well as developers involve in testing the system.
(5) Follows Iterative Approach of development of system.
De merits of Agile Testing:
(1) For smaller projects, it is not suitable.
(2) More importance given to testing will be ineffective for smaller
systems.
Test by yourself
1. Explain in detail about merits and demerits of agile testing.
2. Compare Agile Testing with traditional testing.
3. Design the algorithm for agile testing and explain with neat sketch.
4. With suitable example, explain test forward approach.
5. Testing is not a phase at all in agile – Elaborate.
Assertion Testing:
Assertion testing uses the Boolean expression in order to test the system. At any point p
in the program, it sets the Boolean expression which will be true if and only if the program
doesn’t have any bug.
If there is any bug in the program, then the Boolean point p leads to false. It holds
testable logic.
Testing Procedure:
(1) Set the Boolean variable p.
(2) Perform the testing.
(3) Examine the Boolean value of p.
(4) If (P is TRUE)
1. No error in the system;
(5) ELSE
1. Bugs encountered in the system;
The above algorithm is just stimulation of basic concept of assertion testing.
Merits:
(1) Simple Method
(2) Allows programmers to find bug in the modules of the system.
(3) Bugs can be easily identified.
Demerits:
(1) In some circumstances, misassumptions may occur.
(2) Longer process.
Automated testing:
 Automated testing is the testing methodology which makes use of automated tools for
the execution of the testing process.
Automated testing uses tools which are again software in order to test the software. The
testing tools will involve in conducting the testing process and reporting the result. The
human involvement in testing may take more time and efficiency degree is very less.
With the help of effective automated tool, one can easily conduct the testing activity
and the degree of efficiency is very high.
Test Automation Framework is the method which is used for implementing the
automated testing.
Importance of Automated Testing:
Reduces the time.
Reduces the complexity of testing.
Higher degree of efficiency and satisfaction.
Reduces manual work.
More test cases can be tested.
Testing Procedure:
(1) Create the software
(2) Use the automated tool to test the system
(3) Get the test report and suggestions from automated tool.
(4) IF(Test Report is free from bugs)
1. System is efficient.
2. Deliver the system.
(5) ELSE
1. Identify which module produces bug.
2. Reconstruct and redesign the module.
(6) End the testing activity.
Explanation:
The manual testing activity involves tester who generates the various test cases
manually in order to find bugs that are encrypted with the system. We have already studied
that, in all pairs testing, generating all possible test cases manually and checking the
correctness of system for all combination of inputs takes larger time and practically
impossible for larger system. Such drawbacks are rectified by the automated testing.
Operations performed by automated tool:
(1) Automated tool takes the system as the input.
(2) It generates the all possible test cases that are required to test the system
efficiency.
 (3) It will perform the testing operation by giving inputs using the test cases
that are generated.
(4) It also produces the summary which is helpful in identifying whether the
system is free from bug or not.
Test Manager:
Test Manager is a good example for automated testing tool. This tool was developed in
Java language. Automated Testing Phases:
It is very essential to follow the following phases before illustrating the automated
testing operation.
Phase 1: Decide on Automation
Phase 2: Select the tool
Phase 3: Create test scripts
Phase 4: Perform the testing activity
Phase 1: Decide on Automation:
This is the initial phase in which the testers will identify whether it is
possible to test the efficiency of the system by automation tool or not.
Some systems are not suitable for automation testing.
Hence, it is very essential to identify whether the system is suitable for
automation testing or not.
Phase 2: Select the tool:
If it is possible to test the system via the automation tool, then the secondary
operation is to identify the tool.
There is several software testing tools available to perform the automation
testing.
For efficient test conduction, it is very important to select the appropriate
tool that perfectly suited for testing the software developed.
If the tool selection is inefficient, then the degree of efficiency in testing
will be very less.
Phase 3: Create Scripts:
Creation of scripts involves designing the executable instructions that are
capable for performing the testing operation with the application developed.
After script development, using the scripts software will be tested.
Phase 4: Perform testing activity:
It is final phase in which using the automated tool selected, testing operation
was performed.
After testing, results are examined.
Demerits of Automated Testing:
(1) If the tool that is selected for testing operation is inefficient, then the whole
testing activity leads to be ineffective.
(2) Planning is essential before implementing automated testing.
(3) Suitable only for particular applications
(4) If bug then bug concept invokes, which means if there is bug in testing tool
then testing will be inefficient.
(5) Inefficient testing tool selection may leads to problem.

Test by yourself
1. What are the needs for automation? Explain.
2. Describe the various phases of automated testing.
3. What is test manager? Explain
4. Explain the algorithm for automated testing.
5. Write in detail about the assertion testing.
6. Discuss the drawbacks of Automated Testing.
7. Compare and contrast between manual and automated testing activity.
8. Contrast the advantages and disadvantages of automated testing.
9. Why test tool identification is a crucial task? Discuss.

Task:
Create test cases for the following scenarios:
1. Pen
2. Iron Box
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘A’)

Testing Name Summary

Adhoc testing Testing without any plan

Acceptance testing Testing from user’s

perspective
Alpha testing Testing at developer site

All Pair testing Testing all possible test

cases

Application Interface Testing the user interface

testing

Age testing Testing the age of software

Accessibility testing Testing whether system is

accessible by all hierarchy
of users

Adaptive testing Testing how the system

reacts for the negative test
cases.

Active testing Testing using conceptual

model.

Agile testing Testing in an iterative

development environment.

Assertion testing Testing using Boolean

Expression

Automated testing Testing with the help of

automated tool.

****

3
 Testing Methods
[B]

Introduction:
Under the alphabetical letter ‘B’, there are 11 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Beta Testing
2. Black Box Testing
3. Backward Compatibility Testing
4. Big Bang Testing
5. BVA Testing
6. Binary Portability Testing
7. Bottom Up Testing
8. Branch Testing
9. Breadth Testing
10. Bench Mark Testing
11. Basic Path Testing

Beta Testing:
Definition:
Beta Testing is a testing approach which is converse to the alpha testing. In the alpha
testing, the testing operations are performed at the developer side.
In beta testing approach the activity of testing is carried out at the customer’s side
with the original input data. Beta testing is also referred as field testing because the
testing process is carried out in the customer’s environment.
At the end of alpha, beta testing begins. In alpha testing, if the system is found to
be efficient with developer’s input then the beta testing will be conducted in order to
measure efficiency of the system at the customer site. Generally, both alpha as well as beta
testing are collectively said to be user acceptance testing.
Testing Procedure:
(1) Perform the alpha testing on the system
(2) IF(Alpha Testing reveals that the system is efficient)
1. Goto Beta:
(3) Else
1. Goto Reconstruct:
 (4) Beta:
1. Test the system efficiency on original site;
2. Allow the real end-users to test the system;
3. Get the feedback about the system;
4. If(Feedback is effective)
1. Deliver the product;
5. Else
1. Goto Reconstruct;
(5) Reconstruct:
1. Identify the bug;
2. Rectify and reconstruct the system;
(6) End the testing activity
The algorithm shows how the beta testing is done.
Typically beta testing doesn’t involve the testers. The end users themselves act
as a tester. Hence it also manipulates the acceptance criteria.
Features of Beta Testing:
(1) Testing is performed at the customer site.
(2) Probably there is no role for testers.
(3) The real workers (end-users) with the system will test the efficiency.
(4) Dealing with how system reacts for original inputs.
(5) Time consumption is also very less.
(6) Since user environment is the testing place, compatibility testing also may
carry out with the beta testing.
(7) Effective and very frequent feedback getting is possible with beta testing.
Conduction Period:
The conduction period of the beta testing is actually after the alpha testing. If the
software is ready at the whole, then only we have to go for Beta Testing. The version of
the software under beta testing is said to be beta version or beta release of the software.
Generally at the end of beta testing, if feedback from the customer is effective, then the
system will be delivered. No other further testing will be implemented. Beta testing is
considered as the end-testing because it is the final testing activity.
Needs of Beta Testing:
Testing by the customer is more effective than the tester. The customer’s own
satisfactory level can be identified with the help of beta testing.
Merits:
(1) Testing performed by the customer.
(2) Acceptance as well as compatibility testing embedded.
 (3) Effective testing approach.
(4) Feedback getting time is probably very less.
(5) Final testing procedure before delivery of the system.
Test by yourself
1. Explain the testing procedure of Beta Testing.
2. What do you meant by beta release?
3. Describe the features of Beta testing.
Black Box Testing:
Black box testing is the testing approach in which the software efficiency is checked
just by giving the input and checking whether the expected output comes / not.
Features of Black Box Testing:
Checks whether the system is capable of yielding expected output or not.
Basic testing approach which conforms the fundamental
Explanation:

Fig: Black Box Testing Strategy

Testing Procedure:
(1) Generate the test cases for the system.
(2) Open the software / system developed.
(3) Apply valid inputs (Positive Test Cases)
(4) IF(System handles effectively)
1. Goto Invalid Inputs
(5) ELSE
1. Goto Redesign
(6) Invalid Inputs:
1. Apply Invalid Inputs (Negative Test Cases)
2. IF(System handles effectively)
1. System passed in the black box.
2. Conduct further testing
3. ELSE
 1. Goto Redesign
(7) Redesign:
1. Identify the bugs.
2. Report the bugs in the document.
3. Request to reconstruct the software
Methods of Black Box Testing:
(1) Random Testing
(2) Domain Testing
(3) Equivalence Class Partitioning
(4) Boundary Value Analysis
(5) All Pair Testing
(6) Error Guessing
(7) Decision Table Testing
We already discussed about the All Pair Testing. The other testing strategies are
described on further chapters of this book.
Real Time Example:
Consider a very simple module of a web-page given below. The ultimate aim of
the module/ page is to provide the link for online examination.
By clicking the link, the end-users can interact with the system (write the
examination).

For the above system, the black box testing will be conducted by the following steps.
(1) Creation of Test Cases:
1. Here only operation is clicking.
2. Hence the possibility of positive test case is to click the link
 specified on the page.
3. Let we assume that the negative test case is just hovering the mouse
on the link. In this case, the system should not redirect the client to
the link specified.
(2) Performing the operation:
1. Applying Positive Test Case:
Result : Online Exam Page opened
2. Applying Negative Test Case
Result : No action takes place
(3) Reporting the result:
1. The system is effective.
2. Free from bugs.
(4) Perform further testing strategies.
Merits:
(1) Very simple testing approach.
(2) Gateway for further internal, complex code checking methods.
(3) Takes very less time.
(4) Easy to perform and to note results.
(5) No technical skills needed for a tester to perform such testing methods.
Demerits:
(1) Since Black box is very fundamental testing approach, it doesn’t
concentrate more on logic’s
(2) It is not possible to conclude the efficiency of the system just by
conducting black box testing.
Test by yourself
1. Deduce the algorithm for Black box testing.
2. What are the various methods of black box testing? Explain.
Backward Compatibility Testing:
Backward compatibility testing is a sub category of Compatibility testing (Refer
Compatibility testing). Generally software is not developed as a single version.
There are several versions and several releases exist so that it evolves the advanced
technology by replacing the older one. The versions are actually named by 1.0, 1.1 and so
on.
The backward compatibility testing checks the version consistency. The newly created
version should be compatible with the older version. The reason for checking this
consistency is because if there is lot of change implemented in the newer version, it makes
end user to feel complex while interacting with the system.
If the older version has some feature and if it is not followed / implemented on the
newer version, then it makes the end-user to feel uncomfortable with the advanced
version.
Hence, before implementing the newer version it is essential for the software testers to
ensure the version consistency.
Conductance Period:
The test conductance period for the backward compatibility testing actually occurs after
the newer version development. If a product is launched for the first time in the market,
the there is no need for backward – compatibility testing. If a product x is already released
and the advanced version of x (say x 1.1) is going to be released, then in such case, after
development of x 1.1 the backward compatibility testing takes place.
Testing Procedure:
(1) Check whether the software that was developed has older version / not.
(2) If (Software has older version)
1. Goto Conduct;
(3) Else
1. No need to conduct backward compatibility testing process.
(4) Conduct:
1. Ensure whether the software is compatible with older releases
1. Check shortcuts are same.
2. Check older version feature remains on the newer
version too.
3. Check platform consistency
2. Identify whether the system is compatible with older version or not.
3. If (Compatible)
1. Perform further testing if necessary.
2. Release the newer version.
4. Else
1. Identify incompatible modules.
2. Reconstruct them.
(5) End the testing activity.
Real Time Example:
Consider the result getting system developed using PHP. Here the web page versions
V1 and V2 are shown in the figure given below.
Let we apply the principles of backward compatibility testing to ensure the system
efficiency.
Version – 1:
In the older version, in order to get the result the user has to enter the class
name as well as roll no.
Here, only one button (submit button) exist, on clicking that button the users
can get the result.
Version – 2:
In this version, the complexity of getting the result is reduced. By entering
user ID only, the users can get the result.
Here the system is more flexible because it is having both submit and reset
buttons.
Applying Backward Compatibility Test:
In the above given scenario, the button named ‘Submit’ exist on both versions which
makes the system to pass in the backward compatibility testing. The name used in the
previous version was preserved in the newer version too. It makes the end-users to feel
comfort to work.
Even though the additional feature (Reset button) added and the user interface has been
changed, the button name remains same to provide backward compatibility to the users. If
the developer use the word ‘Press’ instead of ‘Submit’, the end-users who are familiar
with older version will get confused on handling the system.
Merits:
Deals with extreme degree of consistency.
Minute changes are noted.
Version control monitored.
Demerits:
Backward Compatibility is not a bug at all.
It is again checking the consistency of the system from the user perspective.
Only applicable if software has several versions.
Test by yourself
 1. For the Ms-Office packages version 2007 and 2010 – Perform backward
compatibility testing and produce the test summary report.
2. For the various versions of Windows Operating system, perform the
backward compatibility testing and create the test summary report.
3. Conduct the backward compatibility testing for Android operating system
and produce the test summary report.
4. Derive the testing algorithm for backward compatibility testing. Add note
on merits and demerits.
5. Why the system should be compatible with previous versions? Give valid
points for your answer.
6. Identify any four releases of Google chrome and conduct the backward
compatibility testing.
Big Bang Testing:
Generally the software development activity takes place with modular approach.
Modular development process is very effective and the degree of complexity is very less.
The developers go for modular approach for faster and effective development of the
system. In the modular development technique, the actual system (which is very large) is
divided into various modules.

Fig: Modular Development Approach

The various modules are tested individually in the unit testing process (Refer Unit
Testing). In the big bang testing approach, after development, the entire modules are
joined together and testing will be performed by considering the system as the whole.
After development of all modules (A, B.. N) the modules are joined in a logical manner
and the testing is be performed to ensure the consistency of the system.
Conductance Period:
Generally the big bang testing is conducted after the unit testing approach. In the case
of unit testing, separate modules are tested. After unit testing, the individual modules are
interconnected and the big bang testing will be conducted.
In some cases, without performing integration (refer integration testing) testing and unit
testing, the big bang testing may be conducted.
Testing Procedure:
(1) Design the software as the individual modules.
(2) Interconnect the individual modules in a logical manner.
(3) Apply test cases to check whether the connection is strong and efficient or
not.
(4) If (Efficient)
1. System has passed the Big bang testing;
(5) Else
1. System failed;
2. Reconstruct the system;
(6) End the testing process.
If modular approach is not followed, then it is not possible to conduct the big bang
testing. Combine the modules and test the system as the whole is the key point of the big
bang testing.
Real Time Example:
Consider the web design process; we know that website is nothing but collection of web
pages. If we interconnect the pages then the website is created.

The above figure shows that there are six different pages make the website.
Assume that each page as an individual module.
Hence the modules are
(1) Home.html
(2) Myprofile.html
(3) Mybooks.html
(4) Myprojects.html
(5) Mylectures.html
(6) More.html
Each module is created in an independent manner. After creation, the modules are
interconnected in a logical way and the efficiency is tested just by interacting and
migrating from one page to another by clicking the links. Such type of testing is called
‘Big Bang Testing’.
Merits:
Big bang testing identifies the system performance as a whole.
Identifies interconnection problems too.
Demerits:
Difficult to identify the bug.
Big bang testing takes more time.
Number of test cases is very high.
Takes more time on test reporting.
Task:

Boundary Value Analysis (BVA) Testing:

Boundary Value Analysis (BVA) is a black box testing approach. It checks the
consistency of the system just by giving the inputs.
In the all pair testing approach, giving all possible combination of inputs and checking
the consistency of the system is ineffective method because of the following reasons.
(1) It takes larger time.
 (2) If system is large, then the test case generations is also very large.
In many cases, the problems arrive with the boundary of inputs. Hence, checking the
consistency by generating the test cases that concentrates more on boundary values is said
to be BVA testing.

The above figure shows the logical representation of boundary value analysis. The BVA
reduces the number of test cases thereby reduces the time of testing. The main assumption
in BVA is that, problem arise only with boundaries.
Test cases are generated for both valid boundaries and invalid boundaries. The test case
generation is actually comprises of following combinations,
(1) Valid Input: Between the boundary b.
(2) Invalid Input: Less than the boundary b.
(3) Invalid Input: Greater than the boundary b.
(4) Valid Input: Equal to the minimum boundary b.
(5) Valid Input: Equal to the maximum boundary b.
Testing Procedure:
(1) Identify the input field to be tested.
(2) Derive test cases with the following scenario’s:
1. Valid Input: Between the boundary
2. Invalid Input: Less than the boundary
3. Invalid Input: Greater than the boundary
4. Valid Input: Equal to the minimum boundary
5. Valid Input: Equal to the maximum boundary
(3) Test the test cases.
/*Good system should react positively for valid inputs & should react
negatively for invalid inputs */
(4) Report the results.
Real Time Example:
Consider the Student Database Management System. Let we take a simple module that
allows the end-users to view to the academic details of the student.
The module ‘Academic Details View’ takes the roll number of the candidate as the
input.
The roll number is framed with the following rules,
 (a) It should be a six digit number.
(b) No alphabets and special characters allowed.
(c) The number starts from 601234 and ends with 700000.
Let we perform the boundary value analysis testing with the system. The front
end design for the system is shown below (next page).

Fig: Front End Design for Academic

Details View Module
Performing the BVA:
Step 1: Identification of the input field
Here the input field is Roll Number. The input roll number (6-digit number) is to be
passed as the input for the system.
Step 2: Generation of the test cases
(1) Valid Input: Between the boundary [601234-700000]
Example Input: 601543
(2) Invalid Input: Less than the boundary
Example Input: 601233
(3) Invalid Input: Greater than the boundary b.
Example Input: 700001
(4) Valid Input: Equal to the minimum boundary b.
Example Input: 601234
(5) Valid Input: Equal to the maximum boundary b.
Example Input: 700000
Step 3: Testing the test cases:
Test Case 1:
Valid Input: Between the boundary [601234-700000]
Example Input: 601543
 Fig: System reacts positively
Test Case 2:
Invalid Input: Less than the boundary
Example Input: 601233

Fig: System reacts negatively.

Similarly the other test cases are also checked to ensure the consistency of the system.
Merits:
Less test cases
Faster and takes less time.
Writing reports are easy when compare to all pairs testing.
Boundaries are effectively tested.
Demerits:
Based on the assumption that error occurs only on the boundaries.
No internal logic checking (only black box approach)
Test by yourself
1. Apply the boundary value analysis for Staff details management system with
the module Staff ID update as shown in the figure:
 2. Give short notes on the followings:
1. Advantages of BVA.
2. Disadvantages of BVA.
3. How test cases are generated in BVA? Explain.
4. Compare and contrast the differences between boundary value analysis and all
pairs testing.
5. Derive the testing algorithm for all pairs testing.
6. Explain big bang testing with real time scenario.
Binary Portability Testing:
Binary portability testing is the testing approach in which portability of the software
over various environments will be ensured.
Software that is to be developed should be flexible with all environment and platforms.
If it is not working in some platforms then the degree of users will be reduced. Hence it is
very essential to ensure whether the application or software that is to be developed is
flexible among various platforms.
Test conductance period:
After full development of the system, the system is allowed to execute on different
platform and environments.
Testing Procedure:
(1) Develop the application
(2) Allow to run it on various platforms
(3) Note down the platform support.
(4) If some platforms not supported:
1. Goto update;
(5) Else
1. Perform further testing if needed;
2. Deliver the system after all testing;
(6) End the testing process
Methods of Binary Portability Testing:
Generally we can classify the system into 2 categories. One is graphical system and
another one is web systems.
The graphical system needs installation operations. This system should be installed
using setup files. The web system doesn’t need any typical installations since it depends
on browsers. Based on the system, the binary portability testing is classified into two
categories.
(1) Binary Portability testing for Graphical system.
(2) Binary Portability testing for web system.
Binary portability testing for graphical system:
For the graphical system, the binary portability testing is conducted with the help of
following steps:
(1) Install the graphical system on various platforms
(2) Check any installation problem occurs:
(3) If(Occurs)
1. Goto Failure
(4) Else
1. Goto Success
(5) Open the installed system on various platform
(6) Check any inconsistency occurs while working:
(7) If(Occurs)
1. Goto Failure
(8) Else
1. Goto Success
(9) Failure:
1. Redesign the system
(10) Success:
1. Perform further testing if needed;
Binary Portability testing for web system:
For the web based system, the installation operations are not needed. They fully depend
on browsers. Hence, the binary portability testing involves running the system on various
different browsers like Firefox, Google Chrome, Internet Explorer, UC Browser and so on.
The steps illustrates BPT for web system is given below (next page)
(1) Open the web system on various platforms
(2) Check any problem occurs while opening:
(3) If(Occurs)
1. Goto Failure
(4) Else
1. Goto Success
 (5) Perform operations with system on various browsers
(6) Check any inconsistency occurs while working:
(7) If(Occurs)
1. Goto Failure
(8) Else
1. Goto Success
(9) Failure:
1. Redesign the system
(10) Success:
1. Perform further testing if needed;
Merits:
Portability is very crucial thing. It is ensured by this testing.
Customer may change his/her environment (say OS) frequently. Hence it is
essential to ensure how the system performance on various environment. It is
carried out by this testing.

Test by yourself
1. How binary portability testing is conducted on web systems? Explain with an
example.
2. Write the importance of binary portability testing.
3. Illustrate BP Testing for PDF viewer on various Operating Systems (Windows
and Android OS).
Bottom Up Testing:
Bottom up testing is a sub category of Integration testing (Refer the section Integration
Testing).
In the bottom up testing process, the testing is conducted from lower level modules to
higher level modules.
If any higher level modules are not yet designed, then in such cases drivers are used.
Drivers
If any higher level modules are not yet designed, in such cases drivers are used as a
calling module. The driver module behaves similar to the original module that is not yet
developed. Driver is again software that acts as a prototype for undeveloped module.
They are fake modules that perform similar function as higher level modules.
The following figure illustrates the modular representation and how the modules are
interconnected to form the system.
 Assume that the module I is not yet designed. For performing bottom up testing, it is
essential to produce the module ‘I’. It has to pass the value (has to call) the module K or L
or M. But unfortunately the module I (calling module) is not yet developed by the
developers.
If we wait until the module is developed, it leads to the backlogging problem and time
complexity may arise. Hence we can use the software called driver (which perform similar
function as module ‘I’) in order to perform the bottom up testing operation.
The following figure illustrates how the bottom up testing operation is conducted using
the driver.

In the above figure, instead of module ‘I’ (which is not yet developed), the testers uses
the driver in order to test the efficiency of the system.
It is not essential to use the driver if all modules are already designed and ready for
testing operation.
Bottom Up Testing Procedure:
(1) Identify the bottom level (lower level modules)
(2) Test the lower level modules individually
(3) Identify higher level module and their interconnects
(4) If any higher level modules are not yet designed:
1. Goto Driver
(5) Else
1. Test the interaction between higher and lower level modules.
2. Goto Call
 (6) Call:
1. Make call from higher module to lower
2. IF(Error)
1. Identify the interface problem.
2. Goto Redesign
3. Else
1. Perform further testing if needed
(7) Driver:
1. Use dummy codes which calls lower level module.
2. Execute call operation using driver.
3. Goto Call.
Example:

Consider the above tree structure on which there are only three modules exists
namely S = (M1, M2, M3). Here M2 and M3 are said to be lower level modules whereas
M1 is the higher level module.
To perform the bottom up integration testing, the lower modules should be unit tested
initially.
If needed, we can use the drivers in the activity of unit testing the modules individually.
After the operation of unit test, integrate M1 and M2 (M1 calls M2) and execute the
integration testing. Finally integrate M1 with M3 and perform the integration testing.
The following steps illustrates how the bottom up integration is conducted
(1) Test M2 and M3 separately
(2) Allow M1 to call M2:
1. Test interface between M1 and M2;
2. If Interface inconsistency occurs:
1. Goto Redesign
3. Else
1. Perform further integration testing
(3) Allow M1 to call M3:
1. Test interface between M1 and M3;
2. If interface inconsistency occurs:
1. Goto Redesign
3. Else
1. Perform further testing
(4) Redesign:
1. Reconstruct the module
 Simply we can represent the bottom-up testing on the modules M1, M2, M3 as
(1) Test M2
(2) Test M3
(3) T1=Connect (M1, M2)
(4) Test T1
(5) T2=Connect(M1,M3)
(6) Test T2
Test by yourself
1. Perform the bottom-up integration testing on the modular graph of the system S
given below:

2. Assume that module O is not yet designed. Perform the bottom up integration
testing.

3. What is driver? Explain the needs of driver in bottom up testing process.

4. Perform the bottom up testing with the tree given below.

5. Identify the merits and drawbacks of Bottom up testing process.

Branch Testing:
Branch testing is the testing methodology in which the decision making points of a
system are checked to note its efficiency.
A system module may consist of various several decision making points. It is very
essential to check the decision making points because of the following reasons:
(1) To ensure whether any code remains unreachable.
 (2) To ensure whether the system executes effectively for both Boolean cases.
(3) To ensure how system effectively handles the decision making process.
Branch testing allows the tester to identify the above quoted points. The ultimate
scope of branch testing is to predict how effectively the decision points are designed in the
system.
A branch may be a decision making statement (IF), looping statement or switch case
statement.

The above figure shows the decision point (DP) or we can say it as a branching point of
a simple IF Statement. It has two paths (True and False).
An effective system should execute both valid and invalid path in a meaningful
manner. The branch testing avoids unreachable code which doesn’t produce any harm to
the software but makes the system complex.
Testing Procedure:
(1) Identify the decision point of the module
(2) Generate the test cases to validate all possible paths of the branch.
(3) Apply the generated test case
(4) Identify any code remain unreachable.
(5) Predict whether the system execute all possible path in an efficient way or
not.
(6) Report the test summary.
Real Time Example:
The following module updates the RESULT field in the student database. The condition
is given by
IF(Student Mark is Greater than or equal to 50):
Set: Result = Pass
Else
Set: Result = Fail
The flowchart for this scenario is given by
Testing Process:
Step 1: Identify the decision point (DP) or Branch Point:
Here the decision point or branch point is checking whether the mark (M1) is greater
than or equal to 50 or not. There are only two possible Boolean operations exist
(1) M1 > = 50 IS TRUE
(2) M1 > = 50 IS FALSE
Step 2: Generation of the test cases
The test cases are generated based on number of possible branches. Here the possible
branches are 2. Hence two test cases are essential to evaluate the system.
(1) Test Case 1: (True Condition) 64
(2) Test Case 2: (False Condition) 17
Step 3: Applying the generated test cases
Test Case 1: (True Condition): Input: 64
Expected output: RESULT field set to PASS.
The execution path is

Test Case 2: (False Condition): Input: 17

Expected Output: RESULT field set to FAIL
The execution path is
Step 4: Identifying the efficiency of the system
IF(Arrived Output (AO) == Expected Output (EO))
System is efficient;
ELSE
Branching problem occurs;
Check and redo branching;
Step 5: Write the test output in the test summary
Test by yourself
1. Perform the branch testing on the following tree

Breadth Testing:
Breadth testing is the testing activity which evaluates the entire functionality of the
system. The main drawback in the breadth testing is that it doesn’t evaluate the salient
features of the software system.
Breadth testing is a sub category of Top down integration testing (Refer Top down
integration testing section).
In the modular software development approach, the software is divided into several
logical modules. Each module is developed individually and tested individually. After
testing them as individual module they are interconnected in a logical manner and testing
is again performed. The process of interconnecting them in a logical manner is said to be
integration in software testing.
Such integration process may perform in two ways. One is top down and another one is
bottom up integration. In the case of top down integration testing, the modules of higher
hierarchy (higher level modules are tested first), then the module interconnections with
lower level modules are tested.
 Breadth testing is a sub category of Top down integration testing process in which the
software modules which are in the same level are tested first rather than performing
testing in the depth first manner.
As similar to breadth first search algorithm, the breadth testing is executed. In this
testing process, the modules of same level are tested first, and then the priority is given to
the lower level modules.
Here, the test suite concentrates on functionality.
Testing Procedure:
(1) Interconnect the developed modules of the system in a logical manner.
(2) Identify the higher and lower level modules.
(3) Start with the higher level module.
(4) Start : Identify the same level module.
(5) Perform testing on same level module:
(6) IF(All Same level modules are not yet tested)
1. Identify module that has to be tested.
2. Goto Start;
(7) ELSE
1. Identify the successive lower level module.
2. Goto Start;
Example:
In the following graph, each node represents the different modules of the software; the
interconnections refer to how they are logically connected.

Generally, the software testing process in top down testing approach starts with the
higher level module. Here the higher level module is A.
Hence the process is to be started with the module A. The breadth testing suggests that
the modules with same hierarchy level should be tested.
Steps:
(1) Test A.
(2) Test B and C individually.
(3) Interconnect A-B, A-C and test them.
 (4) Test D,E and F individually
(5) Interconnect A-B-D, A-C-E A-C-F and test them
(6) Test G,H and I individually
(7) Interconnect A-C-E-G, A-C-F-H, A-C-F-I and test them
Thus execution of testing takes place from the main module to the lower module in a
breadth first manner.
Merits:
Identifies how the software satisfies its functional quality standard.
All interface connectivity will be checked.
Demerits:
Time complexity in testing.
Features of the product cannot be evaluated.

Test by yourself
1. Apply the principles of breadth testing and test the following module-graph of
software.

2. Write the testing procedure of breadth testing.

3. Comment on efficiency of breadth testing.
Bench mark testing:
Bench mark testing is the testing activity in which the efficiency of the system under
various circumstances is measured. The word ‘benchmark’ refers to evaluating the
efficiency by comparison. The benchmark testing will be executed again and again so that
the performances of the system on various aspects are measured. Bench mark
testing mainly deals with the performance of the system under the environment.
Key points:
Testing the product again and again on the same environment with the
intend of measuring performance.
Repeated testing operation which measures quality standard of the software
Testing Procedure:
(1) Test the product under same environment for several times.
(2) Note down the outcome of testing process every time.
 (3) Derive the performance measure of the product from the test summary
report.
Benchmark techniques:
(1) Benchmark of Databases
(2) Benchmark of networking systems.
(3) Benchmark of firewalls.
Who involve in bench mark activities?
For DB benchmarking, DBA’s will involve, for network benchmark and firewall
benchmark security and network engineers and testers will involve.
Benchmarking report:
The benchmark operation mainly concentrates on evaluating the quality of the system.
Various performance measures are noticed by repeated testing process and they are noted
in the test summary report.
Generally, at the end of any testing process the testers will write a test summary report
which helps the developer about the bug information and redo’s of the software or module.
In the case of benchmark testing, the results are represented in terms of graphs instead
of summary report texts. It is because the number of execution times of testing is
relatively high.
Representing them as text is very tedious to do and also to understand them. Hence,
here the results are recorded and displayed in terms of graphical representation such as bar
graphs, bar charts, pie charts etc.
The following figure illustrates how the reports are represented after the benchmark
testing activity.

Bench mark testing is also conducted by automated tools which are said to be
automated-benchmark testing.
Merits:
Concentrates more on performance of the system.
Load and stress can be evaluated.
Domain specific methods of testing.
Very effective.
 Faster with efficient automatic tools.
Demerits:
In-effective for some simple applications

Test by yourself
1. What is the main goal of benchmark testing? Explain.
2. Conduct the benchmark testing for any security based real time application
with your own assumptions. Produce the test summary report as a statistical-
graphical data.
Task:
a) Match the followings:
1. Performance evaluation - Beta Version
2. Same level testing - Binary Portability
3. Decision based - Breadth testing
4. Platform testing - Benchmark
5. Test release - Branch testing
b) Compare the similarities between the following:
1. Alpha and Beta Testing
2. Top down and bottom up testing
3. Top down and breadth testing
4. Verification and Validation
5. Big bang and Integration testing
Basic Path testing:
Basic Path testing is an internal logic testing approach. In this approach, testing doesn’t
deal with input handling capacity of the system. It is a white box testing approaches (Refer
White Box Testing) in which the internal logic of the program will be tested.
The entire code is converted into flow graph. The flow graph is the graphical
representation of the logical flow for any program. It is very similar to flow chart.
The basic path testing evaluates all possible paths that the program can take in order to
reach the end state or termination state.
For an efficient program, it should start with the root node of the flow graph and it
should end with the termination phase of the flow graph. If any internal termination
encounters, it represents that the system can stop abruptly for some situation.
The main theme of basic path testing is find out the various all possible execution paths
of the program and to measure the efficiency and cyclomatic complexity.
Cyclomatic complexity deals with how complex the program or source code is. Code
coverage criteria are also evaluated in the basic path testing process.
Features of Basic Path testing:
Every possible path is examined.
Code coverage is examined.
Complexity of code is examined.
Efficiency of the system is also examined.
Deals with internal logic.
Need experts to perform the testing operation,
Path examination:
The various paths of the program can be examined by converting the code into relevant
flow – graph.
In flow-graph, Circle represent Nodes, Arrows represents edges, predicate node (P) is
said to be decision making node, bounded locations are said to be regions(R).
Types of Flow graphs:
Flow graphs are classified as sequential, decision making and looping flow graphs.
The sequential flow graph doesn’t involve in decision making or repetitive operations.
They are also called as compulsory paths. Every execution should go via this path without
fail.

The above figure illustrates the sequential flow-graph in which no decision parameters
are represented.
They are compulsory paths for any inputs.
Decision making flow graphs:

The above figure illustrates how the decision making flow graphs are drawn. Here P
refers to predicate node or decision making node.
IF(P == TRUE):
Left side node gets executed;
Else:
Right side node gets executed;
Looping flow graphs:

(a) While Loop (b) For-loop

The above two diagrams illustrates how for loop and while loops are represented in the
flow graph. The node P is called as predicate node.
Using the flow-graph one can compute the number of possible path that a program can
take and also the complexity of the program.
Conversion of Code to flow graph:
Consider the following pseudo-code and the flow-graph below the pseudo-code
represents how it is converted to flow graph
Pseudo code:
(1) Start
(2) Read Input ‘X’
(3) Read Input ‘Y’
(4) IF (X<Y)
1. Print Y is greater
(5) ELSE IF(X>Y)
2. Print X is greater
(6) ELSE
3. Print X and Y are equal
(7) Terminate
Cyclomatic Complexity:
Cyclomatic complexity deals with how complex the program is. It is calculated by
using the flow-graph. There are three ways for calculating the cyclomatic complexity.
Mc Cabe’s Cyclomatic Complexity:
Mc Cabe’s method of cyclomatic complexity suggests a simple way to find the
complexity of the code. Using the flow graph it is calculated with the help of the formula
given by
Cyclomatic Complexity(C.C)= E – N + 2
Where
E - Number of Edges of flow graph
N - Number of Nodes of flow graph
2 - Number of Terminal Vertices (usually 2)
Cyclomatic Complexity using predicate nodes:
For calculation of cyclomatic complexity using predicate nodes we can make use of the
simple formula given by
Cyclomatic Complexity (C.C) = P + 1
Where
P - Number of Predicate Nodes
Cyclomatic Complexity based on regions:
For calculation of cyclomatic complexity using regions we can make use of the
simple formula given by
(C.C) = Number of Outer Region + Inner Region
Where
C.C = Cyclomatic Complexity
 All the above quoted method will yield the same value for the cyclomatic complexity
of the code.

Example 1:
Calculate the cyclomatic complexity of the code given below.
(1) Start
(2) Read Input ‘X’
(3) Read Input ‘Y’
(4) IF (X<Y)
1. Print Y is greater
(5) ELSE IF(X>Y)
4. Print X is greater
(6) ELSE
5. Print X and Y are equal
(7) Terminate
Solution:
Step 1: Construction of the flow graph:

Step 2: Calculating Cyclomatic Complexity

Method 1: Mc Cabe’s Cyclomatic Complexity:
C.C = E – N + P
In our example, E = 8, N = 7, P=1
C.C = 8 – 7 + 1 = 2
Method 2: Cyclomatic Complexity by Predicate Nodes:
C.C = P + 1
Here, only one predicate node exist
P = 1, Hence C.C = 1+1 = 2
Method 3: Cyclomatic Complexity by region:
In example, outer region = 1 (always 1), inner region = 1. Hence
C.C = 1 + 1 = 2
All the above quoted method yields the same cyclomatic complexity (i.e, 2).

Basic Path Identification:

As we discussed, basic path represents what are all the various combination of path that
the program can take while execute. Consider our example flow-graph; it can take the
following basic paths
(1) 1 – 2 – 3 – 4 – a – 7
(2) 1 – 2- 3 – 4 – b – 7
(3) 1 – 2 -3 – 4 – c – 7
Test by yourself
1. Design the flow graph and evaluate the cyclomatic complexity by using Mc
Cabe’s method for the following pseudo code:
(1) Read Input A and B
(2) Add A and B
(3) Store it to C
(4) IF C is positive
1. Display Positive
(5) ELSE IF C is negative
1. Display Negative
(6) ELSE
1. Display C = 0
(7) Terminate the code
2. Derive the basic path for the following flow graph and also derive the
cyclomatic complexity using Mc Cabe’s Method:

3. Given that there are ten edges and seven nodes in a flow graph with two inner
loops. Calculate the cyclomatic complexity by using various methods.
 4. Perform the basic path testing and deduce the cyclomatic complexity for the
following:
1. Fibonacci Series Generation
2. Prime Number for a given range
3. Sum of N numbers
4. Factorial of a number
5. Square of a give number
6. Reverse of a number
5. Explain the testing procedure and importance of Basic Path testing.
6. Write the algorithm for greatest of three numbers. Identify the cyclomatic
complexity also.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘B’)

Testing Name Summary

Beta testing Testing at the customer site

with the beta version of the
product.

Black box testing Testing without checking

the internal logic or code of
the software.

Backward Checks whether the newly

Compatibility developed version is
compatible with older
version or not.

Big Bang testing Testing system as a whole.

BVA Testing Testing for boundary input

values.

Binary Portability Testing the compatibility of

testing system.

Bottom Up testing Type of Integration testing

 Branch testing Testing the decision paths

Breadth testing Testing which uses the

breadth first approach.

Bench mark testing Evaluates the performance

of the system by repetitive
testing.

Basic Path testing White box testing in which

various path of execution is
traced.

****

4
Testing Methods
[C]

Introduction:
Under the alphabetical letter ‘C’, there are 10 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Code Driven Testing
2. Compatibility Testing
3. Comparison Testing
4. Component Testing
5. Configuration Testing
6. Condition Coverage Testing
7. Compliance Testing
8. Concurrency Testing
9. Conformance Testing
10. Context Driven Testing
11. Certification Testing
Code Driven Testing:
Definition:
Code driven testing is the testing activity in which initially the test cases are developed
before code which will fail to execute since the code remains unwritten.
After that process, we have to perform the normal testing operation to measure the
efficiency of the system after writing the code. Refactoring will be done to iteratively
develop the code.
After that process finally, again testing will be made in order to measure its efficiency.
If the system seems to work well, then the system is said to be efficient.
Testing Procedure:
(1) Start:
Create test cases before code;
(2) Execute the system with test cases
(3) IF (System fails)
1. Goto Update
(4) ELSE
1. Goto Start
(5) Update:
1. Update the code in meaningful way.
2. Goto Execute;
(6) Execute:
1. Perform execution on the code;
2. IF(System executes effectively):
1. Perform further testing;
3. Else:
1. Goto Update;
Merits:
1. Iterative Development Approach
2. Flexible one
3. Refactoring concerns
4. Good for larger systems
5. Easy to add new features with the system
Compatibility Testing:
Compatibility Testing – by the word itself we can understand that it is testing approach
which measures whether the developed software can able to work in all environments
without any conflicts.
Compatibility of software doesn’t deals only with the environment but also deals with
the compatibility of various things like hardware, versions and so on.
Based on the various factors, compatibility testing is classified into different categories.
They are
(1) Platform Compatibility
(2) Device Compatibility
(3) DB Compatibility
(4) Browser Compatibility
(5) Version Compatibility
Platform Compatibility:
Platform compatibility is the measure of how the developed application is compatible
with various platforms.
Platform generally refers to the operating system.
Assume that software is developed for managing the accounting information for a super
market. The developers system holds the Windows XP as the operating system.
After development, if the testing is made only with Windows XP OS , if Platform
compatibility is not checked to ensure whether it is working on various platforms or not.
In such case, if the customer (Super market) uses the any other operating system (say
BOSS OS). In such case, the system may not work properly.
It will come to known only during beta testing (which is a final testing activity). Hence
this situation makes the software system to redesign.
To avoid such drawbacks, platform compatibility testing should be executed.
Testing Procedure:
(1) Develop the software.
(2) Generate test cases.
(3) Execute the software with different platforms using same test cases.
(4) IF(All test cases shows positive result)
1. System passed the Platform compatibility
(5) ELSE
1. Reconstruct the system
2. Identify the compatibility problem
The procedure of checking the platform compatibility efficiency is generally
termed as platform compatibility check.
Real Time Example:
Let we perform the platform compatibility check with the Ms – Office. Here we will
assume two operating systems. One is Windows 7 and another one is ubuntu. By installing
and opening the system interface we can identify whether it is platform compatible or not.
 Fig: Winword Opened in Ubuntu OS

Fig: Winword Opened in Windows 7 OS

Merits of Platform Compatibility Testing:

Checks whether the system works on effectively over different platform.
Device Compatibility testing:
Device compatibility testing will ensure whether the developed software is compatible
with various different devices / not.
Software that is developed should be compatible with the different devices. If the
system is device compatible, then only the system is said to be having greater degree of
portability.
A software designed for PC should also be compatible with the mobile phones, tablets
etc.
If degree of device compatibility is less, then it leads to inefficiency and user
popularity of such system will be poor in nature.
Testing Procedure:
(1) Develop software and test cases.
(2) Run the system various devices.
(3) Check for compatibility
Hints:
(1) While ensuring the device compatibility, ensure whether the developed
software has UI Consistency over various devices.
(2) Check the security concerns.
(3) Ensure whether the system operations are perfectly executed on every
compatible device in effective manner.
Merits:
Comforting property of the system can be identified.
Increases the rate of users if the system is more compatible with many
devices.
Database Compatibility:
This sort of compatibility checking ensures the compatibility of internal logics. Usage
of various kinds of databases at developer and client side may leads to inconsistency. Such
consistencies and comfortless should be evaluated.
Testing Procedure:
(1) Create test cases that mainly deal with the database queries.
(2) Execute the queries using front-end with various DB support.
(3) Identify the efficiency of the result.
(4) IF (Result is efficient)
1. Perform further testing operation
(5) ELSE
1. Reconstruct and the system/module to ensure the degree of
consistency of the system.
Merits:
Enhances the data maintenance quality.
Data duplication, deletion, querying defects can be identified.
Importance:
The main thing that any system can deal with is nothing but data. Without input device,
computer doesn’t work and its goal is to produce the output data in an effective and
meaningful manner.
Database provides a platform to store the data. In order to ensure the quality of the data
that is to be stored in the system, it is essential to measure the database compatibility.
Browser Compatibility:
The browser compatibility mainly deals with the web related applications. Web
applications that is developed should be tested over various browsers like Mozilla Firefox,
Google chrome, IE, UC browser etc to check the consistency.
Some browsers have built in options but some browsers don’t have such built in
support. As a tester and developer, we didn’t know about the user side browser.
A good web application should be compatible with all sort of browser. To ensure such
consistency standards, the browser compatibility testing is used.
Testing Procedure:
(1) Create test cases for web applications.
(2) Open the web app in various browsers.
(3) Deploy the test cases (Perform testing)
1. Identify UI Consistency.
2. Identify internal logic problems.
3. Identify built in support.
4. Ensure the execution time.
5. Ensure the speed of application.
(4) IF(Result is efficient)
1. Perform further testing operation
(5) ELSE
1. Redo the system
Real time example:
Consider a web application (Online voting system) which is developed with intend of
online voting process.
The end-users of online voting system will be from various part of country. Each user
probably has their own views and interests on using the browsers. Some people don’t have
much knowledge about efficient browsers and there may be a chance of using IE too.
In such case, the system design should support in consistent way for all users (ie, users
of various browsers).
It should be compatible with UI Consistency, design consistency, speed etc. For the
above quoted scenario, the browser compatibility testing is very essential.
 Fig: Front end of the voting system - Google Chrome

Fig: Front end of the online voting system - Mozilla Firefox

By contrasting the figures, we can observe that the font has been changed while
changing the browser. Change of fonts doesn’t produce greater degree of impact. But the
change of logic, UI consistency will produce greater degree of impact.
Merits:
Suites well for web applications.
Evaluates various technical concepts like UI, execution time etc.
Essential for web-applications and applications that are partly using the
browsers.
Properties of browsers can be studied.
Version Compatibility:
Software is not evolved as a single version. Due to the requirement changes, additions,
updations, increase in user expectation it goes towards the various versions.
The SCM (Software configuration management) team is responsible for monitoring
such versions. They have a board called version control board.
For any updations or changes, the developers have to get the acceptance letter for
updations from the team members of version control board.
We already discussed about (Backward compatibility testing) – the system that is
developed should possess degree of consistency with previous versions.
For more information, refer the backward compatibility testing concept (Testing under
‘B’)
From the above different types of compatibility testing we can enhance the degree of
compatibility of the system developed.
Test by yourself
1. Explain various types of compatibility testing with suitable example.
2. What type of compatibility testing is suitable for web applications? Discuss.
3. Give the importance of compatibility testing.
Comparison Testing:
Generally, the activity of any software testing approach is giving input and examining
the execution consistency, identifying the efficiency degree of the output just by
comparing with expected output.
The number of test cases, checking methodology, accuracy plays vital role and such
keys leads to various testing approach. But, whatever the testing process may be the
general schema or blue print is nothing but, revealing defects by examining the output.
The comparison testing is also termed as a basic testing process. We classify this
comparison testing into two categories for better understanding. They are
(1) Version based comparison testing
(2) Output based comparison testing
Version based comparison testing:
As we discussed, due to several factors the software will take various version. The
comparisons among the different version should be done in order to measure whether the
new version have improvised performance than the older.
The version performance graph should be increased in an exponential way for good
software. The newer version should have greater point of efficiency.
Such comparison among the versions of the software system that has developed is said
to be version based comparison testing.
For a good system, version comparison graph should be exponential along newer
versions as shown below.

The above graph illustrates three regions, lower performance region is one in which the
system performance is poor. It is plotted against version V1 and V2. For the version V3
the degree of performance is average (50% to 60%). The final version of the software
system reaches the greater performance of 80% which proves the exponential growth of
performance among various versions of the system.
For any system, the degree of performance never is 100% even though many testing
approaches encountered before release.
Degradation of performance over version leads the users to switch over the older
version instead of newer.
In such situations, the release of newer version doesn’t produce any meaning among the
market. The following graph shows the poor system version comparison graph.

From the graph, we can understand that V1 (initial version gives average performance
where as further releases V2 and V3 doesn’t provide any satisfactory level of
performances. This case makes the user to feel uncomfortable on using newer versions.
To identify whether the newer version solved the problems that was arose in the
previous version(s) the process of version comparison testing should be done and the
results should be plotted graphically for better understanding purpose.
Signs of effective newer release:
Newer release should be consistent with the older.
Newer release should have both features of older version as well as added
features.
Degree of performance should be more for newer when compared with the
older.
Newer version should produce exponential growth on performance.
Testing Procedure:
(1) Develop the newer version (say X 1.1).
(2) Identify the older versions of X 1.1 (say X 1.0)
(3) Compare and contrast between X1.0 and X1.1
(Use graphs for better comparison)
(4) If (X 1.0 is effective than X 1.1)
1. Newer version seems to be worthless
(5) Else
 1. Newer version satisfies the signs of effective newer release.
2. Proceed with further testing if essential
Output based comparison testing:
The basic idea behind the testing can be defined by the algorithm given below
(1) Generate Test Cases
(2) Apply test cases to developed system
(3) IF(Expected output == Arrived output):
1. System passed
(4) ELSE
1. System failed
2. Redo the system
The output based comparison also performs the same operation. It checks whether
the expected output is equivalent to that of arrived output due to the applied input. If so,
system is effective else it is in effective, reconstruction should be done.
Real Time Example:
Consider the online result displaying system. The input field is User ID using that
primary key the results will be fetched from the database and shown to the end-user using
the front end design.
The front end of the system is shown below for better understanding the scenario.

For the above quoted scenario, initially we have to develop test cases before performing
output comparison testing.
By the proposition of software analysis, we have to develop both valid and invalid test
cases. For simplicity, let we consider one valid and one invalid test case.
TC No Test Case V/IV Expected Arrived P/F
1 204 V PASS PASS P
2 503 IV Error Error P
From the table shown above, we can have clear understanding about output
comparison.
The test case for our scenario is the User ID. V/IV bits refer to whether it is a valid or
invalid test case. The system Expected output is equivalent to arrived output; hence the
system passed the comparison testing.
If not, the comparison testing yields negative result.
Merits (Comparison Testing)
Comparatively measures the efficiency of the system.
Allows checking whether the basic responsibility of the system is satisfied
or not.
Takes very less time.
Statistical analysis encountered.
Demerits:
No concept on security advanced testing concerns.
Very basic approach of testing processing.

Test by yourself
1. A software system has four versions as listed in the table. Derive the version
comparison graph so as to prove that the system is effective over various
versions.

Version Performance (%) Release Date

1 50% Jun-05,2015.
2 70% Aug-06,2015.
3 75% May-07,2016.
4 80% Oct-07,2016.
2. Fill the PASS/FAIL Criteria column of the following table.
TC No Test Case V/IV Exp Arrived P/F
1 101 V PASS PASS
2 102 IV Error Error
3 105 V PASS PASS

Component Testing:
Software systems consist of several different components. We can refer the components
as modules. For building a house, we need several different items like bricks, cement etc.
The main role is played by bricks and cement materials. Similarly, software has various
components or modules (bricks) and they are interconnected using the interfaces (cement)
to form original system (house).
Testing the individual components of the system is said to be component testing. We
already discussed about the concepts of big bang testing. It states the testing of system as a
whole. Here, the component testing allows the tester to test the individual components
rather than testing the system as the whole.

The above figure illustrates how the system is formed. It shows that the system is an
interconnection of N modules in a logical and meaningful manner. Each and every module
has its own tasks and responsibilities.
Testing the individual components allows the testers to ensure the following:
(1) Role of individual components.
(2) Efficiency of the individual components.
(3) How they are interfaced with others?
(4) Whether the individual component has any bugs?
It is very important task to ensure the component efficiency because it is the basic part
of the system. If there is any problem with the basement then the overall system will be
collapsed. Hence ensuring the component testing is very important, essential and
compulsory one.
Testing Procedure:
(1) Start the process.
(2) Identify the individual components of the system (Say C1, C2, C3 …)
(3) Generate test cases to test the system.
(4) Use(Stubs, Drivers) if needed.
(5) Test C1, C2, C3…
(6) Measure the efficiency of each component.
(7) IF(Ineffective)
1. Perform updations.
(8) ELSE
1. Go for integration testing to ensure the degree of interface
consistency.
(9) End the testing process.
 Some module doesn’t work without the help of some other module. It may need an
input from one module or else it may send the output to some other module. In such case,
a pre-defined stubs and drivers are used to pass and get inputs in component testing
activity.
Real Time Example:
Consider the menu bar of online examination system. It has different links to various
pages.

Each links will direct the end user to the particular page. For web oriented systems,
each page is a component and collection of pages will form web site (system). Hence, in
the case of component testing, we have to test the individual pages (components) of the
web system.
The testing procedure follows the steps given below.
(1) Identification of individual module
1. Online Test (A)
2. Register (B)
3. Result (C)
4. Admin Login (D)
(2) Test A, B, C and D individually.
(3) Note down the efficiency degree of A, B, C, D.
(4) IF (Any one of the component is inconsistent while testing):
1. Redesign the system component.
(5) ELSE
1. Test the system after interfacing.
The main idea behind the component testing is that, it will ensure basic parts of
system before forming the complex system. Hence, the problems are identified easily and
effectively with less time complexity.
If the component testing is neglected by the tester, it leads to lot of difficulties to
test the system.
Merits:
Ensures performance of basic level components.
Acts as basic testing criteria.
Pre-detection of errors can be possible.
De-Merits:
Interfacing problems cannot be identified.
 Usage of stubs, drivers needed.

Test by yourself
1. How will you perform the component level testing to the Ms-Office Word
Package? Explain.
2. Why it is important to measure the efficiency of components? Discuss.
3. A software system consists of various components as shown in the figure given
below. Derive component testing algorithm for the system

Home User Login Contact Queries

4. For the scientific calculator software system how will you perform the
component testing? Explain the role of it.
5. Compare the differences between stubs and drivers. Explain the role of it in
component testing.
6. Consider a Java package named system with three java files inside it. How will
you perform the component testing in such case?
7. Write down the merits and demerits of component testing.

Configuration Testing:
Configuration testing is used for checking configuration status of the software
developed. The software that is developed probably will not be configurable with all
environments, platforms etc. Hence the configuration testing is essential to identify the
configuration status of the system.
Especially for gaming systems, when we buy the system / download the system we can
able to find the configuration attachment document/notice with it.
The configuration attachment document holds the configuration item names that
includes hardware, software etc that is essential for running the system.
If the client or end-user system meets the configuration then only the system can
efficiently work on the client platform. If the client doesn’t have such configuration with
him, then he has to purchase them.
For higher graphical games, the main configuration and basic configuration is Graphic
cards. Computers can work well without graphic cards. But when the client or user wants
to install higher level games with more graphics, then before installing, he has to embed
graphic card with the system so that the game will work or else it won’t be working.
Hence, configuration document is very important and allows end-user to know whether
the system works perfectly with his/her machine. For the identifying the essential
configuration needed for running the system, the configuration testing is very important
and it plays a vital role in the software testing approach.
Types of Configuration Testing:
There are various different types of configuration testing available to ensure various
configuration aspects of the system developed. They are
(1) Hardware configuration testing
(2) Software configuration testing
(3) Operating system configuration testing
(4) Browser configuration testing
Hardware configuration testing:
The essential hardware that is needed for the working of the system is identified using
the hardware configuration testing.
After developing operation, the software is allowed to execute in various hardware
environments and the results are noted. Finally, the results are analysed in order to identify
the hardware requirements of the system.
Testing Procedure:
(1) Develop the system
(2) Allow them to run on various hardware platforms
(3) Note down the performance of the system over various platforms
(4) Using the result,
1. Summarize the hardware configurations of the system.
2. Perform further configuration testing.
Merits:
Very helpful in gathering hardware configuration status and also serve as the
important testing approach.
Software configuration testing:
The software configuration testing will ensure additional software that is essential to
execute the main system. Generally, some software requires additional software support.
Such supportive software information that is essential to execute the system in the client
machine will be identified with the help of the software configuration testing.
For example, in order to write the PHP programs we need notepad or any other editor
and XAMPP, for running the PHP programs we additionally need the browser. Hence, the
software configurations that are required for the execution of PHP program is
(1) Browser
(2) Local host server
(3) Editor
Similarly, to identify the software components that are needed for execution of
system in efficient way we have to perform the software configuration testing.
Operating system configuration testing:
The operating system acts as the interface between the software and the hardware. To
execute any application (or) system software, the essential thing needed as operating
system. It serves as a platform for the application software. Testing the platform ensure the
software quality.
Generally, some application run on particular operating system, some application can
run on operating system if and only if some additional components are installed. Such
information can come to be known if the operating system configuration testing is
performed.
Testing Procedure:
(1) Develop the application software.
(2) Allow them to run on various operating system
(3) Note down the performance of the system over various operating system
(4) Based on the result, identify the operating system requirements of the
particular application.
Browser configuration testing:
Browser configuration testing is especially designed for the web oriented systems.
Some applications will run in the particular browsers and some applications may run on
any browsers.
Such browser configuration status should be mentioned with the system. For identifying
the browser information, browser configuration testing should be implemented.

Fig: Configuration Information for a web system

The above figure illustrates the label that shows the configuration information of the
web system (online feedback system). From the specification, we can identify that Google
chrome is needed for the execution of the system and the software will work only on
Windows OS (7 and higher version only). Additional software that is needed is a PDF
reader.
Condition coverage testing:
Condition coverage testing method is considered as the white box testing approach.
Condition coverage ensures the efficiency of the internal logic. As a black box, the
illiterate people cannot involve in condition coverage testing. Technical knowledge is very
important for performing the condition coverage testing process.
Decision making points are evaluated in the condition coverage testing. From the
decision making point, the program is divided. Two Boolean operations play vital role in
the decision making point they are true and false.
Needs of Condition coverage testing:
(1) Ensures efficiency of the decision points.
(2) Identifies unreachable code.
(3) Finds whether any probability of occurring the infinite loops / abnormal
termination of the program.
The test cases are generated in such a way that it executes both true and false
condition so that unreachable code, infinite loops can be identified.
Hints for test case generation:
As proposed in the principles of testing, the test cases should be generated
for both valid and invalid conditions.
Test case generation should concentrate more on the boundaries.
More important should be given to decision making points like conditions,
loops etc.
Test case also is prepared for meeting else part.
Testing Procedure:
(1) Develop the test cases for the system as per the hints specified.
(2) Apply the test cases
(3) Observe the decision points
(4) Record the results
(5) Analyse the results to find
1. Uncovered paths
2. Unreachable paths
3. T/F condition executions
(6) IF(a || b satisfies)
1. Redesign the particular decision part
(7) ELSE
1. Perform the further testing process
(If needed)
(8) End
Real Time Example:
Assume the flow graph given below, the decision making part here is a simple IF
condition which is specified in the flow graph. It is for checking eligibility of voting.
Here the possible execution paths are
(1) 1 – 2 – 3 – 4A – 5 – 6 (OR)
(2) 1 – 2 – 3 – 4B – 5 – 6
The condition coverage testing suggests that the test cases should be generated to test
both paths of execution.
Test case generation:
Assume that, 4A will executes if input is greater than or equal to 18, else 4B will
be executed. For such assumption the test case generation process will be of

TC_No Test Case Path

Valid Test Cases
1 12 (1) – 4A
2 53 (2) – 4B
Invalid Test Cases [ELSE Part will work]
3 ABC (2) – 4B
4 ! (2) – 4B
Merits:
As discussed, it helps for finding the unreachable code, paths of execution.
More effective method.
100% condition coverage is examined.
Chance of reducing lines of code of the system.
Demerits:
White box testing – hence technical knowledge is very important.
Concentrates only on code bugs, no importance given to other issues like
security.
For bigger system, it will take very large time hence the time complexity is
probably very high.
Reporting result is also very difficult.
Compliance Testing:
Compliance testing is conducted for verifying the standards, quality, and rule
satisfaction of the software developed. Compliance testing is a non-functional testing
approach.
The non-functional requirements are one that is not stated by the customer. Whenever
the client approaches the developer for the need of system. The developer’s will conduct
the requirement collection meet in order to collect the requirements.
The requirements which are stated by the customer during requirement collection is
said to be functional requirements. The requirements that are not stated by the customer is
said to be non-functional requirements.
Compliance testing is non-functional requirement satisfaction testing because the client
does not state about any rule satisfactions of the company.
The company internally has some rules and regulations for every software developed.
Before delivery, it is very important to check such things.
Such non-functional requirements are satisfied or not can be understood by using the
compliance testing approach.
Generally, audit should be conducted in order to perform compliance testing. During
audit, the technical group will discuss about the non-functional features that are satisfied
by the system.
After the satisfaction of the audit, the further steps to deliver the software will be
undertaken. IT standards satisfaction checking is the main goal of compliance test.
Concurrency Testing:
Concurrent execution checking is very important aspect of any real time software.
Software that are especially designed to perform transaction operations should maintain
the concurrency.
A software that is designed to perform transaction should be efficient with the
following operations:
(1) Commit
(2) Rollback
(3) Save point
Concurrency maintenance is especially needed for banking systems. Problems in
the concurrency may lead to failure of entire operations.
System using the database should also maintain concurrency. N users may access
the database at the same time. An efficient system should provide the services to all end-
users in effective manner.
System should have a queue that holds user requests. It should process the user
request as by FIFO concept. Because of the importance of concurrency, it is very
important to estimate the concurrency efficiency of the software that has developed.
Testing Procedure:
(1) Develop the system.
(2) Execute the system operations with N users
(3) Note down drawbacks if encountered.
(4) IF(concurrency_problem):
1. Reconstruct
(5) ELSE:
1. Perform further testing if needed.
Concepts of Concurrency:
As discussed before, the concurrent system should support commit, rollback and save
point operations.
Commit:
Commit operation informs to the system that the changes can be made permanently. A
commit point conforms the saving process in permanent manner.
Rollback:
Rollback operation allows the users to rollback to certain point. If user made any illegal
operations with the system, if they want to rollback their operations in such case rollback
is used.
Save point:
A temporary point that the user can fix to return in case of any problem with operations
occur is said to be a save point.
The above quoted operations are helpful to perform temporary saving, permanent
saving, roll backing to particular point etc which are essential and important in the case of
concurrent operations.
Concurrent operation on transaction of money from one account to another:
Assume the scenario that an amount of $50 should be transferred from account A to
account B. An improper transaction is illustrated below.
Transaction – I Transaction – II
Open(A) Open(B)
Read(A) SET (B_bal=B_bal+50)
IF(Avail of $50)
SET (A_bal = A_bal - $50)
In the above scenario, if any problem occurs with the transaction, there may be a
chance of loss to either A or B. Two cases may occur.
(1) $50 may reduced from account A but not added to account B.
 (2) $50 may not be reduced from account A but added to account B.
Effective Transaction:
Transaction – I Transaction – II
Initial_A: Open(A)
Read(A)
IF(Avail of $50)
SET (A_bal = A_bal - $50)
IF(Updated)
Goto Initial_B
ELSE
Rollback Initial_A
Initial_B:
Open(B)
SET(B_Bal=B_bal+50)
IF(Updated)
Commit(B)
ELSE
Rollback Initial_B
Commit(A)
END
From the above example, we can clearly understand the importance of commit, rollback
and save point.
Concurrency testing concentrates more on such commit, rollback and save point
operations to ensure it.
Merits:
(1) Especially designed for transaction related applications.
(2) Concurrency problem will cause the whole system to be failed. Identifying
such concurrency problem can be examined by this testing.
(3) Simple method. No internal code checking needed if and only if essential.
Demerits:
(1) Number of people involve in testing operation is relatively high.
(2) Separating system hardware problem and concurrency problem is a
challenging task.
Test by yourself
1. A system is designed to perform chatting. Explain the importance of
concurrency testing in it.
2. Compare the differences between commit, rollback and save point.
3. What is concurrent execution? Explain.
4. Comment on database concurrency.
5. Describe the effectiveness of the following transaction

Transaction – A Transaction – B Time

Reduce(Rs.20) Add(Rs.20) T1
Commit Commit T2
END END T3

Conformance Testing:
As the name implies, the conformance testing ensures whether the system satisfies
(1) Functional specifications
(2) Non-functional specifications
(3) Standards and goals of institution
(4) Quality of service satisfaction
(5) Technical standard etc.
Conforming all aspects of the system before delivering it is encountered with the
help of conformance testing. Generally audit conducting will ensure it.
Needs:
Final verification that conforms the standards of the system developed.
Conformance testing not only concentrates on functional specification. It
covers entire conformance strategy of the system.
Real Time Example:
Assume that the conformance testing should be conducted for the scientific calculator
developed. The conformance testing will involve.
(1) Identifying functional and non-functional features of scientific calculator.
(2) Identifying whether the calculator designed as per standards and
regulations.
(3) Speed, processing time conformance.
 (4) Conforming whether manuals that allows end-users to learn how to operate
is readily available/not.
(5) Conforming whether the calculator is ready to deliver or not. (From the test
results)
Context Driven Testing:
Context driven testing method allows the tester to choose appropriate testing technique
for particular context. Performing all the testing is not possible at all because of the
following reason.
(1) Budget allocated for testing is very less comparatively for developing
system.
(2) Time allocated to test the system is also very trace.
(3) Some testing may not applicable for some systems.
Hence, it very important activity of a tester to identify the appropriate technique of
testing. Context driven testing allow the tester to find appropriate testing that is effective
for the software under test.
Context driven testing policy is an approach and not a method of testing. Hence there
is no specific testing procedure available for it.
It allows the testers to notify regarding the effective method of testing that is suitable
for the system.
Test by yourself
1. Perform the conformance testing for a web related application system.
2. What is context driven testing?
3. Prove that: Context driven testing is an approach not a method of testing.
4. Discuss the merits of context driven testing.
5. Why performing all testing for a system is not possible?
6. Differentiate between functional and non-functional requirements of a system.

Certification Testing:
Certification testing is a part of compatibility testing. The main goal of compatibility
testing is to identify whether the system is suitable for all environments or not.
In the certification testing, software vendors will run the system on various
environments and provide certification to the system to report whether the system failed or
passed to work on particular environment.
Hence, we can say that the certification testing is an extension of the compatibility
testing.
Pass/Fail Criterion:
If the system works good for given environment then the system is certified as passed,
else the system is certified as failed under the environment.
 Finally, based on the certification the compatibility document will be prepared which
states various categories of compatibility.
Real time example:
Assume that the system X is given for compatibility test. The vendors will test the
system under environments A, B, C. Assume that
X works good for A and C but not for B. Hence the result of certification testing should
be like
System Environment Certification
X A PASS
X B FAIL
X C PASS
From the above result, the compatibility document is prepared and it should state the
following quote.
“This system is compatible only with environment A and C”.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘C’)

Testing Name Summary

Code Driven Testing Test cases generated before

developing the system.

Compatibility Testing Testing to ensure the

environments that are
compatible for the system.

Comparison Testing Comparing performance of

system under various
circumstances.

Component Testing Modular testing approach.

Configuration Testing configuration

Testing status.

Condition Coverage Decision paths testing.

 Testing

Compliance Testing Quality, standards

verification of the system.

Concurrency Testing Testing concurrent

execution of the system
under testing.

Conformance Testing Testing that conforms all

aspects of the system under
testing.

Context Driven Allows tester to choose

Testing effective testing methods.

Certification Testing Extension of the

compatibility testing

****

5
Testing Methods
[D]

Introduction:
Under the alphabetical letter ‘D’, there are 5 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Decision Coverage Testing
2. Destructive Testing
 3. Dependency Testing
4. Dynamic Testing
5. Domain Testing
Decision Coverage Testing:
Decision coverage testing is nothing but branch coverage testing that we already
discussed.
Decision coverage testing is the testing methodology in which the decision making points
of a system are checked to note its efficiency.
A system module may consist of various several decision making points. It is very
essential to check the decision making points because of the following reasons:
(1) To ensure whether any code remains unreachable.
(2) To ensure whether the system executes effectively for both Boolean
cases.
(3) To ensure how system effectively handles the decision making
process.
Decision coverage testing allows the tester to identify the above quoted points. The
ultimate scope of decision coverage testing is to predict how effectively the decision
points are designed in the system.
A decision coverage may be a decision making statement (IF), looping statement or
switch case statement.

The above figure shows the decision point (DP) or we can say it as a decision cover
ageing point of a simple IF Statement. It has two paths (True and False).
An effective system should execute both valid and invalid path in a meaningful
manner. The decision coverage testing avoids unreachable code which doesn’t produce
any harm to the software but makes the system complex.
Testing Procedure:
(1) Identify the decision point of the module
(2) Generate the test cases to validate all possible paths of the decision
coverage.
(3) Apply the generated test case
(4) Identify any code remain unreachable.
 (5) Predict whether the system execute all possible path in an efficient way or
not.
(6) Report the test summary.
Real Time Example:
The following module updates the RESULT field in the student database. The condition
is given by
IF(Student Mark is Greater than or equal to 50):
Set: Result = Pass
Else
Set: Result = Fail
The flowchart for this scenario is given by

Testing Process:
Step 1: Identify the decision point (DP) or Decision coverage Point:
Here the decision point or decision coverage point is checking whether the mark (M1)
is greater than or equal to 50 or not. There are only two possible Boolean operations exist
(1) M1 > = 50 IS TRUE
(2) M1 > = 50 IS FALSE
Step 2: Generation of the test cases
The test cases are generated based on number of possible decision coverage’s. Here the
possible decision coverage’s are 2. Hence two test cases are essential to evaluate the
system.
(1) Test Case 1: (True Condition) 64
(2) Test Case 2: (False Condition) 17
Step 3: Applying the generated test cases
Test Case 1: (True Condition): Input: 64
Expected output: RESULT field set to PASS.
The execution path is
Test Case 2: (False Condition): Input: 17
Expected Output: RESULT field set to FAIL
The execution path is

Step 4: Identifying the efficiency of the system

IF(Arrived Output (AO) == Expected Output (EO))
System is efficient;
ELSE
Decision cover ageing problem occurs;
Check and redo decision cover ageing;
Step 5: Write the test output in the test summary
Test by yourself
1. Perform the decision coverage testing on the following tree

2. Write the pseudo code for palindrome checking and convert it to flowchart and flow
graph
Destructive Testing:
Destructing the system under test that is, making the system to fail by performing
illegal operations, giving stress, load to the system and then identifying the failure point to
rectify it is said to be destructive testing.
As the name implies, destruction is the process of demolition of the behaviour of the
system under test. After demolition, the point of failure is identified by testing the system.
Types:
(1) Stress Testing
(2) Load Testing
(3) Crash Testing
Importance:
Identifying the failure point (weaker points) of the system can be made with
the help of destructive testing.
Effective method to measure the stress holding capacity of the system under
testing.
The degree of capability of the system under testing can be measured easily.
Robustness is measured.
Testing procedure:
(1) Develop the system.
(2) Make the system to fail in uncontrolled manner.
(3) Identify FAILURE points.
(4) Reconstruct the system in such a way that the failure points are strong
enough to withstand stress.
(5) Perform further testing if essential.
(6) End
Real Time Example:
Let us assume an online exam results displaying system as an example for destructive
testing. The system has a result database R_DB which holds the candidate results from
Grade A to Grade C.
Destructive testing for the system is conducted by the following steps.
(1) Develop the online exam result displaying system.
(2) Here the PRIMARY key that fetches the content from the database R_DB
is ‘Roll No’.
1. Allow many testers to interact with the system to fetch results at a
 time.
(3) Identify FAILURE points.
1. Assume that the failure point is slow access because of storing all
categories of student results in a single database.
(4) Reconstruct the system in such a way that the failure points are strong
enough to withstand stress.
1. Use three different tables
1. R_DB_GRADE_A
2. R_DB_GRADE_B
3. R_DB_GRADE_C
(5) Perform further testing if essential.
(6) End
Merits:
Point of failure identification is easy.
No dedicated test case generation is essential.
Demerits:
After destruction, reconstructing the system is not an easy task at all.
Dependency Testing:
Dependency testing allows the testers to identify the dependent relations. Generally,
modular design approach is followed by the developers to develop the system.
A module may depend on any other modules. The dependency relation is either of the
following.
(1) Module may need input from any other module.
(2) Module may pass the input to any other module.
On the both situations, the module is said to be dependent another module. The
dependency testing will ensure such dependent relations among the various modules.
It also concentrates on database dependency, normalizations to enhance the efficiency
of database managing.
Merits:
By performing the dependency testing, the tester can identify dependent and
independent modules so that usage of threading concepts can be implemented.
Allows the testers to know about the need of stubs and drivers
Demerits:
This testing method doesn’t reveal any defects.
It just provides the structural study of the system under test.
 Bug identification is not possible with the help of dependency testing
activity.
Optional one.
Example:

Assume that there are five modules (A,B,C,D,E) forms the entire system. From the
above diagram, we can identify the dependency relation among the modules as follows,
Module Name Dependent with
A B and C
B A and D
C A and E
D B only
E C only
By performing the dependency testing, it is only possible to predict dependent relations.
Problem:
For the given specification, construct the flow graph that shows modular relationship.
Module Name Dependent with
X Y and Z
Y K and Z
Z X and Z
K Y and N
N Y only
Dynamic Testing:
Generally, the root of testing process is classified into two categories. They are
(1) Static Testing
(2) Dynamic Testing
Dynamic testing is the activity of testing the system by executing. Test cases are
prepared, the system under test is installed and by applying the test cases, the testing
operation will be encountered in the dynamic testing approach.
In the static testing mechanism, execution is not performed. Dynamic testing is further
classified into two categories,
(1) Functional Testing
(2) Non-Functional Testing
Functional testing checks the functional requirement satisfaction whereas non-
functional testing mechanism evaluates the efficiency of non-functional requirements.
Key Facts:
It doesn’t perform the verification process. It only perform the validation
operation.
Test Case Generation is important.
Evaluation is done based on execution.
Effective way of finding bugs of the system.
Probability of detecting bugs is relatively high.
Hierarchy of Dynamic Testing:
Generally, dynamic testing will be performed in different hierarchies.
They are unit, integration, system and acceptance testing activities.
Unit Testing / Component Testing:
Software systems consist of several different components. We can refer the
components as modules. For building a house, we need several different items like bricks,
cement etc.
The main role is played by bricks and cement materials. Similarly, software has various
components or modules (bricks) and they are interconnected using the interfaces (cement)
to form original system (house).
Testing the individual components of the system is said to be component testing. We
already discussed about the concepts of big bang testing. It states the testing of system as a
whole. Here, the component testing allows the tester to test the individual components
rather than testing the system as the whole.
Integration Testing:
After checking the system individual modules, to check interface consistency the
integration testing will be performed. Integration testing is classified into different types.
They are
(1) Top down Integration Testing
(2) Bottom up Integration Testing
(3) Sandwich Integration Testing
Top down Integration Testing:
In the case of top down integration testing activity, the interface consistency is
evaluated from top module (or) main module to lower level modules.
 The detailed concept of top down integration testing is discussed in the topic
“Testing under ‘T’. (Refer Testing under ‘T’)
Bottom up Integration Testing:
In the case of bottom up integration testing activity, the interface consistency is
evaluated from bottom level module to top level modules.
If any higher level modules are not yet designed, in such cases drivers are used as
a calling module. The driver module behaves similar to the original module that is not yet
developed. Driver is again software that acts as a prototype for undeveloped module.
They are fake modules that perform similar function as higher level modules
Sandwich Testing
Performing both top down integration testing and bottom up integration testing
simultaneously is called as sandwich testing approach.
System Testing:
System testing is the activity of performing the testing by considering the system as the
whole. In the case of unit testing, the individual units are tested, in the case of integration
testing, interfaces are evaluated. The next level is system testing. System testing will
ensure the consistency level of the system as the whole.
It is actually a black box testing approach. By taking complete system into
consideration the system testing will be performed. It is actually followed by the
integration testing process.
Various functional and non-functional features are evaluated by the system testing
approach. It is similar to the user perspective level of testing.
For more information about system testing, refer the system testing section. (Refer
Testing under ‘S’)
Acceptance Testing:
The last level in the hierarchy of dynamic testing is acceptance testing.
A system should be developed as per the customer or client’s requirements. Meeting all
the functional requirements (Requirements that are stated by the user) is very important
aspect that has to be considered while designing the system.
Such considerations are tested using the approach of acceptance testing. As the name
implies, after the software development, when it is given to the customer, he will check
whether the requirements stated by him are satisfied or not. If it is not satisfied, it will lead
to reconstruction of the entire system.
The cost of reconstruction is very higher than the development which makes the
company to lose large amount of money.
Hence, the procedure of testing the acceptance criteria is essential activity.
Testing Procedure: (Dynamic Testing)
(1) Develop the system.
 (2) Design the test cases using test case design strategy.
(3) Perform the following testing activities:
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing
(4) Note the results and redo if any inconsistency.
(5) Perform further testing if needed.
Domain Testing:
Domain testing is the important and essential testing methodology. Generally testing
involves, giving the input (based on the test cases) and identifying whether the expected
output is equivalent to arrived output or not.
The very challenging task here is nothing but selection of test cases. For any
application, there are infinite number of test cases may be generated.
Applying all the test cases to test the system is ineffective because of time complexity
and other issues.
Domain testing allows the testers to select the particular amount of test cases from the
wide amount of test cases.
In the domain testing activity, the domain is partitioned into small sub domains. The
sub domains are said to equivalence classes.
Myer’s Boundary Table:

Variable Valid Invalid Boundaries Comment

EC EC

X 1 to 100 >100 100, 101

<1 1, 0
String ..

Y Same Same Same

Domain Fault Model:

Domain fault model is nothing but an assumption which states where the problem or
fault actually encountered. If boundary not defined effectively, then the domain fault will
occur in it.
For effective system, defining the boundaries are very essential and tester should
concentrate more on it.
ON and OFF Points:
A point which lies on the boundary is said to be ON point. A point which doesn’t lie on
the boundary is said to be OFF point. OFF point may be either open or closed.
A point that lies out of the boundary is said to be closed OFF point. A point that lies
inside the boundary specified is said to be open OFF point.

For better understanding, consider the following equation x + y > 4. If the input x is 2,
then for satisfying the ON point the y should be 2. Hence (2,2) lies on the boundary in the
ON state.
Consider the domain D with boundary x + y < 5, closed OFF point will lies out of
boundary (say 3,4) and the open ON point lies inside boundary (say 2,1).
Test by yourself
(1) Compute the ON points for the following inequalities:
(1)
(2)
(3)
(4)

CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘D’)

Testing Name Summary

Decision Coverage Testing the decision making

Testing points of the system. It is
white-box testing approach.

Destructive Testing Testing in which system is

initially made to fail and
then system is reconstructed
to strengthen the weaker
points of the system.
 Dependency Testing Identification of dependent
modules is performed by
dependency testing.

Dynamic Testing Basic testing which is based

on execution of test cases.
Further classified as
a) Functional Testing
b) Non Functional Testing
Different levels of Dynamic
testing includes
a) Unit Testing
b) Integration Testing
c) System Testing
d) Acceptance Testing

Domain Testing Domain testing allows the

testers to select the
particular amount of test
cases from the wide amount
of test cases.

****

6
Testing Methods
[E]

Introduction:
Under the alphabetical letter ‘E’, there are 5 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Error Handling Testing
2. End to End Testing
 3. Endurance Testing
4. Exploratory Testing
5. Equivalence class partitioning

Error Handling Testing:

Error handling testing methodology ensures the error handling capacity of the system. It
identifies how the system reacts in the following situations.
(a) If user given invalid input.
(b) If user performs any illegal operations.
(c) If the user given input is improper but valid.
Performing the error handling testing is very important because if the software
delivered without performing this sort of testing, the end-user may suffer from lot of
problems.
A good system should be capable of handling the errors in an effective manner. To
ensure it, error handling testing is very essential and important.
Testing Procedure:
(1) Design the test cases.
1. Concentrate more on invalid and error producing test cases.
(2) Identify how the system reacts for invalid test cases.
(3) IF(Reacts Effectively)
1. Perform further testing (if necessary)
(4) ELSE
1. Redo
(5) Redo:
1. Reconstruct the system in such a way that it reacts good for invalid
inputs.
Real Time Example:
Consider a simple program with the pseudo code given below.
(1) Start
(2) Read numbers A and B.
(3) Get Operation from the user.
1. (1) – Addition
2. (2) – Subtraction
3. (3) – Multiplication
(4) Perform operation and print the result.
 (5) End the task.
The error handling testing operation concentrates more on invalid test cases.
(Negative Test Cases).
Let us trace the algorithm of error handling testing for the given example.
Step 1: Design of Test Cases:
Hints:
Concentrate more on negative test case.
In our example, there are two different input fields.
(1) Reading the two numbers ‘A’ and ‘B’
(2) Reading the operation (1) Add (2) Sub (3) Multiply
Test case for reading two numbers (Invalid TC’s)

TC A B Valid/Invalid
Number

1 X Y IV

2 15 X IV

3 X 23 IV

4 X 2.235 IV

By studying the pseudo code, we cannot predict the system output for the above test
cases. This is because of poor error handling capacity of the system.
Hence, it is essential to re-correct. Before re-correction of the pseudo code. The output
obtained is

TC A B OUTPUT
Number

1 X Y Abnormal
Termination

2 15 X Abnormal
Termination

3 X 23 Abnormal
Termination

4 X 2.235 Abnormal
Termination
Rewriting the Pseudo code:
(1) Start
(2) Read numbers A and B.
(3) IF(A IS INT && B IS INT):
1. Goto Op:
(4) ELSE
1. Goto Error;
(5) Op: Get Operation from the user.
1. (1) – Addition
2. (2) – Subtraction
3. (3) – Multiplication
(6) Perform operation and print the result.
(7) Error:
Print Invalid Input! System only accepts integer.
(8) End the task.
After rewriting the code, the output of the system is of

TC A B OUTPUT
Number

1 X Y Invalid Input! System

only accepts integer.

2 15 X Invalid Input! System

only accepts integer.

3 X 23 Invalid Input! System

only accepts integer.

4 X 2.235 Invalid Input! System

only accepts integer.

Test Case for reading the operation:

TC I/P No Operation Valid/Invalid

Number

1 5 Y IV

2 4 X IV
 3 2 SUB V

4 1 ADD V

The output of the above pseudo-code obtained by applying the test cases will be

TC I/P No Operation OUTPUT

1 5 Y Abnormal
Termination

2 4 X Abnormal
Termination

3 2 SUB V

4 1 ADD V

Rewriting the Pseudo code:

(1) Start
(2) Read numbers A and B.
(3) IF(A IS INT && B IS INT):
1. Goto Op:
(4) ELSE
1. Goto Error;
(5) Op: Get Operation from the user.
1. (1) – Addition
2. (2) – Subtraction
3. (3) – Multiplication
(6) IF(Option is 1 or 2 or 3)
1. Goto Execute;
(7) ELSE
1. Goto Invalid Option;
(8) Execute: Perform operation and print the result.
(9) END the task.
(10) Error:
Print: Invalid Input! System only accepts integer.
(11) Invalid Option:
(12) Print: Invalid Option! Check your option no.
After reconstruction of code, the output obtained will be

TC I/P No Operation OUTPUT

1 5 Y Invalid Option!
Check your option
no.

2 4 X Invalid Option!
Check your option
no.

3 2 SUB V

4 1 ADD V

Thus for ensuring the error handling capacity and identifying how the system reacts for
invalid inputs that are passed by users, the error handling testing should be performed.
Test by yourself
(1) For the pseudo codes given below, perform the error-handling testing with
invalid test cases.
Pseudo Code – I
(1) Start
(2) Read the numbers A and B.
(3) IF(A > B):
1. Print ‘A’ is greater;
(4) ELSE
1. Print ‘B’ is greater;
(5) End
Pseudo Code – III
(1) START
(2) Read Number (N)
(3) Initialize s to 0
(4) WHILE(N !=0)
1. R=N%10;
2. s=s+r*r*r;
3. N=N/10;
(5) IF(N==s):
 1. Print
“It is Armstrong Number”;
(6) ELSE
1. Print
“It is not an Armstrong Number”;
(7) END
End to End Testing:
End to End testing methodology is used for tracing the flow of execution from the
starting point to the end point of the system.
The full system is tested from the technical as well as user point of view.
Needs:
The end-to-end testing method identifies how the entire system performance will be. By
performing the end-to-end testing, we can get the answers for the following questions
given below
(1) Whether the system interface connections are perfect or not?
(2) Whether the system interacts with database effectively or not?
(3) Whether the system communicates with external hardware (if any) in
effective way or not?
(4) Whether the system flow is logical and in a meaningful manner or not?
Testing Procedure:
(1) Design the system
(2) Open the system under test.
(3) Give inputs in such a way that it covers end to end flow.
(4) Identify the followings:
1. Interface Consistency
2. Database Consistency
3. Communication Consistency
4. Flow of code Consistency
(5) Note down the results.
(6) IF(Results are not effective):
1. Redesign the code flow.
(7) ELSE
1. Perform further testing (If essential)
(8) End the testing activity.
Real Time Example:
Consider online exam result providing system. The end-to-end testing will include.
/* Start Point */
(1) Open the web URL
(Assume the URL as www.examresulthp.com)
(2) IF(URL Opened)
1. Input the register number to view result.
(Provide both valid and invalid R_NO)
2. IF(Result fetched for valid input AND
System shows for invalid input)
1. System is effective;
(Database interaction check)
/*End Point */
3. ELSE
1. Redesign the system;
(Check database consistency)
(3) ELSE /*URL Not opened*/
1. Identify the problem with the system
2. Reconstruct it.
The above shown is a technical definition. Generally, from the user point of view,
the end-to-end testing will follow the steps given below
(1) Open URL
(2) Accessing the result
(3) Printing the result
(4) Quitting the browser.
Example 2:
Consider the system structure given below,
 From the diagram we can understand the followings
Module Name Accessibility To Database
Main Module A and C –
Module ‘A’ B –
Module ‘B’ – Database X
Module ‘C’ – Database Y
The end to end to testing for the above system structure will check the followings.
(1) Main module can access A and C or not.
(2) Module A can access B or not.
(3) Module B can access database X or not.
(4) Module C can access database Y or not.

If any problem problem with the accessing from starting to end point of operation, it
will be identified by using the end to end testing approach.
Endurance Testing:
Endurance testing estimates the tolerating capacity of the system. It is also called as
soak testing. The following questions can be answered from the result of endurance
testing.
(1) How effectively the system withstand the load?
(2) What is the tolerating capacity of the system?
(3) How system reacts under continuous usage?
(4) What is the memory capability under continuous usage?
(5) How system can face the longevity issues?
Testing Procedure:
(1) Develop the system
(2) Open and use the system continuously (For more than 4 to 5 hours)
(3) Note down whether any problem encounters with continuous usage or not.
 (4) IF(Encounters)
1. Redesign the system
(5) ELSE
1. Perform further testing (if needed)
(6) End
Real Time Example:
Assume the gaming system. The endurance testing procedure for the gaming system
will involve
(1) Open the gaming system.
(2) Play the game continuously.
(3) Identify the problem (If any encountered)
(4) IF(Encounters):
1. Redo the gaming system
Exploratory Testing:
The exploratory testing involves both learning the application and testing it. It is an
effective and interactive testing methodology where the testers explore the system first and
then test it.
Features:
No Procedure will be followed.
No prior generation of test cases.
Better understanding about the system.
Based on the tester’s experience and skills.
Simpler methodology.
No documentation complexity issues.
A sub-category of Ad hoc testing.
As similar to black box testing approach.
In this testing approach, there is no prior generation of test cases. The tester will
understand the system functional characteristics and then depends upon the testers skill
he/she will test the system efficiency.
No dedicated procedures are followed to perform the testing operation. Wastage of
time by applying unwanted test cases are avoided with the help of exploratory testing.
Both the tester as well as developer will involve from the beginning of time in order to
measure the effectiveness of the system.
Demerits:
 It is an Adhoc testing approach. Hence, we cannot ensure that the system is
effective.
No procedure followed.
Depends upon the skill of the tester.
Tester should learn about the system as faster.
Equivalence Class Partitioning:
The main problem with the testing is time shortage. The time allocated for testing the
product is probably very less. Especially about a week.
Hence it is only possible for a tester to use minimal amount of test cases to test the
system. The Equivalence Class Partitioning is the test case generation method in which the
input domain is classified into equivalent classes.
ECP falls under the black box testing technique because the internal code checking is
not possible with this testing approach.
The partition of input domain into various classes and testing the system by taking any
one sample input from each class is performed by ECP. It reduces the number of test cases
used for testing the system as well as the time.
Generation of Test Cases:
Assume that the system accepts the input ranges from K1 to K10. The ECP suggest that
the input domain is divided into various classes as follows
EC Class Criteria Valid/Invalid
C1 >K10 Invalid
C2 <K1 Invalid
C3 Special Characters Invalid
C4 K1 to K10 Valid
In the case of boundary value analysis, the boundary values are only taken into
consideration that is
Lower boundary (K1)
Upper boundary (K10)
Less than Lower boundary (K0)
Greater than Upper boundary (K13)
But in the case of ECP, the input domain classes are tested. The testing of
application involved by taking any one of the input from each class. The following table
illustrates it
EC Class Input Valid/Invalid
C1 K15 Invalid
 C2 K0 Invalid
C3 XY Invalid
C4 K4 Valid
It is enough to test any one of the input from each classes. The main assumption is that,
if one input passes then all other inputs on that particular class will pass and vice versa.
Merits:
Number of test cases are less.
It is enough to check only one input from each class.
Possibility of checking all category of inputs.

Test by yourself
(1) Design the Equivalence Classes for the following sub routine.
int add(int X, int Y)
{
if(X>5 && Y>5)
print “Error”;
else
Z=X+Y;
return Z;
}
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘E’)

Testing Name Summary

Error Handling Testing the error handling

Testing capacity of the system.

End to End Testing Testing the flow of control

of the system from the
starting point to the end
point of operation.
It involves checking how
system handles the device
connectivity, database and
 network connections.

Endurance Testing Tolerating capacity of the

system under continues
usage is estimated by this
testing approach.

Exploratory Testing Exploratory testing

involves both testing as
well as learning about the
system. It is a type of
Adhoc testing technique.
Good testing skills required
for a tester to perform
exploratory testing.

Equivalence Class Input domain is classified

Partitioning into various different
classes based on valid and
invalid conditions. It is a
method of test case
generation. Number of test
cases used for testing the
system is reduced by this
ECP test case generation
technique.

****

7
Testing Methods
[F]

Introduction:
Under the alphabetical letter ‘F’, there are 4 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Fault Injection Testing
2. Formal Verification Testing
3. Functional Testing
4. Fuzz Testing
Fault Injection Testing:
Fault injection testing methodology embeds the faults into the system under test. By
introducing the fault, the code efficiency will be increased in this method. The process of
fault injection testing is classified into two different categories
(1) Static Fault Injection
(2) Dynamic Fault Injection
Static Fault Injection:
The fault injection at the compile time is said to be static fault injection technique.
Different fault injecting tools are available for injecting the faults into the system that is
under testing operation.
Dynamic Fault Injection:
Dynamic fault injection is the activity carried out to inject faults to the system at the run
time. It enforces the faults into the system at running time.
Fault Injection Tools:
There are various tools available for injecting faults into the system. Some of them are
(1) Ferrari
(2) MODIFI
(3) FTAPE
(4) DOCTOR
(5) Xception
(6) Grid-FIT
Ferrari:
Ferrari refers to Fault and Error automatic real time injection.
Using the traps, the faults are injected to the system
MODIFI:
MODIFI stands for Model Implemented Fault Injection.
Supports the fault modelling in XML.
FTAPE:
FTAPE stands for Fault Tolerance and Performance Evaluator.
By including disk which injects faults into data.
 It also injects faults to memory and registers.
DOCTOR:
DOCTOR stands for Integrated Software Fault Injection Environment.
It is an effective tool for fault injection.
Formal Verification Testing:
Formal verification testing evaluates the efficiency of the system under test by checking
whether the algorithm is implemented in an effective manner or not.
There are many approaches in verifying the correctness of the system using formal
verification testing approach.
Functional Testing:
Functional testing is the testing mechanism which ensures the functional requirements
of the system. Design specification satisfaction measurement is the main goal of the
functional testing.
Testing Procedure:
(1) Get the functional specifications of the software from the SRS document.
(2) Create inputs which evaluates the functional specification of the system
under test.
(3) Apply the inputs to test the system.
(4) IF(Expected Output == Arrived Out):
1. System passed under functional testing;
(5) ELSE
1. Reconstruct the system.
(6) End
Types:
There are four different categories in the functional testing. They are
(1) Sanity testing (Refer Testing under ‘S’)
(2) Smoke testing (Refer Testing under ‘S’)
(3) Regression testing (Refer Testing under ‘R’)
(4) Usability testing (Refer Testing under ‘U’)
Real Time Example:
 The above figure shows the user interface of the staff management system. One
module of this system requires Staff ID as the input to access the staff information. Hence,
the functional requirement for the system includes
(1) System should produce the result (staff Information) if Staff ID is thrown
as an input to it.
(2) System should produce error if staff ID is incorrect.
The above two things are functional requirements of the system (stated by users).
Merits
Checks whether user stated concepts are implemented or not
It is similar to the acceptance testing performed by testers.
Demerits
No importance given to non-functional requirements.
For bigger systems, it takes larger time.
Test by yourself
(1) Identify the functional requirements for
1. Online Course Reservation System.
2. Student Details Management System.
Fuzz Testing
Fuzz testing methodology ensures the software efficiency by giving large collection of
random inputs (particularly invalid inputs that causes error). Generally, Fuzz testing is
conducted with the help of automation tools.
Large collection of random invalid inputs generated by automation system to test the
system under test is said to be Fuzz or Fuzz Input. If any vulnerability found then fuzz
tester is used.
By applying the fuzz, if the system fails then we can conclude that there are defects
available with the system.
Types:
There are various different methods available in Fuzz testing approach. Some of them
are
(1) Random Fuzzing
(2) Capture Replay Fuzzing
 (3) Block based Fuzzing
(4) Model based Fuzzing
Fuzzing Inputs:
The Fuzzing inputs may take any one of the following formats
(1) File Based Fuzz Inputs
(2) Protocol Based Fuzz Inputs
(3) Function Based Fuzz Inputs
File Based Fuzz Inputs:
The random inputs are passed to the system using file (ie, fuzz inputs are stored into
file) and system takes that file as an input.
The file format will be either PDF or PNG or MOV and so on.
Protocol Based Fuzz Inputs:
The random inputs are passed to the system using networking protocols. Some of the
protocols used are SOAP, HTTP, SNMP and so on.
Function Based Fuzz Inputs:
Writing a method which passes the input to the system is said to be function based fuzz
inputs. The following example explains the function based fuzz inputs
void Fuzz()
{
for(i=1;i<=1000;i++)
/* Large inputs should be generated */
{
Generate random invalid inputs;
Pass the input to the system;
}
}
Fuzz Generation
Generation of Fuzz inputs can be generated by any one of the following methods.
(1) Mutation Fuzzing
(2) Intelligent Fuzzing
Mutation Fuzzing
There are various methods involved in Fuzz input generation by mutation Fuzzing
approach. The mutation is very simple to study and as well as apply. No strong skills
needed to do it.
 One among the method of mutation Fuzzing is bit flipping. From the name itself, we
can understand that bit flipping is the approach in which bits of the code are changed
randomly.
Example:
Actual Code:
<?php
echo “Hello Hari Prasath”;
echo “Your D-O-B”;
?>
Code after flipping:
<?php
echo “ell H ‘A $5$2”;
echo “Your D-O-B”;
?>
Another method of mutation fuzzing is appending. In this method, random inputs are
appended in the code.
Actual Code:
<?php
echo “Hello Hari Prasath”;
echo “Your D-O-B”;
?>
Code after appending:
<?php
echo “Helloooooooo Haaaari Prasaath”;
echo “Your D-O–—BBBB”;
?>
Intelligent Fuzzing
Intelligent Fuzzing technique uses special tools, advanced techniques and
approaches to create the fuzz input data.
Testing Procedure:
(1) Design the system
(2) Create the Fuzz
(3) Apply the Fuzz to the system
(4) IF(System Crashes):
 1. Identify the reason for crash;
2. Reconstruct the system;
(5) ELSE
1. System is effective;
2. Perform further testing (If needed);
(6) End the testing
Merits:
An automated way to perform testing.
Interesting and easy method of testing.
Concentrates both on expected and unexpected behaviours of the system.

Test by Yourself
1. How will you perform Fuzz Testing? Explain.
2. Briefly discuss about the fault injection tools.
3. Explain the role of automation in Fuzz Testing.
4. Define the following terms
1. Fuzz
2. FTAPE
3. DOCTOR
4. Xception
5. Vulnerability Test

CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘F’)

Testing Name Summary

Fault Injection By injecting / including

Testing fault to the system the
system efficiency of fault
toleration is tested.

Formal Verification Verification of system

Testing features, formal tracing of
algorithms.

Functional Testing Finding the functional

features of the system. As
 similar to acceptance
criteria checking process.

Fuzz Testing By giving random invalid

inputs generated by
automation tool, testing is
performed

****

Few Automation Tools

Tool Name Testing

DOCTOR Fault Injection
Crash Me Fuzz Testing
Selenium Web Testing Tool
Soap UI Function Testing
Test Complete Windows Platform
Egg Plant GUI Automation
RSpec Ruby

8
Testing Methods
[G]

Introduction:
Under the alphabetical letter ‘G’, there are 5 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Gorilla Testing
 2. Grey Box Testing
3. Glass Box Testing
4. GUI Testing
5. Globalization Testing
Gorilla Testing
Gorilla Testing is the approach which involves continuous testing of a particular
module using same as well as different test cases.
Because of its complexity and strong determination in continuous testing it is named as
Gorilla testing.
In the Gorilla testing approach, the test case is generated based on any one of the test
case generation technique (say equivalence class, BVA etc.) Using that test cases the
testing will performed.
Gorilla testing doesn’t satisfy with single time testing. Multiple times TC’s are applied
to the system.
The main theme of the Gorilla testing is to ensure the efficiency of a module at a greater
extend. In this type of testing both tester as well as developer will involve in the activity of
testing the system.
The goal of the Gorilla testing is to identify the ability of the system to cope with the
errors while running.
Testing Procedure
(1) Design the module
(2) Design the Test Cases
(3) Apply:
1. Apply the test cases to the system;
2. Check for its efficiency;
3. If(Satisfaction degree ! = 100)
1. Goto Apply;
4. ELSE
1. Goto End;
(4) End:
1. Complete testing of module.
2. Consider another module for testing (If any)
Real Time Example
Consider the staff details management system consist of four modules A (Staff Details
Module), B (Staff Salary Module), C (Staff Designation Module) and D (Staff
Performance Monitoring Module).
Gorilla testing methodology takes only one module at a time for testing. Let we start
with the module ‘A’ to trace the algorithm. It is important to identify the logic of the
module to generate test cases. Gorilla testing ensures modular consistency by various
aspects.
Module – I:
Input Field : Staff ID
Output : Staff Details
Step 1: Design the Module – I:
Assume that the module I is already designed.
Step 2: Generation of Test Cases:
There are various test case generation technique used for generation of test cases. For
simplicity, let us generate test cases randomly.
TC No Input V/IV Exp. Output
1 201 IV Error
2 459 V Staff Details
3 309 IV Error
Step 3: Applying Test Cases:
The generated TC’s acts as the input to the system. Apply them one by one.
If(Expected Output == Arrived Output)
{
System is Consistent;
IF(Satisfied)
END
ELSE
Apply test cases again.
}
Else
{
Redesign the module;
}
Merits:
Thorough checking of module.
Grey Box Testing
Grey box testing is the combination of both black box as well as white box testing
approaches.
 In the case of black box testing method, the tester cannot know about the internal logic
or code. The black testing method is based on inputs.
Black box testing is the testing approach in which the software efficiency is
checked just by giving the input and checking whether the expected output comes / not.
White box testing is the testing methodology in which the internal codes are
analysed in order to measure the efficiency of the system under test.
In the case of Grey box testing, the tester partially concentrates on internal logic
also.
Types
There are four different types of Grey box testing available. They are
(1) Pattern based Grey Box Testing
(2) Matrix Testing
(3) Orthogonal Array Testing
(4) Regression Testing
Testing Procedure
(1) Design the system
(2) Generate the Test Cases
(3) Apply the test cases
(4) IF(Necessity to check internal logic)
1. Perform internal logic checking
(5) ELSE
1. Obtain the results from the system
2. End the testing
Real Time Example
Consider an online voting system that has to be tested. Initially, the testers will try to
measure the efficiency by black box approach which involve following activities
(1) Generation of Test Cases
(2) Applying TC’s to the system
During that time, if the tester need to know about the cause of arrived output, then
he/she should go for white box approach.

The above figure illustrates that grey box testing is the combination of both black box
and white box testing.
Note that, in white box testing – full internal logic is tested. In Grey box, if needed
then only the internal logic is tested. No internal logic checking for entire system.
In our case, let us consider that the tester wants to make sure about database field
where the voting results are stored. In such case, probably the tester need to perform
internal logic checking (White box approach).
Merits
It is the combination of both white box as well as the black box testing
scenarios.
Demerits
Some bugs may remain undiscovered.
Test cases given to the system will drive the whole testing process.
Glass Box Testing
Glass box testing is also called as white box testing or clear box testing or structural
testing. The white box testing approach involves testing the internal logics of the system.
Glass box testing approach explores the internal code deeply in order to find the bugs. It
also measure the time complexity, space complexity concepts.
Methods:
There are different methods of glass box testing exists. Some of them are
(1) Statement Coverage
(2) Path Coverage
(3) Branch Coverage
(4) Condition Coverage
(5) Cyclomatic Complexity
Statement Coverage
The statement coverage testing involves test of each executable statements in the
system. The test cases are designed in such a way that it executes all statements in the
system at least once.
With this idea, each statement is evaluated in order to measure the effectiveness. By this
approach, it is also possible to find unreachable code (if any).
Testing Procedure
(1) Develop the system
(2) Generate test cases in such a way that it executes all statement at least once.
(3) Apply test cases
(4) Test the system performance
Real Time Example:
Consider the following example which illustrates the greatest of 3 numbers.
Pseudo Code:
1. Read the numbers A,B and C.
2. IF (A>B)
3. IF(A>C)
4. Print “A” is greater;
5. ELSE
6. Print “C” is greater;
7. ELSE IF(B>C)
8. Print “B” is greater;
9. ELSE
10. Print “C” is greater;
The test cases are generated to evaluates all statements at least once.
Generation of Test Case:

TC No Input Statements Output

Executed
A B C

1 3 2 1 1–2–3–4 A is
greater

2 4 5 6 1–2–7–9– C is
10 greater

3 7 8 2 1–2–7–8 B is
greater

From the table, we can understand the statement coverage and its importance. It is
not possible to cover entire statements only by using a single test case.
Merits:
Unreachable code can be easily identified.
Effective method which covers all lines of code.
Demerits:
High technical skills needed for the testers.
Path Coverage
Path coverage suggests the testers to design test cases in such a way that it covers all
possible paths of execution.
All linearly independent paths should be executed at least once – is the primary goal of
the path coverage testing approach. Generally Control Flow Graphs (CFG’s) are used for
identifying the paths. Path coverage is nothing but basic path testing.
T he entire code is converted into flow graph. The flow graph is the graphical
representation of the logical flow for any program. It is very similar to flow chart.
The basic path testing evaluates all possible paths that the program can take in order to
reach the end state or termination state.
We already discuss about how to convert the code to flow graph. Consider the CFG
given below,

The test cases should be generated in such a way that it covers all possible paths of
execution from starting to the termination vertex.
Test Case Generation:
The pseudo code for the above CFG is
(1) Read the number ‘X’.
(2) Check whether it is number or not. If not Go to (6)
(3) Check the number is positive / negative. If positive go to (4) else go to (5)
(4) Print it is positive
(5) Print it is negative number
(6) Print “Invalid Input”

TC Input Path of Output

No Execution
(X) (Expected)

1 +3 1–2–3–4 Positive

2 -7 1–2–3–5 Negative

3 BCD 1–2–6 Invalid

Input

From the above table, it is easy to understand the importance of path coverage. By
using this technique, we can evaluate the efficiency of execution paths.
Merits
Simpler approach and easy to find.
Identifies how the system reacts for different TC’s.
System path taking capability can be studied with the help of Path coverage
testing.
Demerits
If the CFG is complex, then it is very difficult to generate the test cases.
Technical skills are needed.
Very difficult to generate the test cases
Importance
Unreachable paths can be identified.
Infinite looping paths can also be detected.
Branch Coverage
We have already discussed about the branch coverage testing approach. (Refer Branch
Testing – Testing under ‘B’)
Condition Coverage
We have already discussed about the concepts of condition coverage testing. (Refer
Condition coverage testing – Testing under ‘C’)
Cyclomatic Complexity
In the basic path testing approach, we discussed with the finding of cyclomatic
complexity. Let us summarize the formulae here.
Method – I:
Cyclomatic Complexity(C.C)= E – N + 2
Method – II:
Cyclomatic Complexity (C.C) = P + 1
Method – III:
(C.C) = Number of Outer Region + Inner Region
Example
Calculate the cyclomatic complexity for the CFG given below
Solution:
From the graph, we can say that there are
Edges : 5
Vertex: 5
Method – I:
Cyclomatic Complexity(C.C)= E – N + 2
Hence,
C.C = 5 – 5 + 2 = 2
Method – II:
Cyclomatic Complexity (C.C) = P + 1
Here, there is only one predicate node (P),
C.C= 1+1 = 2
Method – III:
(C.C) = Number of Outer Region + Inner Region
Outer region is always one, the inner region (closed) is also one in our example.
C.C=1+1 = 2
Test by yourself
(1) Perform the statement coverage, path coverage, cyclomatic complexity,
branch coverage testing for the CFG given below.

(2) Conduct all white box testing methods for a module that generates prime
number up to specified range.
(3) Brief the importance of control flow graphs. (CFG).
GUI Testing
 GUI testing is a type of application interface testing approach in which the front-end
consistency of the graphical system is measured.
The GUI Testing ensures that following concepts
(1) Whether the screen elements are consistently placed or not.
(2) Whether the front-end fits with back-end or not.
(3) Whether the alert-messages are implemented in a proper manner or not.
(4) Whether the user interface developed for error messages or not.
(5) Whether the screen is resizable or not.
(6) Whether the Interface Colour Consistency is maintained or not.
(7) Whether accessibility is good or not.
(8) How fast the interface provides services?
(9) Whether the response time is effective?
Methods
There are two methods of performing in GUI Testing. They are
(1) Manual testing of interface
(2) Model oriented testing of interface
Manual testing of interface
In this approach, tester manually predicts the expected output and then they will test the
system by applying test cases.
IF(Expected Output == Arrived Output)
System passed;
(Perform further testing)
Real Time Example
Consider the GUI system module that checks the eligibility criteria for voting. Assume
that, minimum age to vote is 21. The code for the module is
Vote()
{
age=input();
IF(age>=21)
You are eligible to vote;
ELSE
Your are not eligible to vote;
}
 The above figure shows the GUI of the voting eligibility checking system.
Initially, the tester develop the test cases and identifies the expected output manually. Then
testing will perform to ensure whether expected output obtained or not.
GUI Testing also concentrates about the text box size and other attributes.
Generally, form elements, alignments, consistencies of UI are evaluated by GUI Testing.
TC Input Manual Final
1 35 Eligible Eligible
2 12 Not Eligible Not Eligible
3 100 Eligible Not Eligible
Globalization Testing
Software that is developed may have a global or local usage. The global usage refers to
the usage of the software all over the world without any cultural, language and other
straits.
Software that is developed for particular region and cultural usage is called locally
designed system (local usage). Globalization testing is performed if and only if the system
has global scope of usage.
If the scope and usage of the system is local, then in such circumstances, one should
perform localization testing instead of globalization testing approach.
Testing Procedure
(1) Develop the system
(2) Identify the globalization aspects and test them
(3) IF(System is capable of working under various cultural environment)
1. Perform further testing
(4) ELSE
1. Reconstruct the aspects
(5) END
Globalization aspects
Globalization aspects are factors which are to be evaluated while performing
globalization testing. The aspects include
Language supporting
Economical supporting
Global language supporting
 Compatibility supporting
Input field format supporting
Language Support
If a software is designed with the aim of global usage, then language support is the
main aspect that is to be concentrated. A good system should offer multi-language support.

Some websites provide the multi-language support which allows the global users
to access the site in more efficient way.

The above figure shows the front end of e-learning website which is globalized by
embedding all language support.
Before entering to the website, the user should select the language of preference.
Economical Support
For a global software which perform transactions, it is very important to have a
economical globalization support. The currency conversions, tax appending operations
should be supported and they should be updated dynamically based on the country.
Global language Support
If the developer feels complex to embed multi-language support, then he/she should
design the system with global language (English) rather than local language supporting.
Compatibility Support
Different countries users have different platforms. The system should compatible with
all platforms. It is suggested to perform compatibility testing.
Test by yourself
(1) With a real time application, discuss the importance of globalization.
(2) Compare and contrast the differences between localization and
globalization.
(3) What are the factors governed by GUI Testing?
(4) Suggest guidelines for designing a web page with global access and
consistent user interface.

CHAPTER SUMMARY
Software Testing Techniques
 (Testing under ‘G’)

Testing Name Summary

Gorilla Testing Testing the single module

again and again to measure
the consistency.

Grey box Testing Combination of both black

box as well as white box
testing.

Glass box Testing Testing the internal logic

(White Box Testing).
Involves path coverage,
statement coverage, branch
coverage, cyclomatic
complexity and so on.

GUI Testing Front-end consistency

checking for graphical
systems.

Globalization Testing Checking global aspects of

system.

****

9
Testing Methods
[H]
Introduction:
Under the alphabetical letter ‘H’, there is only one testing methodology available for
testing the effectiveness and efficiency of the system. It is called as hybrid integration
testing.
Hybrid Integration Testing
Hybrid integration testing is also called as sandwich testing which comprises of both
bottom up integration testing as well as top down integration testing.
Perform both top down as well as bottom up integration testing at the same time is said
to be hybrid integration testing. In this technique, both stubs and drivers are used instead
of undeveloped modules.
Testing Procedure
Top down integration testing approach is used for top level modules whereas the
bottom down integration testing approach is used for bottom level modules.
Another way to perform the hybrid integration testing involves the following steps
(1) Identify the centralized module (say C-M).
(2) Perform bottom up testing for modules (only for modules located above the
C-M)
(3) Perform the top down integration testing for modules that are located below
the C-M.
(4) Perform big bang testing for middle level modules (C-M modules)

The hybrid integration testing divides the system into two categories. Let us
consider A is the top level module where as B and E are middle level modules and the
modules D,E and F are lower level modules. The hybrid integration testing involve the
following steps
(1) Perform bottom up testing for
1. Module A
(2) Perform big bang testing for
1. Module B
2. Module C
(3) Perform top up testing for
1. Module D
2. Module E
3. Module F
Merits
 Includes both bottom up as well as top down approach of testing.
Faster method of checking interface consistency.
Useful for complex systems.

10
Testing Methods
[I]

Introduction:
Under the alphabetical letter ‘I’, there are 5 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Integration Testing
2. Interface Testing
3. Install/Uninstall Testing
4. Internationalization Testing
5. Inter system Testing
Integration Testing
Integration testing is the second level dynamic testing in which the individual modules
are connected and tested for its interface consistency. There are different approaches
available in the integration testing
(1) Top down Integration testing
(2) Bottom up Integration testing
(3) Hybrid Integration Testing
(4) Big Bang Testing
We already discussed the concepts of bottom up, big bang and hybrid integration
testing process.
For the top down integration testing, refer Testing under ‘T’. When the system is
developed under the modular approach, in such cases the integration testing is very
essential and important to check the interface consistency.
Interface Testing
Interface testing is very similar to the application interface testing in which front-end
design is tested for its effectiveness. (Refer Application Interface Testing)
Install/Uninstall Testing
 As the name implies, install/uninstall testing ensures whether the system produce any
problem while installing and uninstalling process or not.
Generally, graphical system requires installation whereas web system doesn’t require
any installations because they are fully based on the browsers.
Hence, the install/uninstall testing is essential only for the graphical systems and they
are not essential for the web based systems.
From the name itself, we can understand that, it comprises of two testing scenario’s
(1) Installation Testing
(2) Uninstallation Testing
Installation Testing
Installation testing is the activity of installing the system to measure the problem
occurrences during the installation operation.
Uninstallation Testing
Uninstallation testing is the activity of uninstalling the system to detect problem
occurrences during the Uninstallation activity.
Testing Procedure – Installation Testing
(1) Develop the system
(2) Install the system over various platforms
(3) IF(Installed Perfectly)
1. Perform further testing(If essential)
(4) ELSE
1. Reconstruct the system
(5) END
Testing Procedure – Uninstallation Testing
(1) Make sure whether the system installed/not
(2) IF(uninstalled)
1. Goto Installation Testing
(3) ELSE
1. Uninstall the system
2. Check whether any problem occurs;
3. IF(Occurs)
1. Reconstruct the Uninstallation code
4. ELSE
1. Perform further testing
(4) END
Real Time Example
Consider the Windows-7 operating system. The installation step comprises the
following steps
(1) Turn On the System
(2) Insert CD/DVD and Press F2
(3) Choose the booting option via CD/DVD
(4) Select English and accept the license agreements
(5) Click on CUSTOM installation
(6) Perform portioning
(7) Give user account information
(8) Enter the product key and network information
(9) Restart and open the system
Merits
It is very important testing method especially for the graphical system.
If any problem occurs with installation, then it is not possible to open the
system hence it is effective testing approach.
Simple
No test case generation complexity.
No documentation complexity.

Puzzle

Across
[2] Black Box + White Box
[3] Test again and again
Down
 [1] Another name of white box
Internationalization Testing
If the software developed has a world wide scope, then it is very essential to verify
whether it works perfectly across various regions or not.
Checking whether the system is capable over all geographical regions is performed by
the internationalization testing approach.
It identifies the problems on globalizing the system.
Intersystem Testing
Intersystem testing ensures whether the system is capable of supporting the existing
software or operating system. It is also called as interoperability testing.
The system may interconnect with any other system or application. Generally
application software require the support of operating system. The intersystem testing
ensures this capability.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘I’)

Testing Name Summary

Integration Testing Combining the module and

performing the testing to
check interface problems.

Interface Testing Front-end consistency

testing method.

Install/Uninstall Testing whether the system

Testing is capable of install and
uninstall operation.

Internationalization Checks whether the system

Testing works perfectly across
various regions or not.

Intersystem Testing Testing whether the system

is capable of supporting
existing software.

****
 11
Testing Methods
[K]

Introduction
Under the alphabetical letter ‘H’, there is only one testing methodology available
for testing the effectiveness and efficiency of the system. It is called as Keyword driven
testing.
Keyword Driven Testing
Keyword driven testing involves separation of the test cases and testing primitive.
Keyword (often called as action words) is the set of actions that is to be performed with
the system. The keywords are maintained with the help of keyword documentation.
Keyword Documentation
The keyword documentation suggests the set of various keywords that are essential to
test the system actions. It is a table with keyword as well as inputs essentials that are
necessary to execute the keyword.
The keyword driven testing is also called as table-driven testing approach. In the table,
test cases and keywords are available to test the efficiency of the system under test.
Keyword driven testing activity is performed by both manual and automated approach.
Real Time Example
Consider the web system which is developed for e-examination activity. The different
modules of the web system include
(1) Login
(2) Take the Test
(3) Timer
(4) Database Connections
(5) Result
The keyword driven testing will perform table generation for each module as follows
Module – 1: Login
Keyword I/P Purpose
Requirements

Login User ID 304 Checking whether

the system login
Password 309 operations are
effective/not

Output Expectation: System should logged in if

valid User ID and Password

Module – 2: Take the Test

Keyword I/P Purpose

Requirements

Write Clicking radio Checking whether the

buttons questions are loaded
in a proper manner
and checking whether
the system allows
clicking of answers

Output Expectation: System should migrate to

next question if the user click ‘Next’ button,
system should store user answers for further
validation

Module – 3: Timer

Keyword I/P Purpose

Requirements

Time – Checking whether the

time is reducing a
proper way

Output Expectation: Time should reduce and it

should redirect to home page when time expires

Module – 4: Database Connections

 Keyword I/P Purpose
Requirements

Database Q.No 1 2 Checking whether

the user entered
Q.No 2 4 operations are stored
in database / not.

Output Expectation: Database should update

information

Module – 5: Result

Keyword I/P Purpose

Requirements

Result User ID 304 Checking whether

system is effectively
Password 309 valuating the user
answers/not

Output Expectation: After effective evaluation,

result should be displayed to the candidate

From the above table we can understand the importance of the keyword driven testing
approach. It is very effective testing approach. It evaluates various functions of the system
with effective test cases. Documentation complexity is the only problem in the keyword
driven testing approach.

12
Testing Methods
[L]

Introduction:
Under the alphabetical letter ‘L’, there are 3 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
 1. Load Testing
2. Localization Testing
3. Loop Testing
Load Testing
Load testing is the non-functional testing approach which evaluates the non-functional
features of the system. The load bearing capacity of the system is tested by this software
analysis approach.
The maximum withstanding capacity of the system can be easily identified using the
load testing approach. Load testing is performed under two conditions
1. By applying normal load
2. By applying over load
Generally load testing is automated with the help of automation tools for reducing
time complexity of operation.
After system is designed, it is very important activity to identify whether it has
good load bearing capacity/not. To measure it, load testing is very important.
Testing Procedure
(1) Develop the input
(2) Apply normal and peak load using automation tools and techniques
(3) Check the system efficiency
Automation tools for load testing
There are various automation tools available for performing load testing. Some of them
are
(1) TEST MAKER
(2) GRINDER
(3) JMETER
(4) RUBIS
(5) OPENSTA
TEST MAKER
TEST MAKER is an open source, automation tool developed for testing the
system.
It is platform independent tool.
Developed in Java
GRINDER
Load testing tool developed in Java.
Scripts of Grinder are written in Jython language.
 Grinder 2 executes testing sequentially whereas Grinder 3 uses arbitrary
branching, looping.
Dynamic scripting support.
JMETER
Java based system for load testing
Open Source
Capable to perform load testing of different protocols like SOAP, LDAP,
SMTP, IMAP, POP etc.
Enhanced caching support.
RUBIS
Designed using Java.
Open source automation testing tool.
Effective to UNIX environment.
Test results are generated as html file.
OPENSTA
Designed using C++ language.
Open source automation tool.
Dedicated for performance testing.
Provides versatile testing environment.
Allows to detect the performance of WAE.
Merits
(1) Effective method of performance evaluation of system.
(2) System scalability, speed and other aspects can also be measured with the
help of load testing.
(3) Enormous automated tools available for testing.
(4) Load testing concentrates on many aspects like throughput of the system,
CPU usage, memory usage, disk accessing latency, cache performance etc.
(5) Especially suitable for multi user systems.
Demerits
(1) In many cases, the load testing is performed with the help of automation
tools, unexpected errors in the tool leads to various problems.
(2) Result documentation is very complex.
Localization Testing
Localization testing is just a converse of globalization. Software that is developed may
have a global or local usage. The global usage refers to the usage of the software all over
the world without any cultural, language and other straits.
Software that is developed for particular region and cultural usage is called locally
designed system (local usage). Localization testing is performed if and only if the system
has local scope of usage.
If the scope and usage of the system is local, then in such circumstances, one should
perform globalization testing instead of localization testing approach.
Generally, to convert the globalized product into localized one, the translators are
involved. They involve in translating the resource file.
Testing Procedure
(1) START
(2) Develop the system
(3) Identify the localization aspects and test them
(4) IF(System is capable)
1. Perform further testing
(5) ELSE
1. Reconstruct the aspects
(6) END
Localization aspects
Localization aspects include the followings
(1) Local language support
(2) UI Consistency support
(3) Manual support
Local language support
It is not compulsory to have a multi-language support for a local product. Generally,
while converting the global product to local product, translators are used. They will
convert the system as a local product.
UI Consistency support
The end-users of different location uses different type of user interface. They are
familiar with various sort of interface designs. To convert a product as a local product, it is
essential to convert UI regarding to the region so that the end-users feel more comfort.
Manual support
Generally, manual is attached with the product if the product include any external
hardware support. The manual is need not to be multi-lingual one in case of local
products. Hence manual language should also be changed with respect to the region of
usage.
Methods of Localization
(1) Water fall method of localization
(2) Agile Method of localization
Water fall method
As similar to water fall method in SDLC, it has four stages such as building glossary,
translation, testing and fixing bugs.
Agile method
We already discussed about agile testing approach. It is a test and develop approach.
Same approach is used in the localization concept also.
Merits:
Linguistic issues are fixed.
Loop Testing
Loop testing is the glass box testing approach in which the looping statements in the
system are tested. Generally various problems will encounter with looping operation. If
the looping operation is not implemented in a proper way, then it leads to the following,
(1) Infinite looping process.
(2) Abnormal termination.
(3) Extra looping process.
To enhance efficiency of looping statements, the loop testing should be performed.
Categories of loops:
In a programming concept, loops can be classified into four different categories.
(1) Simple loop
(2) Nested loop
(3) Joined loop
(4) Unstructured loop
Simple loop
The following figure illustrates the structure of the simple loop

A simple is accomplished with one decision point.

Conditions are very simple.
Nested loop
A loop inside a loop is said to be nested loop.

The above figure illustrates that there are two loops one after another.
Concatenated loop
Loop which comes after the execution of another loop is said to be
concatenated loop

Each loops are independent working and followed by one after another.
Unstructured loop
Loop which doesn’t have any proper structure is said to be unstructured
loop.
It has the various combinations of (nested, concatenated, simple) loops.
Testing Procedure
(1) START
(2) Identify the looping statements
(3) Generate test cases for satisfying both valid and invalid paths of the loop.
(4) Apply the test cases.
(5) Check:
1. Whether the loop executed as per expected iterations.
2. Whether it executes in a right path.
(6) IF(Consistent)
 1. Perform further testing (IF needed)
(7) ELSE
1. Reconstruct the looping statement
Real Time Example
Consider a simple looping statement given below
a=get_from_user();
while(a>0)
{
Print “Hello!”;
a=a-1;
}
If a=2, the output of the above looping statement is
Hello!
Hello!
Iteration Generation for Input A=2

Iteration A value Condition Expectation

P/F Criteria

1 2 P Loop Takes

2 1 P Loop Takes

3 0 F Loop
Terminates

Merits
Checks the internal logic (White box approach)
Efficient approach.
Identifies unreachable code if any.

Test by yourself
(1) Perform loop testing for
S=6
while(S<5)
{
 S=S-1;
Print(S);
}

(2) Perform the loop testing for

for(i=5;i>=0;i—)
{
Print(i);
i+=1;
}
(3) Explain the various automation tools used in performing the load testing
activity.
(4) Bring out the importance of localization concept.
(5) Differentiate between localization and globalization.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘L’)

Testing Name Summary

Load Testing Load withholding capacity

of the system is tested.

Localization Testing Translating the system as

local product, embedding
regional primitives with the
product.

Loop Testing Loop unrolling, loop

efficiency is tested using
this testing technique.

****
Crossword
Across
[1] Test and Develop
[3] Performance Testing
Down
[1] Hybrid Integration Testing

13
Testing Methods
[M]

Introduction:
Under the alphabetical letter ‘M’, there are 3 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Manual Testing
2. Model Based Testing
3. Mutation Testing
Manual Testing
Manual testing is the approach in which the testing is performed manually. Without
using any automation tools, if testing is performed then such sort of testing is said to be
manual testing.
Generally black box testing, unit testing, integration testing, system testing, acceptance
testing, alpha testing, beta testing are conducted manually without the usage of automation
tools, such testing approaches are said to be manual testing.
The testing methods like fault-injection testing, load testing are conducted with the help
of automation tools. The converse of automation testing is called as manual testing
process.
The only disadvantage with the manual testing is that it takes long time when compared
to the automation testing approach.
Automated versus Manual

S.No Automated Testing Manual Testing

1 No time complexity Greater degree

of time
complexity

2 100% efficiency if We cannot

automated tool is assure for 100%
efficiency efficiency

3 Number of test cases / Number of test

scripts are very high cases are very
less

4 No need of more man More man

power power is needed

5 Cost of testing is high Comparatively

low

6 It is not possible to It is possible to

perform only automated perform only
testing manual testing

7 Accuracy is high Less

8 No complexity in Complexity
reporting of test results encountered in
(Automated) reporting results

9 Modern approach of Traditional

testing Testing
Approach

10 Test case generations Some TC’s may

are effective in the not appear in
automated testing manual testing
activity

These are the various differences between manual and automated approach.
Model Based Testing
Model can be defined as the explanation of system behaviour under applied inputs. The
flow, operations of the system can be easily identified with the help of models. To identify
the behaviour of the system over various circumstances, model is used.
Generally, automated testing approach is used for performing the model based testing.
The diagrammatic representation of the system under test is said to be a model. The model
holds the following information
(1) Transition of the states due to applied inputs.
(2) Control flows
(3) Start and terminate state of the system.
Model based testing is the diagrammatic approach of testing. It is very important and
essential to have a knowledge of UML (Unified Modelling Language).
UML was created by Grady Booch which is used for describing the logic’s of the
system in the diagrammatic approach. It is used to derive the blue-print of the system that
has to be developed.
It’s not actually a programming language rather it is the visual language (logical
diagrammatic representation) of the software system. Using UML standard notations, the
schema or logic of the system can be visually represented.
Needs of UML:
Provides Pictorial representation of system to be developed.
Resolves the complexity problems during software design.
Acts as a blue-print.

The models are represented in any one of the following format

(1) Finite State Machine
(2) State Transition Diagrams
(3) Markov Chains
Finite State Machine
Technically, finite state machine is represented in terms of five objects given below
M = (S, Q0, F0, T, I)
In the above representation of machine(M), S represents the starting state, Q0 is the
initial state, F0 represents final state, T represents transition and I represents set of inputs.
A machine may have many final state but there should be only one initial state.
Final state machines are just a replacements of flow charts. Let the machine be M and I
be the implementation of it. The testing mechanism should conform whether I is the
implementation of M or not.
 By applying the input, if the FSM transition ends at any one of the final state F then the
system is effective, if the system remains without any transition in the middle of the FSM,
then it is in-effective.
The following diagram illustrates the FSM of the ATM System which machine M can
be represented as

M = ({START, READ PIN, VALIDATE PIN, GET WITHDRAW AMOUNT, CHECK

AVAILABILITY, TRANSACTION, ERROR, COMMIT, GENERATE BILL & MONEY,
END}, START, END, T, {PIN, AMOUNT})
Finite State Machine for ATM System:

Generating the test cases

To evaluate the effectiveness of the system, let us generate test cases by any one
of the test case generation technique. Generally, automation tools will construct the
models and generate the test cases.
TC Number PIN V/IV Amount V/IV
1 1234 V 500 V
2 6877 IV – –
3 6666 V 730 IV
The system should go to end state after performing valid and meaningful transitions.
For simplicity the FSM is reconstructed by replacing state name by numbers.
It is very difficult to perform the model based testing manually for complex systems
with large number of input fields.
Simplified FSM:
TC Number Path Taken END
1 1-2-3—5-6-7-8-10 R
2 1-2-3-9-10 R
3 1-2-3-4-5-9-10 R
The above system is designed in effective way because for both valid and invalid input
test cases, it performs transition in a meaningful manner and reaches the end state without
any problems.
The mathematical study of FSM, string acceptance and rejection activities helps the
testers to create and deploy the effective models of the system.
State Chart Diagrams
State chart diagram is the UML diagram which illustrates the flow of the system. Using
standard UML notations, state chart diagrams are drawn. Generally state chart diagram is
the combination of states and events.
The state chart diagram for the credit card processing system is given below.
Mutation Testing
Mutation testing is the approach in which the program statements are changed and the
system effectiveness is measured by applying the test cases. If the program statements are
changed, then the program is said to be mutant (or) mutated program. New test cases are
generated for killing the mutant.
Testing Procedure
(1) Develop the system
(2) Generate the test cases (TC1)
(3) Mutate the code
(4) Generate the test cases for mutant (TC2)
(5) Apply TC1 and TC2
(6) Compare the outputs
(7) IF(TC1 output==TC2 output)
1. Kill the mutant
(8) End
Mutant code creation
 The activity of mutant code creation can be performed by various methods and
techniques. Some of them are
(1) Statement Removal
(2) Condition Changing
(3) Operator Change
(4) Statement Addition
(5) Statement Duplication
(6) Variable change
After generating mutant, test cases are generated to execute both mutant code as
well as original code for identifying the problems.
Statement Removal
One or many statements in the original code is removed. It is also called as statement
deletion operation.
Original Code Mutant Code
int add() int add()
{ {
a=1; a=1;
b=3; a=a+b;
a=a+b; return(a);
return(a); }
}
Condition Changing
Condition changing is the task of replacing the condition operators.
Original Code Mutant Code
if(a>0) if(a<0)
{ {
a=a+1; a=a+1;
b=3; b=3;
a=a+b; a=a+b;
return(a); return(a);
} }
Operator Changing
Mutant code is generated by replacing the operator.
Original Code Mutant Code
if(a>0) if(a<0)
{ {
a=a+1; a=a*1;
} }
Statement Addition
Task of adding additional code to the existing code in order to mutate them is called as
statement addition.
Original Code Mutant Code
if(a>0) if(a<0)
{ {
a=a+1; a=a+1;
b=3; b=3;
a=a+b; a=a+b;
a=a/b;
return(a); return(a);
} }
Statement Duplication
Art of duplicating the already existing statements in the program is called as statement
duplication.
Original Code Mutant Code
if(a>0) if(a<0)
{ {
a=a+1; a=a+1;
b=3; b=3;
b=3;
a=a+b; a=a+b;
return(a); return(a);
} }
Variable Change
Replacement of variable name is called as variable change. Assume that for adding two
numbers, two variables A and B are used. The result is stored in C. Variable mutation
involving changing A or B or C to any other unknown variable X.
Test by yourself
(1) Apply various types of mutation testing :
<?php
$conn=mysql_connect(“localhost”,“root”,“2211”);
$i=69;
while($i<=70)
{
$sql=mysql_query(“Select question from where qid=’$i’”);
$retval = mysql_query( $sql, $conn );
$row=mysql_fetch_assoc($retval);
echo $row[“question”];
}
?>
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘M’)

Testing Name Summary

Manual Testing Execution of testing

operation manually, without
using any automation tools.

Model Based Testing Generating model of the

system to identify system
operations. FSM, Markov
chains, State diagrams are
used.

Mutation Testing Changing some statements

in the original code
(mutating) to evaluate the
performance of the system.

****

14
 Testing Methods
[N]

Introduction:
Under the alphabetical letter ‘N’, there are 2 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Non functional Testing
2. Negative Testing
Non functional Testing
Non functional testing is the converse of functional testing. In the case of functional
testing activity, the functional requirement satisfaction degree is measures whereas the
non-functional testing methodology measures the non-functional features and its
efficiency.
Non functional requirements
The requirements which are not stated by the customer are classified as non-functional
requirements. The developers embed these requirements for better performance of the
system.
Non functional testing involves checking of various non-functional requirements
satisfaction. It is very simple method of testing, with zero degree of complexity.
Quality of the software is increased by this testing.
Testing Primitives
The testing primitives of non-functional requirement include the following
(1) Fault Tolerance Testing
(2) Quality Ensuring
(3) Portability Testing
(4) Degree of effectiveness
(5) Response Time
(6) Compatibility
(7) Cache performance etc.
Real Time Example
Non-functional testing of an online voting system does not involve checking of any
internal logic. The following aspects should be measured.
Fault Tolerance
Checking whether the system is capable to handle the faults.
How the system reacts under critical circumstances?
Response Time
Checking whether the system response time is effective/not.
Whether cache performance, load bearing capacity are effective/not.
Compatibility
Performing the compatibility testing (Refer testing under ‘C’)
Other Non-functional aspects
Checking whether security factors and other non-functional aspects are
implemented in a proper way or not.
Negative Testing
Negative testing is the converse of positive testing. Invalid input handling of the system
is measured using this testing approach.
Testing Procedure
(1) Develop the system
(2) Design the negative (invalid) test cases
(3) Apply the test cases to the system
(4) Measure the system performance
(5) IF(Negative inputs are handled perfectly)
1. Perform further testing
(6) ELSE
1. Reconstruct the system
(7) End
Real Time Example
The figure given below shows the front-end of e-library system. Concentrating the
ISBN Number field, it is only possible to give 13-digit number.
 Under the condition, the negative testing provides the following test cases to the system
Test Case Generation
TC No Test Case Input (ISBN) V/IV
1 34565 IV
2 59A48560495684567 IV
3 SDSA IV
Testing Output
An effective system provide the following output
TC No Test Case Input (ISBN) Output
1 34565 Alert*
2 59A48560495684567 Alert*
3 SDSA Alert*
Alert* - Invalid ISBN number. Check the ISBN.
Test by yourself
(1) Differentiate between functional and non-function testing.
(2) Write the importance of negative test cases.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘N’)

Testing Name Summary

Non functional Checking the non-

Testing functional features of the
system.

Negative Testing Testing the system by

applying negative test
cases.

****

15
Testing Methods
 [O]

Introduction:
Under the alphabetical letter ‘O’, there are 2 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Operational Testing
2. Orthogonal Array Testing
Operational Testing
Operational testing ensures whether the system reached the final state or not. It is a non-
functional testing activity. Before delivering the beta version of the product, the product
readiness to release is measured with the help of operational testing.
Testing Procedure
(1) Develop the system
(2) Perform functional testing
(3) Perform non-functional testing
(4) IF(Efficient)
1. Identify operability aspects;
2. Deliver the system if consistent;
(5) ELSE
1. Redesign the system
Orthogonal Array Testing
Orthogonal array testing is similar to all pair testing approach. OAT approach also uses
the concept of combinations. Generally OAT is a black box testing strategy, which is
suitable for systems with large number of input fields. Tester should have a good
mathematical knowledge to perform orthogonal array testing activity. It is systematic
testing activity.
Testing Procedure
(1) Start
(2) Find out the input fields
(3) Find out possible combination of inputs possible to each field.
(4) Construct orthogonal array
(5) Convert it to test case inputs
 (6) Apply test cases to perform testing
(7) End
Test Case Generation using OATS
Using the concept of OATS, the test case generation involves the following activities.
(1) Finding input fields and possible combination of inputs possible to each
field.
(2) Constructing orthogonal array
(3) Converting them into TC’s
Orthogonal Array Structure
As similar to all pair testing approach, test cases are generated to measure the
efficiency of the system. Here x refers to input fields and y refers to possible values.
Effective and organized test case is generated by this testing approach.
Real Time Example
Consider that a system has 3 input fields with 3 possible combinations of input to each.
Let the input fields be X, Y and Z. The input combinations are {0, 1, 2}.

Level Input(X) Input(Y) Input(Z)

1 0 1 2

2 0 2 1

3 1 0 2

4 1 2 0

5 2 0 1

6 2 1 0

7 0 0 0

8 1 1 1

9 2 2 2

Merits
Enhanced approach of all pairs testing.
OATS uses the concept of permutation and combinations, hence TC’s are
effective.
Demerits
 For complex systems with n input fields (n is large), it is very difficult to
perform OATS.
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘N’)

Testing Name Summary

Operational Testing Checking whether the

system reached final
state/not.

Orthogonal Array TC Generation using

Testing combinations.

****

16
Testing Methods
[P]

Introduction:
Under the alphabetical letter ‘P’, there are 6 different testing methodologies are
available for testing the effectiveness and efficiency of the system. The methodologies are
1. Pair Testing
2. Passive Testing
3. Path Testing
4. Parallel Testing
5. Penetration Testing
6. Performance Testing
Pair Testing
Along with the testers, developers too involve in testing the system in some cases. An
effective pairing of the tester as well as developer is important. In some cases, two/more
testers involve in testing the system. Pairing the testers is also crucial. A good pairing
increases the work flexibility.
Teaming the tester, developer is the main action performed by pair testing. It is not a
black box or white box testing approach. This testing is just a suggestion.
Different types of pairing depend on organization.
Passive Testing
Passive testing is the converse of active testing. Without applying the test cases, the
system efficiency is measured.
Testing Procedure
(1) Start
(2) Develop the system
(3) Check the features of the system
(Without applying test cases)
(4) If(System found to be efficient)
1. Perform further testing
(5) ELSE
1. Reconstruct the system
(6) END
Merits
No need for generating test cases
Simpler approach
Demerits
Passive testing is not an effective method.
No involvement of the tester with the system.
Path Testing
Execution paths of the system are checked for efficiency. Path testing suggests the
testers to design test cases in such a way that it covers all possible paths of execution.
All linearly independent paths should be executed at least once – is the primary goal of
the path testing approach. Generally Control Flow Graphs (CFG’s) are used for identifying
the paths. Path testing is nothing but basic path testing. (Refer Path Coverage – Glass Box
Testing)
Parallel Testing
Parallel testing is the art of testing the sub-components of the system in a parallel
manner in order to reduce the time complexity.
It is applicable for the system which is developed using the modular approach.
Checking each and individual modules in sequential way is inefficient because of the
following reasons.
(1) Time Constraints
(2) Unutilized resources
Time constraints
The time allocated for over all testing activity is very less. Checking the system in a
sequential approach within given time period is not possible for larger systems.
Unutilized resources
An organization does not have only one tester. It consists of n number of testers. If
sequential approach is followed, un-utilization of human and system resources may
encounter.
Testing Procedure
(1) Start
(2) Develop the system
(3) Identify individual modules
(4) Allow testers to test them in concurrent manner
(5) Collect the results of each module.
(6) IF(Effective)
1. Perform further testing.
(7) ELSE
1. Reconstruct the system
(8) END
Real Time Example
Consider a website with the following pages
(1) Home
(2) My Books
(3) Contact Me
(4) Order Now
Sequential Approach
When the testers follow the sequential approach of testing the system the time
complexity is very high. It is shown in the figure given below
Parallel Approach

From the above diagram, we can identify the importance of the passive testing. It saves
the time complexity which is the main problem of the software testing activity.
Penetration Testing
As the name implies, how strong the system security is tested with the help of
penetration testing. How secure the system is from hackers is identified with the help of
penetration testing activity.
Generally penetration testing is performed with the help of automation tools.
Performance Testing
Performance testing measures the performance efficiency of the system under testing.
Performance testing concentrates on both functional as well as non-functional aspects of
the system. Two important categories of performance testing include
(1) Load Testing
(Refer Testing under ‘L’)
(2) Stress Testing
(Refer Testing under ‘S’)
Testing Procedure
(1) Start
(2) Develop the system
(3) Measure the performance
(Functional and non-functional)
(4) Identify degree of efficiency.
(5) IF(Efficient)
1. Perform further testing
 (IF needed)
(6) ELSE
1. Identify the problem.
2. Reconstruct the system.
(7) END
CHAPTER SUMMARY
Software Testing Techniques
(Testing under ‘P’)

Testing Name Summary

Pair Testing Testing method which

concentrates on pairing
tester-tester and tester-
developer.

Passive Testing Converse of active testing

approach. Testing
performed without applying
test cases.

Path Testing Path tracing, identifying

path efficiency.

Parallel Testing Applying the testing for

individual modules
simultaneously in order to
reduce the time complexity.

Penetration Testing Security concern of the

system is tested with the
help of penetration testing
activity.

Performance Testing Functional and non-

functional performance of
the system is tested with
this technique

****
Software Testing Tools – Penetration Testing Tools
 (1) Net Sparker
(2) OWASP ZAP
(3) Core Impact
(4) Ettercap

17
Testing Methods
[Q]

Introduction
Under the alphabetical letter ‘Q’, there is only one testing methodology available
for testing the effectiveness and efficiency of the system. It is called as Qualification
testing.
Qualification Testing
Qualification testing ensures whether the system is qualified by meeting requirement
specifications or not. An audit is conducted in order to measure the qualification attribute
of the system under test. It is a static testing approach. Documentation plays vital role
here.
 18
Other Testing Methods
[R to W]

Testing Name Definition

Ramp Testing Testing performed by

applying critical inputs.
Testing ends when the
system breaks.

Recovery Testing If failure occurs,

whether the system
recovery is possible/not
is measured using this
testing

Smoke Testing Hardware efficiency

checking

System Testing Testing the system as

whole

Stress Testing Applying stress, the

system withstanding
capacity is tested.

Top down integration Testing the modules

Testing from top to bottom.

Usability Testing User convenience is

tested

Unit Testing Refer Component

Testing

UI Testing Front end testing (Refer

API)
White Box Testing Also called Glass Box
Testing (Refer Glass
Box Testing)

Kindly provide your valuable reviews….

Thank you!!
Send your feedbacks to
author.php@gmail.com