Software testing-in-gurgaon

Prepared by: AP Edusoft Software Solutions
http://apedusoft.com/ 1AP Edusoft Software Solutions

Manual Testing
 Manual testing is the process of manually
testing software for defects. It requires a tester to
play the role of an end user and use most of all
features of the application to ensure correct behavior.
 Day 1
What is testing?
 Software testing is a process of executing a
program or application with the intent of finding
the software bugs.

Introduction of Software Testing.
 Testing is a process used to help identify the correctness,
completeness and quality of developed computer software.
With that in mind, testing can never completely establish
the correctness of computer software.
Objectives of Testing.
 To discuss the distinctions between validation testing and
defect testing
 To describe the principles of system and component testing
 To describe strategies for generating system test cases
 To understand the essential characteristics of tool used for test
automation

Responsibilities of tester
 Analyzing the Requirements from the client
 Participating in preparing Test Plans
 Preparing Test Scenarios
 Preparing Test Cases for module, integration and system testing
 Preparing Test Data’s for the test cases
 Preparing Test Environment to execute the test cases
 Analyzing the Test Cases prepared by other team members
 Executing the Test Cases
 Defect Tracking
 Giving mandatory information of a defect to developers in order to fix it
 Preparing Summary Reports
 Preparing Lesson Learnt documents from the previous project testing experience
 Preparing Suggestion Documents to improve the quality of the application
 Communication with the Test Lead / Test Manager
 Conducting Review Meetings within the Team

Attribute of a Tester
 1. Be Skeptical Don’t believe that the build given by developers is bug free or quality
outcome. Question everything. Accept the build only if you test and find it defect free.
Don’t believe anyone whatever be the designation they hold, just apply your knowledge
and try to find errors. You need to follow this till the last testing cycle.
 2. Don’t Compromise on Quality Don’t compromise after certain testing stages. There
is no limit for testing until you produce a quality product. Quality is the word made by
software testers to achieve more effective testing. Compromising at any level leads to
defective product, so don’t do that at any situation.
 3.Ensure End User Satisfaction Always think what can make end user happy. How
they can use the product with ease. Don’t stop by testing the standard requirements. End
user can be happy only when you provide an error free product.
 4. Think from Users Perspective Every product is developed for customers. Customers
may or may not be technical persons. If you don’t consider the scenarios from their
perspective you will miss many important bugs. So put yourself in their shoes. Know
your end users first. Their age, education even the location can matter most while using
the product. Make sure to prepare your test scenarios and test data accordingly. After all
project is said to be successful only if end user is able to use the application successfully.

 5. Prioritize Tests First identify important tests and then prioritize
execution based on test importance. Never ever execute test cases
sequentially without deciding priority. This will ensure all your
important test cases get executed early and you won’t cut down on
these at the last stage of release cycle due to time pressure. Also
consider the defect history while estimating test efforts. In most cases
defect count at the beginning is more and goes on reducing at the end
of the test cycle.
 6. Never Promise 100% Coverage Saying 100% coverage on paper is
easy but practically it is impossible. So never promise to anyone
including clients about total test coverage. In business there is a
philosophy – “Under promise and over deliver.” So don’t goal for 100%
coverage but focus on quality of your tests.
 7. Be Open to Suggestions Listen to everyone even though you are an
authority on the project having in depth project knowledge. There is
always scope for improvements and getting suggestions from fellow
software testers is a good idea. Everyone’s feedback to improve the
quality of the project would certainly help to release a bug free
software.

 8. Start Early Don’t wait until you get your first build for testing. Start
analyzing requirements, preparing test cases, test plan and test
strategy documents in early design phase. Starting early to test helps to
visualize complete project scope and hence planning can be done
accordingly. Most of the defects can be detected in early design and
analysis phase saving huge time and money. Early requirement analysis
will also help you to question the design decisions.
 9. Identify and Manage Risks Risks are associated with every project.
Risk management is a three step process. Risk identification, analysis
and mitigation. Incorporate risk driven testing process. Priorities
software testing based on risk evaluation.
 10. Do Market Research Don’t think that your responsibility is just to
validate software against the set of requirements. Be proactive, do your
product market research and provide suggestions to improve it. This
research will also help you understand your product and its market.

 The test team must have a vision – clear direction from
the management in order to be productive. Otherwise
the team will end up heading in different directions.
State the objectives of the test team and seek approval
of these with senior management. Some examples of
good test objectives are:
 Assess software quality
 Help achieve software quality
 Assess and report on risk
 Help preserve software quality
Test Team Structure & Test Candidates

 Key motivators for testers
There are a number of aspects in addition to the standard
motivators that are specific for testers:
 Clear goals and vision for testing. It is important to know
where we are heading in testing and that this is agreed with
senior management. Discuss the 'terms or reference for
testing' with your team, produce a one page document and
publicize it. This shows commitment towards testing.
 Support for your testers. It is important, as a test manager,
that we listen to the team and if the need arises – we fight the
'tester's corner'. Discuss various courses and staff
development with your team. Think about sending them on
testing courses, conferences or testing seminars to improve
their skill.

 It is also important that we are seen to strike the right balance
between 'hands-off' and 'hands-on' test management. Small
things like sitting with the testers rather than in a large office
and actually helping with testing will motivate the team. It
shows them that you are involved rather than removed.
 Promoting the value of testing. Another way we can
motivate the team is to promote the value of testing at every
opportunity. This is such an important aspect because so
often testers are not valued for the work they do. The primary
reason, I believe, is that we do not produce anything that is
'tangible'. We must constantly reflect and report on how
individuals, as well as the whole team, have added value to
the project and company.
 Career path & Salary acknowledged. Salaries for testers
should reflect their skill and the value that they add to the
company. There should be no differentiation between tester,
developer and designer's salary structures.

Motivating your team
 Understanding motivation
 Motivated testers will be more productive. What are the key signs of
our testers being motivated and more importantly – how do we
recognize when they are de-motivated?
Before we look at the key motivational areas for testers we should ask
ourselves four basic questions:
 1. What is motivation?
 The Dictionary's definition of motivation is "to cause someone to act in
a certain way" Motivation is the will to act. It was once assumed that
motivation had to be injected from the outside but it is now
understood that everyone is motivated by several different forces.
 2. Why is motivation important?
 For the employee, the chief advantage is job satisfaction. For the
employer, it can mean good quality work. Motivation encourages
higher productivity in the organization.

Signs of motivation Signs of de-motivation
High performance Apathy & indifference
Drive & enthusiasm Dissatisfaction
Co-operation in overcoming problems Poor time-keeping/high absenteeism
Keen to achieve results Resists change
Accept responsibility Exaggeration of disputes
Working long hours! Generally uncooperative
Happiness & enjoyment Blame
Welcomes change Withdrawal

 3. Whose responsibility is it to motivate?
 Motivation should not be left to the manger. It is everyone's
responsibility to motivate! Self-motivation is however longer-
lasting, we should therefore encourage self-motivated staff
further by trusting them to work on their own initiatives and
encourage them to take responsibility for entire tasks.
 4. Should motivation be long or short term?
 Motivation should be both short term and long term.
 There have been numerous studies on motivation and
various theories produced. To help with the understanding of
motivation further we shall take a brief look at two such
theories: Hertzberg's theory and Maslow's theory.

Test Environment
 What is Test Environment?
 Test Environment consists of elements that support test
execution with software, hardware and network configured.
Test environment configuration must mimic the production
environment in order to uncover any
environment/configuration related issues.
 Factors for designing Test Environment:
 Determine if test environment needs archiving in order to
take back ups.
 Verify the network configuration.
 Identify the required server operating system, databases and
other components.
 Identify the number of license required by the test team.

 Environmental Configuration:
 It is the combination of hardware and software environment
on which the tests will be executed. It includes hardware
configuration, operating system settings, software
configuration, test terminals and other support to perform
the test.
 Example:
 A typical Environmental Configuration for a web-based
application is given below:
 Web Server - IIS/Apache
 Database - MS SQL
 OS - Windows/ Linux
 Browser - IE/FireFox
 Java version : version 6

Software Development Life
Cycle Models
 Software Development Life Cycle is a process used by
software industry to design, develop and test high quality
software. The SDLC aims to produce a high quality
software that meets or exceeds customer expectations,
reaches completion within times and cost estimates.
 SDLC is the acronym of Software Development Life Cycle.
 It is also called as Software development process.
 The software development life cycle (SDLC) is a framework
defining tasks performed at each step in the software
development process.
 ISO/IEC 12207 is an international standard for software life-
cycle processes. It aims to be the standard that defines all the
tasks required for developing and maintaining software.

 What is SDLC?
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.
The following figure is a graphical representation of the
various stages of a typical SDLC.

SDLC Models There are various software development life cycle models defined and
designed which are followed during software development process. These
models are also referred as "Software Development Process Models". Each
process model follows a Series of steps unique to its type, in order to ensure
success in process of software development.
 Following are the most important and popular SDLC models followed in the
industry:
 Waterfall Model
 Incremental or Iterative Model
 Spiral Model
 RAD
 V-Model
The other related methodologies are
 Agile Model
 Rapid Application Development
 Prototyping Models.

 Waterfall approach was first SDLC Model to be used
widely in Software Engineering to ensure success of
the project. In "The Waterfall" approach, the whole
process of software development is divided into
separate phases. In Waterfall model, typically, the
outcome of one phase acts as the input for the next
phase sequentially.
 Following is a diagrammatic representation of different
phases of waterfall model.
Waterfall Model

The sequential phases in Waterfall model are:
 Requirement Gathering and analysis: All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification doc.
 System Design: The requirement specifications from first phase are studied in this phase and
system design is prepared. System Design helps in specifying hardware and system requirements and
also helps in defining overall system architecture.
 Implementation: With inputs from system design, the system is first developed in small programs
called units, which are integrated in the next phase. Each unit is developed and tested for its
functionality which is referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase are integrated into a
system after testing of each unit. Post integration the entire system is tested for any faults and
failures.
 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

Waterfall Model Adv. & Dis-Adv.
 Advantage
 The advantage of waterfall development is that it allows for
departmentalization and control. A schedule can be set with
deadlines for each stage of development and a product can proceed
through the development process model phases one by one.
 Development moves from concept, through design,
implementation, testing, installation, troubleshooting, and ends up
at operation and maintenance. Each phase of development
proceeds in strict order.
 Disadvantage
 The disadvantage of waterfall development is that it does not allow
for much reflection or revision. Once an application is in the
testing stage, it is very difficult to go back and change something
that was not well-documented or thought upon in the concept
stage.

Iterative Model
Iterative process starts with a simple implementation of a
subset of the software requirements and iteratively
enhances the evolving versions until the full system is
implemented. At each iteration, design modifications are
made and new functional capabilities are added. The basic
idea behind this method is to develop a system through
repeated cycles (iterative) and in smaller portions at a time
(incremental).
Following is the pictorial representation of Iterative and
Incremental model:

Iterative Model Application
Like other SDLC models, Iterative and incremental development
has some specific applications in the software industry. This
model is most often used in the following scenarios:
 Requirements of the complete system are clearly defined and
understood.
 Major requirements must be defined; however, some
functionalities or requested enhancements may evolve with time.
 There is a time to the market constraint.
 A new technology is being used and is being learnt by the
development team while working on the project.
 Resources with needed skill set are not available and are planned to
be used on contract basis for specific iterations.
 There are some high risk features and goals which may change in
the future.

Iterative Model Adv and Dis-Adv.
 The advantage of this model is that there is a working
model of the system at a very early stage of development
which makes it easier to find functional or design flaws.
Finding issues at an early stage of development enables
to take corrective measures in a limited budget.
 The disadvantage with this SDLC model is that it is
applicable only to large and bulky software development
projects. This is because it is hard to break a small
software system into further small serviceable
increments/modules.

Spiral Model
The spiral model combines the idea of iterative development with the systematic, controlled aspects
of the waterfall model.
Spiral model is a combination of iterative development process model and sequential linear
development model i.e. waterfall model with very high emphasis on risk analysis.
It allows for incremental releases of the product, or incremental refinement through each iteration
around the spiral.
The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called Spirals.
 Identification: This phase starts with gathering the business requirements in the baseline spiral. In
the subsequent spirals as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
 This also includes understanding the system requirements by continuous communication between
the customer and the system analyst. At the end of the spiral the product is deployed in the
identified market.

 Design: Design phase starts with the conceptual design in the baseline spiral and
involves architectural design, logical design of modules, physical product design and
final design in the subsequent spirals.
 Construct or Build: Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design
is being developed a POC (Proof of Concept) is developed in this phase to get customer
feedback.
 Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to customer for feedback.
 Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and
cost overrun. After testing the build, at the end of first iteration, the customer evaluates
the software and provides feedback.
Following is a diagrammatic representation of spiral model listing the activities in each
phase:

Spiral Model Application
Spiral Model is very widely used in the software industry as it is
in synch with the natural development process of any product
i.e. learning with maturity and also involves minimum risk for
the customer as well as the development firms. Following are the
typical uses of Spiral model:
 When costs there is a budget constraint and risk evaluation is
important.
 For medium to high-risk projects.
 Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
 Customer is not sure of their requirements which is usually the
case.
 Requirements are complex and need evaluation to get clarity.
 New product line which should be released in phases to get enough
customer feedback.
 Significant changes are expected in the product during the
development cycle.

 Spiral Model Adv. and Dis-Adv.
 The advantage of spiral lifecycle model is that it allows for
elements of the product to be added in when they become
available or known. This assures that there is no conflict
with previous requirements and design.
 This method is consistent with approaches that have
multiple software builds and releases and allows for
making an orderly transition to a maintenance activity.
Another positive aspect is that the spiral model forces
early user involvement in the system development effort.
 On the other side, it takes very strict management to
complete such products and there is a risk of running the
spiral in indefinite loop. So the discipline of change and
the extent of taking change requests is very important to
develop and deploy the product successfully.

V- Model
 The V - model is SDLC model where execution of processes happens in a
sequential manner in V-shape. It is also known as Verification and Validation
model.
 V - Model is an extension of the waterfall model and is based on association of
a testing phase for each corresponding development stage. This means that for
every single phase in the development cycle there is a directly associated
testing phase. This is a highly disciplined model and next phase starts only
after completion of the previous phase.
 V- Model design
Under 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. Coding phase joins the two sides of the V-
Model.
The below figure illustrates the different phases in V-Model of SDLC.

Verification Phases
Following are the Verification phases in V-Model:
 Business Requirement Analysis: This is the first phase in the
development cycle where the product requirements are understood
from the customer perspective. This phase involves detailed
communication with the customer to understand his expectations
and exact requirement. This is a very important activity and need to
be managed well, as most of the customers are not sure about what
exactly they need. The acceptance test design planning is done at
this stage as business requirements can be used as an input for
acceptance testing.
 System Design: Once you have the clear and detailed product
requirements, it.s time to design the complete system. System
design would comprise of understanding and detailing the
complete hardware and communication setup for the product
under development. System test plan is developed based on the
system design. Doing this at an earlier stage leaves more time for
actual test execution later.

 Architectural Design: Architectural specifications are understood and
designed in this phase. Usually more than one technical approach is proposed
and based on the technical and financial feasibility the final decision is taken.
System design is broken down further into modules taking up different
functionality. This is also referred to as High Level Design (HLD).
 The data transfer and communication between the internal modules and with
the outside world (other systems) is clearly understood and defined in this
stage. With this information, integration tests can be designed and
documented during this stage.
 Module Design:I n this phase the detailed internal design for all the system
modules is specified, referred to as Low Level Design (LLD). It is important
that the design is compatible with the other modules in the system architecture
and the other external systems. Unit tests are an essential part of any
development process and helps eliminate the maximum faults and errors at a
very early stage. Unit tests can be designed at this stage based on the internal
module designs.

V- Model Application
V- Model application is almost same as waterfall model, as both the models are
of sequential type. Requirements have to be very clear before the project starts,
because it is usually expensive to go back and make changes. This model is
used in the medical development field, as it is strictly disciplined domain.
Following are the suitable scenarios to use V-Model:
 Requirements are well defined, clearly documented and fixed.
 Product definition is stable.
 Technology is not dynamic and is well understood by the project
team.
 There are no ambiguous or undefined requirements.
 The project is short.
V- Model Adv. and Dis-Adv.
The advantage of V-Model is that it.s very easy to understand and apply. The
simplicity of this model also makes it easier to manage. The disadvantage is
that the model is not flexible to changes and just in case there is a requirement
change, which is very common in today.s dynamic world, it becomes very
expensive to make the change.

Agile Model
 Agile SDLC model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working
software product.
 Agile Methods break the product into small incremental builds. These builds are
provided in iterations. Each iteration typically lasts from about one to three weeks. Every
iteration involves cross functional teams working simultaneously on various areas like
planning, requirements analysis, design, coding, unit testing, and acceptance testing.
 At the end of the iteration a working product is displayed to the customer and important
stakeholders.
 What is Agile?
 Agile model believes that every project needs to be handled differently and the
existing methods need to be tailored to best suit the project requirements. In agile
the tasks are divided to time boxes (small time frames) to deliver specific features for
a release.
 Iterative approach is taken and working software build is delivered after each
iteration. Each build is incremental in terms of features; the final build holds all the
features required by the customer.
 Here is a graphical illustration of the Agile Model:

Following are the Agile Manifesto principles
Individuals and interactions - in agile development, self-organization and
motivation are important, as are interactions like co-location and pair
programming.
Working software - Demo working software is considered the best means of
communication with the customer to understand their requirement, instead of
just depending on documentation.
Customer collaboration - As the requirements cannot be gathered
completely in the beginning of the project due to various factors, continuous
customer interaction is very important to get proper product requirements.
Responding to change - agile development is focused on quick responses to
change and continuous development.

The RAD (Rapid Application Development) model is based on prototyping
and iterative development with no specific planning involved. The process of
writing the software itself involves the planning required for developing the
product.
Rapid Application development focuses on gathering customer requirements
through workshops or focus groups, early testing of the prototypes by the
customer using iterative concept, reuse of the existing prototypes
(components), continuous integration and rapid delivery.
RAD Model

 What is RAD?
 Rapid application development (RAD) is a software development
methodology that uses minimal planning in favor of rapid
prototyping. A prototype is a working model that is functionally
equivalent to a component of the product.
 In RAD model the functional modules are developed in parallel as
prototypes and are integrated to make the complete product for
faster product delivery.
 Since there is no detailed preplanning, it makes it easier to
incorporate the changes within the development process. RAD
projects follow iterative and incremental model and have small
teams comprising of developers, domain experts, customer
representatives and other IT resources working progressively on
their component or prototype.
 The most important aspect for this model to be successful is to
make sure that the prototypes developed are reusable.

RAD Model Design:
RAD model distributes the analysis, design, build, and test phases into a series of
short, iterative development cycles. Following are the phases of RAD Model:
Business Modeling: The business model for the product under development is
designed in terms of flow of information and the distribution of information
between various business channels. A complete business analysis is performed to
find the vital information for business, how it can be obtained, how and when is the
information processed and what are the factors driving successful flow of
information.
Data Modeling: The information gathered in the Business Modeling phase is
reviewed and analyzed to form sets of data objects vital for the business. The
attributes of all data sets is identified and defined. The relation between these data
objects are established and defined in detail in relevance to the business model.

Process Modeling: The data object sets defined in the Data Modeling phase are
converted to establish the business information flow needed to achieve specific
business objectives as per the business model. The process model for any changes
or enhancements to the data object sets is defined in this phase. Process
descriptions for adding , deleting, retrieving or modifying a data object are given.
Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.
Testing and Turnover: The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow
and the interfaces between all the components need to be thoroughly tested with
complete test coverage. Since most of the programming components have already
been tested, it reduces the risk of any major issues.

RAD Model Adv. and Dis-Adv.
 RAD model enables rapid delivery as it reduces the
overall development time due to reusability of the
components and parallel development.
 RAD works well only if high skilled engineers are
available and the customer is also committed to achieve
the targeted prototype in the given time frame. If there
is commitment lacking on either side the model may
fail.

 Unit Testing:
The smallest unit of the software i.e. the code is tested at the first stage of testing. The
test is always performed by the developers to check the design of the unit. It also gives
them to find any problems early enough so that they can be rectified quickly.
 Integration Testing:
This done to check for any kind of defect in the integration and interfaces of the software
components within the software development itself. If there is any kind of defect in the
design of the software, it should get exposed at this stage.
 System Testing:
System testing helps in confirming that the software developed is has met all
the business requirements documentation specified by the user. It is basically when the
entirety of the software development is tested as a whole and will usually have not only
the involvement of the test team, but also a major role for a business analyst in re-
checking the project management requirements specified.
Different Types of Testing done at Different
Stage

 System Integration Testing
 This ensures that the system works properly when it is integrated
with external systems which are mentioned in the software
requirements specification. This is also the stage when things go
horribly wrong because getting software systems to correctly “talk”
to each other is easier said than done.
User Acceptance Testing
 The simulation or actual functioning of the software is tested either
by independent testers or by potential customers. This is to check
that will actually fulfill the functions required in the real world.
Customer or Operational Acceptance Testing
 Once all the above tests are done, either the customer or operations
will conduct acceptance testing to check the overall functioning
and reliability of the software before accepting it.

Software Test Life Cycle

STLC can be roughly divided into 3 parts:
 Test planning
 Test Design
 Test Execution
In the previous article we have seen that in a practical
QA project, we started with the SRS review and Test
scenario writing – which is actually the step 2 in the
STLC process – the test design, which involves details
on what to test and how to test. Why haven’t we
started with the Test planning?

Designing Test Plan
Making Test Plan has multiple benefits:
 Test Plan helps us determine the effort needed to validate
the quality of the application under test
 Help people outside the test team such as developers,
business managers, customers understand the details of
testing.
 Test Plan guides our thinking. It is like a rule book, which
needs to be followed.
 Important aspects like test estimation, test scope, test
strategy are documented in Test Plan, so it can be
reviewed by Management Team and re-used for other
projects.

How to make a Test Plan
 You already know that making a Test Plan is the most
important task of Test Management Process. Follow the
seven steps below to create a test plan

It has clear information on the following aspects:
Items in a Test Plan Template What do they contain
Scope => Test scenarios/Test objectives that will
be validated.
Out of scope => Enhanced clarity on what we are not
going to cover
Assumptions => All the conditions that need to hold
true for us to be able to proceed
successfully
Schedules => Test scenario prep
Test documentation- test cases/test
data/setting up environment
Test execution
Test cycle- how many cycle
Start and end date for cycles

Roles and Responsibilities => Team members are listed
Who is to do what
module owners are listed and their
contact info
Deliverables => What documents(test artifacts) are
going to produce at what time frames
What can be expected from each
document
Environment => What kind of environment
requirements exist
Who is going to be in charge
What to do in case of problems
Tools => For example: JIRA for bug tracking
Login
How to use JIRA
Defect Management => Who are we going to report the defects
to
How are we going to report
What is expected- do we provide
screenshot?

Risks and Risk Management => Risks are listed
Risks are analyzed- likelihood and
impact is documented
Risk mitigation plans are drawn
Exit criteria => When to stop testing
How to use JIRA
Defect Management => Who are we going to report the defects
to
How are we going to report
What is expected- do we provide
screenshot?
Risks and Risk Management => Risks are listed
Risks are analyzed- likelihood and
impact is documented
Risk mitigation plans are drawn
Exit criteria => When to stop testing

How to Report a Bug?
Fill out at least the following fields:
 Title: A short one-sentence summary that explains the problem (not
your suggested solution).
 Good: "Selecting gender is not functional."
 Bad: "Software crashes."
 Assigned to: You should ignore this field: Developers will set an
assignee when they plan to work on the task.
 CC: You should ignore this field: If you know specific users who will be
interested in getting notified of this task you can add them here.
 Priority: You should ignore this field: In general, the priority is set by
developers who plan to work on the task (see "Setting priorities").

 Select the project(s) in which you've found the bug:
 Projects are how developers find tasks to work on. To identify the right
project(s), use the search function (in the top right) to find its description.
 This could be for example the MediaWiki-General-or-Unknown project for
the wiki software itself, or Wikimedia-Site-Requests for configuration
changes on a Wikimedia site (see "Selecting projects").
 Security: Set this to "Security or Sensitive bug" if many users could be harmed
by the security problem that you are reporting. Your report will be kept hidden
from the public until it is resolved.
 Description: Full details of the issue, giving as much detail as possible. This
can include:
 For bugs:
Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the
described problem. Include any special setup steps.

Bug life Cycle
 Bug or defect life cycle includes following steps or
status:
 New: When a defect is logged and posted for the first
time. It’s state is given as new.
 Assigned: After the tester has posted the bug, the lead
of the tester approves that the bug is genuine and he
assigns the bug to corresponding developer and the
developer team. It’s state given as assigned.

 Open: At this state the developer has started analyzing
and working on the defect fix.
 Fixed: When developer makes necessary code changes
and verifies the changes then he/she can make bug status
as ‘Fixed’ and the bug is passed to testing team.
 Pending retest: After fixing the defect the developer has
given that particular code for retesting to the tester. Here
the testing is pending on the testers end. Hence its status
is pending retest.
 Retest: At this stage the tester do the retesting of the
changed code which developer has given to him to check
whether the defect got fixed or not.
 Verified: The tester tests the bug again after it got fixed by
the developer. If the bug is not present in the software, he
approves that the bug is fixed and changes the status to
“verified”.

 Reopen: If the bug still exists even after the bug is fixed by the
developer, the tester changes the status to “reopened”. The bug goes
through the life cycle once again.
 Closed: Once the bug is fixed, it is tested by the tester. If the tester
feels that the bug no longer exists in the software, he changes the
status of the bug to “closed”. This state means that the bug is fixed,
tested and approved.
 Duplicate: If the bug is repeated twice or the two bugs mention the
same concept of the bug, then one bug status is changed to “duplicate“.
 Rejected: If the developer feels that the bug is not genuine, he rejects
the bug. Then the state of the bug is changed to “rejected”.
 Deferred: The bug, changed to deferred state means the bug is
expected to be fixed in next releases. The reasons for changing the bug
to this state have many factors. Some of them are priority of the bug
may be low, lack of time for the release or the bug may not have major
effect on the software.
 Not a bug: The state given as “Not a bug” if there is no change in the
functionality of the application. For an example: If customer asks for
some change in the look and field of the application like change of
color of some text then it is not a bug but just some change in the looks
of the application.

Software Quality Assurance(QA) &
Quality Control(QC)
Quality Assurance Quality Control
1. Quality Assurance helps us to build
processes.
1. Quality Control helps us to implements the
build processes.
2. It is the Duty of the complete team. 2. It is only the Duty of the Testing team.
3. QA comes under the category of
Verification.
3. QC comes under the category of Validation.
4. Quality Assurance is considered as the
process oriented exercise.
4. Quality Control is considered as the product
oriented exercise.
5. It prevents the occurrence of issues, bugs
or defects in the application.
5. It always detects, corrects and reports the
bugs or defects in the application.
6. It does not involve executing the program
or code.
6. It always involves executing the program
or code.
7. It is one before Quality Control. 7. It is done only after Quality Assurance
activity is completed.
8. It can catch an error and mistakes that
Quality Control cannot catch, that is why
considered as Low Level Activity.
8. It can catch an error that Quality Assurance
cannot catch, that is why considered as High
Level Activity.
9. It is human based checking of documents
or files.
9. It is computer based execution of program
or code.
10. Quality Assurance means Planning done
for doing a process.
10. Quality Control Means Action has taken on
the process by execute them.http://apedusoft.com/ 62AP Edusoft Software Solutions

Quality Assurance Quality Control
11. Its main focuses on
preventingDefects or Bugs in the
system.
11. Its main focuses on identifying
Defects or Bugs in the system.
12. It is not considered as a time
consuming activity.
12. It is always considered as a time
consuming activity.
13. Quality Assurance makes sure that
you are doing the right things in the
right way that is the reason it is always
comes under the category of verification
activity.
13. Quality Control makes sure that
whatever we have done is as per the
requirement means it is as per what we
have expected, that is the reason it is
comes under the category of validation
activity.
14. QA is Pro-active means it identifies
weaknesses in the processes.
14. QC is Reactive means it identifies the
defects and also corrects the defects or
bugs also.

Software Verification & Validation
Verification Validation
Are you building it Rights? Are you building the right Thing?
Ensure that the software meets all the
functionality.
Ensure that the software meets all the
function
Verification takes place First and includes
the checking for documentation, code etc..
Validation occurs after verification and
mainly involves the checking of the overall
product.
Done by developers. Done by Testers.
Have static activities as it includes the
reviews, walkthroughs, and inspections to
verify that software is correct or not.
Have Dynamic activities as it includes
executing the software against
requirements
It is an objective process and no subjective
decision should be needed to verify the
software.
It is a subjective process and involves
subjective decision on how well the
software works

Practically, due to time and budget considerations, it is not possible
to perform exhausting testing for each set of test data, especially
when there is a large pool test cases. We need an easy way or
special techniques that can select test cases intelligent from the
pool of test-case, such that all test scenarios are covered.
For that, we use two techniques - Equivalence Partitioning &
Boundary Value Analysis testing techniques.
Equivalence Partitioning – It is a black box technique (code is not
visible to tester) which can be applied to all levels of testing like
unit, integration, system etc. In this technique, you divide set of test
condition into partition that can be considered the same. To get a
better idea let see an example.
Let's consider the behavior of tickets in the Flight reservation
application, while booking a new flight

Let's consider the behavior of tickets in the Flight reservation
application, while booking a new flight.

Ticket values 1 to 10 are considered valid & ticket is booked. While value 11 to 99 are
considered invalid for reservation and error message will appear, "Only ten tickets
may be ordered at one time".

Here is the test condition
Any Number greater than 10 entered in the reservation
column (let say 11) is considered invalid.
Any Number less than 1 that is 0 or below, then it is
considered invalid.
Numbers 1 to 10 are considered valid
Any 3 Digit Number say -100 is invalid.
We cannot test all the possible values because if done,
number of test cases will be more than 100.To address
this problem, we use equivalence partitioning
hypothesis where we divide the possible values of
tickets into groups or sets as shown below where the
system behavior can be considered the same.

The divided sets are called Equivalence Partitions or
Equivalence Classes. Then we pick only one value from
each partition for testing. The hypothesis behind this
technique is that if one condition/value in a
partition passes all others will also pass. Likewise,
if one condition in a partition fails, all other
conditions in that partition will fail.

Boundary Value Analysis- in Boundary Value Analysis, you test boundaries
between equivalence partitions

In our earlier example instead of checking, one value for each
partition you will check the values at the partitions like 0, 1, 10, 11
and so on. As you may observe, you test values at both valid and
invalid boundaries. Boundary Value Analysis is also
called range checking.
Equivalence partitioning and boundary value analysis are closely
related and can be used together at all levels of testing.

What is Web Application Testing?
Web application testing, a software testing technique
exclusively adopted to test the applications that are
hosted on web in which the application interfaces and
other functionalities are tested.
 Web Application Testing - Techniques:
1. Functionality Testing - The below are some of the
checks that are performed but not limited to the below
list:
 Verify there is no dead page or invalid redirects.
 First check all the validations on each field.
 Wrong inputs to perform negative testing.
 Verify the workflow of the system.
 Verify the data integrity.

2. Usability testing - To verify how the application is
easy to use with.
 Test the navigation and controls.
 Content checking.
 Check for user intuition.
3. Interface testing - Performed to verify the interface
and the dataflow from one system to other.
4. Compatibility testing- Compatibility testing is
performed based on the context of the application.
 Browser compatibility
 Operating system compatibility
 Compatible to various devices like notebook, mobile,
etc.

5. Performance testing - Performed to verify the server
response time and throughput under various load
conditions.
 Load testing - It is the simplest form of testing conducted to
understand the behaviour of the system under a specific load.
Load testing will result in measuring important business
critical transactions and load on the database, application
server, etc. are also monitored.
 Stress testing - It is performed to find the upper limit
capacity of the system and also to determine how the system
performs if the current load goes well above the expected
maximum.
 Soak testing - Soak Testing also known as endurance testing,
is performed to determine the system parameters under
continuous expected load. During soak tests the parameters
such as memory utilization is monitored to detect memory
leaks or other performance issues. The main aim is to discover
the system's performance under sustained use.

Spike testing - Spike testing is performed by increasing the number
of users suddenly by a very large amount and measuring the
performance of the system. The main aim is to determine whether the
system will be able to sustain the work load.
6. Security testing - Performed to verify if the application is secured on
web as data theft and unauthorized access are more common issues
and below are some of the techniques to verify the security level of
the system.
 Injection
 Broken Authentication and Session Management
 Cross-Site Scripting (XSS)
 Insecure Direct Object References
 Security Misconfiguration
 Sensitive Data Exposure
 Missing Function Level Access Control
 Cross-Site Request Forgery (CSRF)
 Using Components with Known Vulnerabilities
 Unvalidated Redirects and Forwards

Unix - Useful Commands
This quick guide lists commands, including a syntax and
brief description. For more detail, use −
 $man command
Files and Directories
 These commands allow you to create directories and
handle files.

Manipulating data
The contents of files can be compared and altered with the
following commands.

Data Base Testing Overview
Database testing includes performing data validity, data
integrity testing, performance check related to database and
testing of procedures, triggers and functions in the database.
Example:
Consider an application that captures the day-to-day transaction details for
users and stores the details in the database. From database testing point of
view, the following checks should be performed −
 The transactional information from the application should be stored in
the database and it should provide correct information to the user.
 Information should not be lost when it is loaded to database.
 Only completed transactions should be stored and all incomplete
operations should be aborted by the application.
 Access authorization to database should be maintained. No unapproved
or unauthorized access to user information should be provided.

There are multiple reasons why database testing is
performed. There is a need to perform data integrity,
validation and data consistency check on database as the
backend system is responsible to store the data and is
accessed for multiple purpose.
Given below are some common reasons for Database
testing −
Why You Need to Perform Database Testing?
 To ease the complexity of calls to database backend, developers increase the use
of View and Stored Procedures.
 These Stored procedures and Views contain critical tasks such as inserting customer details
(name, contact information, etc.) and sales data. These tasks need to be tested at several levels.
 Black-box testing performed on front-end is important, but makes it difficult to isolate the
problem. Testing at the backend system increases the robustness of the data. That is why
database testing is performed on back end system.
 In a database, data comes from multiple applications and there is a possibility that harmful or
incorrect data is stored in the database. Therefore, there is a need to check database
components regularly. In addition, data integrity and consistency should be checked regularly.

Database Testing Vs Front-End Testing:
Database testing is different from front-end UI testing. The
following table highlights the key differences −

Based on the function and structure of a database,
DB testing can be categorized into three categories −
 Structural Database Testing − It deals with
table and column testing, schema testing, stored
procedures and views testing, checking triggers,
etc.
 Functional Testing − It involves checking
functionality of database from user point of view.
Most common type of Functional testing are
White box and black box testing.
 Nonfunctional Testing − It involves load-
testing, risk testing in database, stress testing,
minimum system requirements, and deals with
the performance of the database.

Structural Database Testing
Structural database testing involves verifying those
components of database, which are not exposed to end
users. It involves all the components of repository, which
are used to store the data and are not changed by the
end users. Database administrators with good command
over SQL stored procedures and other concepts normally
perform this testing.
Discussed are the common components tested with
respect to Structural Testing −

Schema / Mapping Testing
It involves validating the objects of front-end application with
database object mapping.
In Schema Testing −
 Sometimes it happens that the end user application objects
are not correctly mapped or compatible with database objects.
Therefore, checking the validation of the various schema
formats associated with the databases is required.
 It is required to find the unmapped objects in database, like
tables, views, columns etc. is required.
There are various tools in the market that can be used to
perform object mapping in schemas.
Example − In Microsoft SQL Server, a tester can write simple
queries to check and validate schemas in the database.
If the tester wants to make changes to a table structure, he/she
should ensure that all the stored procedures having that table
are compatible with this change.

Stored Procedures and Views Testing
In this testing, a tester ensures that the manual execution of stored
procedures and views generate the required result.
The tester ensures −
 If it enables the required triggers to be executed as expected.
 If the development team has covered all the loops and conditions by
passing input to applications in the procedures.
 If there are any unused stored procedures in the database.
 TRIM operations are applied properly when the data is fetched from
required tables in database.
 Validation of the overall integration of the stored procedure modules
as per as the requirements of the application under test.
 Exception and error handling mechanisms are followed.http://apedusoft.com/ 89AP Edusoft Software Solutions

The most common tools that are used to perform stored procedures testing are
LINQ, SP Test tool, etc.
Trigger Testing
In trigger testing, a tester needs to ensure the following −
 Whether the coding conventions are followed during the coding phase of the
triggers.
 See the triggers executed meets the required conditions.
 Whether the trigger updates the data correctly, once they have been executed.
 Validation of Update/Insert/Delete triggers functionality w.r.t application under
test.

The key areas covered in this testing are −
 Validating the data types in the database to field values in front-end
application.
 Validating the length of data field in database to length of data types
in the application.
 Checking if there are any unmapped tables or columns in the
database from application field objects.
 Naming conventions of database tables and columns are verified, if
they are in accordance with business requirement or not.
 Validating the Keys and Indexes in the database, i.e., primary and
foreign keys in tables are defined as per requirement.
 Check if the primary keys and their corresponding foreign keys are
same in two tables.
 Check Unique and NOT NULL characteristics of keys are
maintained.
 Length and data type of keys and indexes are maintained as per
requirement.
Tables and Column testing

Difference Between Project & Project
Project:
if the requirements are coming from outside the company i.e particular one
person or organization then the outcome of the task is project.
1. Specifications will be given by Client
2. Client views/ requirements will be considered
3. End user is one
4.Once developed it will be finished and further updation also possible if client
required
Product:
if the requirements are coming from with in development company the out come
of the task is product.
1. Company designs product
2. Company with own views (based on market) develops product
3.End users are more than one
4. Never ending process
5.Customization is possible .

Difference between defect, error, bug,
failure and fault:
“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.”
 Error: A discrepancy between a computed, observed, or measured value or condition and
the true, specified, or theoretically correct value or condition. This can be a
misunderstanding of the internal state of the software, an oversight in terms of memory
management, confusion about the proper way to calculate a value, etc.
 Failure: The inability of a system or component to perform its required functions within
specified performance requirements. See: bug, crash, exception, and fault.
 Bug: A fault in a program which causes the program to perform in an unintended or
unanticipated manner. See: anomaly, defect, error, exception, and fault. Bug is
terminology of Tester.
 Fault: An incorrect step, process, or data definition in a computer program which causes
the program to perform in an unintended or unanticipated manner. See: bug, defect,
error, exception.
 Defect: Commonly refers to several troubles with the software products, with its external
behavior or with its internal features.

Functional & Non-Functional Testing
What is Functional Testing?
Functional Testing is the type of testing done against the
business requirements of application. It is a black box type of
testing.
It involves the complete integration system to evaluate the
system’s compliance with its specified requirements. Based
on the functional specification document this type of testing
is to be carried out. In actual testing, testers need to verify a
specific action or function of the code. For functional testing
either manual testing or automation tools can be used but
functionality testing would be easier using manual testing
only. Prior to non Functional testing the Functional testing
would be executed first.

Five steps need to be keeping in mind in the Functional testing:
 Preparation of test data based on the specifications of functions
 Business requirements are the inputs to functional testing
 Based on functional specifications find out of output of the functions
 The execution of test cases
 Observe the actual and expected outputs
To carry out functional testing we have numerous tools available, here is the
list of Functional testing tools.
In the types of functional testing following testing types should be cover:
 Unit Testing
 Smoke testing
 Sanity testing
 Integration Testing
 Interface Testing
 System Testing
 Regression Testing
 UAT

What is non Functional Testing?
The non Functional Testing is the type of testing done against the non
functional requirements. Most of the criteria are not consider in
functional testing so it is used to check the readiness of a system. Non-
functional requirements tend to be those that reflect the quality of the
product, particularly in the context of the suitability perspective of its
users. It can be started after the completion of Functional Testing. The non
functional tests can be effective by using testing tools.
The testing of software attributes which are not related to any specific
function or user action like performance, scalability, security or behavior of
application under certain constraints.
Non functional testing has a great influence on customer and user
satisfaction with the product. Non functional testing should be expressed
in a testable way, not like “the system should be fast” or “the system should
be easy to operate” which is not testable.
Basically in the non functional test is used to major non-functional
attributes of software systems. Let’s take non functional
requirements examples; in how much time does the software will take to
complete a task? or how fast the response is.

Following testing should consider in non functional testing types:
o Availability Testing
o Baseline testing
o Compatibility testing
o Compliance testing
o Configuration Testing
o Documentation testing
o Endurance testing
o Ergonomics Testing
o Interoperability Testing
o Installation Testing
o Load testing
o Localization testing and Internationalization testing
o Maintainability Testing
o Operational Readiness Testing
o Performance testing
o Recovery testing
o Reliability Testing
o Resilience testing
o Security testing
o Scalability testing
o Stress testing
o Usability testing
o Volume testing

Defect Isolation
Break into small modules and then execute it.
Top down Approach - Bisection Technique

Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means
that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug
is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to
corresponding developer or developer team. The state of the bug now is changed to
“ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing
team for next round of testing. Before he releases the software with bug fixed, he
changes the state of bug to “TEST”. It specifies that the bug has been fixed and is
released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be
fixed in next releases. The reasons for changing the bug to this state have many
factors. Some of them are priority of the bug may be low, lack of time for the release
or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug.
Then the state of the bug is changed to “REJECTED”.

7. Duplicate:
If the bug is repeated twice or the two bugs mention the same concept of the bug,
then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester
tests the bug. If the bug is not present in the software, he approves that the bug is
fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer,
the tester changes the status to “REOPENED”. The bug traverses the life cycle once
again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that
the bug no longer exists in the software, he changes the status of the bug to
“CLOSED”. This state means that the bug is fixed, tested and approved.

Defect severity determines the defect criticality whereas defect priority
determines the defect immediacy or urgency of repair
1. High Severity & Low Priority : Suppose there is an application which
generates some banking related reports weekly, monthly, quarterly & yearly by
doing some calculations. In this application, there is a fault while calculating
yearly report. This is a high severity fault but low priority because this fault can
be fixed in the next release as a change request.
2. Low Severity & High Priority : Suppose there is a spelling mistake or
content issue on the homepage of BT.com website which has daily laks of hits
all over UK. In this case, though this fault is not affecting the website or other
functionalities but considering the status and popularity of the website in the
competitive market it is a high priority fault.
3. High Severity & High Priority : Suppose there is an application which gives
some banking related reports weekly, monthly, quarterly & yearly by doing
some calculations. In this application, there is a fault while calculating weekly
report. This is a high severity and high priority fault because this fault will
hamper the functionality of the application immediately within a week. It
should be fixed urgently.
4. Low Severity & Low Priority : Suppose there is a spelling mistake on the
pages which has very less hits throughout the month on any website. This fault
can be considered as low severity and low priority.

Thank You!!!
For More Information, Call Experts:
AP Edusoft Software solutions
M-18, 1st & 2nd Floor, OLD DLF Colony, Sector -14,
Gurgaon(HR) -122001
+91-8595459996, 0124-4209618
enquiry@apedusoft.com
www.apedusoft.com
http://apedusoft.com/ AP Edusoft Software Solutions 102

Software testing-in-gurgaon

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Software testing-in-gurgaon

Similaire à Software testing-in-gurgaon (20)

Dernier

Dernier (20)

Software testing-in-gurgaon