Software Testing - Online Guide

CORPORATE TRAINING BOOK - SOFTWARE TESTING - SELENIUM
MANUAL TESTING:
S.NO. TOPICS TITLE PAGE NO.
1
2
OBJECTIVE
FUNDAMENTALS OF TESTING
1
1
2.1 WHAT IS TESTING? 1
2.2 WHO DOES TESTING? 1
2.3 WHEN TO START TESTING? 1
2.4 WHEN TO STOP TESTING? 2
3 WHAT IS SDLC AND STLC? 4
4 VERIFICATION & VALIDATION 10
5 WHAT IS QA, QC AND TESTING? 15
5.1 DIFF. BETWEEN QA, QC AND TESTING 17
6 METHODS OF TESTING 18
6.1 WHITE BOX TESTING 18
6.2 BLACK BOX TESTING 20
6.3 GREY-BOX TESTING 22
6.4 DIFF. BETWEEN THEM 23
7 FUNCTIONAL TESTING 24
7.1 UNIT TESTING 24
7.2 INTEGRATION TESTING 24
7.3 SYSTEM TESTING 26
7.4 REGRESSION TESTING 26
7.5 ACCEPTANCE TESTING 27

7.6 ALPHA TESTING 27
7.7 BETA TESTING 27
8 NON-FUNCTIONAL TESTING 28
8.1 PERFORMANCE TESTING 28
8.2 LOAD TESTING 29
8.3 STRESS TESTING 30
8.4 USABILITY TESTING 31
8.5 SECURITY TESTING 31
8.6 UI VS USABILITY TESTING 32
8.7 PORTABILITY TESTING 33
9 SOFTWARE TESTING DOCUMENTATION 35
9.1 TEST PLAN 35
9.2 TEST SCENARIO 36
9.3 TEST CASE 37
9.4 TRACEABILITY MATRIX 38
10 REAL TIME EXAMPLES (ON JOBSFACTORY.IN
PROJECT)
40
10.1 SDLC AND STLC 40
10.2 VERIFICATION AND VALIDATION 41
10.3 QA, QC AND TESTING 41
10.4 METHODS OF TESTING 42
10.5 FUNCTIONAL TESTING 43
10.6 NON-FUNCTIONAL TESTING 43
10.7 SOFTWARE TESTING DOCUMENTATION 43

AUTOMATION TESTING - SELENIUM:
S. NO. TOPICS TITLE PAGE NO.
11 WHAT IS AUTOMATION TESTING?
46
11.1 WHEN DO WE GO FOR AUTOMATION TESTING? 46
12 AUTOMATION TESTING TOOLS 48
12.1 INTRODUCTION TO SELENIUM 48
12.2 SELENIUM IDE + WEB DRIVER 48
13 SELENIUM-IDE 50
13.1 INTRODUCTION TO SELENIUM IDE 50
13.2 INSTALLING THE IDE &OPENING IDE 50
13.3 IDE FEATURES 51
13.4 BUILDING TEST CASES 51
13.5 RUNNING TEST CASES 51
13.6
USING BASE URL TO RUN TEST CASES IN
DIFFERENT DOMAINS
52
13.7 SELENIUM COMMANDS – “SELENESE” 52
13.8 SCRIPT SYNTAX – RECORD AND PLAYBACK 54
13.9 BREAKPOINTS 54
14 SELENIUM WEBDRIVER 55
14.1 INTRODUCING WEBDRIVER 55
14.2 ADVANTAGES OF SELENIUM 57
15 SETUP FOR SELENIUM 58
15.1 DOWNLOAD AND INSTALL JAVA 58

15.2 DOWNLOAD AND CONFIGURE ECLIPSE 58
15.3 CONFIGURE FIREBUG 58
15.4 CONFIGURE SELENIUM WEBDRIVER 58
16 LOCATORS & LOCATORS USAGE 60
17 GUI OBJECTS 61
18 BASIC OF JAVA 63
18.1 WHAT IS OBJECT ORIENTED PROGRAMMING? 63
18.2 CONTROL STATEMENT 66
19 SELENIUM SCRIPTING 70
19.1 LOGIN PAGE 70
19.2 REGISTRATION PAGE 71
20 BUG TRACKER 75
20.1 INTRODUCTION 75
20.2 REPORT BUGS 75
21 REAL TIME EXAMPLES (ON JOBSFACTORY.IN
PROJECT)
78
21.1 SELENIUM IDE EXAMPLES (ON JOBSFACTORY.IN) 78
21.2 SELENIUM WEBDRIVER EXAMPLES (ON
JOBSFACTORY.IN)
82

Copyrights © 2017 BigSpire Software Private Limited. All Rights Reserved 1
1. OBJECTIVE
The objective of the training manual to understand the techniques in the software testing using
manual and automated options. For automated option Selenium is explained in a detailed format
with real time examples.
2. FUNDAMENTALS OF TESTING
Software Testing Fundamentals (STF) is a platform to gain (or refresh) basic knowledge in the of
Software Testing. If we are to ‘cliche’ it, the site is of the testers, by the testers, and for the testers.
Our goal is to build a resourceful repository of Quality Content on Quality.
2.1 WHAT IS TESTING
Software testing is a process of executing a program or application with the intent of finding the
software bugs. It can also be stated as the process of validating and verifying that a software
program or application or product.
2.2 WHO DOES TESTING
The following professionals are involved in testing a system within their respective capacities
Software Tester
Software Developer(called unit testing)
Project Lead/Manager
End User
Why Software Testing is necessary:
Software testing is really required to point out the defects and errors that were made
Testing is necessary to make sure the product or application is Defect free, as per customer
requirement. Software should be error free and secured
Testing is required for an effective performance of software application or product.
Testing is necessary in order to provide the facilities to the customers like
Delivery of high quality product or software application which requires lower
Maintenance cost and hence results into more accurate.
2.3 WHEN TO START TESTING
Testing can be started from the Requirements Gathering phase and continued till the deployment
of the software. Testing is done in different forms at every phase of SDLC:
During the requirement gathering phase, the analysis and verification of requirements are also
considered as testing.
Reviewing the design in the design phase with the intent to improve the design is also considered
as testing.
Testing performed by a developer on completion of the code is also categorized testing.

2.4 WHEN TO STOP TESTING
The following aspects are to be considered for stopping the testing process:
Testing Deadlines
Completion of test case execution
Completion of functional and code coverage to a certain point
Bug rate falls below a certain level and no high-priority bugs are identified
Test budget has run out
Types of Testing:
1) Manual Testing
2) Automation Testing
What is Manual Testing
Manual testing is the process of manually testing software for defects. It requires a tester to play
the role of an end user and use most of all features of the application to ensure correct behaviour.
Manual testing is a testing process that is carried out manually in order to find defects without the
usage of tools or automation scripting.
Steps for Manual Testing:
1) Understand the functionality of application.
2) Prepare the test plan.
3) Write the test cases and execute on the auto.
4) Verify actual and expected results.
5) Prepare the bug report.
After receiving the modified build from the developer we will go for retesting and regression testing.
These processes are repeated until the bug status is closed.
Examples of Manual Testing:
A) A simple example of testing would be a Login screen
• Checking if Both Username and Password are entered and not blank
• Masking of Password is implemented
• Verifying if screen navigates to next page in case valid Login credentials are provided.
• In case of invalid login, ensuring system does not navigate further but displays an error
message.
• Checking the maximum possible length of login and password fields.
B) Electric bulb Test Cases
• The bulb should be of required shape and size
• Should be able to fitted and removed from the holder
• Should sustain the voltage for which it is designed for

• Should glow on switching on
• Should not glow on switching off
• Should glow with required illumination
• Life of the bulb should meet the requirement

3. WHAT IS SDLC AND STLC
Software Development Life Cycle Overview (SDLC):
SDLC, Software Development Life Cycle is a process used by software industry to design,
develop and test high quality software. The SDLC aims to produce high quality software that meets
or exceeds customer expectations, reaches completion within times and cost estimates.
• SDLC is the acronym of Software Development Life Cycle.
• It is also called as Software development process.
• The software development life cycle (SDLC) is a framework defining tasks performed
At each step in the software development process.
Planning and Requirements Analysis: Establishes a high-level view of the intended project and
determines its goals.
Defining Requirements: Refines project goals into defined functions and operation of the intended
application. Analyzes end-user information needs.
Designing the product architecture: Describes desired features and operations in detail, including
screen layouts, business rules, process diagrams, pseudo code and other documentation.
Building or Developing the Product: The real code is written here.
Testing the Product: Brings all the pieces together into a special testing environment, then checks
for errors, bugs and interoperability.
Deployment in the Market and Maintenance: The final stage of initial development, where the
software is put into production and runs actual business. Changes, correction, additions, move to a
different computing platform and more. This, the least glamorous and perhaps most important step
of all, goes on seemingly forever.
Models of SDLC:
Waterfall Model: All these phases are cascaded to each other in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall
Model". In this model phases do not overlap.

Iterative Model: It is developed to overcome the weaknesses of the waterfall model. It starts with an
initial planning and ends with deployment with the cyclic interactions in between. The basic idea
behind this method is to develop a system through repeated cycles (iterative) and in smaller
portions at a time (incremental), allowing software developers to take advantage of what was
learned during development of earlier parts or versions of the system.
Spiral Model: The spiral model has four phases. A software project repeatedly passes through
these phases in iterations called Spirals. Phases are Identification, Design, Construct or build,
Evolution and risk analysis.
V-Model: The V - model is also known as Verification and Validation model. V - Model is an
extension of the waterfall model and is based on association of a testing phase for each
corresponding development stage. This means that for every single phase in the development
cycle there is a directly associated testing phase. This is a highly disciplined model and next phase
starts only after completion of the previous phase.
Big Bang Model: The Big Bang model is SDLC model where there is no specific process followed.
The development just starts with the required money and efforts as the input, and the output is the
software developed which may or may not be as per customer requirement.
What is Agile: Agile model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements. In agile the tasks are
divided to time boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build
is incremental in terms of features; the final build holds all the features required by the customer.
Here is a graphical illustration of the Agile Model:
Agile thought process had started early in the software development and started becoming popular
with time due to its flexibility and adaptability.

The most popular agile methods include Rational Unified Process (1994), Scrum (1995), Crystal
Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven
Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as agile methodologies, after the Agile Manifesto was published in 2001.
Software Testing Life Cycle Overview (STLC):
1) Normally, testing of any Large Systems will be in TWO parts. The functional verification
and validation against the Requirement Spec and Performance evaluation against the
indicated requirements.
2) Testing activity is involved right from the beginning of the project
3) Some company follows V&V Process model to successfully deliver a project on time
4) This model is followed for a complete project life cycle model
Testing activities in Design phase:
1) Develop Test cases to ensure that product is on par with Requirement Specification
document.
2) Verify Test Cases & test scripts by peer reviews.
3) Preparation of traceability matrix from system requirements
Testing activities in System Testing phase:
1) System test is done for validating the product with respect to client requirements
2) Testing can be in multiple rounds
3) Defect found during system test should be logged into Defect Tracking System for the
purpose of tracking.
4) Test logs and defects are captured and maintained.
5) Review of all the test documents

Testing activities in Integration Testing Phase:
1) This testing is conducted in parallel with integration of various applications (or
components)
2) Testing the product with its external and internal interfaces without using drivers and
stubs.
3) Incremental approach while integrating the interfaces.
Performance Testing:
1) This is done to validate the performance criteria of the product / application.
2) This is non-functional testing
Business Cycle Testing:
1) This refers to end to end testing of real life-like business scenarios.
Testing activities during Release phase:
1) Acceptance testing is conducted at the customer location.
2) Resolves all defects reported by the customer during Acceptance Testing
3) Conduct Root Cause Analysis (RCA) for those defects reported by customer during
acceptance testing
Team Structure:
An effective testing team includes a mixture of members who has
1) Testing expertise
2) Tools expertise
3) Database expertise
4) Domain/Technology expertise
The testing team must be properly structured, with defined roles and responsibilities that allow the
testers to perform their functions with minimal overlap.
There should not be any uncertainty regarding which team member should perform which duties.
The test manager will be facilitating any resources required for the testing team.
Clear Communication protocol should be defined within the testing team to ensure proper
Understanding of roles and responsibilities. The roles chart should contain both on-site and Off-
shore team members.
Roles and Responsibilities:
Test Manager
• Single point contact between Wipro onsite and offshore team
• Prepare the project plan
• Test Management
• Test Planning
• Interact with Wipro onsite lead, Client QA manager

• Team management
• Work allocation to the team
• Test coverage analysis
• Co-ordination with onsite for issue resolution.
• Monitoring the deliverables
• Verify readiness of the product for release through release review
• Obtain customer acceptance on the deliverables
• Performing risk analysis when required
• Reviews and status reporting
Test Lead
1) Resolves technical issues for the product group
2) Provides direction to the team members
3) Performs activities for the respective product group
4) Review and Approve of Test Plan / Test cases
5) Review Test Script / Code
6) Approve completion of Integration testing
7) Conduct System / Regression tests
8) Ensure tests are conducted as per plan
9) Reports status to the Offshore Test Manager
Test Engineer
1) Development of Test cases and Scripts
2) Test Execution
3) Result capturing and analysing
4) Defect Reporting and Status reporting
5)
Testing: It is a process of executing software in a controlled manner, in order to answer the question
“Does the software behave as specified?”
Verification: Says “Are we building the product right?”All QC activities throughout the life cycle that
ensure that interim deliverables meet their input specification.
Validation: Says “Are we building the right product?” The test phase of the life cycle which assures
that the end product meets the user’s needs.
Test Case: “An input operation and the corresponding expected output” in order to test a small unit
of work.
Test Script: “A logical group of test cases which, when taken together, test a particular function or
unit of a system”

Test Bed: “A group of test scripts which, when taken together, test all functions of an entire system”
Audit: An inspection/assessment activity that verifies compliance with plans, policies and
procedures
Baseline: A quantitative measure of the current level of performance
Bug: A catch all term for all software defects or errors
Certification: Acceptance of a software by an authorized agent or its validity been demonstrated to
an authorized agent
Cost of Quality (COQ): Money spent above and beyond expected production costs, this involves
prevention, appraisal, internal & external failure costs
Cyclomatic Complexity: The number of decision statements plus one.
Defect: It is “A deviation from specification or standard” or “Anything that causes customer
dissatisfaction”.
Desk Check: Verification technique conducted by the author of the artifact to verify the
completeness.
Dynamic Assertion: A dynamic analysis technique that inserts into the program code assertions
about the relationship between program variables
Force field Analysis: A group technique used to identify both driving and restraining forces that
influence a current situation
Inspection: A formal assessment of a work product conducted by one or more qualified independent
reviewers to detect defects, violation of development standards, etc. Inspection identifies defects but
does not attempt to correct them.

4. VERIFICATION AND VALIDATION
V-Model:
V-Model means Verification and Validation. Verification and Validation are very widely and
commonly used terms. Most of the times we consider the terms same, but actually the terms are
quite different.
Advantages of V-model:
Testing activities like planning, test designing happens well before coding.
This saves a lot of time. Hence higher chance of success over the waterfall model.
Proactive defect tracking – that is defects are found at early stage.
Avoids the downward flow of the defects.
Works well for small projects where requirements are easily understood.
Simple and easy to use.
Disadvantages of V-model:
Very rigid and least flexible.

Software is developed during the implementation phase, so no early prototypes of the software are
produced.
If any changes happen in midway, then the test documents along with requirement documents has
to be updated.
When to use the V-model:
The V-shaped model should be used for small to medium sized projects where requirements are
clearly defined and fixed.
The V-Shaped model should be chosen when ample technical resources are available with needed
technical expertise.
A. Verification: Are we building the product right?
Verification focuses on 'Find defects as early as possible'.
Verification is the process of evaluating work-products of a development phase to determine
whether they meet the specified requirements. Verification ensures that the product is built
according to the requirements and design specifications.
Verification testing can be best demonstrated using V-Model. The examples such as test Plans,
requirement specification, design, code and test cases are evaluated.
Verification is done at the starting of the development process. It includes reviews and meetings,
walkthroughs, inspection, etc. to evaluate documents, plans, code, requirements and
specifications.
Example:
Suppose you are building a table. Here the verification is about checking all the parts of the table,
whether all the four legs are of correct size or not. If one leg of table is not of the right size it will
imbalance the end product. Similar behaviour is also noticed in case of the software product or
application. If any feature of software product or application is not up to the mark or if any defect is
found then it will result into the failure of the end product. Hence, verification is very important. It
takes place at the starting of the development process.
Advantages of Verification:
• Filter is applied at every stage during SDLC to 'purify' the application as it Progresses.
• Verification helps in identifying not only the presence of defects but also their location.
• Defects can get detected even before they get coded or tested.
• It helps to identify and remove issues early.
Verification is also known as static testing as software application is not actually used or executed
but the documents or code is checked statically to find the defects.
B. Validation: Are we building the right product
The process of evaluating software during the development process or at the end of the
development process to determine whether it satisfies specified business requirements.
Validation Testing ensures that the product actually meets the client's needs. It can also be defined
as to demonstrate that the product fulfils its intended use when deployed on appropriate
environment.
Validation testing can be best demonstrated using V-Model.

The Software/product under test is evaluated during this type of testing.
1) Unit Testing:
What is Unit?
The smallest piece of software that can be tested in isolation to verify its behaviour.
Who does it?
• It is actually done by developers.
• What is its purpose?
• Ensures that the code meets the requirements.
• Unit testing only tests the functionality of the units themselves.
Benefits:
• Faster error detection – Unit testing tests smaller amounts of code making it easy to find
errors.
• Easy to isolate errors – As small pieces of code are tested at one go.
• Faster development– less time spent in debugging.
2) Integration Testing:
Integration testing is the phase in software testing in which individual software modules are
combined and tested as a group. It occurs after unit testing and before validation testing.
Also after integrating two different components together we do the integration testing. As displayed
in the image below when two different modules ‘Module A’ and ‘Module B’ are integrated then the
integration testing is done.
Integration testing is done by a specific integration tester or test team.
Integration testing follows two approach known as ‘Top Down’ approach and ‘Bottom Up’ approach
as shown in the image below:

3) System Testing:
In system testing the behaviour of whole system/product is tested. Validates that the system meets
its functional and non-functional requirements.
System testing is always done by a Tester.
4) User Acceptance Testing:
User acceptance testing (UAT) is the last phase of the software testing process.
During UAT, actual software users test the software to make sure it can handle required tasks in
real-world scenarios, according to specifications.
User acceptance is performed by customers and end users.
Validation is also known as Dynamic Testing as the application is actually uses to test and find the
defects.
Advantages of Validation:
During verification if some defects are missed then during validation process it can be caught as
failures.
If during verification some specification is misunderstood and development had happened then
during validation process while executing that functionality the difference between the actual result
and expected result can be understood.
Validation is done during testing like feature testing, integration testing, system testing, load testing,
compatibility testing, stress testing, etc.
Validation helps in building the right product as per the customer’s requirement and helps in
satisfying their needs.
Example of verification and validation are explained below:
Suppose we have the specifications related to the project than by checking that specifications
without executing to see whether the specifications are up to the mark or not is what we have done
in verification.
Similarly Validation of the software is done to make sure that the software always meets the
requirements of the customer by executing the specifications of the project and product.
Difference between Verification and Validation:
Verification Validation
1. Verification is a static practice of
verifying documents, design, code and
program.
1. Validation is a dynamic mechanism of validating and
testing the actual product.
2. It does not involve executing the code. 2. It always involves executing the code.
3. It is human based checking of
documents and files.
3. It is computer based execution of program.

4.Verification uses methods like
inspections, reviews, walkthroughs, and
Desk-checking etc.
4.Validation uses methods like black box (functional)
testing, gray box testing, and white box (structural)
testing etc.
5. Verifications to check whether the
software conforms to specifications.
5. Validation is to check whether software meets the
customer expectations and requirements.
6. It can catch errors that validation
cannot catch. It is low level exercise.
6. It can catch errors that verification cannot catch. It is
High Level Exercise.
7.Target is requirements specification,
application and software architecture, high
level, complete design, and database
design etc.
7. Target is actual product-a unit, a module, a bent of
integrated modules, and effective final product.
8. Verification is done by QA team to
ensure that the software is as per the
specifications in the SRS document.
8. Validation is carried out with the involvement of
testing team.

5. WHAT IS QA, QC AND TESTING
What is Quality:
Quality is meeting the requirement, expectation and needs of the customer being free from defects,
lacks and substantial variants.
Consistently meeting customer needs in terms of
1) Requirements
2) Cost
3) Delivery Schedule
4) Service
What is Assurance:
It means giving a positive declaration on a product which obtains confidence/guarantee for the
outcome.
It gives a security that the product will work without any glitches as per the expectations.
The definition of assurance is an affirmation and commitment.
Example: Assurance about the software or product to the customer.
What is Quality Assurance (QA):
The Monitoring and Measuring the strength of development process is called as QA. Quality
Assurance is known as QA and focuses on preventing defect. Quality Assurance ensures that the
approaches, techniques, methods and processes are designed for the projects are implemented
correctly.
Quality assurance activities monitor and verify that the processes used to manage and create the
deliverables have been followed and are operative.
Quality Assurance is a proactive process and is Prevention in nature. It recognizes flaws in the
process. Quality Assurance has to complete before Quality Control.
It is a defect prevention activity.
Example: Reviews and Audits.
Reviews: Management Review is also known as Software Quality Assurance or (SQA). It focuses
more on the software process rather than the software work products.
Audits: It is a systematic process to determine how the actual testing process is conducted within
an organization or a team.
1. Internal Audits: Work within an organization and report to its audit committee and/or
directors. They help to design the company’s organizing systems and help develop specific risk
management policies.
2. External Audits: Are independent of the organization they are auditing. They are port to the
company’s shareholders. They provide their experienced opinion on truthfulness of the company’s
financial statements and perform work on a test basis to monitor systems in place.
What is Quality Control (QC):
• The validation of final product before release to the customer is called QC.
• Quality Control is known as QC and focuses on identifying defect.

• Attempts to test a product after it is built.
• If expected behaviour is not the same ads actual, fixes the product and rebuilds it.
• Defect-detection and defect-correction oriented.
• Example: Software testing at various levels (Functional and Non-functional testing)
What is Testing:
It involves identifying bug/error/defect in software without correcting it. Normally professionals with
a quality assurance background are involved in bug’s identification. Testing is performed in the
testing phase.
Software testing is a process of executing a program or application with the intent of finding the
software bugs.
It can also be stated as the process of validating and verifying that a software program or
application or product:
• Meets the business and technical requirements that guided it’s design and development
• Works as expected
• Can be implemented with the same characteristic.
• Focuses on actual testing.
1. Static Testing: It can test and find defects without executing code. Static Testing is done during
verification process. This testing includes reviewing of the documents (including source code) and
static analysis. This is useful and cost effective way of testing. For example: reviewing,
walkthrough, inspection, etc.
2. Dynamics Testing: In dynamic testing the software code is executed to demonstrate the result of
running tests. It’s done during validation process. For example: unit testing, integration testing and
system testing etc.
What is Debugging:
It involves identifying, isolating, and fixing the problems/bugs.
Developers who code the software conduct debugging upon encountering an error in the
Debugging is a part of White Box Testing or Unit Testing. Debugging can be performed in the
development phase while conducting Unit Testing or in phases while fixing the reported bugs.

Debugging is the process of locating and fixing or bypassing bugs (errors) in computer program
code.
5.1 DIFF. BETWEEN QA, QC AND TESTING
Many people think QA and QC are same and interchangeable but this is not true. Both are tightly
linked and sometimes it is very difficult to identify the differences. Fact is both are related to each
other but they are different in origins. QA and QC both are part of Quality Management however
QA is focusing on preventing defect while QC is focusing on identifying the defect.
Quality Assurance Quality Control Testing
Process oriented Product oriented Product oriented activities
Defect preventive
activities.
It is a detection and corrective
process.
It is a preventive process.
Checking the process Evaluating the product is meeting
requirement or not
Focuses on actual testing.
QA includes activities
that ensure the
implementation of
processes, procedures
and standards in
context to verification
of developed software
and intended
requirements.
It includes activities that ensure
the verification of a developed
software with respect to
documented (or not in some
cases) requirements.
It includes activities that ensure the
identification of bugs/error/defects
in software.
QA means Planning
for doing a process.
QC Means Action for executing
the planned process.
Testing means executing software
and finding defects.
All team members are
responsible for QA.
Testing team is responsible for
QC.
Testing team is responsible for QC.
QA does not involve
executing the
program.
QC always involves executing the
program.
Testing always involves executing
the program.
QA e.g. Verification. QC e.g. Validation. Testing e.g. Validation.

6. METHODS OF TESTING
6.1 WHITE BOX TESTING
White-box testing is the detailed investigation of internal logic and structure of the code. White-box
testing is also called glass testing or open-box testing. In order to perform white-box testing on an
application, a tester needs to know the internal workings of the code.
The tester needs to have a look inside the source code behaving inappropriately.
Steps to perform White box testing:
Step 1 – Understand the functionality of the application through its source code. Having said that, it
simply means that the tester must be well versed with the programming language and other tools
and techniques used to develop the software.
Step 2 – Create the tests and execute them.
When we discuss about testing, “coverage” is the most important factor. Here I will explain how to
have maximum coverage in the context of White box testing.
Types of white box testing:
There are different types and different methods for each white box testing type. See below image.
The three main White box testing Techniques are:
• Statement Coverage
• Branch Coverage
• Path Coverage
Let’s understand these techniques one by one with a simple example.
1) Statement coverage:
In programming language, statement is nothing but the line of code or instruction for the computer
to understand and act accordingly. A statement becomes an executable statement when it gets
compiled and converted into the object code and performs the action when the program is in
running mode.

Hence “Statement Coverage”, as the name suggests, is the method of validating that each and
every line of code is executed at least once.
2) Branch Coverage:
“Branch” in programming language is like the “IF statements”. If statement has two branches: true
and false.
So in Branch coverage (also called Decision coverage), we validate that each branch is executed at
least once.
In case of a “IF statement”, there will be two test conditions:
• One to validate the true branch and
• Other to validate the false branch
Hence in theory, Branch Coverage is a testing method which when executed ensures that each
branch from each decision point is executed.
3) Path Coverage:
Path coverage tests all the paths of the program. This is a comprehensive technique which ensures
that all the paths of the program are traversed at least once. Path Coverage is even more powerful
that Branch coverage. This technique is useful for testing the complex programs.
Let’s take a simple example to understand all these white box testing techniques.
White box testing example
1) INPUT A & B
2) C = A + B
3) IF C>100
4) PRINT “IT’S
5) DONE”
For Statement Coverage – we would need only one test case to check all the lines of code.
If I consider TestCase_01 to be (A=40 and B=70), then all the lines of code will be executed
Now the question arises:
Is that sufficient?
What if I consider my Test case as A=33 and B=45?
Because Statement coverage will only cover the true side, for the pseudo code, only one test case
would NOT be sufficient to test it. As a tester, we have to consider the negative cases as well.
Hence for maximum coverage, we need to consider “Branch Coverage”, which will evaluate the
“FALSE” conditions.
In real world, you may add appropriate statements when condition fails.
So now the pseudo code becomes:
1) INPUT A & B
2) C = A + B

3) IF C>100
4) PRINT “IT’S DONE”
5) ELSE
6) PRINT “IT’S PENDING”
Since Statement coverage is not sufficient to test the entire pseudo code, we would require Branch
coverage to ensure maximum coverage.
So for Branch coverage, we would require two test cases to complete testing of this pseudo code.
TestCase_01: A=33, B=45
TestCase_02: A=25, B=30
With this, we can see that each and every line of code is executed at least once.
Here are the conclusions so far:
• Branch Coverage ensures more coverage than Statement coverage
• Branch coverage is more powerful than Statement coverage,
• 100% Branch coverage itself means 100% statement coverage,
• 100 % statement coverage does not guarantee 100% branch coverage
Now let’s move on to the Path Coverage:
As said earlier, Path coverage is used to test the complex code snippets, which basically involves
loop statements or combination of loops and decision statements.
Consider this pseudo code:
1) INPUT A & B
2) C = A + B
3) IF C>100
4) PRINT “IT’S DONE”
5) END IF
6) IF A>50
7) PRINT “IT’S PENDING”
8) END IF
6.2 BLACK BOX TESTING
The technique of testing without having any knowledge of the interior workings of the application is
called black-box testing. The tester is oblivious to the system architecture and does not have
access to the source code. Typically, while performing a black-box test, a tester will interact with
the system's user interface by providing inputs and examining outputs without knowing how and
where the inputs are worked upon.
Tools used for Black Box testing:

Black box testing tools are mainly record and playback tools. These tools are used for regression
testing that to check whether new build has created any bug in previous working application
functionality. These record and playback tools records test cases in the form of some scripts like
TSL, VB script, Java script, Perl.
Advantages of Black Box Testing
• Tester can be non-technical.
• Used to verify contradictions in actual system and the specifications.
• Test cases can be designed as soon as the functional specifications are
Complete
Disadvantages of Black Box Testing
• The test inputs needs to be from large sample space.
• It is difficult to identify all possible inputs in limited testing time. So writing test cases is
slow and difficult
• Chances of having unidentified paths during this testing
Methods of Black box Testing:
• Graph Based Testing Methods:
Each and every application is build-up of some objects. All such objects are identified
and graph is prepared. From this object graph each object relationship is identified and
test cases written accordingly to discover the errors.
• Error Guessing:
This is purely based on previous experience and judgment of tester. Error Guessing is
the art of guessing where errors can be hidden. For this technique there are no specific
tools, writing the test cases that cover all the application paths
• Boundary Value Analysis:
Many systems have tendency to fail on boundary. So testing boundary values of
application is important. Boundary Value Analysis (BVA) is a test Functional Testing
technique where the extreme boundary values are chosen. Boundary values include
maximum, minimum, just inside/outside boundaries, typical values, and error values.
• Extends equivalence partitioning:
Test both sides of each boundary
Look at output boundaries for test cases too
Test min, min-1, max, max+1, typical values
BVA techniques:
• Number of variables
For n variables: BVA yields 4n + 1 test case.
• Kinds of ranges
Generalizing ranges depends on the nature or type of variables

Advantages of Boundary Value Analysis:
• Robustness Testing – Boundary Value Analysis plus values that go beyond the limits
• Min – 1, Min, Min +1, Nom, Max -1, Max, Max +1
• Forces attention to exception handling
Limitations of Boundary Value Analysis:
Boundary value testing is efficient only for variables of fixed values i.e. boundary.
Equivalence partitioning is a black box testing method that divides the input domain of a program
into classes of data from which test cases can be derived.
6.3 GREY BOX TESTING
Grey-box testing is a technique to test the application with having a limited knowledge of the
internal workings of an application. In software testing, the phrase the more you know, the better
carries a lot of weight while testing an application.
In the Gray box testing tester is usually has knowledge of limited access of code and based on
this knowledge the test cases are designed and the software application under test treat as a black
box & tester test the application from outside. Don’t confuse with White box &Gray box, as in the
Gray box testing is tester doesn’t have the knowledge in detailed. Also the Gray box testing is not a
black box testing method because the tester knows some part of the internal structure of code. So
Gray Box Testing approach is the testing approach used when some knowledge of internal
structure but not in detailed.
The name is comes because the application for tester is like a gray box like a transparent box and
tester see inside it but not fully transparent & can see partially in it. As tester doesn’t require the
access to code the gray box testing is known as unbiased & non-intrusive.
To test the Web Services application usually the Gray box testing is used.
Gray Box Testing Example:
We will take example of web application testing. To explore gray testing will take a simple
functionality of web application. You just want to enter email id as input in the web form & upon
submitting the valid email id user & based on users interest (fields entered) user should get some
articles over email. The validation of email is using Java Script on client side only. In this case if
tester doesn’t knows the internal structure of the implementations then you might test the web
application of form with some cases like Valid Email Id, Invalid Email ID & based on this will check
whether functionality is working or not.
But tester is aware of some internal structure & if system is making the assumptions like
• System will not get Invalid email ID
• System will not send email to invalid email ID
• System will not receive failure email notifications.
In this type of testing you have to test the application by disabling the Java Script, it might be
possible due to any reason Java Script is failed & System get Invalid email to process & all
assumptions made by system will failed, as a result incorrect inputs are send to system, so
• System will get Invalid email ID to process
• System will send email to invalid email ID

• System will receive failure email notifications.
6.4 DIFF. BETWEEN THEM
BLACK BOX TESTING GREY BOX TESTING WHITE BOX TESTING
1. The internal workings
of an application are not
required to be known.
1. Somewhat knowledge of internal
workings are known.
Tester has the full knowledge of
the internal workings of an
application.
2. Also known as closed
box testing, data driven
testing and functional
testing.
2. Another term of grey box testing
is translucent testing as the tester
has the limited knowledge of the
insides of the application.
2. Also known as clear box testing,
structural testing and code based
testing.
3. Performed by end
users and also by
testers and developers.
3. Performed by end users and
also by testers and developers.
3. Normally done by testers and
developers.
4. Testing is based on
external expectations.
Internal behaviour of an
application is unknown.
4. Testing is done on the basis of
high-level database diagrams and
dataflow diagrams.
4. Internal workings are fully known
and the tester can design test data
accordingly.
5. This is the least time
consuming and
exhaustive.
5. Partly time consuming and
exhaustive.
5. The most exhaustive and time
consuming type of testing.
6. Not suited to
algorithm testing.
6. Not suited to algorithm testing. 6. Suited for algorithm testing.
7. This can only be done
by trial and error
method.
7. Data domains and internal
boundaries can be tested if known.
7. Data domains and internal
boundaries can be better tested.

7. FUNCTIONAL TESTING
This is a type of black-box testing that is based on the specifications of the software that is to be
tested. The application is tested by providing input and then the results are examined that need to
conform to the functionality it was intended for. Testing team concentrates on customer
requirements in terms of functionality. It is a process of verifying whether product meets its design
and functional specifications.
7.1 UNIT TESTING
Unit – smallest testable piece of software
Unit testing is a procedure used to validate that individual unit of source code is working
properly
Test the functionality of units
Typically done by the developers and not by testers.
It is typically used to verify control flow, data flow and memory leak problems.
Example: Whether loop or statement in a program is working properly or not than
This is called as unit testing. Tests that are performed during the unit testing are explained below:
1) Module Interface test: In module interface test, it is checked whether the
information is properly flowing in to the program unit (or module) and properly happen
out of it or not.
2) Local data structures: These are tested to inquiry if the local data within the
3) module is stored properly or not.
4) Boundary conditions: It is observed that much software often fails at boundary related
conditions. That’s why boundary related conditions are always tested to make safe that the
program is properly working at its boundary condition’s.
5) Independent paths: All independent paths are tested to see that they are properly
executing their task and terminating at the end of the program.
6) Error handling paths: These are tested to review if errors are handled properly by the or
not.
7.2 INTEGRATION TESTING
1) Integration testing is defined as the testing of combined parts of an application to determine
if they function correctly.
2) Integration is a process of combining and testing multiple components together.
3) Integration testing can be done in two ways: Bottom-up integration testing and Top Down
integration testing.
Bottom-up integration testing:
• Process of testing the very lowest layers of software first is called the bottom up approach
• Program is tested from bottom to top
• In this approach, programmers use a temporary program instead of main program, which is
under construction.

• The temporary program is called Driver or calling program
(Under Construction)
Top-down integration testing:
Process of testing the top most layers of software first is called the top down approach.
Program is tested from top to down.
In this approach, programmers use a temporary program instead of main program, which is under
construction.
The temporary program is called Stubs or called program
(UC)
MAIN
SUB1 SUB2
DRIVER
MAIN
SUB1
SUB2
STUB

Hybrid integration testing:
Also known as sandwich approach, this is a combination of Top-down and Bottom up approach
process.
Its need big team
7.3 SYSTEM TESTING
System testing tests the system as a whole. Once all the components are integrated, the
application as a whole is tested rigorously to see that it meets the specified Quality Standards.
System testing is classified into 3 levels as
Usability testing:
1) Also, called as accessibility testing
2) To check the ease is to understand the application and process execution for
the user
3) Usability testing consist s of two sub-techniques:
• User-Interface Testing:
• Manual Support Testing:
Functional Testing(Back-box testing)
1) Testing team concentrates on customer requirements in terms of functionality.
2) Concentrating on requirements correctness and completeness.
3) This testing is classified into 2 sub tests as follows
• Sanity Testing:
• Smoke Testing:
Non- Functional Testing
In non-functional testing the quality characteristics of the component or system tested.
Example: How many people can log in at once
7.4 REGRESSION TESTING
Whenever a change in a software application is made, it is quite possible that other areas within
the application have been affected by this change.
Whenever a change in a software application is made, it is quite possible that other areas within
the application have been affected by this change.
When you fix one bug, you introduce several newer bugs.
Ensure that a bug is fixed without any side effects are called regression testing.
Regression testing is required when there is a change in requirement and code is modified
according to the requirement
Defect fixing
Performance issue fixed

New feature is added in the software
7.5 ACCEPTANCE TESTING
Both tester and developers are involved
Done with user
After completion of system testing, the project management concentrates on
UAT to collect feedback from real customer or model customer.
There are 2 ways to conduct UAT
7.6 ALPHA TESTING
This test is the first stage of testing and will be performed amongst the teams (developer and
QA teams).
Performed by end users inside the development organization
Done in controlled environment
Defect found by end users are noted down by the development team and fixed before
release
Developers are present
During this phase, the following aspects will be tested in the application:
1) Spelling Mistakes
2) Broken Links
3) Cloudy Direction
The Application will be tested on machines with the lowest specification to test loading times and
any latency problems.
7.7 BETA TESTING
Performed by end users outside the development organization and inside the end user
organization.
Environment is not under control & Developers are not present
Defect found by end user are reported to the development organization
Beta testing is also known as pre-release testing
Users will install, run the application and send their feedback to project team.

8. NON-FUNCTIONAL TESTING
Non-functional testing is the testing of a software application or system for its non- functional
requirements: the way a system operates, rather than specific behaviours of that system
Performance Testing
Load Testing
Stress Testing
Usability Testing
Security Testing
UI Vs Usability Testing
Compatibility Testing
8.1 PERFORMANCE TESTING
Term often used interchangeably with ‘load’ and ‘stress’ testing
Performance testing is designed to test run-time performance of software within the context
of an integrated system.
Performance metrics
Base set of metrics
S. No Performance metrics Category
1
Processor Processor utilization
2
Process Memory consumption
Processor utilization
Process recycles
3
Memory Memory available
Memory utilization
4
Disk Disk utilization
5
Network Network utilization
6
Transactions/business metrics Transactions/sec
Transactions succeeded

Transactions failed
Orders succeeded
Orders failed
7
Threading Contentions per second
Deadlocks
Thread allocation
8
Response times Transactions times
Some Performance Testing Tools:
Tools Requirement
Nmap Linux, Windows, and
Mac OS X.
Nsiqcppstyle Platform Independent
Oedipus OS Independent
Zed Attack Proxy Windows, Linux, Mac
OS
Performance Testing:
Rational Quantify
True time
Web Testing:
Silk Test
Astra Quick Test
eTest Suite
8.2 LOAD TESTING
Testing application under heavy loads, such as Testing of websites under range of loads To
determine at what point the system’s response time degrades or fails
Step 1 - Identify performance acceptance criteria

Step 2 - Identify key scenarios
Step 3 - Create a workload model
Step 4 - Identify the target load levels
Step 5 - Identify metrics
Step 6 - Design specific tests
Step 7 - Run tests
Step 8 - Analyze the results
Examples with ATM Functionality:
• Response time. For example, the product catalogue must be displayed in less than 3
seconds.
• Throughput. For example, the system must support 100 transactions per second.
• Resource utilization. A frequently overlooked aspect is the amount of resources your
application is consuming, in terms of processor, memory, disk input output (I/O), and
network I/O.
• Maximum user load. This test objective determines how many users can run on a
specific hardware configuration.
• Business related metrics. This objective is mapped to business volume at normal and
peak values; for example, the number of orders or Help desk calls handled at a given
time.
Resource-intensive scenarios can be identified by using design documents or the actual code
implementation. The primary resources are:
• Processor
• Memory
• Disk I/O
• Network I/O
Once they have been identified, you will use these key scenarios to create workload profiles
and to design load tests.
8.3 STRESS TESTING
Designed to confront programs with abnormal situations.
It executes a system in a manner that demands resources in abnormal quantity, frequency or
volume.
Examples With ATM Functionality:
Special tests may be designed that generate 10 interrupts per second, when one or two is the
average rate.
Input data rates may be increased by an order of magnitude to determine how input functions will
respond.
Test cases that require maximum memory or other resources may be executed.

8.4 USABILITY TESTING
Evaluates the ease of Using and learning the system and system user documents by the
end users
Evaluates the effectiveness of system functioning in supporting User tasks and ability to
recover from User’s errors
In usability testing basically the testers tests the ease with which the user interfaces can be
used. It tests that whether the application or the product built is user-friendly or not.
Usability Testing is a black box testing technique.
Usability testing also reveals whether users feel comfortable with your application
or Web site according to different parameters– the flow, navigation and layout,
speed and content– especially in comparison to prior or similar applications.
Usability Testing tests the following features of the software.
• How easy it is to use the software.
• How easy it is to learn the software.
• How convenient is the software to end user.
Usability testing includes the following five components:
• Learn ability: How easy is it for users to accomplish basic tasks the first time they encounter
the design?
• Efficiency: How fast can experienced users accomplish tasks?
• Memo ability: When users return to the design after a period of not using it, does the user
remember enough to use it effectively the next time, or does the user have to start over
again learning everything?
• Errors: How many errors do users make, how severe are these errors and how
easily can they recover from the errors?
• Satisfaction: How much does the user like using the system?
Benefits of usability testing to the end user or the customer:
• Better quality software
• Software is easier to use
• Software is more readily accepted by users
• Shortens the learning curve for new users
8.5 SECURITY TESTING
Attempts to verify that protection mechanisms built into a system will in fact protect it from improper
logins.
The tester plays the role of an individual who desires to hack the system.

The role of the system designer is to make the cost of hacking greater than the value of the
information that will be obtained.
Discovery: The purpose of this stage is to identify systems within scope and the services in use. It
is not intended to discover vulnerabilities, but version detection may highlight deprecated versions
of software / firmware and thus indicate potential vulnerabilities.
Vulnerability Scan: Following the discovery stage this looks for known security issues by using
automated tools to match conditions with known vulnerabilities. The reported risk level is set
automatically by the tool with no manual verification or interpretation by the test vendor. This can
be supplemented with credential based scanning that looks to remove some common false
positives by using supplied credentials to authenticate with a service (such as local windows
accounts).
Vulnerability Assessment: This uses discovery and vulnerability scanning to identify security
vulnerabilities and places the findings into the context of the environment under test. An example
would be removing common false positives from the report and deciding risk levels that should be
applied to each report finding to improve business understanding and context.
Security Assessment: Builds upon Vulnerability Assessment by adding manual verification to
confirm exposure, but does not include the exploitation of vulnerabilities to gain further access.
Verification could be in the form of authorised access to a system to confirm system settings and
involve examining logs, system responses, error messages, codes, etc. A Security Assessment is
looking to gain a broad coverage of the systems under test but not the depth of exposure that a
specific vulnerability could lead to.
Penetration Test: Penetration test simulates an attack by a malicious party. Building on the
previous stages and involves exploitation of found vulnerabilities to gain further access. Using this
approach will result in an understanding of the ability of an attacker to gain access to confidential
information, affect data integrity or availability of a service and the respective impact. Each test is
approached using a consistent and complete methodology in a way that allows the tester to use
their problem solving abilities, the output from a range of tools and their own knowledge of
networking and systems to find vulnerabilities that would/ could not be identified by automated
tools. This approach looks at the depth of attack as compared to the Security Assessment
approach that looks at the broader coverage.
Security Audit: Driven by an Audit / Risk function to look at a specific control or compliance issue.
Characterised by a narrow scope, this type of engagement could make use of any of the earlier
approaches discussed (vulnerability assessment, security assessment, penetration test).
Security Review: Verification that industry or internal security standards have been applied to
system components or product. This is typically completed through gap analysis and utilises build /
code reviews or by reviewing design documents and architecture diagrams. This activity does not
utilise any of the earlier approaches (Vulnerability Assessment, Security Assessment, Penetration
Test, Security Audit)
8.6 UI VS USABILITY TESTING
Testing that purposely subjects a system (both hardware and software) to a series of tests
where the volume of data being processed is the subject of the test. Such systems can be
transactions processing systems capturing real time sales or could be database updates
and or data retrieval.
Volume testing will seek to verify the physical and logical limits to a system's capacity and
ascertain whether such limits are acceptable to meet the projected capacity of the
organization's business processing.

List of GUI testing tools
Name
Supported platforms (testing
system)
Supported platforms (tested
system)
QF-Test Windows, Linux
Java/Swing/SWT/Eclipse, JavaFX,
Web applications
Ranorex Windows, iOS, Android Unknown
Rational Functional
Tester
Windows, Linux Windows, Swing, .NET, HTML
Robot Framework Unknown Unknown
8.7 COMPATIBILITY TESTING
The goal of globalization testing is to detect potential problems in application design that
could inhibit globalization. It makes sure that the code can handle all international support
without breaking functionality that would cause either data loss or display problems.
Globalization testing checks proper functionality of the product with any of the
culture/locale settings using every type of international input possible
There are four testing attributes included in portability testing. The ISO 9126
(1991)standard breaks down portability testing attributes as Install ability,
Compatibility, Adaptability and Replace ability. The ISO 29119 (2013) standard
Describes Portability with the attributes of Compatibility, Install ability, Interoperability and
Localization testing.
Adaptability testing- Functional test to verify that the software can perform all of its intended
behaviours in each of the target environments. Using communication standards, such as HTML
can help with adaptability. Adaptability may include testing in the following areas: hardware
dependency, software dependency, representation dependency, standard language conformance,
dependency encapsulation and/or text convertibility.
Compatibility/ Co-existence- Testing the compatibility of multiple, unrelated software systems to co-
exist in the same environment, without effecting each other’s behavior.This is a growing issue with
advanced systems, increased functionality and interconnections between systems and subsystems
who share components. Components that fail this requirement could have profound effects on a
system.
For example, if 2 sub-systems share memory or attack, an error in one could propagate to the
other and in some cases cause complete failure of the entire system.
Install ability testing- Installation software is tested on its ability to effectively install the target
software in the intended environment.Installability may include tests for: space demand, checking
prerequisites, installation procedures, completeness, installation interruption, customization,
initialization, and/or reinstallation.
Interoperability testing- Testing the capability to communicate, execute programs, or transfer data
among various functional units in a manner that requires the user to have little or no knowledge of
the unique characteristics of those units
Localization testing- Localization is also known as internationalization. Its purpose is to test if the
software can be understood in using the local language where the software is being used

Replace ability testing- Testing the capability of one software component to be replaced by another
software component within a single system. The system, in regards to the replaced component,
should produce the same results that it produced before the replacement. The issues for
adaptability also apply for replace ability, but for replace ability you may also need to test for data
load-ability and/or convertibility.

9. SOFTWARE TESTING DOCUMENTATION
Testing documentation involves the documentation of artefacts that should be developed
before or during the testing of Software.
Documentation for software testing helps in estimating the testing effort required, test coverage,
requirement tracking/tracing, etc. This section describes some of the commonly used documented
artefacts related to software testing such as:
Test Plan
Test Scenario
Test Case
Traceability Matrix
9.1 TEST PLAN
A test plan will be used to test an application, the resources that will be used, the test environment
in which testing will be performed, and the limitations of the testing and the schedule of testing
activities. Typically the Quality Assurance Team Lead will be responsible for writing a Test Plan.
A test plan includes the following:
• Test plan identifier
• Introduction
• Test scope
• Test objective
• Risk analysis
• Strategy
• Features to be tested
• Roles and responsibilities
• Entry Criteria
• Exit Criteria
• Document Control
Test plan identifier:
Unique identifier with version number. can also be called as a document number.
Introduction :
Overview of software application. Purpose of this document.
Test scope:
Test scope defines the extent of testing.

Test objective:
Defines the testing goal.
Risk analysis:
Document possible risks during testing activates and their estimated impact on the test effort and
schedule. Example – defects not getting fixed on time.
Strategy :
Methods to be used – Black box /White box .
Levels of testing in scope – Unit , integration etc.
Features to be tested:
What is to be tested from users viewpoint.
Roles and responsibilities:
Testing team structure and their responsibilities.
Entry criteria:
Describe when to start testing. For eg, Testing can be started when build and test data is ready.
Exit criteria:
Describe when to stop testing. For eg , when all the test cases are executed and all the defects are
closed.
Document control:
Reviewers of test plan, Approvers of test plan and Test plan distribution list.
9.2 TEST SCENARIO
Test scenario can be defined as a top view of functionalities under test.
How to identify Test scenario?
From use cases
Functionality breakdown
From state changes
Test scenario represents what needs to be tested in an application. Test scenario identification
ensure coverage of all features of the application in testing. If test scenarios are not identified, it
may result in a particular functionality not getting tested in detail or not getting tested at all. Test
scenario further help in developing end to end or combination scenario.
Uses of Test Scenario:
• Helps further for developing test cases, a very important test deliverable.

• Can be used in integration, system and acceptance testing.
Identification of Test Scenario:
From Use Cases – Use case describes how user will interact with the Application functionalities.
By functionality breakdown- functionality breakdown includes identifying various features or
services provided by the application based on the requirement documents.
Using state transition technique – In transaction based applications, the status of an entity can
change based on the user transactions.
For example, "Cancel Order” process can change the state of order from “In Process” to
“Cancelled”. Hence “Cancel Order” is identified as one test scenario.
Combination or End To End scenario:-
Test scenario can be combined to represent different sequence of user processes or combination
of different functionalities. Test scenario combinations can also be achieved through tracking the
different state changes of an entity from start to end.
Example of combination scenario:
The diagram below describes the possible state transition for an order. So combined test scenarios
are:
Placed -> In- process ->Shipped -> Delivered -> closed
Placed -> Cancelled -> Closed
Placed -> In-process -> Cancelled -> Closed
Example: Flight Reservation
Test scenario 1 – Check the login functionality.
TS2 – check that a new order can be created.
TS3 – check that an existing order can be opened.
TS4 – check that a user can fax an order.
TS5 – check that the information displayed in the help section is correct.
TS6 – check that the information displayed in about section, like version
, programmer name, copy right information is correct.
9.3 TEST CASE
Specifies “how” to test the particular functionality. Test cases are used to check the actual
behaviour of the application. Test case provides a detailed procedure that helps to test a particular
feature of an application in detail. Test cases are created by tester who has
Sufficient knowledge about the application functionalities and user requirements. However, the
following components are always available and included in every test case:
Test case ID
Section
Menu

Test case Procedure
Test Data / Input Data
Expected Result
Actual Result
Status
Many test cases can be derived from a single test scenario. In addition, sometimes multiple test
cases are written for single software which is collectively known as test suites.
Example 1:-Gmail registration form
Sr.
No.
Test
Case
Id
Section Menu Procedure Test
Data/Input
Data
Expected
Result
Actual
Result
Status
(Pass/F
ail)
1 TC_0
1
Front
End/Back
End.
Registrati
on form
page
Try to check
the first
name field.
eg. kajal
It should be
character.
2 TC_0
2
Front
End/Back
End.Logi
n page
Try to check
the last
name field.
eg- kabade
It should be
character.
3 TC_0
3
Front
End/Back
End.
Try to check
the email id
field.
eg.kajal@bigs
pire.com
It should be
characher,Spec
ial symbol
'@',numbers.
4 TC_0
4
Front
End/Back
End.
Try to check
the
password
field.
eg-
kajalkabade
password
should be
greater than
8character.
9.4 TRACEABILITY MATRIX
A traceability matrix is a document that co-relates any two-baseline documents that require a
many-to-many relationship to check the completeness of the relationship. It is used to track the
requirements and to check the current project requirements are met.
In other words, it is a document that maps and traces user requirement with test cases. The main
purpose of Requirement Traceability Matrix is to see that all test cases are covered so that no
functionality should miss while testing.
The main goals for this matrix are:
• Make sure the software is developed as per the mentioned requirements.
• Helps in finding the root cause of any bug.
• Helps in tracing the developed documents during different phases of SDLC.

Types of Traceability Matrix
Forward traceability: This matrix is used to check whether the project progresses in the desired
direction and for the right product. It makes sure that each requirement is applied to the product and
that each requirement is tested thoroughly. It maps requirements to test cases.
Example – Business Requirement > Software requirement > System requirement >design
specification > test cases > automates test scripts
Backward or reverse traceability: It is used to ensure whether the current product remains on the
right track. The purpose behind this type of traceability is to verify that we are not expanding the
scope of the project by adding code, design elements, test or other work that is not specified in the
requirements. It maps test cases to requirements.
Example – automates test scripts > test cases > design specification > System requirement >
Software requirement > Business Requirement
Bi-directional traceability ( Forward + Backward): This traceability metrics ensures that all
requirements are covered by test cases. It analyzes the impact of a change in requirements affected
by the defect in a work product and vice versa.
Example:-
Requirement R1 R2 R3 R4 R5 R6 R7
Test cases Totals 1 2 1 2 2 2 1
TC1 2 X X
TC2 1 X
TC3 1 X
TC4 2 X X
TC5 2 X X
TC6 1 X
TC7 2 X X

10. REAL TIME EXAMPLES ON MANUAL TESTING
EXAMPLES ON JOBSFACTRY.IN
10.1 SDLC AND STLC
In Jobs factory project, how we can implement the process of SDLC.
To be successful in Jobs factory project we should go through the SDLC process from
planning to deployment and maintenance.
And we can implement in models of SDLC, as we have 5 models of SDLC.
Steps for implementation of SDLC
• What modules should be there in Jobs factory.
• What should be each modules description.
• How the page should look like.
• Which language of coding we should use, what format we should follow.
• After coding the fields should show correct result we have to test. What more
• Improvements are required we can tell.
• Finally we can give that application to use and in that stage the maintenance will be done.
STLC: In Jobs factory we have to implement different phases of STLC.
Steps for implementation of STLC
Design phase:
• Preparing the testcases to ensure that product is on par with Requirement specification
document
• Verifying the testcases and testscripts of all fields. And preparation of traceability matrix.
System testing phase:
• Testing should start from this phase by following the testcases . It can be done in multiple
rounds.
• If we are finding any defects during this phase, immediately we can report to developer for
fixing.
• Review of test douments .
Performance testing:
We can check the performance criteria during this phase. This is a non-functional testing.
Business Cycle testing:
This refers to end to end testing like business scenarios.

Release phase:
• It is conducted at customer's location, so we have to think like customer.
• Acceptance testing is done in this phase
10.2 VERIFICATION AND VALIDATION
Verification:
In Jobs factory project, we are using some fields, tables, dropdowns, buttons etc.
Steps for Verification
1) We have to check whether the table is of proper size or not.
2) Which fields are required fields.
3) Dropdown is selecting proper value or not
4) Which language of coding we should follow for development.
5) We can solve some defects in early stages.
6) Because here codes and documents, we have to check.
Validation:
In Jobs factory project according to our plan whether we developed that product correct or not we
have to check.
Steps for Validation
1) Checking the codes which we have used in Jobs factory project, whether it is correct or
not .Generally it is done by developers.
2) Then we will test the application module wise like 1
st
we will test for login details of jobs
factory, then we will check for list page, then for search keywords and so on.
3) And we can test depended modules also in top down or bottom up ways.
4) Then we have check behaviour of jobs factory project whether it meets the functional and
non-functional requirements or not.
5) Then we have checked the project finally to make sure it can handle to customers. We
have to think like users.
6) It ensures that project is error free and users can use.
10.3 QA, QC AND TESTING
QA
In Jobs factory project we have to monitor and measure the development process means as
according to design plan the fields are implemented correctly or not.
Steps of QA
1) In the project we have to review the software process rather than software work.

2) We have to audit which members are involving in this project and in which module they are
working, interaction with shareholders ,clients ,all are obeying the company policies or not.
QC:
Before handling over the project to customer validation is done according to test cases of Jobs
factory.
Steps of QC
1) If we are checking for login details of jobs factory ,then according to test case it should show
the correct result means the actual result should same with expected result.
2) If logging details fields not giving correct result ,then we can rebuild the data’s again.
Testing:
1) We will check the application and all types of testing are done for validation purpose.
2) And if we are finding any bugs/error/defects then we can report that to developer.
10.4 METHOD OF TESTING
White box testing:
We have to check the internal logic and structure of Jobs factory.
Steps of WBT
1) We have understand the source code of jobs factory project means tester must be well
versed with the programming language and techniques used in Jobs factory.
2) Creating test cases for each module of Jobs factory and execute them.
Black box testing:
We have to check system architecture of Jobs factory.
Steps of BBT
1) Only we have to give input in required fields to check the functionality means for login we
have give username and password and check it is working or not.
2) Only we have to check the system architecture without knowing the source code.
3) While checking this manually, we can prepare test cases for corresponding modules of Jobs
factory.
Grey box testing
In this testing, we should know the system architecture and as well as some coding knowledge
about Jobs factory.

Steps of GBT
1) If we are checking for valid email address of jobs factory login page ,then we should know
valid email id for input and validation is done using JavaScript ,so that we can check more
deeply.
2) We can check, it should not take invalid email id, and it will not receive any failure
notifications.
10.5 FUNCTIONAL TESTING
1) Go to http://jobsfactory.in/.
2) In functional testing, application is tested by providing input and check that whether as Per
3) Unit testing, verify source code is working correctly i.e take login page of jobs factory.
4) Email-id and password and check whether it will login or not (make sure that Email-id is
already registered in jobs factory).
5) Integration testing, Take two different module and test i.e first module login page and second
module registration page. first register your mail id after that you will get confirmation on
registered mail id ,after this process go to login page and login with registered mail id and
check whether it will login or not.
6) System testing .test whole system i.e. after integration testing check whether all components
meets as per requirements or not.
7) Acceptance testing, after project completion, software will send to client, after that client will
check that project whether the software is as per requirements or not.
8) Regression testing, after acceptance testing if changes are there in previous requirements
then as per new requirements we have to check whether any that new requirement is
affecting on other pages or not.
10.6 NON-FUNCTIONAL TESTING
1) Go to http://jobsfactory.in/.
2) Performance testing, checks the response time of application or speed of the processing,
means take registration form and check the performance of registration form after submitting
all the mandatory fields.
3) Usability testing, how easily user can manage the software or how easily user is
understanding the application and executing the software.
4) Security testing, jobs factory only can access the valid users, invalid users cant access jobs
factory.
5) User interface testing, test the application in different browsers with different versions and
check whether the size of application is same in all browsers and also check the alignment
issue is there.
6) Compatibility testing (Portability testing) ,checks whether jobs factory application is running
on customers expected platform or not and also check which operating system is supporting
jobs factory application.
10.7 SOFTWARE TESTING DOCUMENTATION
Test plan:
Test plan for jobs factory.

1) Test plan identifier – Provide a unique identifier of jobs factory and which menu should test
first.
2) Test scope – In jobs factory registration form, as per user point of view they will check after
completion of registration form they are getting conformation mail or not this will come
under features to be tested. They will give valid data only while doing registration so this
will come under features not to be tested.
3) Test objective – Define testing goal means for example jobs factory is users for searching
jobs, getting’s interview calls from company.
4) Risk analysis-Risk analysis means if registration form is not submitting after clicking on
submit button then this bug not fixed on time.
5) Strategy – Which testing method will use for jobs factory means black box or white box,
manual or automated.
6) Roles and responsibilities – List the responsibilities of each team means who will take care
of development and who will do testing for which module.
7) Entry criteria – After completion of development part of jobs factory project we can do
testing.
8) Exit criteria – When all test cases executed of jobs factory and all defects are closed then at
that time exit criteria will done.
9) Document control – Take approval of test plan of jobs factory project or distribute the test
plan.
Test scenario –
Jobs factory registration form –
1) Test Scenario 1 – Check the login functionality.
2) Test Scenario 2 – Check the new registration form can be created for new user.
3) Test Scenario 3 – Check that an existing email id can take.
4) Test Scenario 4 – Check that user can get confirmation link.
5) Test Scenario 5 – Check that the information displayed correctly in profile section.
Test cases –
Jobs factory registration form –
Sr.No. Test Case
Id
Section Menu Procedure Test
Data/In
put
Data
Expected
Result
Actual
Result
Status
(Pass/Fail)
1 TC_01 Front
End/Back
End.
Registr
ation
form
page
Try to check
the full name
field.
eg.
kajal
kabade
It should be
character.

2 TC_02 Front
End/Back
End.
Try to check
the mobile
no field.
eg-
888807
7214
It should be
10 digits
no.
3 TC_03 Front
End/Back
End.
Try to check
the current
location
dropdown.
eg-
Bangal
ore
It should be
selected
from
dropdown
list.
4 TC_04 Front
End/Back
End.
Try to check
the Email-id
field.
eg-
kajal@
bigspire
.com.
It should be
character,n
umbers.
Traceability Matrix – Identify items in documentation and jobs factory application is related to
requirements or not.

11. WHAT IS AUTOMATION TESTING
Automated testing tools are capable of executing tests, reporting outcomes and comparing
results with earlier test runs.
It is the process of instructing a tool to perform an operation on an application under Test
Test automation is the use of software to control the execution of tests & the comparison of
expected v/s actual results.
11.1 WHEN DO WE GO FOR AUTOMATION TESTING
• Less cost
• Less time consumption
• Data types were not required
• We can reuse those same scripts written for earlier version to modified version of the same
application.
When to automate
• When the application under manual test is stable
• Tests that require execution of multiple data called parameterization
• Identical test cases which have to be executed on different hardware configuration
When not to be automated
• It cannot be used when the functionality of application changes frequently
• When the project doesn't have enough time for the initial time required for writing
automation test scripts
Why Automation Testing
• Improve efficiency of testing
• Reducing testing costs
• Replicating testing across different platforms
• To give consistent and accurate results
Things we do before automation:
• Identify the test cases that covers functionalities of each module
• Identify what can be tested and what cannot be tested
• Plan the flow of control and sequence of steps

Selecting of automation tool:
Choosing an automated software testing tool is an important step generally a good tool should:
• It should have good debugging facilities
• It should have clear help file and a user manual
Disadvantages of manual testing:
• Time-consuming and tedious
• Requiring a heavy investment in human resources
• Worst of all, time constraints often make it impossible to manually test every
• feature thoroughly before the application is released
Benefits of automation testing:
• Fast
• Reliable
• Repeatable
• Programmable
• Comprehensive
• Reusable
Various Tool Vendors:
Mercury
Interactive(HP)
IBM(Rational
Corporation)
Segue Software Open Source Tools
Functional &
Regression
Testing Tools
- Win runner
- QTP(VB Script)
- Rational
Robot(SQA)
- RFT(Java)
- Silk Test - Selenium(Java)
Performance
Testing Tools
- Load runner - Rational
Performance Tool
- Silk Performer - Jmeter
Test
Management
Tool
- Test Director
- Quality
Centre(QC)
- Rational
Management Tool
- RQM
- Silk Radar

12. WHAT IS AUTOMATION TESTING
Test automation is one of the most cost-effective and time-saving methods of testing software
products with long maintenance cycles. Undoubtedly, it makes the life of a test engineer a lot
easier, when compared to the manual testing. However, there are quite a lot of automation testing
tools available in the market, which makes it difficult to understand which tool will best suit your
testing requirements.
12.1 WHEN DO WE GO FOR AUTOMATION TESTING
Selenium automates browsers. That's it! What you do with that power is entirely up to you.
Primarily, it is for automating web applications for testing purposes, but is certainly not limited to
just that. Boring web-based administration tasks can (and should!) also be automated as well.
Selenium has the support of some of the largest browser vendors who have taken (or are taking)
steps to make Selenium a native part of their browser. It is also the core technology in countless
other browser automation tools, APIs and frameworks.
Selenium is at present the most powerful freeware of open source automation tool. It is developed
by Jason Huggins and his team. This is release under the Apache 2.0 license and can be
downloaded and used without any charge. Selenium is easy to get started with for simple functional
testing of web application. It supports record and playback for testing web based application.
Selenium supports multithreading feature i.e. multiple instance of script can be run on different
browsers.
Selenium (Open Source )
Selenium is a popular automated web testing tool and helps you automate web browsers across
different platforms. Selenium has the support of some of the largest browser vendors who have
taken steps to make Selenium a native part of their browser.
12.2 SELENIUM IDE + WEB DRIVER
Selenium ide:
Selenium IDE is an integrated development environment for Selenium scripts. It is implemented as
a Firefox extension, and allows you to record, edit, and debug tests. Selenium IDE includes the
entire Selenium Core, allowing you to easily and quickly record and play back tests in the actual
environment that they will run in.
Selenium IDE is not only a recording tool: it is a complete IDE. You can choose to use its recording
capability, or you may edit your scripts by hand. With auto complete support and the ability to move
commands around quickly, Selenium IDE is the ideal environment for creating Selenium tests no
matter what style of tests you prefer.
Selenium Web driver:
The primary new feature in Selenium 2.0 is the integration of the Web Driver API. Web Driver is
designed to provide a simpler, more concise programming interface in addition to addressing some
limitations in the Selenium-RC API. Selenium-Web Driver was developed to better support dynamic
web pages where elements of a page may change without the page itself being reloaded. Web
Driver's goal is to supply a well-designed object-oriented API that provides improved support for
modern advanced web-app testing problems.

Advantages:
• Selenium is pure open source, freeware and portable tool.
Selenium supports variety of languages that include Java, Perl, Python, C#, Ruby,Groovy,
Java Script, and VB Script. etc.Selenium supports many operating systems like Windows,
Macintosh, Linux, Unix.
Selenium supports many browsers like Internet explorer, Chrome, Firefox, Opera, Safari
etc.
Selenium can be integrated with ANT or Maven kind of framework for source code
compilation.
Selenium can be integrated with TestNG testing framework for testing our applications and
generating reports.
Selenium can be integrated with Jenkins or Hudson for continuous integration.Selenium can
be integrated with other open source tools for supporting other features.
• Selenium can be used for Android, IPhone, Blackberry etc. based application testing.
• Selenium supports very less CPU and RAM consumption for script execution.
Selenium comes with different component to provide support to its parent which is
• Selenium IDE, Selenium Grid and Selenium Remote Control (RC).

13. SELENIUM-IDE
The Selenium-IDE (Integrated Development Environment) is the tool you use to develop your
Selenium test cases.
13.1 INTRODUCTIONTOSELENIUMIDE
The Selenium-IDE (Integrated Development Environment) is the tool you use to develop your
Selenium test cases. It’s an easy-to-use Firefox plug-in and is generally the most efficient way to
develop test cases. It also contains a context menu that allows you to first select a UI element from
the browser’s currently displayed page and then select from a list of Selenium commands with
parameters pre-defined according to the context of the selected UI element.
13.2 INSTALLINGTHEIDEOPENINGIDE
Using Firefox, first, download the IDE from the SeleniumHQ
1) When downloading from Firefox, you’ll be presented with the following window.
2) Select Install Now. The Firefox Add-ons window pops up, first showing a progress
bar, and when the download is complete, displays the following.

To run the Selenium-IDE, simply select it from the Firefox Tools menu. It opens as follows with an
empty script-editing window and a menu for loading, or creating new test cases.
13.3 IDEFEATURES
Speed Control: Controls how fast your test case runs.
Run All: Runs the entire test suite when a test suite with multiple test cases is loaded
Run: Runs the currently selected test. When only a single test is loaded this button and the Run All
button have the same effect
Pause/Resume: Allows stopping and re-starting of a running test case.
Step: Allows you to “step” through a test case by running it one command at a time. Use for
debugging test cases.
Test Runner Mode: Allows you to run the test case in a browser loaded with the Selenium-Core
Test Runner.
Apply Rollup Rules: This advanced feature allows repetitive sequences of Selenium commands to
be grouped into a single action.
Record: Records the user’s browser actions.
13.4 BUILDINGTESTCASES
Recording:
Many first-time users begin by recording a test case from their interactions with a website. When
Selenium-IDE is first opened, the record button is ON by default. If you do not want Selenium-IDE
to begin recording automatically you can turn this off by going under Options > Options... and
deselecting “Start recording immediately on open.”
During recording, Selenium-IDE will automatically insert commands into your test case based on
your actions. Typically, this will include
1) Clicking a link - click or clickAndWaitcommands
2) Entering values - type command
3) Selecting options from a drop-down listbox – select command
4) Clicking checkboxes or radio buttons – click command
13.5 RUNNINGTESTCASES
The IDE allows many options for running your test case. You can run a test case all at once, stop
and start it, run it one line at a time, run a single command you are currently developing, and you
can do a batch run of an entire test suite.
1) Run a Test Case:Click the Run button to run the currently displayed test case
2) Run a Test Suite:Click the Run All button to run all the test cases in the currently loaded test
suite.
3) Stop and Start:The Pause button can be used to stop the test case while it is running. The
icon of this button then changes to indicate the Resume button. To continue click Resume

4) Stop in the Middle: You can set a breakpoint in the test case to cause it to stop on a
particular command. This is useful for debugging your test case. To set a breakpoint,
select a command, right-click, and from the context menu select Toggle Breakpoint.
5) Start from the Middle: You can tell the IDE to begin running from a specific command in the
middle of the test case. This also is used for debugging. To set a start point, select a
command, right-click, and from the context menu select Set/Clear Start Point.
6) Run Any Single Command: Double-click any single command to run it by itself.
13.6 USINGBASEURLTORUNTESTCASESINDIFFERENTDOMAINS
The Base URL field at the top of the Selenium-IDE window is very useful for allowing test cases to
be run across different domains.
13.7 SELENIUMCOMMANDS–“SELENESE”
Selenium commands, often called selenese, are the set of commands that run your tests. A
sequence of these commands is a test script
Selenium commands come in three “flavors”: Actions, Accessors, and Assertions. Actions are
commands that generally manipulate the state of the application. They do things like “click this link”
and “select that option”. If an Action fails, or has an error, the execution of the current test is
stopped.
Accessors examine the state of the application and store the results in variables, e.g. “storeTitle”.
They are also used to automatically generate Assertions.
Assertions are like Accessors, but they verify that the state of the application conforms to what is
expected. Examples include “make sure the page title is X” and “verify that this checkbox is
checked”.
Commonly Used Selenium Commands:
Open:opens a page using a URL.

Click/clickAndWait:Performs a click operation, and optionally waits for a new page to load.
VerifyTitle/assertTitle:Verifies an expected page title.
VerifyTextPresent:Verifies expected text is somewhere on the page.
VerifyElementPresent:Verifies an expected UI element, as defined by its HTML tag, is present on
the page.
VerifyText:Verifies expected text and its corresponding HTML tag are present on the page.
VerifyTable:Verifies a table’s expected contents.
WaitForPageToLoad:Pauses execution until an expected new page loads. Called automatically
when clickAndWait is used.
WaitForElementPresent:Pauses execution until an expected UI element, as defined by its HTML
tag, is present on the page.
Locating Elements:
By ID:
WebElement element = driver.findElement(By.id("coolestWidgetEvah"));
By Class Name:
WebElement eleme=driver.findElement(By.ClassName("coolestWidgetEvah"));
By Tag Name:
WebElement element = driver.findElement(By.tagName("coolestWidgetEvah"));
By Name:
WebElement element = driver.findElement(By.Name("coolestWidgetEvah"));
By Link Text:
WebElement element = driver.findElement(By.LinkText("coolestWidgetEvah"));
By Partial Link Text:
WebElement element=driver.findElement(By.partialLinkText("coolestWidgetEvah"));
By CSS:
WebElement element = driver.findElement(By.cssSelector("coolestWidgetEvah"));

By Xpath:
WebElement element = driver.findElement(By.xpath("//input"));
13.8 SCRIPTSYNTAX–RECORDANDPLAYBACK
Selenium commands are simple; they consist of the command and two parameters. For example:
Command TargeValue
13.9 BREAKPOINTS
To set a breakpoint, select a command, right-click, and from the context menu select Toggle
Breakpoint. Then click the Run button to run your test case from the beginning up to the
breakpoint.

Software Testing - Online Guide

Software Testing - Online Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Testing - Online Guide

Similar to Software Testing - Online Guide (20)

Recently uploaded

Recently uploaded (20)

Software Testing - Online Guide