Functional Testing.docx

SOFTWARE:
Software is a collection of programs that help us to perform a certain task. Piece
of code created to achieve a certain functionality
Software Types
1.System Software
2.Programming Software
3.Application Software
System Software:
System software is nothing but device drivers, OS and servers that are all comes
under system software’s
Programing Software
Programing Software's are used for compiling or debugging or interpreting your
programs.
We generally write a computer program using a high-level language.
A high-level language is one which is understandable by us humans. It contains
words and phrases from the English (or other) language.
But a computer does not understand high-level language. It only understands
program written in 0's and 1's in binary, called the machine code.
A program written in high-level language is called a source code. We need to
convert the source code into machine code, and this is accomplished by compilers
and interpreters.
Hence, a compiler or an interpreter is a program that converts program written in
high-level language into machine code understood by the computer.
Application Software
Application Software is nothing but a any application which we are using
Ex : Word, Excel, Websites

WHAT IS PRODUCT
Product is like ‘ready to use solution’ which is built by the company and sold to
different customers (or) setup as free source.
If customer requires any changes like colour, title, appearance changes and some
extra functionality to be added, then customizations are done to the product.
Examples: Google products like Gmail, Drive (Free sources) and Oracle products
like Databases etc, Warehouse Management systems of Manhattan, SAP.
WHAT IS PROJECT:
Project is ‘taking requirements from customer to build a solution’.
The requirements are gathered from aclient.
General e.g.
1.Indian railways need an application for online ticket reservation in place of
counter reservation.
Examples: Banking projects like ICICI
Products Vs Projects
Requirements gathered from market survey. Requirements gathered from
particular client.
End users are more than one. End user is one.
Develop the application for Global clients. Develop the application for
particular client.

TYPES OF APPLICATIONS
1. Desktop Application
2. Web Based application
DesktopApplication:
A desktop application means any software that can be installed on a single
computer (laptop or a desktop) and used to perform specific tasks. Some desktop
applications can also be used by multiple users in a networked environment.
Ex:
Microsoft Outlook
Windows Calculator
Skype for Windows.
WhatsApp Application
In the Desktop application, you have two different components to test.
Application is loaded on server machine while the application exe on every client
machine.
You will test broadly in categories like, GUI on both sides, functionality, Load,
client-server interaction, backend.
Web Application Testing:
Web application testing is a testing methodology focused on applications that are
hosted on the web.
Any application which can be accessed through an URL is a Web-based
application.

What is Domain in Testing?
Is nothing but a key business area. Also, we can say the industry for which the
software testing project is created. When we talk about software project or
development, this term is often referred. For example, Insurance domain, Banking
domain, Retail Domain, Telecom Domain, etc.
Different Types of Domains
BFSI(Banking financial services and Insurance)
ERP(enterprise resource planning)
Banking Application
Healthcare Application
E-commerce Applications
insurance Applications
Telecom Application
Business Intelligence
Mainframe Testing
Payment Gateway Testing
Retail POS (Point Of Sale) System
Banking Application
Banking Applications directly deal with confidential financial data.
Banking software perform various functions like transferring and depositing fund,
balance inquiry, transaction history, withdrawal and so on.
Testing banking application assures that these activities are not only executed
well but also remain protected from hackers.
Insurance Applications:
Software Systems helps them to deal with various insurance activities like
developing standard policy forms, handling billing process, managing customer's
data.

Healthcare
What is POS:
POS Testing is defined as Testing of a Point of Sale Application. A POS or Point Of
Sale software is a vital solution for retail businesses to carry out retail transactions
effortlessly from anywhere.
You must have seen Point of Sale terminal while checking out at your favourite
Mall.
E-Commerce:
Buying and selling of goods services on the internet is termed as “E-Commerce”.
Sometimes, the word “e-Business and e-Commerce” are often used
interchangeably.
Online retail selling (e-tailing) on websites with online catalogs
Retail:
Goods which are bought and sold to the end users is termed as “Retail”.
Telecom:
Telecom (Telecommunication) is a term used for the process of exchange and
transmission of messages electronically.

Utilities:
Utilities industry incorporates companies which offer services like Electric power,
Steam supply, natural gas and sewage removal.
Finance:
Financial Services include stock-broking, Payment gateways, mutual funds etc.
Payment Gateway
A payment gate-way system is an e-commerce application service
that approves credit card payment for online purchases.
Payment gateways safeguard the credit card details by encrypting sensitive
information like credit card numbers, account holder details and so on.
This information is passed safely between the customer and the merchant and
vice versa

SOFTWARE CONFIGURATION MANAGEMENT TOOLS
A software or application is made up of number of physical entities which includes
requirement documents, source codes, test cases, reports, test scripts, third party
software etc.
During the course of creating the software, series of reviews and meetings
happen, and these entities change very often.
Since all these entities are quite complex and very dynamic, it’s very important to
manage and have control on these changes.
So, here is the place or situation, where configuration management comes into
picture.
List of Software configuration management tools available are:
VSS – Visual source safe
CVS- Concurrent version system
IBM Rational Clear Case
SVN- Subversion
Perforce
TortoiseSVN
Razor
Quma version control system
Source Anywhere

BUILD AND RELEASE
Build is like converting source code file into standalone artefact
A build is a version of a program or a Package (combination of classes)
A build mainly contains the compiled package which could include the
executable exe, the libraries like dll, and archives like zip files.
Development Team creates the build and provide it to the deployment team
for installation.
Once the build is deployed, QA team is notified to do the build verification
testing (BVT) and if it is successful, the team performs the rest of
the functional testing.
basically, release decides how many features we are delivering to client or
pushing to production.
Even release of the product is not the final, release is also ongoing, some
companies may release monthly, quarterly or yearly depending on the
client need.
"Build" refers to software that is still in testing, but "release" refers to software
that is usually no longer in testing.
“Builds" occur more frequently; "releases" occur less frequently.

QUALITY STANDARDS
1. ISO (International Organization for Standardization)
2. IEEE(The Institute of Electrical and Electronics Engineers Standards
Association)
3. CMM/CMMI
Definition: Quality Standards
A product is said to be of quality if it is free from any manufacturing defect
deficiency or significant variation.
In order to do so certain specific standards, need to be set so that uniformity is
achieved in the entire set of products being manufactured.
The standard defined should be such that the features and specifications offered
by the product should be capable to meet the implied need of the product.
CMM (Capability Maturity Model)
CMM was developed and is promoted by the Software Engineering Institute
(SEI), a research and development centre sponsored by the U.S. Department of
Defence (DoD).
More specifically, SEI was established to optimize (make the best or most
effective use of) the process of developing, acquiring, and maintaining heavily
software-reliant systems for the DoD.
SEI was founded in 1984 to address software engineering issues
Later based on the CMM-SW model created in 1991 to assess the maturity of
software development, multiple other models are integrated with CMM-I.
Today CMM act as a "seal of approval" in the software industry. It helps in
various ways to improve the software quality.
The CMM is similar to ISO 9001, one of the ISO 9000 series of standards
specified by the International Organization for Standardization (ISO). The ISO
9000 standards specify an effective quality system for manufacturing and
service industries

CMM Levels
1. Initial
2. Repeatable/Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
INITIAL:
The software process is characterized as inconsistent, and occasionally
even chaotic (in a state of complete confusion and disorder). Success of the
organization majorly depends on an individual effort.
The heroes eventually move on to other organizations taking their wealth
of knowledge or lessons learnt with them.
REPEATABLE:
This level Organization has a basic and consistent project management
processes to track cost, schedule, and functionality. The process is in place
to repeat the earlier successes on projects with similar applications.
DEFINED:
All projects across the organization use an approved, tailored version of the
organization's standard software process for developing, testing and
maintaining the application.
MANAGED:
For these processes, detailed measures of process performance are
collected and statistically analyzed.
OPTIMIZING:
The Key characteristic of this level is focusing on continually improving
process performance through both incremental and innovative
technological improvements. Identify and deploy new tools and process
improvements to meet needs and business objectives

HOW THE SOW GET SIGNED
Client (Indian railways) will prepare and distribute the RFP(request for
proposal) to selected vendors
Software companies Sales and marketing team respond the RFP with their
proposal about the company, technical solutions, delivery schedule, budget
and timeline
if the Client like the proposal from any vendor, then they will sign SOW
(statement of work or Work order) with the vendor
Conducts Kick-off meeting (it’s a high- level meeting between senior manager
and BA)
Identify the project manager
Project manager will prepare the project management plan
RFP
RESPONSE
SOW
PMP
SRS

SDLC(Software Development Life Cycle)
SDLC is a process followed for a software project, within a software
organization.
It consists of a detailed plan describing how to develop, maintain, replace and
alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and
the overall development process.
Phases In SDLC
Requirement Analysis
Designing
Development or Implementation
Testing
Deployment of System
Maintenance

Requirement Analysis &Gathering:
When the client approaches the organization for getting the desired product
developed, it comes up with rough idea about what all functions the software
must perform and which all features are expected from the software.
Referencing to this information, the analysts does a detailed study about
whether the desired system and its functionality are feasible to develop.
Feasibility Study (The Possibility that can be made, done or achieved)
Defining Requirements (Or) Requirement Gathering
Once the requirement analysis is done (feasibility report is positive towards
undertaking the project) the next step is to clearly define and document the
product requirements and get them approved from the customer.
This is done through SRS (Software Requirement Specification) document
which consists of all the product requirements to be designed and developed
during the project life cycle.
DESIGNING
SRS is the reference for product architects to come out with the best
architecture for the product to be developed.
Based on the requirements specified in SRS, usually more than one design
approach for the product architecture is proposed and documented in a DDS -
Design Document Specification.
There are several tools and techniques used for describing the system design
of the system.
These tools and techniques are: Flowchart, Data flow diagram (DFD), Data
dictionary, Structured English, Decision table and Decision tree
Design Types
Architectural Design (HLD)
Module Design (LLD)

Architecture design (HLD)
The phase of the design of computer architecture and software
architecture can also be referred to as high-level design.
The baseline in selecting the architecture is that it should realize all which
typically consists of the list of modules, brief functionality of each module,
their interface relationships, dependencies, database tables, architecture
diagrams, technology details etc.
Module design (LLD)
The module design phase can also be referred to as low-level design.
The designed system is broken up into smaller units or modules and each of
them is explained so that the programmer can start coding directly.
The low-level design document or program specifications will contain a
detailed functional logic of the module, in pseudocode:
DEVELOPMENT OR IMPLEMENTATION
It means translating the design into a computer readable language.
Development team does the actual coding based on designed software and
writes unit tests for each component to test the new codes written by
them.
TESTING
The job of testing team is to test the application against the requirements.
The aim of tester is to find out the gaps or defects within the system and
also to verify that the software works as expected according to the
requirements.
DEPLOYMENT OF SYSTEM
Once the functional and non-functional testing is done; the product is
deployed in the customer environment or released into the market.

MAINTENANCE
There are some issues which come up in the client environment. To fix
those issues, patches are released. Also, to enhance the product some
better versions are released. Maintenance is done to deliver these changes
in the customer environment.
SDLC Models
Waterfall Model
Spiral Model
V Model
Prototype
Rad Model
Agile Methodology

WATERFALL MODEL
The Waterfall model is the earliest SDLC approach that was used for software
development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins
only if the previous phase is complete. In this waterfall model, the phases do
not overlap.
In "The Waterfall" approach, the whole process of software development is
divided into separate phases.
Draw Backs or Disadvantages of Waterfall Model:
this is purely dependency model, every phase is depending on other phase
we can't accommodate frequent changes in the middle of the project.
In this Waterfall model, typically, the outcome of one phase acts as the input
for the next phase sequentially.
The following illustration is a representation of the different phases of the
Waterfall Model.

Spiral Model
Basically, this model is developed for product, usually what's the behavior
of the product, product is having multiple versions.
Different colors represent different spiral or iteration. For first iteration,
represented in Full Green color, all the 4 activities (Planning, risk analysis,
engineering and evaluation) are performed.
After the evaluation phase is over for the first iteration (spiral), second
iteration (spiral) starts the second iteration, which is represented in Light
color, here again all the 4 activities (Planning, risk analysis, engineering and
evaluation) are performed.
In a similar way, third iteration is done shown in Pale color and so on the
process continues
Ex:
Windows is started with 98 after that 200 after 2003 ...2010
there are multiple versions have been released to the market similarly MS
office. 2005,2010 2016 is going on.

V-Model
The V-model is an SDLC model where execution of processes happens in a
sequential manner in a V-shape. It is also known as Verification and
Validation model.
Under the V-Model, the corresponding testing phase of the development
phase is planned in parallel. So, there are Verification phases on one side of
the ‘V’ and Validation phases on the other side.
the left-hand side shows the development activities and right-hand side
shows the testing activities.
Verification: Verification is a static analysis technique. In this technique
testing is done without executing the code. Examples include – Reviews,
Inspection and walkthrough.
Validation: Validation is a dynamic analysis technique where testing is done
by executing the code. Examples include functional and non-functional
testing techniques.
Requirement analysis: In this phase the requirements are collected,
analyzed and studied.
Verification activities: Requirements reviews.

Validation activities: Creation of UAT (User acceptance test) test cases
High level design: In this phase a high-level design of the software is build.
The team studies and investigates on how the requirements could be
implemented.
• Verification activities: Design reviews
• Validation activities: Creation of System test plan and cases, Creation of
traceability metrics
Architectural design:
• Validation activities: Integration test plan and test cases.
Module design/ Low level Design:
In this phase each and every module or the software components are
designed individually. Methods, classes, interfaces, data types etc are all
finalized in this phase.
• Validation activities: Creation and review of unit test cases
Implementation / Code: In this phase, actual coding is done.
• Verification activities: Code review, test cases review
• Validation activities: Creation of functional test cases.
Right Hand Side:
• Right hand side demonstrates the testing activities or the Validation Phase.
Unit Testing: In this phase all the unit test case, created in the Low-level design
phase are executed.
• Artifacts produced: Unit test execution results

Integration Testing: In this phase the integration test cases are executed which
were created in the Architectural design phase
Systems testing: In this phase all the system test cases, functional test cases and
nonfunctional test cases are executed. In other words, the actual and full fledge
testing of the application takes place here. Defects are logged and tracked for its
closure.
• The traceability metrics are updated to check the coverage and risk
mitigated.
• Artifacts produced: Test results, Test logs, defect report, test summary
report and updated traceability matrices.
User acceptance Testing: Acceptance testing is basically related to the business
requirements testing. Here testing is done to validate that the business
requirements are met in the user environment
• Artifacts produced: UAT results, Updated Business coverage matrices.

AGILE METHODOLOGY
Agile methodology is a practice that promotes continuous iteration of
development and testing throughout the software development lifecycle of
the project.
Agile software development is based on an incremental, iterative(frequent)
approach
Incremental Approach: We build and delivers the software incrementally
means instead trying to deliver all at once
In the Agile methodology, each project is broken up into several ‘Iterations’.
All Iterations should be of the same time duration (between 2 to 4 weeks).
Deliver Working s/w frequently from weeks to a month, here we make the first
level approach and will show it to the customer and will take the customer
feedback and we refine them.
both development and testing activities are concurrent unlike the waterfall
model
AGILE METHODOLOGY TYPES

Scrum Methodology
Scrum is a flexible process control for complex software project. It uses
iterative and incremental practices on the software product.
It became popular because of its fast iterations and active collaboration
between teams, customers, and stakeholders.
For the sake of better collaboration, there are predefined team roles
(Product Owner, Scrum Master, Scrum Team)
Scrum is based on following 3 Pillars:
Roles in Scrum
There are three chief roles in Scrum Testing – Product Owner, Scrum
Master and The Whole Team. Let's study them in detail
Product Owner:
The product owner is the key stakeholder or the lead user of the
application to be developed.
The product owner is the person who represents the customer side. He/she
have the final authority and should always be available for the team.
He/she should be reachable in case anyone has any doubts that need
clarification.

It is important for the product owner to understand and not to assign any
new requirement in the middle of the sprint or when the sprint has already
started.
Scrum Master:
Scrum Master is the facilitator of the scrum team. He/she make sure that
the scrum team is productive and progressive.
In case of any impediments, scrum master follows up and resolves them for
the team. SCRUM Master is the mediator between the PO and the team.
He / She keeps the PO informed about the progress of the Sprint.
If there are any roadblocks or concerns for the team, discuss with the PO
and get them resolved.
Like team’s Daily Standup, a standup of the SCRUM Master with the PO
happens every day.
Scrum Team:
The team usually consists of people with different skills such as developers,
automation engineers, and testers. All team members have to support each
other in order to be successful.
Sprint:
Sprint is a predefined interval or the time frame in which the work has to
be completed and make it ready for review or ready for production
deployment.
This time box usually lies between 2 weeks to 1 month. In our day to day
life when we say that we follow 1-month Sprint cycle, it simply means that
we work for one month on the tasks and make it ready for review by the
end of that month.

2. Scrum Artifacts
A scrum process includes
• User stories: They are short explanation of functionalities of the system
under test. Example for Insurance Provider is – "Premium can be paid using
the online system."
• Product Backlog: It is a collection of user stories captured for a scrum
product. The product owner prepares and maintains the product backlog.
It is prioritized by product owner, and anyone can add to it with approval
from the product owner.
• Release Backlog: A release is a time frame in which the number of
iterations is completed. Theproduct owner co-ordinates with the scrum
master to decide which stories should be targeted for a release. Stories in
the release backlog are targeted to be completed in a release.
Prioritize what all the features or backlogs we are going to deliver for
particular sprint
• Sprints: It is a set period of time to complete the user stories, decided by
product owner and developer team, usually 2-4 weeks of time.
• Sprint Backlog: It's a set of user stories to be completed in a sprint. During
sprint backlog, work is never assigned, and the team signs up for work on
their own. It is owned and managed by the team while the estimated work
remaining is updated daily. It is the list of tasks that has to be performed in
Sprint

Burn down chart
Burn-down chart represents overall progress of the work in progress and work
completed throughout the process. It represents in a graph format the stories and
features not completed
Each day, Scrum Master records the estimated remaining work for the sprint. This
is nothing but the Burn Down Chart. It is updated daily.
A burn down chart gives a quick overview of the project progress, this chart
contains information like total amount of work in the project that must be
completed, amount of work completed during each sprint and so on.
Burn Down Charts provide proof that the project is on track or not. Both burn-up
and burn-down charts are graphs used to track the progress of a project.
Burn Down Charts provide proof that the project is on track or not. Both burn-up
and burn-down charts are graphs used to track the progress of a project.
Both burn-up and burn-down charts are graphs used to track the progress of a
project.
Burn-up charts represent how much work has been completed in a project
whereas Burn-down chart represents the remaining work left in a project.

3.Ceremonies (Processes) in Scrum
1. Sprint Planning
2. Daily Scrum
3. Sprint Review/ Retrospective
Sprint Planning: A sprint begins with the team importing stories from the release
backlog into the sprint backlog; it is hosted by scrum master. The Testers estimate
effort to test the various stories in the Sprint Backlog.
In sprint planning, tester should pick a user-story from the product backlog that
should be tested.
As a tester, he/she should decide how many hours (Effort Estimation) it should
take to finish testing for each of selected user stories.
As a tester, he/she must know what sprint goals are.
As a tester, contribute to the prioritizing process
Daily Scrum: It is hosted by scrum master, it last about 15 minutes. During Daily
Scrum, the members will discuss the work completed previous day, the planned
work for the next day and issues faced during sprint. During daily stand-up
meeting team progress is tracked.
Sprint Review/ Retrospective: It is also hosted by scrum master, it last about 2-4
hours and discuss what team has accomplished in the last sprint and what lessons
were learned.
AGILE RETROSPECTIVE
An Agile retrospective is a meeting that's held at the end of an iteration in Agile
software development (ASD ).
During the retrospective, the team reflects on what happened in the iteration and
identifies actions for improvement going forward.

Each member of the team members answers the following questions:
What worked well for us?
What did not work well for us?
What actions can we take to improve our process going forward?
The retrospective is team-driven, and team members should decide together how
the meetings will be run and how decisions will be made about improvements.
ADVANTAGES OF AGILE
War Room Concept
The most advantage of Scrum would be its changeability. Scrum can take
action when something changes, e.g. requirement change from marketing.
The customers are satisfied because after every Sprint working feature of the
software is delivered to them.
If the customers have any feedback or any change in the feature, then it can
be accommodated in the current release of the product.
In Agile methodology the daily interactions are required between the business
people and the developers.
Changes in the requirements are accepted even in the later stages of the
development.
Disadvantages of Agile
 In Agile methodology the documentation is less.
 Sometimes in Agile methodology the requirement is not very clear hence
it’s difficult to predict the expected result.
 In few of the projects at the starting of the software development life cycle
it’s difficult to estimate the actual effort required.

SOFTWARE TESTING
Software testing is a process, to evaluate the functionality of a software
application with an intent to find whether the developed software met the
specified requirements or not and to identify the defects to ensure that the
product is defect free in order to produce the quality product.
Testing is basically a part of SDLC process, the main objective of testing is to
deliver the quality of software or product to the client.
Ex: Let Say client has given some requirements to develop and per that we have
developed and deliver the product to the client.
After deployment if they find a greater number of defects. Then they will come
back and they start frustrating.
to avoid that we must deliver quality product/bug free product. To do that we
should test s/w thoroughly before delivering to the customer.
No One Should Test Their Programs:
 Programming is nothing but a logic implementation of design in specified
language on a specific platform.
 It is quite natural that one cannot easily spot out the mistakes made by
himself.
 A third-party team should be there to do testing and this team should know
the functionality of the application
Importance ofTesting:
Testing is important because software bugs could be expensive or even
dangerous.
• Nissan cars have to recall over 1 million cars from the market due to
software failure in the airbag sensory detectors. There has been reported
two accident due to this software failure.
• In 2015 fighter plane F-35 fell victim to a software bug, making it unable to
detect targets correctly.

WHY TOCHOOSE TESTING
I think software is an industry has come a long way I mean we had a main frame
and we had COBAL and we had pascal and Fortran which is no longer
System quality will never go out of fashion you got to test, and you got to test in
different ways
Testing Types
• Static Testing
• Dynamic Testing
Static Testing
Static testing involves manual or automated reviews of the documents.
This review is done during an initial phase of testing to catch Defect early in STLC.
It examines work documents and provides review comments
The main objective of this testing is to improve the quality of software products
by finding errors in the early stages of the development cycle.
This testing is also called a Non-execution technique or verification testing.
Examples of Work documents-
• Requirement specifications
• Design document
• Source Code
• Test Plans
• Test Cases
• Test Scripts

Static Testing Techniques:
Review: Reviews are used to verify documents such as requirements, system
designs, code, test plans and test cases.
Walkthrough: The author of the work product explains the product to his team.
Participants can ask questions if any. A meeting is led by the author. Scribe makes
note of review comments
Inspection: The main purpose is to find defects and meeting is led by a trained
moderator. This review is a formal type of review where it follows a strict process
to find the defects. Reviewers have a checklist to review the work products. They
record the defect and inform the participants to rectify those errors.
Dynamic Testing:
• The main objective of this testing is to confirm that the software product
works in conformance with the business requirements.
• This testing is also called an Execution technique or validation testing.
• Dynamic testing executes the software and validates the output with the
expected outcome.
• Dynamic testing is performed at all levels of testing and it can be either
black or white box testing.
Conclusion:
• Verification and Validation are two measures used to check that the
software product meets the requirements specifications.
• Static testing involves verification whereas dynamic testing involves
validation. Together they help improve software quality.

Functional Testing:
Functional Testing is the type of testing done against the business
requirements of application. It is a black box type of testing.
Unit Testing
Smoke testing
Sanity testing
Integration Testing
System Testing
Re-Testing
Regression Testing
Internationalization Testing
Localization Testing
UAT
Non-Functional Testing:
Performance Testing
Load Testing
Compatibility testing
Usability Testing
Volume Testing
Security Testing

User Interface Elements
 Input Controls: checkboxes, radio buttons, dropdown lists, list boxes, buttons,
toggles, text fields, date field
 Navigational Components: breadcrumb, search field, pagination
 Informational Components: tooltips, progress bar, notifications, message
boxes
Checkboxes:Checkboxes allow the user to select one or more options from a set.
Radio buttons:Radio buttons are used to allow users to select one item at a time.
Dropdown lists: Dropdown lists allow users to select one item at a time, similarly
to radio buttons
List boxes
List boxes, like checkboxes, allow users to select a multiple item at a time
Buttons: A button indicates an action upon touch

Dropdown Button: The dropdown button consists of a button that when clicked
displays a drop-down list of mutually exclusive items.
Toggles: A toggle button allows the user to change a setting between two states.
Text fields: Text fields allow users to enter text.
Date and time pickers : A date picker allows users to select a date and/or time.

Navigational Components
Search Field:
A search box allows users to enter a keyword or phrase (query) and submit it to
search the index with the intention of getting back the most relevant results
Breadcrumb
Breadcrumbs allow users to identify their current location
Pagination: Pagination divides content up between pages

Information Components
Notifications: A notification is an update message that announces something new
for the user to see.
Tool Tips: A tooltip allows a user to see hints when they mouse over an item
SOFTWARE TESTING – METHODS
There are different methods that can be used for software testing.
Black-Box Testing
White-Box Testing
Grey-Box Testing
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.
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 and find out which
unit/chunk of the code is behaving inappropriately.
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.

Software Testing Techniques
Software Testing Techniques help you design better test cases.
1. Boundary Value Analysis (BVA)
2. Equivalence Class Partitioning
3. Decision Table based testing.
4. State Transition
5. Error Guessing
Boundary Value Analysis (BVA)
In software testing, the Boundary Value Analysis (BVA) is a black box test design
technique based on test cases. This technique is applied to see if there are
any bugs at the boundary of the input domain.
Boundary value analysis is the next part of Equivalence partitioning for designing
test cases where test cases are selected at the edges of the equivalence classes.
Ex: Username and Password
Username accepts only alpha numeric 4 to 16 char
Password accepts only alphabets with 6 to 10 chars

Equivalence Partitioning
Equivalence partitioning or equivalence class partitioning (ECP) is a software
testing technique that divides the input data of a software unit into partitions of
equivalent data from which test cases can be derived.
using equivalence partitioning you have categorized all possible test cases into
three classes. Test cases with other values from any class should give you the
same result.
This is used to reduce the total number of test cases to a finite set of testable test
cases.
One test value is picked from each class while testing. If one condition in a
partition works, we assume all of the conditions in that partition will work and if
one condition fails it is assumed that all others in the partition will fail and there is
no point in testing others.
Example 1:
Assume, we have to test a field which accepts Age 18 – 56
Invalid Input: less than or equal to 17 (<=17), greater than or equal to 57 (>=57)
Valid Class: 18 – 56 = Pick any one input test data from 18 – 56
Example 2:
Assume, we have to test a filed which accepts a Mobile Number of ten digits.

Valid input: 10 digits
Invalid Input: 9 digits, 11 digits
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.
State Transition
This testing technique allows the tester to test the behavior of an AUT. The tester
can perform this action by entering various input conditions in a sequence.
In State transition technique, the testing team provides positive as well as
negative input test values for evaluating the system behavior.
Ex:
If the user enters a valid password in any of the first three attempts the user will
be able to log in successfully.
If the user enters the invalid password in the first or second try, the user will be
prompted to re-enter the password.
When the user enters password incorrectly 3rd time, the action has taken, and
the account will be blocked.

Error Guessing
It is basically an experience-based testing technique where the test analyst uses
his / her experience to guess the problematic areas of the application.
This technique necessarily requires experienced testers. Based on the prior
testing experience with similar applications, he can easily identify the issues in the
application without going through the requirement document.
Levels of testing
Unit Testing
Integration Testing
System Testing
UAT (User Acceptance Testing)
UNIT TESTING:
A unit is a module or a small set of modules.
In Java, a unit is a class.
Unit testing is a white box testing technique, A unit is the smallest part of an
application that is ready to test. like functions, classes, procedures, interfaces.
Unit testing is a method by which individual units of source code are tested to
determine if they are ready for use. To simply define, Unit testing is testing
the smallest available unit.
This testing is basically performed by the development team.
INTEGRATION TESTING:
A System is made up of different components or modules (individual units),
Testing the interactions between such modules is called as integration testing.
Integration Testing starts with testing the interactions between few modules and
ends when all the interfaces of different systems are integrated.

Stratagies to execute Integration testing
Big Bang Approach:
Incremental Approach: which is further divided into following
Top Down Approach
Bottom Up Approach
Sandwich Approach - Combination of Top Down and Bottom Up
Big Bang Approach:
Here all component are integrated together at once, and then tested.
Incremental Approach:
In this approach, testing is done by joining two or more modules that are logically
related.
Then the other related modules are added and tested for the proper functioning.
Process continues until all of the modules are joined and tested successfully.
This process is carried out by using dummy programs called Stubs and Drivers.
Stubs and Drivers do not implement the entire programming logic of the software
module but just simulate data communication with the calling module.
Stub: Is called by the Module under Test.
Driver: Calls the Module to be tested.
Incremental Approach in turn is carried out by two different Methods:
Bottom Up
Top Down

Bottom up Integration
In the bottom up strategy, each module at lower levels is tested with higher
modules until all modules are tested.
It takes help of Drivers for testing
Top down Integration:
In Top to down approach, testing takes place from top to down following the
control flow of the software system.
Takes help of stubs for testing.

SYSTEM TESTING
System testing is performed after integration testing. This is also called End to End
testing scenario.
System Testing is the testing of a complete and fully integrated software product.
System testing means testing the system as a whole.
System test falls under the black box testing category of software testing.
1. Usability Testing
2. User Interface Testing
3. GUI
4. Functionality
5. Smoke Testing
6. Sanity Testing
7. Re-Testing
8. Regression Testing
9. Ad Hoc Testing
10.Non-Functionality Testing
11.Error Handling Testing
12.Input Domain Testing
13.Compatibility Testing
14.Concurrent/Parallel Testing
15.Performance
16.Load Testing
17.Stress Testing
18.Security
19.Authorization

20.Access Control
21.Installation Testing
22.Migration Testing
Usability testing:
Usability testing is a black box testing technique. Normally testers test if the
developed application is user friendly or not, user friendly means the application
should be easy to understand and easy to access.
Normally testers test in usability testing
How easy it is to use the application.
How easy it is to learn the application.
How convenient is the application to the end user?
GUI Testing:
GUI is what the user sees. Say if you visit mindq.com what you will see say
homepage it is the GUI (graphical user interface) of the site.
Especially the focus is on the design structure, images that they are working
properly or not.
If we have to do GUI testing, we first check that the images should be completely
visible in different browsers. Also, the links are available
UITESTING (User Interface):
Ensure That in a given application label names, menu names are all understand to
the user and are easy to operate
Easy To Use
Easy to use ensures that all Microsoft 6 rules followed by by the company are
implemented or not

1.Controls must be well known to the user
E.g. EOF may not be understood by the user so we have to expand it as End of file
and mention it clearly
2. Spell Checking
3.System menu
4.Controls must not be overlapped
5.Accuracy Of Data
E.g. There is a field amount
Amount 256
Here Amount means $256 or Rs 256
6.Controls must be visible
Brow
FUNCTIONALITY TESTING:
Functional testing is a type of software testing in which the system is tested
against the functional requirements and specifications.
To Ensure that functionality of product is working as per the requirements. It tests
the behavior of the software under test. Based on the requirement of the client.
Non-functional testing
Non-functional testing is a type of testing to check non-functional aspects
(performance, usability, reliability, etc.) of a software application
It verifies the behavior of an application.
It is based on expectations of customer.
It helps to improve the performance of the application.
Browser
Brow

1.ERROR HANDLING TESTING
Intension of this testing is finding out error by performing negative navigation.
E.g. In Username and Password fields ,
Here we are testing whether we are getting a proper message when incorrect ,
missing and empty values are given and therefore it is called as negative testing
2.Input Domain Testing
During this testing a test engineer concentrate on input domain of each input
object
1.Boundary Value Analysis
2.Equivalence Class Partition
3. What is Concurrency Testing?
• Concurrency Testing is defined as a testing technique to detect the defects
in an application when multiple users are logged in. In other words,
monitoring the effect while multiple users perform the same action at the
same time. The image below shows the concurrent testing
• Concurrent testing is also referred as multi-user testing.
4. What is Compatibility Testing?
• Compatibility Testing is a type of Software testing to check whether your
software is capable of running on different hardware, operating systems,
applications, network environments or Mobile devices.
Types of Compatibility Tests
Hardware: It checks software to be compatible with different hardware
configurations.
Operating Systems: It checks your software to be compatible with different
Operating Systems like Windows , Unix , Mac OS etc.
Software: It checks your developed software to be compatible with other
software’s. For example: MS Word application should be compatible with
other software like MS Outlook, MS Excel , Vba etc.

Network: Evaluation of performance of system in a network with varying
parameters such as Bandwidth, Operating speed, Capacity. It also checks
application in different networks with all parameters mentioned earlier.
Browser: It checks compatibility of your website with different browsers like
Firefox, Google Chrome, Internet Explorer etc.
Devices: It checks compatibility of your software with different devices like
USB port Devices, Printers and Scanners, Other media devices and Blue tooth.
Mobile: Checking your software is compatible with mobile platforms like
Android, iOS etc.
Versions of the software: It is verifying your software application to be
compatible with different versions of software. For instance checking your
Microsoft Word to be compatible with Windows 7, Windows 7 SP1 , Windows
7 SP 2 , Windows 7 SP 3.
5.Performance Testing
Execution of our application under predetermined levels of resources to estimate
performance is called performance testing
5.Load Testing
Execution of our application under predetermined levels of resources and
customer expected load to estimate performance is called load testing
6.Stress Testing
Execution of our application under predetermined levels of resources to under
maximum peak load to which the system can sustain
E.g. if the user asks to test load for 100 users, we test for 110,120 and determine
the break-even point

7.SECURITY TESTING
Whether our application provides privacy to customer operations or not
During this testing test engineer concentrate on login process for authorization
authorities of authorized users for access control and encryption/decryption to
prevent hacking.
1.Authorization
2.Access Control
Authorization
Prevent unauthorized user
Security purposes
Eg Password
Keeping login for any type of software is must
Access Control
Authorization to specific users
Here authorized users also categorized into
Users and administrators
Administrator can use all services
End users are pertaining and can use some/few services only
Login to bank application
Logout from that
Now click on Back button
It should not go in to bank home page, it should ask for login details again

Smoke Testing
Smoke Testing is done to make sure if the build we received from the
development team is testable or not. It is also called as “Day 0” check. It is done
at the “build level”.
It helps not to waste the testing time to simply testing the whole application
when the key features don’t work, or the key bugs have not been fixed yet.
Smoke testing performed on a particular build is also known as a build
verification test.
Sanity Testing
Sanity Testing is done during the release phase to check for the main
functionalities of the application without going deeper. It is also called as a subset
of Regression testing. It is done at the “release level”.
At times due to release time constraints rigorous regression testing can’t be done
to the build, sanity testing does that part by checking main functionalities.
General meaning Of
Sanity:the fact of showing good judgment and understanding:
The closer we got to the deadline for action, the more I questioned the
sanity of the decision we had taken.
Ad hoc Testing
also known as Random Testing or Monkey Testing, is a method of software
testing without any planning and documentation. The tests are conducted
informally and randomly without any formal expected results.
Ad hoc testing is an informal testing type with an aim to break the system. This
testing is usually an unplanned activity. It does not follow any test design
techniques to create test cases.
Testers randomly test the application without any test cases or any business
requirement document.

Re-Testing:
Retesting is done to confirm whether the failed test cases in the final
execution are working fine or not after the issues have been fixed.
The purpose of retesting is to ensure that the particular bug or issue is
resolved, and the functionality is working as expected.
Regression Testing
Basically, regression testing is carried out to ensure that the existing
functionality is working fine and there are no side effects of any new change or
enhancements done in the application.
In other words, Regression Testing checks to see if new defects were
introduced in previously existing functionality.
Regression testing is done to find out the issues which may get introduced
because of any change or modification in the application.
Globalization (Internationalization) Testing:
Globalization Testing is testing process to check whether software can perform
properly in any locale or culture & functioning properly with all types of
international inputs and steps to effectively make your product truly global.
This type of testing validates whether the application is capable for using all
over the world and to check whether the input accepts all the language texts.
Ex1,
if you are in India, then you have an option to use the Facebook in English,
Hindi, Marathi, Bangla, Punjabi, Gujarati or whichever language you are
comfortable with.
A person from South Africa can use Facebook in Afrikaans, one from France
can use it in France and so on.
So, based on your country and region across the globe, you can select the
language of your choice and use the app accordingly.

Ex2
In India, the Zip codes are 6 numeric digits (no alphabets). So, if you have
selected your country as India then while entering the pin code of your area, it
should only accept the 6-digit code.
If your country is Canada, then the Zip codes include 6 alphanumeric
characters.
In the above case, your application should accept the Zip code according to the
Canadian Zip code format.
Localization Testing:
Localization definition: Localization testing is testing process to validate
whether application is capable enough for using in a particular location or
country.
In this testing localization, testing is to be carried out to check the quality of
the product for particular locale/culture.
USER ACCEPTANCE TESTING (UAT)
UAT means testing a software by the user/client to determine whether it can be
accepted or not
This is final testing performed when functional, system and regression testing is
completed. The main purpose of this testing is to validate the software against
the business requirements. This validation is carried out by end users who are
familiar with the business requirements.
As user acceptance testing is the last testing carried out before the software goes
live, obviously this is the last chance for the customer to test the software and
measure if it’s fit for the purpose.
When is it performed?
This is typically the last step before the product goes live or before the
delivery of the product is accepted. This is performed after the product itself is
thoroughly tested.

Who performs UAT?
Users or client – This could be either someone who is buying a product or
someone who has had a software custom built through a software service
provider or the end user.
Types Of UAT
Alpha Testing
Beta Testing
What is Alpha Testing?
Alpha testing is a type of acceptance testing; performed to identify all possible
issues/bugs before releasing the product to the public.
Alpha testing is to ensure the quality of the product before moving to Beta testing
What is Beta Testing?
Beta Testing of a product is performed by "real users" of the software application
in a "real environment" and can be considered as a form of external User
Acceptance Testing.
Beta version of the software is released to a limited number of end-users of the
product to obtain feedback on the product quality. Beta testing reduces product
failure risks and provides increased quality of the product through customer
validation.
It is the final test before shipping a product to the customers. Direct feedback
from customers is a major advantage of Beta Testing. This testing helps to tests
the product in customer's environment.

Software Testing Life Cycle
Requirement Analysis:
During this phase, test team studies and analyzes the requirements from a testing
perspective. This phase helps to identify whether the requirements are testable
or not.
Automation feasibility for the given testing project is also done in this stage.
The QA team may interact with various stakeholders (Client, Business Analyst,
Technical Leads, System Architects etc) to understand the requirements in detail.
Entry Criteria: BRS (Business Requirement Specification)
Deliverables: List of all testable requirements, Automation feasibility report (if
applicable)

Test Planning:
In this phase typically Test Manager/Test Lead involves determining the effort and
cost estimates for the entire project.
Preparation of Test Plan will be done based on the requirement analysis.
Activities like resource planning, determining roles and responsibilities, tool
selection (if automation), training requirement etc., carried out in this phase.
Entry Criteria: Requirements Documents
Deliverables: Test Strategy, Test Plan, and Test Effort estimation document.
Test Design:
Test team starts with test cases development activity here in this phase. Test
team prepares test cases, test scripts (if automation) and test data.
Once the test cases are ready then these test cases are reviewed by peer
members or team lead. Also, test team prepares the Requirement Traceability
Matrix (RTM).
RTM traces the requirements to the test cases that are needed to verify whether
the requirements are fulfilled.
Entry Criteria: Requirements Documents (Updated version of unclear or missing
requirement)
Deliverables: Test cases, Test Scripts (if automation), Test data.
Test Environment Setup:
Test environment setup is done based on the hardware and software
requirement list.
Some cases test team may not be involved in this phase. Development team or
customer provides the test environment.
Meanwhile, test team should prepare the smoke test cases to check the readiness
of the given test environment.

Entry Criteria: Test Plan, Smoke Test cases, Test Data
Deliverables: Test Environment. Smoke Test Results.
Test Execution:
Test team starts executing the test cases based on the planned test cases.
If a test case result is Pass/Fail then the same should be updated in the test cases.
Defect report should be prepared for failed test cases and should be reported to
the Development Team through bug tracking tool (eg., Quality Center) for fixing
the defects.
Entry Criteria: Test Plan document, Test cases, Test data, Test Environment.
Deliverables: Test case execution report, Defect report, RTM
Test Closure:
The final stage where we prepare Test Closure Report, Test Metrics.
Test team analyses the test artifacts (such as Test cases, Defect reports etc.,) to
identify strategies that have to be implemented in future, which will help to
remove process bottlenecks in the upcoming projects.
Entry Criteria: Test Case Execution report (make sure there are no high severity
defects opened), Defect report
Deliverables: Test Closure report, Test metrics

Test Plan
A test plan is a document describing the scope, approach, objectives, resources,
and schedule of a software testing effort.
It identifies the items to be tested, items are not tested, who will do the testing,
the test approach followed, what will be the pass/fail criteria, training needs for
team, the testing schedule etc.
Test Plan Contents:
Test plan identifier:Unique identifying reference.
Introduction:A brief introduction about the project and to the document and
Provide an overview of the test plan.
Objective:
Test Objective is the overall goal and achievement of the test execution. The
objective of the testing is finding as many software defects as possible; ensure
that the software under test is bug free before release.
Acronyms and Definitions
IACUC: Institutional Animal Care and Use Committee

PI : Principal investigator
ACUF : Animal Care and Use Form
Staffing and training needs:
Captures the actual staffing requirements and any specific skills and training
requirements.
Schedule:States the important project delivery dates and key milestones.
Test In-Scope
List the features of the software/product to be tested.
Test In-Out of Scope/Functions and Features that will not be tested
Modules which are not listed in above section 2.1 are considered to be Out of
Scope.
Identify the features and the reasons for not including as part of testing.
Test deliverables:
The deliverables that are delivered as part of the testing process, such as test
plans, test specifications and test summary reports.
Acceptance Criteria
The issues and enhancements detailed in the release notes must be met to satisfy
the overall acceptance criteria. Test Cases authored will be marked as ‘Pass’ if the
expected results have been met; otherwise it will be marked as ‘Failed’ and a bug
will be logged in ALM (Bug tracking tool). Testing will be complete when all test
cases have passed.
The application would be accepted based on the following criteria
QA team will perform an initial smoke test
A detailed report on each release including status of the bug fixes and
enhancements.

Test Suspension and Resumption Criteria
If any defects are found which seriously impact the test progress, the QA manager
may choose to suspend testing. Criteria that will justify test suspension are:
Hardware/software is not available at the times indicated in the project schedule.
Regression Test Scope
The regression test will cover all modules that may have been affected due to the
defect fix or implementation of new requirement. Below are the point when
regression testing will takes place.
Defect fix
Enhancement requirement.
Risks and Mitigation
Risk Description Mitigation Plan
Network issues due to VPN disconnection In case of test environment limitation,
identified test cases will be executed from
onsite
Click application connectivity issue Interactions with support team to get the
access
Any delay from development team would
impact testing plan and deliverables.
Continuous interactions with Dev team to get
the builds on time
Environmental needs
Defining the environmental requirements such as hardware, software, OS,
network configurations, tools required.
Staffing and training needs :
Captures the actual staffing requirements and any specific skills and training
requirements.

Role Responsibility
Test Manager
Ensure the change management is handled properly
Ensure the test environment is adequate and available to the team
Ensure and track the builds schedules vs the timeline to complete the testing
Ensured the defects are tracked and closed in the Change Synergy in time
Ensure the test scripts are reviewed and review comments are closed in time
Ensure the validity of the data in the reports & timely report generation
Test Lead
Responsible for the development of test plans traceability matrix, test summ
other reports
Ensure the reports are sent in time and ensure the test execution progress is
Monitor defects and collection of data to capture test metrics
Provide technical guidance to the team
Senior Test
Engineer
Develop detailed test scripts and scenarios
Execute testing of the application and/or its interfaces
Identify/logs issues
Defect tracking & reporting
Provide status updates
Provide support to test leads as required
Script review
Technical guidance to engineers
Test Engineer
Understand application functionality and requirements
Execute test cases
Document and report bugs

Entry Criteria:
Entry criteria is a set of conditions that permits a task to perform, or in absence of
any of these conditions, the task cannot be performed.
For Instance, to start the Test Cases development phase, the following conditions
should be met
The requirement document should be available.
Complete understanding of the application flow is required.
The Test Plan Document should be ready.
Exit Criteria
Exit Criteria for STLC phases can be defined as items/documents/actions/tasks
that must be completed before concluding the current phase and moving on to
the next phase.
For Instance, to conclude the Test Cases development phase, following
expectations should be met −
Test Cases should be written and reviewed.
Test Data should be identified and ready.
Test automation script should be ready if applicable.
Issue Management
Issues or concerns raised during the testing phase are tracked in the customized
query tracking sheet. Action Items are planned for the Issues or Concerns raised
by the client and will be tracked periodically to the closure.
Change Management
Any changes made to the identified configuration items should be reviewed by
Test Lead/Manager.
Any changes in scope are addressed by CR. Estimation and Impact analysis, and an
approval has to obtain.

Test Scenarios
Identify all possible areas to be tested (or) What is to be tested or A concept
which provides one-line information about what to test.
How to create a Test Scenario
As a tester, you can follow these steps to create Test Scenarios-
Step 1: Read the Requirement Documents like BRS, SRS, FRS. You could also refer
uses cases, books, manual, etc. of the application to be tested.
Step 2: For each requirement, figure out possible user's actions and objectives.
Determine the technical aspects of the requirement.
Step 3: Once you have listed all possible Test Scenarios, a Traceability Matrix is
created to verify that each & every requirement has a corresponding Test
Scenario
Entry Criteria to Identify Test Scenarios
Approved Test Plan
Approved SRS
Tests Scenarios Template
Exit Criteria to Identify Test Scenarios:
Test Scenarios Should be reviewed and approved (Mapping test scenarios with
requirements)
Once Test Scenarios are approved test lead will create baseline (TS1.0) and he
will update into Configuration Repository
Test Scenario Template

Test Scenarios of ATM Machine
1. Verify that there are limited number of attempts up to which user is
allowed to enter pin code
2. Verify that pin is encrypted and when entered
3. Verify that user is only allowed to enter amount in multiples of
denominations as per the specifications
4. Verify that user is not allowed to exceed one day transaction limit amount
5. Verify that user is not allowed to proceed with expired ATM card
6. Verify that in case ATM machine runs out of money, proper message is
displayed to user
7. Verify that in case sudden electricity loss in between the operation, the
transaction is marked as null and amount is not withdrawn from user's
account
8. Verify that user cannot fetch more amount than the total available balance

Test Cases
A concept which provides detailed information what to test, steps to be taken and
expected result of the same
A test case is a document which consists of a set of input values, conditions or
actions which are performed on the software application in order to verify the
expected functionality of the feature.
A sample test case
Below is the description of the test case fields/columns
Test case ID : The ID of the test case
Test case description : The objective or summary of the test case
Prerequisites : Any preconditions which need to be executed before starting the t
Test steps : Procedure to execute the test
Test data : Data required while executing the test
Expected Result : The expected output of the test

Actual Result : The actual output of the test
Status :
Pass, Fail, ‘Not executed’ when test case is not executed and ‘Bloc
bug is found
Created By : Name of the person who wrote the test case
Date of creation : The date on which the test case was authored
Executed By : Name of the person who ran or executed the test case
Date of execution : The date on which the test case was executed
What is RTM (Requirement Traceability Matrix)?
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 doing Software testing.

Defect Life Cycle
A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect from which
it goes through covering the different states in its entire life. This starts as soon as
any new defect is found by a tester and comes to an end when a tester closes that
defect assuring that it won’t get reproduced again.
Defect States:
1)New: This is the first state of a defect in the defect life cycle. When any new
defect is found, it falls in a ‘New’.
2) Assigned: In this stage, a newly created defect is assigned to the development
team for working on the defect. This is assigned by the project lead or the
manager of the testing team to a developer.

3) Open: Here, the developer starts the process of analyzing the defect and works
on fixing it, if required. If the developer feels that the defect is not appropriate
then it may get transferred to any of the below four states namely Duplicate,
Deferred, Rejected or Not a Bug-based upon the specific reason.
Rejected: If the defect is not considered as a genuine defect by the developer
then it is marked as ‘Rejected’ by the developer.
Duplicate: If the developer finds the defect as same as any other defect or if the
concept of the defect matches with any other defect then the status of the defect
is changed to ‘Duplicate’ by the developer.
Deferred: If the developer feels that the defect is not of very important priority
and it can get fixed in the next releases or so in such a case, he can change the
status of the defect as ‘Deferred’.
Not a Bug: If the defect does not have an impact on the functionality of the
application then the status of the defect gets changed to ‘Not a Bug’.
4) Fixed Or Resolved : When the developer finishes the task of fixing a defect by
making the required changes then he can mark the status of the defect as ‘Fixed’.
5) Pending Retest: After fixing the defect, the developer assigns the defect to the
tester for retesting the defect at their end and till the tester works on retesting
the defect, the state of the defect remains in ‘Pending Retest’.
6) Retest: At this point, the tester starts the task of working on the retesting of
the defect to verify if the defect is fixed accurately by the developer as per the
requirements or not.
7) Reopen: If any issue still persists in the defect then it will be assigned to the
developer again for testing and the status of the defect gets changed to ‘Reopen’.
8) Verified: If the tester does not find any issue in the defect after being assigned
to the developer for retesting and he feels that if the defect has been fixed
accurately then the status of the defect gets assigned to ‘Verified’.
9) Closed: When the defect does not exist any longer than the tester changes the
status of the defect to ‘Closed’.

Defect Identification
While Executing the test cases, If the expected result is not matched with actual
result or Application is not working as per SRS, then we will report it as a defect
Defect Reporting – Guideline to log defects:
The moment test engineer identifies the defect in the current project/application
we should fallow below bug guidelines
1. Reproduce the bug in same computer
2. Reproduce the bug in peers(colleague) computer
3. Check the defect data base for duplicate
4. Once all the verification done login to defect tracking tool like Jira, ALM and
Submit the defect to developer
5. At the time of reporting defect status is new
6. Defect can be reported in two ways
1. Manually
2. Using Tool
Manually : Copy template from file server or VSS and fill the template and send an
e-mail to assigned person defect as an attachment
Using Tool : Using specific defect tracking tool

Bug tracking system or Defect tracking system :
A bug tracking system or defect tracking system is a software application that
keeps track of reported software bugs in software development projects.
Defect tracking tools are applications which help us to record, report and monitor
the bugs in a software development project
List of Popular Defect Tracking Tools:
1. BUGZILLA:
2. HP ALM
3. JIRA
4. MANTIS:
5. TRAC
6. IBM RATIONAL CLEARQUEST
7. SALESFORCE
8. REDMINE
9. FOGBUGZ
10.YOUTRACK
11.BUGNET

JIRA (developed by Atlassian):
According to Atlassian, Thousands of software professionals use JIRA as a bug-
tracking tool because of its easy to use framework.
JIRA is a commercial product and helps to capture and organize the team issues,
prioritizing the issue and updating them with the project.
Different Types of Jira Issues
It not just allows us to file bugs but also enables us in other kinds of ‘tickets’ or
‘requests. It is more of a general request management application.
Different organizations may have different types of issues depending upon
their suitability/ needs. A Jira administrator can efficiently customize this field.
Different Types of Jira Issues
Bug: This is any defect or deviation that is found in the application.
Enhancement request: It is also known as a change request (CR). This type is
used to depict any change in the existing functionality or altogether a new
functionality.
Task: This is more of a configuration or analysis issue. For Example, setting up
proper configurations can be a task.
Question: Issue can be as simple as asking a question about how to use some
functionality in the application. This type is more often used by the end
customers.
Story: Entire user story about a feature could be a type of issue.
Test case: Issue can be a test case. This type of issue will be available once Jira
is integrated with plug-ins like Zypher.

Creating A Jira Issue
Assuming that a user has logged into Jira and the desired project.
Step 1:
Click on ‘+’ (‘Create’) toolbar button.
This will open up the ‘Create issue’ page as displayed in the following images:
Step 2:
Enter the mandatory details and other data as much as possible on the ‘Create
issue’ page.
Description of Fields on ‘Create issue’ Page

#1) Summary:
This is also more often called as the title of the issue, The title should be unique
so that by looking at the title itself, the issue can be understood.
#2) Component/s:
Name(s) of the module or area of the application where the defect is detected
#3) Description:
Typically should contain the steps to reproduce the issue if the issue type is a bug.
In case of an enhancement request, it should detail about the new requirement
which is typically called as a story in the agile terminology.
#4) Fix Versions:
Name of the version in which the issue/enhancement request will be delivered.
This value is typically filled by the product owner in co-ordination with the scrum
master in an agile scrum environment.
#5) Priority:
This field indicates the criticality of the issue.
Priority indicates how soon the bug should be fixed
Let see an example of low severity and high priority and vice versa
A very low severity with a high priority: A logo error for any shipment website,
can be of low severity as it not going to affect the functionality of the website but
can be of high priority as you don't want any further shipment to proceed with
the wrong logo.
SEVERITY:
Severity defines the importance of defect with respective to functional point of
view, means criticalness of defect with respective to application. Severity
indicates the seriousness of the defect on the product functionality
The impact of the defect on our application.

Critical : A major functionality is failed testing can't continue
High : A major functionality is not working properly, and testing can continue
Medium : A minor issues that imposes some loss of functionality and testing
can be processed
Low : Usability and UI issues
#6) Labels:
This field is entered with the texts which will help in categorizing issues.
#7) Environment:
This is an optional field and the test environment is specified here.
#8) Attachment:
Supporting images for the issue being created. The user can simply drag and drop
images or copy and paste.
#9) Affects Version/s:
For a ‘bug’ type of issue, the product version should be entered here.
For Example 5.6, 5.7 etc.
#10) Linked Issues:
Other relevant issues can be linked to the new issue by choosing a proper value
from this drop-down.
#11) Assignee:
It is the name of the user who will be working on the issue.
For instance, in the case of a bug, it will be the name of the developer who will fix
the issue. This field is typically filled by the product owner or scrum master. Again
who assigns the issue may vary from one organization to another.
#13) Sprint:
Name of the sprint is selected here, indicating when the issue will be worked
upon. It could be a future sprint as decided by the product owner.

#14) Reporter:
This filed is auto-populated by Jira with the name of the logged in user.
Error : It belongs to coding. It is a runtime error (If there is an error in coding, it is
not converted into .EXE code).
Ex: Syntax errors
Defect : It belongs to functionality. The mismatch between Expected and Actual
values.
Bug : We report the defects to the development team, and then they perform
debugging. Now those defects treated as Bug in Development site and Defect in
testing site.
“A mistake in coding is called Error, error found by tester is called Defect, defect
accepted by development team then it is called Bug, build does not meet the
requirements then it Is Failure.”
Bug Leakage:
Bug leakage is something, when the bug is discovered by the end users or
customer, and not detected by the testing team while testing the software.
Bug (defect) Age:
Bug (defect) Age is the difference in time between the date a defect is detected
(confirmed and assigned) and the defect was fixed (verified and closed).
Defect triage meeting?
Defect Triage is also known as Bug Triage.
The purpose of defect triage meeting in Software Development Process is to
prioritize the defects based on its severity, risk, reoccurrence etc.,

Bug Triage Meeting is done to sort out the priority of all open bugs. When and
how these open bugs need to be fixed is decided in this Defect Triage Meeting.
Defect Triage Template
Before the kickstart of every Defect Triage Meeting, the Test Lead shares the
defect report to all the participants in a specific format and the report pulled out
from the Defect Management Tool like HP ALM,Jira etc.
• Process of Defect Triage Meeting?
• Defect triage process is as follows:
• Defect Review
• Defect Assessment
Process of Defect Triage Meeting?
Defect triage process is as follows:
Defect Review
Defect Assessment
Defect Assignment
Triage team reviews the defects to fix the defects. Defect assessment will
be done on the basis of defect severity. In this assessment process, the triage
team will decide whether these defects are needed to be fixed or kept on hold or
removed from the list. The defects which are in the list of ‘to be fixed’ will be
assigned to the concerned department/person after proper analysis of the
defects.
Participants in the Defect Triage Meeting?
Test Lead, Development Lead, and Project Manager are the main
participants in the Defect Triage Meeting as these people will discuss all the
defects and take necessary action. It’s more like having one person from each
department.

Testing Metrics
Software testing metrics are the best way of measuring and monitoring the
various testing activities performed by the team
helps to estimate the progress, quality, and health of a software testing effort.
Test Case Productivity:
This metric gives the test case writing productivity based on which one can have a
conclusive remark.
Test Case Productivity = [Total Row Steps/Effort(hours)] Steps/hour
Efforts took for writing 183 steps is 8 hours.
TCP=183/8=22.8
Test case productivity = 23 steps/hour
Text Execution Productivity
This metric gives the test cases execution productivity which on further analysis
can give conclusive result.
Percentage test cases executed= (No of test cases executed/ Total no of test cases
written) X 100
Test Case Pass Percentage:
Passed Test Cases Percentage = (Number of Passed Tests/Total number of tests
executed) X 100
Test Case Pass Percentage:
Failed Test Cases Percentage = (Number of Failed Tests/Total number of tests
executed) X 100
Defect Acceptance:
This metric determines the number of defects accepted during execution.
Defect Acceptance = Number Of Valid Defects/Total Number Of Defects *100

Defect Rejection:
This metric determines the number of defects rejected during execution.
Defect Rejection = Number of Defects Rejected /Total Number Of Defects *100
Fixed Defect Percentage:
Fixed Defects Percentage = (Defects Fixed/Defects Reported) X 100
Avg Time Taken for Defect Fix:
Average time for a development team to repair defects = (Total time taken for
bugfixes/Number of bugs)
Kick Off Meeting:
It is an initial meeting conducted in the software company, soon after the project
is signed off, in order to discuss the overview of the project and also to select a
project manager.
Usually Project managers, Technical managers, Quality managers, High level
management, Test leads, Development leads and sometimes customer
representatives will be involved in this meeting.
Note: Apart from this meeting any kind of startup meeting during the process can
be considered as ‘Kick off Meeting`.
What Is Release Notes
Release notes are documents that are shared with end users, customers and
clients of an organization
Release notes may include the following sections:
Header - Name of the document, which carries product name, release number,
release date, release note date and version.
Purpose - An overview of the purpose of the release notes which lists the new
feature, enhancements and defects of the current build.

QUALITY CONTROL: (DEFECT DETECTION, CORRECTION)
A product is built and tested for the expected result, on noticing any difference in
actual result, a defect is logged and fixes are given. This process repeats until all
the test results are passed. Thus, QC is defect detection and correction-oriented
approach.
QUALITY ASSURANCE (DEFET PREVENTION)
On the other hand, Quality assurance concentrates on defect prevention instead
of defect correction.
QA approach incorporates some standards to prevent defects which includes:
Reviewing the requirements before designing phase.
Review design before product is built.
Ensure coding is developed based on standards.
Requirements gathered from market survey.

Functional Testing.docx

Recommended

Recommended

More Related Content

Similar to Functional Testing.docx

Similar to Functional Testing.docx (20)

Recently uploaded

Recently uploaded (20)

Functional Testing.docx