Tests carried out in different SDLC

Waterfall Model - The waterfall model adopts a 'top-down' approach, regardless

of whether it is being used for software development or testing. The basic steps
involved in this software testing methodology are as follows:

Requirement analysis
Test case design
Test case implementation
Testing, debugging, and validating the code or product
Deployment and maintenance

Advantages:
 The main benefit of this methodology is its simplistic, systematic, and
orthodox approach.
 Required resources used are low in this model as compare to other.
 After every phase of the model a document in created which help & simpler
to understand & design the system.

Drawbacks:
 In this methodology, you move on to the next step only after you have
completed the present step.

 The model follows a non-iterative approach.

 It has many shortcomings, since bugs and errors in the code are not
discovered until and unless the testing stage is reached.
 This can often lead to wastage of time, money, and other valuable resources.
V-Model

Advantages of V-model:

 Simple and easy to use.

 Testing activities like planning, test designing happens well before coding.
This saves a lot of time. Hence higher chance of success over the waterfall
model.
 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
 Works well for small projects where requirements are easily understood.

Disadvantages of V-model:

 Very rigid and least flexible.

 Software is developed during the implementation phase, so no early

prototypes of the software are produced.
 A prototype is an early sample, model, or release of a product built to test a concept or process or
to act as a thing to be replicated or learned from
 If any changes happen in midway, then the test documents along with
requirement documents has to be updated.

When to use the V-model:

 The V-shaped model should be used for small to medium sized projects
where requirements are clearly defined and fixed.
 The V-Shaped model should be chosen when ample technical resources are
available with needed technical expertise.

High confidence of customer is required for choosing the V-Shaped model

approach. Since, no prototypes are produced, there is a very high risk involved in
meeting customer expectations.

-------------------------------------
Agile methodology

Video

-----------------------------------------

What is Incremental model- advantages, disadvantages and when to use it?

?
In incremental model the whole requirement is divided into various builds.
Multiple development cycles take place here, making the life cycle a “multi-
waterfall” cycle. Cycles are divided up into smaller, more easily managed
modules. Each module passes through the requirements, design, implementation
and testing phases. A working version of software is produced during the first
module, so you have working software early on during the software life cycle.
Each subsequent release of the module adds function to the previous release. The
process continues till the complete system is achieved.

For example:
In the diagram above when we work incrementally we are adding piece by piece
but expect that each piece is fully finished. Thus keep on adding the pieces until
it‟s complete. As in the image above a person has thought of the application. Then
he started building it and in the first iteration the first module of the application or
product is totally ready and can be demoed to the customers. Likewise in the
second iteration the other module is ready and integrated with the first module.
Similarly, in the third iteration the whole product is ready and integrated. Hence,
the product got ready step by step.

Diagram of Incremental model:

Advantages of Incremental model:

 Generates working software quickly and early during the software life cycle.
 This model is more flexible – less costly to change scope and requirements.
 It is easier to test and debug during a smaller iteration.
 In this model customer can respond to each built.
 Lowers initial delivery cost.
 Easier to manage risk because risky pieces are identified and handled during
it‟d iteration.

Disadvantages of Incremental model:

  Needs good planning and design.
 Needs a clear and complete definition of the whole system before it can be
broken down and built incrementally.
 Total cost is higher than waterfall.

When to use the Incremental model:

 This model can be used when the requirements of the complete system are
clearly defined and understood.
 Major requirements must be defined; however, some details can evolve with
time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
 There are some high risk features and goals.

What is Spiral model- advantages, disadvantages and when to use it?

?
The spiral model is similar to the incremental model, with more emphasis placed
on risk analysis. The spiral model has four phases: Planning, Risk Analysis,
Engineering and Evaluation. A software project repeatedly passes through these
phases in iterations (called Spirals in this model). The baseline spiral, starting in
the planning phase, requirements are gathered and risk is assessed. Each
subsequent spirals builds on the baseline spiral.

Planning Phase: Requirements are gathered during the planning phase.

Requirements like „BRS‟ that is „Business Requirement Specifications‟ and „SRS‟
that is „System Requirement specifications‟.

Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk
and alternate solutions. A prototype is produced at the end of the risk analysis
phase. If any risk is found during the risk analysis then alternate solutions are
suggested and implemented.

Engineering Phase: In this phase software is developed, along with testing at the
end of the phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral.

Diagram of Spiral model:

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.

 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.

Disadvantages of Spiral model:

 Can be a costly model to use.

 Risk analysis requires highly specific expertise.
 Project‟s success is highly dependent on the risk analysis phase.
 Doesn‟t work well for smaller projects.

When to use Spiral model:

 When costs and risk evaluation is important

 For medium to high-risk projects
  Long-term project commitment unwise because of potential changes to
economic priorities
 Users are unsure of their needs
 Requirements are complex
 New product line
 Significant changes are expected (research and exploration)

What is re-testing?
Testing a functionality with different inputs

What is STATIC and Dynamic testing?

Static security testing is used to analyse software in a non-
runtime environment – when the software is inactive, and not in operation.
This allows developers to perform a thorough inspection of every aspect of
the software‟s source code, in order to identify and remedy any flaws, back-
doors, and in some instances, malicious code. Static testing is often referred
to as verification: the evaluation of the development process.

Dynamic testing is performed in a runtime environment, with security

analysis carried out whilst software is in operation. With a given input, the
software‟s actual output is compared to its expected output. This allows
developers to analyze the functional behavior of a piece of software, and
monitor its interaction with system memory, CPU function and overall
system performance. Dynamic testing is often referred to as validation: the
evaluation of a finished product.

What is Structural testing?

Structural testing, also known as glass box testing or white box testing
is an approach where the tests are derived from the knowledge of the
software's structure or internal implementation.
The other names of structural testing include clear box testing, open
box testing, logic driven testing or path driven testing.

Structural Testing Techniques:

Statement Coverage - This technique is aimed at exercising all
programming statements with minimal tests.
 Branch Coverage - This technique is running a series of tests to ensure
that all branches are tested at least once.
Path Coverage - This technique corresponds to testing all possible
paths which means that each statement and branch are covered.

What is Maintenance testing?

Once a system is deployed it is in service for years and decades.
During this time the system and its operational environment is often
corrected, changed or extended. Testing that is provided during this phase is
called maintenance testing.
Usually maintenance testing is consisting of two parts:
First one is, testing the changes that has been made because of the
correction in the system or if the system is extended or because of some
additional features added to it.
Second one is regression tests to prove that the rest of the system has
not been affected by the maintenance work.

What is Smoke Testing?

Smoke Testing is a testing technique that is inspired from hardware
testing, which checks for the smoke from the hardware components once the
hardware's power is switched on. Similarly in Software testing context,
smoke testing refers to testing the basic functionality of the build.
If the Test fails, build is declared as unstable and it is NOT tested
anymore until the smoke test of the build passes.
Smoke Testing - Features:
 Identifying the business critical functionalities that a product
must satisfy.
 Designing and executing the basic functionalities of the
application.
 Ensuring that the smoke test passes each and every build in
order to proceed with the testing.
 Smoke Tests enables uncovering obvious errors which saves
time and effort of test team.
 Smoke Tests can be manual or automated.
What is Sanity Testing?

Sanity testing, a software testing technique performed by the test team for
some basic tests. The aim of basic test is to be conducted whenever a new
build is received for testing. The terminologies such as Smoke Test or Build
Verification Test or Basic Acceptance Test or Sanity Test are
interchangeably used, however, each one of them is used under a slightly
different scenario.
 Sanity test is usually unscripted, helps to identify the dependent
missing functionalities. It is used to determine if the section of
the application is still working after a minor change.
 Sanity testing can be narrow and deep. Sanity test is a narrow
regression test that focuses on one or a few areas of
functionality.

What is confirmation testing?

Confirmation testing: When a test fails because of the defect then
that defect is reported and a new version of the software is expected that has
had the defect fixed. In this case we need to execute the test again to confirm
that whether the defect got actually fixed or not. This is known as
confirmation testing and also known as re-testing. It is important to ensure
that the test is executed in exactly the same way it was the first time using
the same inputs, data and environments.

What is random/monkey testing?

Monkey testing is a software testing technique in which the testing is
performed on the system under test randomly. The Input data that is used to
test also generated randomly and keyed into the system.

Characteristics of Monkey Testing:

Following are the characteristics of the Monkey testing:
 This testing is so random that the tester may not be able to
reproduce the error/defect.
 The scenario may NOT be definable and may NOT be the
correct business case.
 Monkey Testing needs testers with very good domain and
technical expertise.
 Advantages of Monkey Testing:
 As the scenarios that are tested are adhoc, system might be under
stress so that we can also check for the server responses.
 This testing is adopted to complete the testing, in particular if there
is a resource/time crunch.

What is adhoc testing?

When a software testing performed without proper planning and
documentation, it is said to be Adhoc Testing. Such kind of tests are executed only
once unless we uncover the defects.
Adhoc Tests are done after formal testing is performed on the application.
Adhoc methods are the least formal type of testing as it is NOT a structured
approach. Hence, defects found using this method are hard to replicate as there are
no test cases aligned for those scenarios.
Testing is carried out with the knowledge of the tester about the application
and the tester tests randomly without following the specifications/requirements.
Hence the success of Adhoc testing depends upon the capability of the tester, who
carries out the test. The tester has to find defects without any proper planning and
documentation, solely based on tester's intuition.
When to Execute Adhoc Testing ?
 Adhoc testing can be performed when there is limited time to do
exhaustive testing and usually performed after the formal test
execution. Adhoc testing will be effective only if the tester has in-
depth understanding about the System Under Test.
Forms of Adhoc Testing :
1) Buddy Testing: Two buddies, one from development team and one from
test team mutually work on identifying defects in the same module.
Buddy testing helps the testers develop better test cases while
development team can also make design changes early. This kind of
testing happens usually after completing the unit testing.
2) Pair Testing: Two testers are assigned the same modules and they share
ideas and work on the same systems to find defects. One tester executes
the tests while another tester records the notes on their findings.
3) Monkey Testing: Testing is performed randomly without any test cases in
order to break the system.
What is State Transition Testing?

What is Backward Compatibility Testing?

Type of software testing performed to check newer version of the software can
work successfully installed over previous version of the software and newer
version of the software works as fine with table structure, data structures, files that
were created by previous version of the software.

What is Boundary Value Testing (BVT)

Boundary Value Testing is a testing technique that is based on concept “error
aggregates at boundaries”. In this testing technique, testing is done extensively to
check for defects at boundary conditions. If a field accepts value 1 to 100 then
testing is done for values 0, 1, 2, 99, 100 and 101.

What is Equivalence Partitioning?

Equivalence partitioning technique is used in black box and grey box testing types.
Equivalence partitioning classifies test data into Equivalence classes as positive
Equivalence classes and negative Equivalence classes, such classification ensures
both positive and negative conditions are tested.

What is Localization Testing?

Localization testing a type of software testing performed by software testers, in this
type of testing, software is expected to adapt to a particular locale, it should
support a particular locale/language in terms of display, accepting input in that
particular locale, display, font, date time, currency etc., related to a particular
locale. For e.g. many web applications allow choice of locale like English, French,
German or Japanese. So once locale is defined or set in the configuration of
software, software is expected to work as expected with a set language/locale.

Explain Software testing life cycle?

Software Testing is not a just a single activity. It consists of series of activities

carried out methodologically to help certify your software product. These activities
(stages) constitute the Software Testing Life Cycle (STLC).
The different stages in Software Test Life Cycle -

Requirement Analysis

During this phase, test team studies the requirements from a testing point of view to identify the
testable requirements. The QA team may interact with various stakeholders (Client, Business
Analyst, Technical Leads, System Architects etc) to understand the requirements in detail.
Requirements could be either Functional (defining what the software must do) or Non Functional
(defining system performance /security availability ) .Automation feasibility for the given testing
project is also done in this stage.

Activities

 Identify types of tests to be performed.

 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
  Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).

Test Planning

This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager
will determine effort and cost estimates for the project and would prepare and finalize the Test
Plan.

Activities

 Preparation of test plan/strategy document for various types of testing

 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement

Deliverables

 Test plan /strategy document.

 Effort estimation document.

Test Case Development

This phase involves creation, verification and rework of test cases & test scripts. Test data , is
identified/created and is reviewed and then reworked as well.

Activities

 Create test cases, automation scripts (if applicable)

 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables

 Test cases/scripts
 Test data

Test Environment Setup

Test environment decides the software and hardware conditions under which a work product is
tested. Test environment set-up is one of the critical aspects of testing process and can be done
in parallel with Test Case Development Stage. Test team may not be involved in this activity if
the customer/development team provides the test environment in which case the test team is
required to do a readiness check (smoke testing) of the given environment.

Activities

 Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables

 Environment ready with test data set up

 Smoke Test Results.

Test Execution

During this phase test team will carry out the testing based on the test plans and the test cases
prepared. Bugs will be reported back to the development team for correction and retesting will be
performed.

Activities

 Execute tests as per plan

 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the defect fixes
 Track the defects to closure

Deliverables

 Test cases updated with results

 Defect reports

Test Cycle Closure

Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be
implemented in future, taking lessons from the current test cycle. The idea is to remove the
process bottlenecks for future test cycles and share best practices for any similar projects in
future.

Activities

 Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software, Critical
Business Objectives , Quality
  Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the customer.
 Test result analysis to find out the defect distribution by type and severity.

Bug Life Cycle