www.quastech.

in

QUORATE SOFTWARE SOLUTIONS AND TECHNOLOGIES

Manual Testing Guide

www.quastech.in

+91-8422800381/82/83

Office No. 102, Rajdarshan Apt, Dada Patil

Wadi, Opp Thane Railway Station, Platform
No.1, Thane (W) - 400601
www.quastech.in

Module 1: Introduction to Testing

Module 2: Development Models
Module 3: Verification and Validation
Module 4: Test Methods and Test Types
Module 5: Requirement Analysis
Module 6: Use Cases
Module 7: Test Plan and Strategy
Module 8: Configuration Management
Module 9: Test Design Techniques
Module 10: Defect Management
Module 11: Agile Testing
Module 12: Manual and Automation Testing
www.quastech.in

Module1
Introduction To Testing
1.1 What is Software?
Software is a series of instructions for the computer that perform a
particular task called a program; the two major categories of software
are system software and application software.

System software is made up of control programs. Application software

is any program that processes data for the user (spreadsheet, word
processor, payroll, etc.)

1.2 What is Testing?

Testing is nothing but set of activities conducted with the Intention of
Finding defects in software.

According to ANSI/IEEE 1059 standard, Testing can be defined as - A

process of analyzing a software item to detect the differences between
existing and required conditions (that is defects/errors/bugs) and to
evaluate the features of the software item.

1.3 Why Testing is Essential?

Y2K Bug or Year 2000 Bug
Due to bug, almost all computers which ran in years before 2000 would have
read 1 January 2000 many 1 Jan 1900 as Time Management System those days
was representing years in two digits. So 1970 would be represented as 70.

PayPal Bug That Made a $92 Quadrillion deposit

On a hot humid day in June 2013, Chris Reynolds got a fright of his life
because his PayPal account showed a credit of $92,233,720,368,547,800.
www.quastech.in

Bug in Windows native calculator

This bug has not caused any loss but continues till date. Every version of
Microsoft’s Windows operating software has a calculator which can’t give
correct answer for square root (9)-3. The answer this arithmetic should be 0
but the Windows calculator doesn’t give 0 as an output.
It is important to note that software is mainly tested to see that it meets the
customers’ needs and that it conforms to the standards.
Quality software saves good amount of time and money. Because software will
have fewer defects, this saves time during testing and maintenance phases
Greater reliability contributes to an immeasurable increase in customer
satisfaction as well as lower maintenance costs

1.4 Test Method

Black Box Testing
 Software testing method in which the internal structure/ design/ code of item
being tested is not known to the tester.
 These tests can be functional or non-functional, though usually functional.
 Requirements Document or Functional Specification Document forms the
basis of this testing, which requires the user to understand the processes
within the software.
 It is done by Tester, Developer and End-User
 Also Called as Behavioral Testing, opaque-box, closed-box, specification-
based or eye-to-eye testing.
www.quastech.in

White Box Testing

 Software testing method in which the internal structure/ design/ code of item
being tested is known to the tester.
 The tester chooses inputs to exercise paths through the code and
 determines the appropriate outputs.
 Programming know-how and the implementation knowledge is essential.
 Also known as Structural Testing /Glass Box Testing/ Open Box Testing /
Clear Box Testing

Grey Box Testing

 Grey Box Testing or Grey box testing is a software testing technique to test a
software product or application with partial knowledge of internal structure
of the application.

 The purpose of Grey box testing is to search and identify the defects due to
improper code structure or improper use of applications.

 In this process, context-specific errors that are related to web systems are
commonly identified.

 It increases the testing coverage by concentrating on all of the layers of any

complex system.

 In Software Engineering, Gray Box Testing gives the ability to test both
sides of an application, presentation layer as well as the code part. It is
primarily useful in Integration Testing and Penetration Testing.
www.quastech.in

 Gray Box Testing is a software testing method, which is a combination of

both White Box Testing and Black Box Testing meth

 In White Box testing internal structure (code) is known

 In Black Box testing internal structure (code) is unknown
 In Grey Box Testing internal structure (code) is partially known.

1.5 Types of Testing:

Functional Testing
 Functional Testing checks against functional requirement /feature.
 Functions (or features) are tested by feeding them input and Examining
the output.
 The Functions/Feature are “what the system does”
Ex. Whats App Application should create group.

Non- Functional Testing

 Non-functional testing is designed to figure out if your product will
provide a good user experience, GUI, Ease of use etc.
 It means “How” well system does it within design and resource
constraints.
Ex. The email notification is sent within 5 minutes

1.6 Defects
 What is Defect
Difference between the expected and actual behavior of the software
www.quastech.in

 Defects Types
Functional Defect
Wrong
The Software does something that the software specification says it should
not do.
Missing
The Software does not do something that the software specification says it
should do.
Extra
The Software does something that is not mention in the software
specification

Non-Functional Defect
Hard to use, Hard to Learn and Understand (GUI Related issue), Performance
issue (Slow) etc.

Synonyms of Defects
 Incident
 Bug
 Failure
 Problem
 Error

1.7 Debugging and Testing

 Debugging and testing are different. Dynamic testing can show failures that
are caused by defects.
 Debugging is the development activity that finds, analyzes and
removes the cause of the failure.
 The responsibility for these activities is usually testers test and
developers debug

1.8 Software Development Life Cycle

 Requirement Gathering Analysis and Planning
 Software Design
www.quastech.in

 Coding
 Testing
 Release
 Maintenance

A. Requirement Gathering Analysis and Planning

 During this phase requirement is gathered by Business Analyst from
customer, Analyses the requirements and BRS is prepared
 After BRS document SRS document is prepared by System Analyst.
 In Analysis phase we are doing feasibility study i.e (Time feasibility,
cost feasibility, technical feasibility, resource feasibility etc).
 During this phase Planning is done for Complete Project and Project
Plan will be prepared
B. Software Design
 During this phase software Designing will be done which act as blue
print of Software
 Two Types of Design Documents Created as below
 HLD (High Level Design)/ Global Design for Entire System
 LLD (Low Level Design)/ Detail Design for Component
C. Coding
 During this phase programs are written in selected Language
 Source Code document is produced
D. Testing
 During this phase test cases are executed
 Tester make sure that system fulfills the customer needs.
 If any defect is found it is forwarded to the Developer to fix it.
E. Release
 During this phase Tested software is Deployed at Client side.
 Here, there is the separate installation team which will deploy the
software in client’s environment
 User manual is prepared in this phase along with the installation guide
F. Maintenance
 If any Defect found while using that product it will be handled by
Maintenance Team.
 In maintenance phase changes are possible these changes are handled
by configuration management team.
 Here, in this phase Change Request document is created and submitted
to BA person and then to Configuration management team which
www.quastech.in

handles the post deployment changes (refer configuration management

chapter for more details).

1.9 Software Testing Life Cycle:

 Test Planning and Control
 Test Analysis and Design
 Test Implementation and Execution
 Evaluate Exit Criteria & Reporting
 Test Closure

1. Test Planning and Control

 Test planning activity is very important where testing strategy is
defined.
 Test Plan Document is Created
 Done by Test Manager / Test Lead / Project Manager
 SRS / BRS, Project plan and Design documents (Optional) documents
are referred
 During Test Planning Scope of Testing, Schedule, Roles &
Responsibilities etc. is decided.
 Test control is the ongoing activity of comparing actual progress
against the
 plan, and reporting the status, including deviations from the plan.
 It involves taking necessary actions to meet the mission and objectives
of the project

2. Test Analysis and Design

 Reviewing and understanding the test basis (BRS, SRS)
 Evaluating test ability of the test basis and test objects
 Writing and prioritizing test conditions & Test Cases based on analysis
 Done by Tester
 Test Manager monitors, guides and controls.

3. Test Implementation and Execution

 Test implementation and execution is the activity where test procedures
or scripts are specified.
 Environmental set up will be done and the tests are run
 Comparing Expected Result with Actual Result.
 Defect Reporting and fixing will done.
www.quastech.in

4. Evaluate Exit Criteria & Reporting

 Checking test logs against the exit criteria specified in test planning.
 Assessing if more tests are needed or if the exit criteria specified should
be changed.
 Writing a test summary report for stakeholders against the defined
objectives.

5. Test Closure Activities

 Test closure activities occur at project milestones such as when a
 Software system is released, a test project is completed (or cancelled), a
milestone has been achieved.
 Finalizing and archiving test ware, the test environment and the test
infrastructure for later reuse
 Handing over the test ware to the maintenance organization
 Store and Share Learning's /Experience

1.10 What Exactly does a Software Tester do?

 Exposing Faults.
 Creating Test Cases/Scripts
 Generating Test Data
 Executing Test Cases
 Evaluation of Result of Testing
 Defect Reporting
 Make Defect fix from Developer

1.11 What makes a Good Tester?

 Know the technology & Domain.
Knowing technology & Domain helps to design better and powerful test
cases basing on the weakness or flaws of the technology
 Tactful, diplomatic
Good software testers are tactful & know how to break the news to the
developers. They are diplomatic while convincing the developers of the bugs
 An explorer
A bit of creativity and an attitude to take risk helps the testers venture
into unknown situations and find bugs that otherwise will be looked over
 Troubleshoot
Troubleshooting and figuring out why something doesn’t work helps testers
be confident and clear in communicating the defects to the developer
www.quastech.in

 Organize
Testers are very well organized and have checklists, use files, facts and
figures to support their findings that can be used as an evidence and
double check their findings as they too can make mistake.

1.12 Seven Principle of Testing

Principle 1: Testing Shows Presence of Defect
Testing can show that defects are present, but cannot prove that there are no
defects. Testing reduces the probability of undiscovered defects remaining in
the software but, even if no defects are found, it is not a proof of correctness

Principle 2: Exhaustive Testing is impossible

Testing everything (all combinations of inputs and preconditions) is not
feasible except for trivial cases.

Principle 3: Early Testing

To find defects early, testing activities should start as early as possible in the
software or system development life cycle, and should be focused on defined
objectives
Principle 4: Defect Clustering
A small number of modules usually contain most of the defects, or is
responsible for the most failures. Approximately 80% of the defects are
found in 20% of the modules.

Principle 5: Pesticide Paradox

If the same tests are repeated over and over again, eventually the same
set of test cases will no longer find any new defects. To overcome this
“pesticide paradox”, the test cases need to be regularly reviewed and revised,
and new and different tests need to be written.

Principle 6: Testing is Context Dependent:

Testing is done differently in different contexts. For example, safety- critical
software is tested differently from an e-commerce site.
Principle 7: Absence of Error fallacy
Finding and fixing defects does not help if the system built is unusable
and does not fulfill the users’ needs and expectations. Means if system is
not fit for use, there is no point in testing, finding defects and fixing it.
www.quastech.in

Module 2
Software Development Model

2.1 Different Software Development Models

Sequential Model
Waterfall
V-Model

Incremental/ Iterative Model

Agile
RAD
Spiral

2.2 Waterfall (Sequential Model)

 The Waterfall Model was first Process Model to be introduced. It is also

referred to as a linear-sequential life cycle model. It is very simple to
understand and use.

 In a waterfall model, each phase must be completed fully before the next
phase begin. This type of software development model is basically, used for
the project which is small and there are no uncertain requirements.
www.quastech.in

 At the end of each phase, a review takes place to determine if the project is
on the right path and whether or not to continue or discard the project. In this
model software starts only after the development is complete. In waterfall
model phases do not overlap.
 Recommended for small scale, Low budget and Short term projects.

2.3 Iterative /Incremental Model

 Software is developed step by step.
 First increment is the core product.
 After the first increment is ready it is released for the use of the client.
 As a result of user, the plan is prepared for the next increment.
 Modification is made to the core product to meet the needs of the customer.
 Client gets early working software.
 Example: Spiral and Agile model.

2.4 Agile (Iterative /Incremental Model)

 In Agile, the whole-team approach used means involving everyone with

different knowledge and skills to ensure project success.
 The team includes representatives from the customer and other business
stakeholders who determine product features
www.quastech.in

 Engages the stakeholders continuously so that the new requirements are

gathered faster and there is no scope for guess work by the teams.
 Provides the end result of higher quality of the software delivered and a
highly satisfied customer.

2.5 RAD (Iterative /Incremental Model):

 Rapid Application Development (RAD) is formally a parallel development
of functions and subsequent integration.
 RAD model is Rapid Application Development model. It is a type of
incremental model. In RAD model the components or functions are
developed in parallel as if they were mini projects. The developments are
time boxed, delivered and then assembled into a working prototype.
 There are some advantages of rad model like. Product can develop soon, can
take initial reviews quickly, Integration from very beginning solves a lot of
integration issues.
 And some disadvantages like it required strong team and good individual
performance to understand business requirements, Only system that can be
modularization can be built using RAD. Rad model should be chosen only if
resources with high business knowledge are available and there is a need to
produce the system in a short span of time (2-3 months).
www.quastech.in

2.6 Spiral (Iterative /Incremental Model):

 The spiral model is a risk-driven process model generator for software
projects. This model is best used for large projects which involves
continuous enhancements.
 There are specific activities which are done in one iteration
(spiral) where the output is a small prototype of the large software.

 The same activities are then repeated for all the spirals till the entire software
is build.
 Some advantages of Spiral model is It is use for Larger projects,
More and more features are added in a systematic way.

 Some disadvantage is that It is costly for smaller projects, is not beneficial

for smaller projects, and time consuming also.
www.quastech.in

Module 3
Verification & Validation
3.1.1 Verification:
 Verification ensures that the software documents comply with the
organizations standards.
 In simple words, Verification is verifying the documents.
 Also known as Static Testing.
 Are we building the product, right?
 It Avoid defect multiplication.
 Verification ensures that the product is built according to the requirements
and design specifications.
 Verification relies on the manual examination (reviews) of Work products
(Documents).
 Defects found costs less to fix as compare to Dynamic Testing.
 Verification can happen on Any software work product, including
requirements specifications, design specifications, code, test plans, test
specifications, test cases, test scripts, user guides etc.
 Benefits of verification include early defect detection.
 Verification and Validation have the same objective – identifying defects.
 Compared to dynamic testing, Verification finds causes of failures (defects)
rather than the failures themselves
 Done by QA (Quality Assurance) Team

3.1.2 Verification Techniques:

 Walk-through
 Inspection
 Review

Walk-Through
Led by author.
It is a step-by-step presentation by the author of a document in order to
gather information and to establish a common understanding of its content.
Done between colleagues.
It may be informal process.
Main purposes: learning, gaining understanding, finding defects
www.quastech.in

Inspection
Led by trained moderator (not the author).
Done at Each phase to have opinion, is phase completed & can we move to
the next phase?
It is semi-formal process
Main purposes: Finding defects

Five Major Roles in Inspection Meeting

 Moderator: Activity Leader
 Author: who’s document under inspection
 Reader: Reads documents for all
 Recorder: Notes Minutes of meeting
 Inspector: Domain Expert

3.1.3 Review
Review is a subsequent examination of a product for the purpose of
monitoring earlier changes.

It is a process in which one or more persons check the changed documents

or data to determine if the changes are correct.

It is also an analysis undertaken at a fixed point in time to determine the

degree to which stated objectives have been reached.
Validation:
 Validation, which requires the execution of Software.
 Also Called as Dynamic Testing.
 It requires Execution of Software.
 Ensures Are we building the right product?
 Validation is the process of evaluating software during or at the end of the
development process to determine whether it satisfies specified
requirements.
 Advantages of Validation if During verification some defects are missed
then during validation process it can be caught as Defect. Defect Fixing cost
in validation is more as Compare to Verification.
 Dynamic Testing(validation) finds just failures not causes of failures.
 Checks the Product, not the process.
 Done by QC (Quality Control) team.
www.quastech.in

Validation Technique/ Levels of Testing

 Unit Testing
 Integration Testing
 Unit Integration testing
 System Integration testing
 System Testing
 User Acceptance Testing

Unit /Component Testing

 Component testing is also known as unit, module or program testing.

 Testing small piece of Independent and executable code.
 The unit testing purpose is to ensure that the unit satisfies its functional
specification
 If Unit is working properly further testing (i.e. Integration Testing) will be
simplified.
 Typically done by Programmer since it requires access to code.
 Defects found & fix during Unit testing typically not recorded (Reported).

3.2.1 Integration Testing

 The purpose of integration testing is to expose defects in the interfaces and

in the interactions between integrated components or systems.
 Component integration testing tests the interactions between software
components and is done after component testing.
 System integration testing tests the interactions between different systems or
between hardware and software and may be done after system testing.
 At each stage of integration, testers concentrate solely on the integration
itself.
 For example, if they are integrating module A with module B they are
interested in testing the communication between the modules, not the
functionality of the individual module as that was done during component
testing. Both functional and structural approaches may be used.
 Integration Testing Approaches:
I. Big Bang testing
II. Incremental Integration Testing
www.quastech.in

1.Bottom-Up
2.Top-Down
3.Sandwich / Hybrid

I. Big Bang Integration Testing:

It is an integration testing strategy wherein all units are linked at once,
resulting in a complete system. When this type of testing strategy is adopted,
it is difficult to isolate any errors found, because attention is not paid to
verifying the interfaces across individual units.

II. Incremental Integration Testing:

1) Bottom-Up Approach:

 Bottom-up testing, as the name suggests starts from the lowest or the
innermost unit of the application, and gradually moves up. Integration
testing starts from the lowest module and gradually progresses towards
the upper modules of the application.
 This integration continues till all the modules are integrated and the
entire application is tested as a single unit.
 We would need some program or a “stimulator”. These stimulator
programs are called DRIVERS.
www.quastech.in

 In simple words, DRIVERS are the dummy programs which are used to
call the functions of the lowest module in case when the calling function
does not exist.

2) Top – Down Approach:

 This technique starts from the top most module and gradually progress
towards the lower modules. Only the top module is unit tested in
isolation.
 After this, the lower modules are integrated one by one. The process is
repeated until all the modules are integrated and test
 we would need some program or a “stimulator”. These stimulator
programs are called STUBS.
 “Stubs” can be referred to as code a snippet which accepts the inputs /
requests from the top module and returns the results/ response.
www.quastech.in

3) Sandwich/Hybrid Approach:
Sandwich Testing is a strategy in which top level modules are tested
with lower level modules at the same time lower modules are integrated
with top modules and tested as a system. It is a combination of Top-down
and Bottom-up approaches therefore it is called Hybrid Integration
Testing. It makes use of both stubs as well as drivers.

3.2.2 System Testing

 System testing is concerned with the behavior of a whole system/product as
defined by the scope of a development project or product.
 System testing is most often the final test to verify that the system to be
delivered meets the customer need or requirement.
 Its purpose is to find as many defects as possible
 System testing should investigate both functional and non- functional
requirements of the system
 In system testing, the test environment should correspond to the final target
or production environment as much as possible in order to minimize the risk
of environment-specific failures not being found in testing. Most often it is
carried out by independent test team.
www.quastech.in

3.2.3 User Acceptance Testing

 Acceptance testing is most often the responsibility of the user or customer.
 User acceptance is a type of testing performed by the Client to certify the
system with respect to the requirements that was agreed upon.
 The acceptance test should answer questions such as: 'Can the system be
released?'
 The main purpose of this testing is to validate the end to end business flow &
not to find defects.
 This testing happens in the final phase of testing before rolling out the
software application to Market or Production environment.

Types of UAT Testing:

Alpha Testing
 A type of UAT in which customer or client do testing in production
environment.
 Developers and Testers monitor Alpha Testing.
 It is always performed within the organization, and not open for market or
public.
 Alpha Testing is done before the launch of software product into the market.

Beta Testing
 A type of UAT in which customer or client do testing inlive environment.
 It is performed at the user’s premises in the absence of the development team
 It is always performed by users.
 Beta Testing is always performed at the time when software product and
project are marketed.
 Beta Testing is also known by the name Field Testing.

3.3 Testing within a Life Cycle Model :

 For every development activity there is a corresponding testing activity
 The analysis and design of tests for a given test level should begin during the
corresponding development activity
 Advantage: Avoid defect Multiplication which can save the time and money.
www.quastech.in

3.4 V Model:

 For every development activity there is a corresponding testing activity.

 The analysis and design of tests for a given test level should begin during the
corresponding development activity.
 V-model is also known as verification & validation model.
 When development documents (BRS, SRS, HLD, LLD) are prepared,
finalized and reviewed in Verification process simultaneously test
documents (test cases) are created (unit, integration, system, acceptance) by
referring development documents in validation process.
 V model is a sequential model so it starts from BRS to coding that comes in
verification process and after that unit to UAT is followed by executing test
cases that comes under validation process. i.e.
 According to BRS test cases for acceptance testing created and executed.
 According to SRS test cases for system testing created and executed.
 According to HLD test cases for integration testing created and executed.
 According to LLD test cases for unit testing created and executed.
www.quastech.in

Module 4
4.1 Types of Testing
A test type is focused on a particular test objective, which could be any of the
following:
 A function to be performed by the software.
 A non-functional quality characteristic, such as reliability or usability, the
structure or architecture of the software or system.
 Change related, i.e., confirming that defects have been fixed (Retesting
/Confirmation testing) looking for unintended changes (regression testing).
 All functional and non-functional type of testing comes under system testing.

4.2 Testing Related to Change

Retesting
 After a defect is detected and fixed, the software should be re-tested to
confirm that the original defect has been successfully removed.
 This is also called confirmation testing.
 It is mandatory to re-execute the failed test case with same input data other
data maybe optional.
Regression Testing
 Regression testing is the repeated testing of an already tested program, after
modification, to discover any new defects introduced as a result of the
change(s).
 It is performed after any kind of changes are made like when requirements
change, environments changed or legislation changed.
 Impact Analysis is done with the help of RTM (Requirement Traceability
Matrix) to decide how much Regression should be done.
 Automation Testing Tools should be used for Regression Testing since it is
repetitive in nature.
www.quastech.in

Advantages of RTM:
 Helps to provide a visual representation
 Building the product right with a representation of testing
 Delivering to business requirements or not.
 Managing test cases.
 Managing versions of your product
 It is also an accountability tool, helping you track if your team is on track.
 To show how you are delivering the product
 It can assist in the planning and managing of testing and then later in
triaging defects

4.3 Testing Related to Function:

4.3.1 Security testing:
A type of functional testing, investigates the functions (e.g. a firewall) relating
to detection of threats, such as viruses, from malicious outsiders.
 For Security testing tester will check
 Access Control
 SQL Injection
 Cookies
 Authentication / Authorization
 Encryption, etc.

4.3.2 Smoke Testing (BAT/BVT):

 In Smoke testing tester test only basic functionalities when the build is
received from the development team.
 It is also known as Build verification testing or Build acceptance testing. It’s
a decision- making point to go for depth testing.

4.3.3 Sanity testing:

 Sanity testing is also the basic functionality test which is performed before
release the product after all the type of testing is performed on system.
 Some basic functionality like:
 Checking links (To finds a dead)
 Forms (i.e. Login, Registration, Payment, etc.)
www.quastech.in

4.4 Testing Related to Software Characteristics

(Non- Functional Testing)
Non-functional testing includes performance testing, load testing, stress
testing, usability testing, reliability testing and portability testing. It is the
testing of “how” the system Looks and Performs.

 Types Of Non-Functional Testing:

 Performance Testing
 Compatibility Testing
 Configuration Testing
 Usability Testing
 User Interface Testing
 Localization
 Internationalization
 Installation Testing
 Re-installation Testing
 Recovery Testing

4.5 Performance Testing:

The degree to which a system or component accomplishes its designated
functions within given constraints regarding processing or response time
and throughput rate.

Performance Testing Tool:

 JMeter
 Load Runner
 RPT

4.6 Types Of Performance Testing:

 Load Testing
 Stress Testing
 Spike Testing
 Endurance Testing
 Volume Testing
www.quastech.in

Load Testing:
Load testing is a kind of performance testing which determines a system's
performance under real-life load conditions. This testing helps determine how
the application behaves when multiple users access it simultaneously.

Why load testing:

Load testing gives confidence in the system & its reliability and performance.
Load Testing helps identify the bottlenecks in the system under heavy user
stress scenarios before they happen in a production environment.

Stress Testing:

 It validates an application’s behavior when it is pushed beyond normal or

peak load conditions.
 The goal of stress testing is to reveal application bugs that surface only under
high load conditions. These bugs can include such things as memory leaks.

Why Stress Testing:

 To check whether the system works under abnormal conditions.

 Displaying appropriate error message when the system is under stress.
 System failure under extreme conditions could result in enormous revenue
loss.
 To find crash point.

Spike Testing:

It is a subset of Stress testing, tests the software's reaction to sudden large

spikes in the load generated by users (Load increments and decrements).
www.quastech.in

Endurance Testing:

It is a subset of Load testing, is done to make sure the software can handle
the expected load over a long period of time.

Volume Testing:

Since Performance Testing requires lots of user’s which is impossible to have

physically. Hence tools are used in performance Testing.

Compatibility Testing
 Compatibility Testing is performed to check that the application functions
properly across various hardware and Software environment. (Client’s
expected platform).
 More Important in web applications since user can use any browser or OS
for accessing.

Configuration Testing
Configuration Testing is also known as Hardware compatibility testing and is
performed to check that the application functions properly across various
hardware.

Usability Testing
 Usability means how easy the application is to use/learn.
 Ease of use should be balance between fresh user and Experience User.
 It should be done by user of Product.

4.7 User interface Testing

 User interface means how user Friendly the application is for the customer.
 The term “User Interface” speaks for itself: it is the part of a website or app
that users interact with. Naturally, the quality of the user interface decides
www.quastech.in

the user’s first (and last) impression of a website or app

 Deal with the Graphical User Interface
Spelling Check
Grammatical Check
Font, Size and Color, etc.

4.8 Localization Testing(non-Functional Testing):

 If Localization Testing is a software testing technique in which the behavior
of software is tested for a specific region, locale or culture. The purpose of
doing localization testing for software is to test appropriate linguistic and
cultural aspects for a particular locale. It is the process of customizing the
software as per the targeted language and country.

 The major area affected by localization testing includes content and UI.

 Example: If the project is designed for Tamil Nadu State in India, The
designed project should be in Tamil language, Tamil virtual keyboard should
be present, etc.

4.9 Internationalization Testing (Non-Functional Testing):

 Internationalization testing is the process of verifying the application under

test to work uniformly across multiple regions and cultures.

 The main purpose of internationalization is to check if the code can handle

all international support without breaking functionality that might cause data
loss or data integrity issues. Globalization testing verifies if there is proper
functionality of the product with any of the locale settings.

 Example: As people are more comfortable in their native language, Google

designed and developed its search products around the local geography,
culture and language.  Google is now available in 123 languages and has
been localized completely or partially for many countries.
www.quastech.in

Module 5
Requirement Analysis:
What is Requirement Analysis?

It involves frequent communication with system users to determine specific

feature expectations, ambiguity in requirements as demanded by the various
users or groups of users, avoidance of feature creep and documentation of all
aspects of the project development process from start to finish.

 In this step testing team understands the requirement to know what to test &
figure out the testable requirements.
 In this Requirements are analyzed in terms of below factors:
- Are requirements complete and Correct?
- Are requirements achievable and Testable?
- Any conflict, missing or not understood any requirement, then QA team
takes follow up with the various stakeholders.

In Requirement Analysis basically, we have two types of Requirements:

Functional Requirement AND Non-Functional Requirement.

Functional Requirement: A Requirement that specifies a function that a

component or System must perform (What the System should do?)

Example:
- Login to the System
- Search option given to user to search

Non-Functional Requirement: A Requirement that is does not relate to

functionality, but to attribute such as Performance, Usability, Reliability,
Portability, UI etc.

Example:
Page of the system should be open within 5 seconds.
www.quastech.in

Explicit Requirement: The requirement which are mention by the client

explicitly is called as “Explicit requirement”.
Example: Client want DOB field in the registration form.

Implicit Requirement: The requirement which are not mention by the

client which are derived from the explicit requirement is called as
“Implicit Requirement”.
Implicit requirement is in the hand of development company how they
implement.
Example:
DOB field can be implemented either by
(drop down, manually entering, search etc.)
www.quastech.in

Module 6
Use Case

6.1 What is Use Case?

 It is Document that exercise the whole system on a transaction by transaction

basis from start to finish
 Use cases describe the process flows through a system based on its most
likely use
 They often use the language and terms of the business rather than technical
terms
 Written only for Functional requirements.
 Use Case is prepare by the BA (Business Analysis) and used by the
developer, tester and users. It’s not a mandatory document. It prepares for
the complex project not for simple project where it includes different types
of user and too much functionality.

6.2 Advantage of Use Case:

 Since it is written in language of user. They serve as the foundation for
developing test cases mostly at the system and acceptance testing levels
 use cases particularly good for finding defects in the real-world use of the
system (i.e. the defects that the users are most likely to come across when
first using the system)
 use case consists mainly of narrative text, it is easily understandable by all
stakeholders, including customers, users and executives, not just developers
and testers.

6.3 Remember:
 Use cases are requirements but are not all of the requirements. Use Cases are
Not Good for defining
 User interfaces, Data formats and Non-functional requirements Use cases are
diagrammatically representations of flow of system.
www.quastech.in

 And can also be written step by step.

6.4 Types Of Use Case:
 Use Case Diagram: It specifies interaction between the user & the system.
 Use Case Document: It specifies process flow.

6.5 Use-case diagram notations:

6.5.1 Use-case:
Use cases are used to represent high-level functionalities and how the user will
handle the system. A use case represents a distinct functionality of a system, a
component, a package, or a class. It is denoted by an oval shape with the name
of a use case written inside the oval shape. The notation of a use case in UML
is given below:

6.5.2 Actor:
It is used inside use case diagrams. The actor is an entity that interacts with the
system. A user is the best example of an actor. An actor is an entity that
initiates the use case from outside the scope of a use case. It can be any
element that can trigger an interaction with the use case. One actor can be
associated with multiple use cases in the system. The actor notation in UML
is given below.

6.5.3 System:

The scope of a system can be represented by a system (shape), or sometime

known as a system boundary. The use cases of the system are placed inside
the system shape, while the actors who interact with the system are put outside
the system. The use cases in the system make up the total requirements of the
system.
www.quastech.in

6.5.4 Relationship:
A generalization relationship is used to represent inheritance relationship
between model elements of same type. The more specific model element
shares the same specification with the more general the model element but
carries more details in extra.

6.6 An example of a use-case diagram:

www.quastech.in

6.7 Attributes Of Use Case Diagram:

 Actor: The users that interact with a system. An actor can be a person, an
organization, or an outside system that interacts with your application or
system. They must be external objects that produce or consume data.

 System: A specific sequence of actions and interactions between actors and

the system. A system may also be referred to as a scenario.

 Goal: The end result of most use cases. A successful diagram should
describe the activities and variants used to reach the goal.

6.8 Types of Actor in a Use Case Model:

 Primary Actor: A user whose defined user goal and is fulfilled by the
system. The primary actor of a use case is the stakeholder that calls on the
system to deliver one of its services. The primary actor is often, but not
always, the actor who triggers the use case.

 Supporting Actor: A supporting actor (also known as a secondary actor) in

a use case in an external actor that provides a service to the system under
design. It might be a high-speed printer, a web service, or humans that have
to do some research and get back to us.

6.9 Types Of Goal:

User Goal: It done in single sitting. For Example: Cash withdrawn.

Summary Goal: It done in multiple sitting or may requires multiple people,

organization, system \interactive to achieve the goal. For Example: Cash
withdrawn by cheque.
www.quastech.in

6.10 Flow/Path:
Normal Path/Basic path: In this goal will achieve.

Alternative Flow: The goal is achieve. It’s other than basic path. There
should be more than one alternate path.

Exception Flow: In this goal is not achieved but we will get reason behind
the failure.

Error Path: In this goal is not achieved. Also system doesn’t give any
reasons behind the failure.

6.11 Use case Document Attributes:

 Use case ID
 Goal
 Actor
 Pre-Condition
 Path
 Step
 Post Condition
www.quastech.in

Module 7
Test Planning and Strategy
7.1 Introduction:

 Test Plan is a document that includes details of scope, Objective and method
of testing such as resources and schedule of intended test activities.
 The test plan serves as a blueprint to conduct software testing activities as a
defined process which is minutely monitored and controlled by the test
manager.
 Test Strategy is the document that tells us what type of technique to follow
to test the different modules of software it is High level document prepared
by the project manager.

7.2 Importance of Test Plan

 It helps to determine the needed efforts.
 Proper Utilization of resources.
 The test planning process and the plan itself serve as the means of
communication with other members of the project team, testers, peers,
managers and other stakeholders.
 Avoids Random Testing.

7.3 Guidelines for Test plan

 Be specific.
For example, when you specify an operating system as a property of a
test environment, mention the OS Edition/Version as well, Make use of
lists and tables wherever possible.
 Avoid lengthy paragraphs.
Test plan must review a number of times prior to baseline it or sending it for
approval.
 Update the plan as and when necessary.
www.quastech.in

7.4 Types of Test Plan:

Master Test Plan
Master Test Plan is a type of test plan that has multiple
levels of testing. It includes a complete test strategy.

Phase Test Plan

A phase test plan is a type of test plan that addresses any
one phase of the testing strategy. For example, a list of
tools, a list of test cases, etc.

Specific Test Plans

Specific test plan designed for major types of testing like
security testing, load testing, performance testing, etc. In
other words, a specific test plan designed for non
-functional testing.

7.5 Test Plan Attributes/ Template IEEE 829:

Test Plan Identifier
Introduction
References
Test Items
Features to be tested
Features not to be tested
Test Environment/ Test Bed
Test Deliverable
Approach/Strategy
Suspend/Resume criteria (Pause Criteria)
Entry & Exit Criteria
Risk & Contingencies
Software Risk issues
Roles & Responsibilities
Schedule
Staffing and Training
Approvals
www.quastech.in

 Test Plan Identifier: Unique ID given to plan so that we can identify

different project and plan.

 Introduction: Detail description about the plan if it’s a Master plan or

Generic Plan, and introduction about project.

 References: Different documents and version that we have referred to

prepared the plan like.
BRS
SRS
Development plan
Previous versions documents.

 Test Items: All the items (Module names) of the current version of the
software.

 Features to be tested: All the Functionalities that has to be tested. This is a

listing of what is to be tested from the Users viewpoint of what the system
does. This is not a technical description of the software, but a User’s view of
the functions.

 Features not to be tested: All the functionalities that may not be released in
the current version. If there is less time than the low priority test cases may
not be executed.

 Test Environment/ Test Bed: Describe the environment in which the

application is going to be accessed It describes Require Hardware and
software for setting-up Test Environment or Test Lab.

 Test Deliverable: All the documents that will be generated as a result of

testing activities (Test plan, Test cases, Execution log).

 Approach/Strategy: This is your overall Test Strategy for this test plan, it
should be appropriate to the level of the plan (Master, Generic etc.)

Are any special tools to be used and what are they?

Will the tool require special training?
How is Configuration Management to be handled?
www.quastech.in

Hardware
Software

 Suspend/Resume criteria (Pause Criteria):

defines under what circumstance we may not be able to continue further
testing

Resume criteria defines under what circumstance we can continue the testing
activates

 Entry & Exit Criteria:

Entry Criteria describes when to start Testing
Exit Criteria describes when to stop testing.

 Risk & Contingencies: Identify the high-risk assumptions of the test plan
related to testing process (Risk Which may delay Testing)
Specify contingency plans for each (Which can overcome Risk)

 Software Risk issues: Also called as Quality Risk and Product Risk.
Delivery of incomplete / faulty product to customer. Software hard to use or
slow to response.

 Roles & Responsibilities: Roles and Responsibilities of Team Lead or Test

Lead and Team members who are involved in project (Who does which
work?)

 Schedule: Schedule for all Test activities in this Software Test Process.

 Staffing and Training: Hiring new Employee as per Project Need. Training
on the application/system (Domain Training) Training for any test tools to be
used.

 Approvals: Specify the names and titles of all persons who must approve the
plan Provide space for signatures and dates.
www.quastech.in

Module 8
Configuration Management
8.1 Configuration Management Need:
Suppose you have a programming error and need to change it, recompile and
use that software.
The following thing should need to identify to recompile same.
What version of the hardware did you use for the original?
What version of the OS, DB, compiler?
What version of the file management software?
So, we must manage
Suppose we change requirements, update or delete
requirements So even when the documentation of the system
changes as it evolves, we must track that, too

8.2 Configuration Management:

Configuration management is the management of features and assurances
through control of changes made to hardware, software, documentation and
test documentation of a system, throughout the development life Cycle.
During test planning, the configuration management procedures and
infrastructure (tools) should be chosen, documented and implemented
For the tester, configuration management helps to uniquely
identify (and to reproduce) the tested item, test documents, the
tests and the test harness.

8.3 Configuration Management Includes:

Change management- Manage changes to the specifications of a potential
software system
Documentation management-Manage all documentation including defects,
specification, testing, purchasing, emails, memos, agendas… every single
documentation detail
Hardware/firmware configuration management - Manage all the hardware
and firmware.
Source code management –Manage changes to the source code
including the application code, operating system, compilers, utilities, database
management system, communication system, middle ware, etc.
www.quastech.in

Module 9
Test Design and Techniques
9.1 Objective:
The objective of test design technique is identify the test conditions and test
scenarios so that effective test cases can be written. Test design technique is
best approach then writing the test cases randomly.

What is Test Design?

After Analyzing the Requirements Deriving the test Scenarios, Test Conditions,
Test data, Writing and Creating Test Cases, Test Suites for Testing the Software.

Why to Design
It will help to know What and How to Test which helps us in achieving
maximum test coverage and to write test cases.

Black Box Test Design Techniques:

Specification based Techniques
 Equivalence Class Partition
 Boundary Value Analysis
 Decision Table Based
 Experience based Techniques
 Error Guessing
 Exploratory Testing

9.2.1 Specification based Techniques:

Equivalence Class Partition (ECP):

In equivalence class partitioning, inputs to the software or system are divided

into groups that are expected to exhibit similar behavior, so they are likely to be
processed in the same way.

Equivalence partitions (or classes) can be found for both valid data
i.e. values that should be accepted and invalid data,
www.quastech.in

i.e., values that should be rejected.

Tests can be designed to cover all valid and invalid partitions. Equivalence
partitioning is applicable at all levels of testing
Choose one data from each Partition.

Equivalence class partition Example:

If we take data rage between 15-60 Yrs. of age then. We take one value which
is less than 15, one value which is greater than 60 it can be any random value
and any one value which is between 15 to 60

Group the inputs/ outputs according to their behavior i.e. they are giving same
outputs.

Example:
14 15-60 61
Invalid Valid Invalid
So there are 3 values 13, 42,62

Boundary Value Analysis (BVA):

Behavior at the edge of each equivalence partition is more likely to be

incorrect than behavior within the partition, so boundaries are an area where
testing is likely to yield defects.

The maximum and minimum values of a partition are its boundary values.
A boundary value for a valid partition is a valid boundary value; the boundary
of an invalid partition is an invalid boundary value.
Tests can be designed to cover both valid and invalid boundary values.
When designing test cases, a test for each boundary value is chosen.

Example:
If we take data rage between 15-60 Yrs. Then we need to take values which
are at the boundary and value which is just above and below the boundary
value Group the inputs/ outputs according to their behavior i.e. They are
giving same outputs.
www.quastech.in

14 15-60 61
Invalid Valid Invalid
Invalid Just +1 and -1 to Edges of valid partition
So overall 6 values in BVA that is 14,15,16,59,60,61

Decision Table Based Testing:

A decision table is also known as to Cause-Effect table. This
software testing technique is used for functions which respond to a
combination of inputs or events. For example, a submit button should be
enabled if the user has entered all required fields.

The first task is to identify functionalities where the output depends on a

combination of inputs. If there are large input set of combinations, then divide
it into smaller subsets which are helpful for managing a decision table.
www.quastech.in

9.2.2 Experience based Techniques:

Error Guessing:
A commonly used experience-based technique is error guessing. Generally,
testers can guess defects based on experience.
Anyone can do error guessing but it gives varying degree of effectiveness
depends on testers experience or skill.

Exploratory testing:
Exploratory testing is concurrent test design, test execution, test logging and
learning, based on a test charter containing test objectives, and carried out
within time-boxes.
It is an approach that is most useful where there are few or inadequate
specifications and severe time pressure, or in order to augment or complement
other, more formal testing.

9.3 Test Scenario Template:

A Test Scenario is defined as any functionality that can be tested. It is also
called Test Condition or Test Possibility. It is a collective set of test cases
which helps the testing team to determine the positive and negative
characteristics of the project.
As a tester, you should put yourself in the end user’s shoes and figure out the
real-world scenarios and use cases of the Application under Test.

Tester who writes Test Scenarios fills following:

 Test Scenario Id
 Test Scenario Name
 Test Scenario Objective
 Precondition
 Test Condition

9.4 Test Case Template:

A Test Case is a set of actions executed to verify a particular feature
or functionality of your software application.
A test case is a document, which has a set of test data, preconditions, expected
www.quastech.in

results and post-conditions, developed for a particular test scenario in order to

verify compliance against a specific requirement

Test Case acts as the starting point for the test execution, and after applying a
set of input values; the application has a definitive outcome and leaves the
system at some end point or also known as execution post-condition.

Tester who writes Test Case fills following:

 Test case ID/business types (Positive\negative)
 Test Objective
 Pre-condition
 Step Id
 Step description
 Test data
 Expected Result
 Actual result
 Status
 Remark

9.5 Characteristics of Good Test Case

 Accurate : Tests what the description says
 Economical : Separate the initiation steps & has only the steps needed for its
purpose
 Repeatable & Reusable : It should be usable to next version
 Self-standing : Independent of Tester
 Appropriate :
 No Pesticide Paradox presents
For both immediate and future testers
 Traceable :
Forward to logs
Backward to a requirement
 Self-Cleaning : Returns the test environment to a start state
www.quastech.in

Module 10
Defect Management
10.1 Introduction:
What Is Defect ?
Difference between the expected and actual behavior of the software
Types of Defects:
Functional and Nonfunctional Defects
What is Incident/Defect Management?
Defect Reporting, Defect Tracking, and Status Tracking is called as Defect
Management.
Some companies use Manual Process (Excel workbook), and some
companies use Tool based process for Defect Management.

10.2 Error vs Defect vs Failure:

10.3 Defect Management Tools

 Bugzilla
 Mantis
 QC(ALM)
 Jira
www.quastech.in

10.4 Reasons of Defect

 Incomplete and incorrect requirement
 Wrong Design
 Wrong Coding
 Wrong Testing
 Error at the time of Defect fixing
 Error because of Impact of Defect Fixing
 Severe Work Pressure

10.5 Status of Defect

 New
 Open/Re-open
 Duplicate
 Deferred
 Assign/ Re-assign
 Fixed/Resolved
 Close

10.6 Defect Life Cycle

www.quastech.in

10.7 Defect Reporting Attributes/ Template

 Defect ID
 Defect Reporting date
 Project Name
 Project Version
 Module/Sub-module Name
 Type of Defect
 Phase in which defect is identified
 Summary of defect
 Description of Defect
 Severity
 Priority
 Status
 Reported By
 Reported To

10.8 Severity & Priority

Severity
Severity is assigned to the Defect by the tester on the basis of Impact of the
defect on the Software.
There are different Severity levels like...
High, Medium, Low
But Severity Levels changed by Different Defect management Tools

Priority
Priority is assigned by the developer to the defect on the basis of how urgent
that bug is to be fixed
Decided by Developer / Client as Urgency is decided based of business.

10.9 Why to Report Defect

 To get the Defect Fix
 To improve the Quality of Software
 Management Reporting
 Preventive Measures
 Process Improvement
www.quastech.in

Module 11
Introduction to Agile Testing

11.1 What is Iterative/Incremental

11.2 What is Agile

 Agile is a software development methodology to build a software
incrementally using short iterations of 1 to 4 weeks so that the development
process is aligned with the changing business needs.

 Instead of a single-pass development of 6 to 18 months where all the

requirements and risks are predicted upfront, Agile adopts a process of
frequent feedback where a workable product is delivered after 1 to 4-week
iteration.
www.quastech.in

11.3 Whole Team Approach

 The whole-team approach means involving everyone with the knowledge
and skills necessary to ensure project success.

 The team includes representatives from the customer And other business
stakeholders who determine product features.

Advantage
 Enhancing communication and collaboration within the team.
 Enabling the various skill sets within the team to be leveraged to the benefit
of the project.
 Making quality everyone’s responsibility.

11.4 Types of Agile Methodologies

11.4.1 Extreme Programming:
 extreme Programming is customer-eccentric and focuses on constantly
changing requirements (Mini Spiral).
 XP teams typically work in iterations that are one or two weeks long
 XP teams do allow changes into their sprints
 XP prescribe engineering practices test-driven development, the focus on
automated testing, pair programming, simple design, refactoring, and so on

11.4.2 Scrum
It is an Agile management framework which contains the following:

 Sprint: Scrum divides a project into iterations (called sprints)of fixed length
(usually two to four weeks).
 Product Increment: Each sprint results in a potentially.
 Releasable/Shippable product (called an increment).
 Product Backlog: The product owner manages a prioritized list of planned
www.quastech.in

product items (called the product backlog). The product backlog evolves
from sprint to sprint (called backlog refinement).
 Sprint Backlog: At the start of each sprint, the Scrum team selects a set of
highest priority items (called the sprint backlog) from the product backlog.
 Definition of Done: To make sure that there is a potentially releasable
product at each sprint’s end, the Scrum team discusses and defines
appropriate criteria for sprint completion.
 Time boxing: If the development team cannot finish a task within a sprint,
the associated product features are removed from the sprint and the task is
moved back into the product backlog.
 Transparency: The development team reports and update sprint status on a
daily basis at a meeting called the daily scrum.

Scrum Team is as Follow:

 Scrum Master: ensures that Scrum practices and rules are implemented and
followed, and resolves any violations, resource issues, or other impediments
that could prevent the team from following the practices and rules. This
person is not the team lead, but a coach.

 Product Owner: represents the customer, and generates, maintains, and

prioritizes the product backlog. This person is not the team lead.

 Development Team: develop and test the product. The team is self-organized: There is no team lead, so the
team makes the decisions. The team is also cro ss-functional
www.quastech.in

11.5 Events:
Release & Iteration Planning
Scrum is an Agile management framework which contains the following
 Release planning looks ahead to the release of a product, often few months
ahead of the start of a project. Release planning defines and re-defines the
product backlog, and may involve refining larger user stories into a
collection of smaller stories
 In release planning, business representatives establish and prioritize the user
stories for the release, in collaboration with the team
 After release planning is done, iteration planning for the first iteration starts.
Iteration planning looks ahead to the end of a single iteration and is
concerned with the iteration backlog.
 In iteration planning, the team selects user stories from the prioritized release
backlog, elaborates the user stories, performs a risk analysis for the user
stories, and estimates the work needed for each user story.
 Daily Scrum Meeting
 The Daily Scrum Meeting is a 15-minute meeting for the Team, conducted
daily to quickly understand the work since the last Daily Scrum Meeting and
create a plan for the next 24 hours.
 This meeting is also referred to as Daily Stand up Meeting.
 The Daily Scrum Meeting is held at the same time and same place every day
to reduce complexity.
 During the meeting, each Team member explains.
-What did he do yesterday that helped the Team meet the sprint Goal?
-Does he see any impediments that prevent him or the team from meeting
the sprint Goal
-Sprint Retrospective
 In Agile development, a retrospective is a meeting held at land of each
iteration to discuss what was successful, what could be improved, and how
to incorporate the improvements and retain the successes in future iterations.
 Retrospectives cover topics such as the process, people organizations,
relationships, and tools.
www.quastech.in

12. Manual
Testing VS Automation Testing

12.1 Introduction
 Software testing is a huge domain, but it can be broadly categorized into two
areas: manual testing and automated testing.
 Both manual and automated testing offer benefits and disadvantages. It’s
worth knowing the difference, and when to use one or the other for best
results.
 In manual testing (as the name suggests), test cases are executed manually
(by a human, that is) without any support from tools or scripts.
 But with automated testing, test cases are executed with the assistance of
tools, scripts, and software.
 The type of testing (manual or automated) depends on various factors,
including
Project Requirements
Budget
Timeline
Expertise
suitability

12.2 Manual Testing Advantages & Disadvantages

Manual Testing Advantages:

Manual testing can be used in big as well as small projects Test cases can be
updated easily
Easy to learn for the new people who entered in to testing
Manual testing allows for human observation, which may be more useful if the
goal is user-friendliness or improved customer experience
If you’re only testing a simple application once, and don’t expect lots of
updates, manual testing doesn’t require you to invest in expensive tools or
software
Automation cannot replace human intuition and reasoning
www.quastech.in

Manual Testing Disadvantages:

Manual testing is not accurate at all times due to human error, hence it is less
reliable.
Manual testing is time-consuming, taking up human resources Repetition of the
Task is not much
Tiredness
Simultaneous auctions are not possible (Parallel Testing)
GUI Objects size difference & color combination etc is not easy to find out in
manual testing
Load testing & performance testing is not possible in manual testing

When to use Manual Testing:

As Soon as Possible Testing
Exploratory Testing
Usability Testing
Ad-hoc Testing

12.3 Automation Testing Advantages & Disadvantages

Automation Testing Advantages:

 Reliable: Tests perform precisely the same operations each time they are
run, thereby eliminating human error
 Repeatable: You can test how the software reacts under repeated execution
of the same operations
 Programmable: You can program sophisticated tests that bring out hidden
information from the application
 Comprehensive: You can build a suite of tests that covers every feature in
your application
 Reusable: You can reuse tests on different versions of an application, even
if the user interface changes
 Economical: As the number of resources for regression test are reduced
 Better Quality Software: Because you can run more tests in less time with
fewer resources
 Fast: Automated Tools run tests significantly faster than human users
www.quastech.in

Automation Testing Disadvantages:

 Though the automation testing has many advantages, it has its own
disadvantages too. Some of the disadvantages are
 Proficiency is required to write the automation test scripts
 Debugging the test script is major issue. If any error is present in the test
script, sometimes it may lead to deadly consequences
 Test maintenance is costly in case of playback methods. Even though a
minor change occurs in the GUI, the test script has to be re- recorded or
replaced by a new test scripts.
 Maintenance of test data files is difficult, if the test script tests more screens.
 It is expensive.
 We cannot automate all areas.

******************************************************************