TESTING

Testing: client give any requirement either it is properly working or not working is called testing (or)
something is there is it properly working or not working based on our requirements is called testing

Testing are two types

1 Manual testing (doing manual testing skills) In order to give quality software to the customer we
always do manual testing

It is not possible to cover to all negative scenarios or random scenarios with the help of automation
testing

Disadvantages: it is time consuming process Manual testing can perform to the at present only

2 Selenium testing Automation (testing skills & programming skills)

SDLC (Software Development Life Cycle) Phases, Methodologies,

Process, and Models
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. It is also called as Software Development process

 Requirement gathering and analysis

 Feasibility study
 Design
 Implementation or coding
 Testing
 Deployment
 Maintenance

Requirement Gathering and Analysis

Business analyst collects the requirements from the customer /client as per the client needs
and documents the requirements Specifications (BRS) and provides the same development
team (or)
We are giving the specifications and ides to give team people whatever the user requirements
and customer requirements that will be in first Document

Design

In this phase, the requirement gathered in the SRS document is used as an input and
software architecture that is used for implementing system development is derived.
TESTING
System design helps in specifying hardware and system requirements and also overall system
architecture.

High level Design (HLD) it gives the architecture of the software product to be developed and is done by
architects and senior developers

Low level Design (LLD) it is done by senior developers it describe how each and every feature in the
product it should work and how every component should work

The outcome from the phase is high level Document and low level Document

Implementation or Coding
Implementation/Coding starts once the developer gets the Design document. The Software design is
translated into source code. All the components of the software are implemented in this phase .

Testing
Testing starts once the coding is complete and the modules are released for testing. In this phase, the
developed software is tested thoroughly and any defects found are assigned to developers to get them
fixed.

Deployment
Once the product is tested, it is deployed in the production environment or first UAT (User Acceptance
testing) is done depending on the customer expectation.

Maintenance
After the deployment of a product on the production environment, maintenance of the product
i.e. if any issue comes up and needs to be fixed or any enhancement is to be done is take care
by the developers.

Software Development Life Cycle Models

Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. It is also called as Software Development process

Waterfall model is the very first model that is used in SDLC. It is also known as the linear sequential
model. Step by step single stage testing

In this model, the outcome of one phase is the input for the next phase. Development of the next
phase starts only when the previous phase is complete.
TESTING

Advantages of the Waterfall Model:

1) Simple and very easy to use

2) Easy to manage
3) Requirements is very well understood
Disadvantages of Waterfall model:

1) Poor model for the ongoing long projects

2) Not good for oops
3) If any new requirements are there we can’t add

V-Shaped Model
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. It is also called as Software Development process
TESTING

V- Model is also known as Verification and Validation Model. In this model Verification & Validation
goes hand in hand i.e. development and testing goes parallel. V model and waterfall model are the
same except that the test planning and testing start at an early stage in V-Model.

Advantages of V_ Model:
It is Simple and very easy to understood

V-model good for the small projects

Disadvantages of V-Model:
V-model is not good for ongoing projects

If any Requirements changes we can’t add

TESTING
Spiral Model
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. It is also called as Software Development process

The Spiral Model includes iterative and prototype approach.

Software development in a series of incremental model
TESTING
The spiral model includes iterative and prototype approach

Advantages of Spiral model:

 Risk Analysis is done extensively using the prototype models.
 Any enhancement or change in the functionality can be done in the next iteration.

Disadvantages of Spiral model:

1) The spiral model is best suited for large projects only.

2) The cost can be high as it might take a large number of iterations
3) Time taking process

Prototype Model
Software Development Life Cycle (SDLC) is a process used by the software industry to design,
develop and test high quality software. It is also called as Software Development process

The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models).This model is used when the customers do not know the exact
project requirements beforehand. ... Once the customer figures out the problems,
the prototype is further refined to eliminate them.

The prototype is also a iterative model

TESTING
Advantages of prototype:

1) Customer can see steady progress

2) This is use full when requirements are changing rapidly

Disadvantages of prototype:

1) It is impossible to know how long it will take

2) This is no way to know the no of iterations will be required
3) It is time taking process

Hybrid Model
Hybrid model is combination of two models example of hybrid is combination of spiral
and prototype models

Process:
1) First we are going to collect the requirements of one model
2) Develop the prototype
3) Test the prototype
4) Customer review
5) Customer approval
6) Then design of that prototype for that module
7) After design , coding and then testing
8) Deploy the customer

Advantages:
Customer satisfaction is more

Customer rejection is less

Customer review, flexible for changes

Prototype can reused

Disadvantages:
No requirements review

Time consuming if the prototype changes

TESTING
Due to this high customer satisfaction ratio many prefers prototype model instead of water fall and
spiral model

When we are going to use prototype model?

Whenever the customer is new to the software industry or he is not clear about the requirements
then we are going to use prototype model

Static testing (without executing) the main purpose of static testing is to prevent the defect at the
early stage it self

Walk through (first to last), Inspection (specific factor), Technical review (Two documents compare)
Audit

Dynamic testing (with executing) the main purpose of doing dynamic testing find the defect and
raise it bug fix it

Developers has done the white box testing and he would have given the build to you deploy
the build and start the testing
TESTING
Functional Testing: Behavioral of system software
Differences between White box Testing and Black box testing?

1) It is a testing method knowledge about the actual code or internal structure of the application
2) It is mostly done by software developers
3) Knowledge of implementation is required
4) It is structural test of the software
5) It is mandatory to have knowledge of programming

Black box testing

1) It is testing method without knowledge about the internal structural of application
2) It is mostly done by software testers
3) No knowledge of implementation is needed
4) It is functional test of the software
5) No knowledge of programming is required

Functional testing or Black box testing types

Unit testing: Manual and Automation To check each and every component or Module
Tools: JUnit Test Ng N-unit
Testing of individual software components or Modules Typically done by the programmer and
not by testers, as it requires detailed knowledge of the internal program design and code may
require developing test drive modules or test harnesses.

Integration testing: Interacts between the two modules or dependent of one module to
another module Ex: Gmail
Testing of integrated modules to verify combined functionality after integration. Modules are
typically code modules, individual applications, client and server applications on a network, etc.
This type of testing is especially relevant to client/server and distributed systems
Approaches/Methodologies/Strategies of integration testing

Incremental Approach: which is further divided into the following

 Top Down Approach

 Bottom Up Approach
 Sandwich Approach - Combination of Top Down and Bottom Up
TESTING
Top down Approach: Top down approach interacts with main program & some sub programs
because remaining programs under construction we replace dummy program is called stub

Top down Approach:

Bottom-Up Approach: (Modules to be tested)

TESTING
Bottom-Up Approach is interacts with the subprograms only without interacts of main program
we replace a dummy program that is called driver
Hybrid/Sandwich: combination of Top-down Approach & Bottom-Up Approach
Combination of three modules that is called System or Big-Bang or Incremental Approach
Non-Incremental Integration Testing: Adding all the modules in a single shot trying to test data
flow between them.

System testing: Testing the application End to End scenario perfectly working or not
End to End
Entire system is tested as per the requirements. Black-box type testing that is based on overall
requirements specifications, covers all combined parts of a system.

Acceptance testing: Before giving the software to the customer User acceptance testing is
performed by the client.
Alpha Beta
Internal (client) External (end users)
It is also called as UAT (user acceptance testing), FAT (final acceptance testing), and RBT (Red
Box testing)

Smoke testing: Client gives any requirements it is properly working or not working is called
Smoke testing or to check the Bolger bugs

Sanity testing: with minor changes in the code, or functionality

Sanity Testing is a type of software testing which is conducted after receiving a software build,
with minor changes in the code, or functionality. The aim is to make sure that the bugs have
been fixed and to confirm that there are no further issues introduced due to the new changes.

Regression testing: Testing the application as a whole for the modification in any module
or Functionality Difficult to cover all the system in regression testing so typically automation
tools are used for these testing types. (or)
is nothing but a unchanged future of an application to make sure that changes like adding a
feature or deleting a feature or modification or fixing defect is not impacting the unchanged
feature of an application is called regression testing
3 Types of Regression testing
1) Unit: Testing the only changed part or modification part that is called unit regression
testing
TESTING
2) Regional : Testing the changed part and also impacted areas that is called Regional
regression testing
3) Full: Testing the changed feature and also remaining part of the application is called full
regression testing

Re-Testing: After a defect is detected and fixed, the software sh ould be retested to confirm
that the original defect has been successfully removed. This is called Confirmation Testing or
Re-Testing

Ad hoc Testing:
Definition:
Ad hoc testing is a commonly used term for software testing performed without any planning
and documentation. These tests are intended to be run only once, unless a defect is discovered.
Ad hoc testing is the least followed formal test method.

Monkey Testing:
Testing a system or an Application on the fly, i.e. just few tests here and there to ensure
the system or an application does not crash out.
We do Monkey testing when we don't have any knowledge on the Application.

Exploratory Testing: without knowledge about the application simultaneously learning test
design and test execution

GUI
INPUT
ERRORHANDLING
OUTPUT
DATABASE
DATA VOLUME
RECOVERY
INTERSYSTEM

Non-Functional testing: apart from the functionality of the requirements there are several
non-functional aspects as well that are required to be tested to improve the quality and
performance of application
Non-Functional testing types:
TESTING
Usability Testing: user friendless Application flow tested can new user understand the
application easily

Performance Testing:
This is test is mainly performed to check whether the software meets the expected
requirements of application speed, scalability &stability

Stress testing: it is used to find ways to break the system the test also provides the range of
maximum load the system can hold.

Load testing: Load testing is a performance testing where we test the system response under
varying load conditions this testing is usually measure the speed and capacity of application

Scalability testing: Scalability testing is non-functional test methodology in which an

applications performance is measured in terms of its ability to scale up or scale down the
number of user request or other such performance measure attributes scalability testing can be
performed at a hardware, software or database level

Volume: Volume testing is a testing done on high volumes of data, where the software
product or application with high volume of data is tested like huge number of input files data
records heavy database tables size in the system also known as flood test
To check System Performance with increased volume of data in the database

Compatibility: Compatibility testing how well software performance in a particular

hardware/software/operating system and other combinations

Security testing: To check if the system is safe from the external attacks or how well the
system protects against the unauthorized internal or external access. Checked if the system
database is safe from external attacks
Typical black-box test design techniques include:
Equivalence partitioning: The variation between valid & invalid is divided into different
equivalent is called EP Range, Type, and Size
Exampple-1 1to 10 tickets only range
Partion-1 partion-2 partion-3
Below 001 10 11-99
Invalid valid invalid

Example-2 Type
P-1 p-2 p-3 p-4
Alphabet number numeric alphanumeric
Invalid valid invalid invalid
 TESTING
 Boundary value analysis: Extension of EP & valid & invalid inputs
Boundary value analysis is a test case design technique to test

boundary value between partitions both valid boundary partition and

invalid boundary partition.

Partion-1 partion-2 partion-3

Below 001 10 11-99
Invalid valid invalid
Minimum-00 Maximum-1 Maximum-11
Maximum-01 Minimum-10 Minimum-99
.
 Error guessing: Error Guessing is a test case design technique where the tester has
to guess what faults might occur and to design the tests to represent them.

Decision table testing: Decision table testing is a testing technique used to test system behavior for
different input combinations. Or it is a combination of inputs and outputs

Examples

T1 T2 Result
User id valid pass
Pass valid pass

User id invalid
Pass valid error

State transition testing: State Transition testing is defined as the testing technique in
which changes in input conditions cause's state changes in the application.

Example

Let's consider an ATM system function where if the user enters the invalid password
three times the account will be locked.
TESTING
Use case testing: Interacts with the users & customer or system

White-box testing (also known as clear box testing, glass box testing, transparent box testing,
and structural testing

 Control flow testing

 Data flow testing
 Branch testing
 Statement coverage
 Decision coverage
 Modified condition/decision coverage
 Prime path testing
 Path testing

Test scenario: it is nothing but a test procedure a test scenario having one or many relations with
test cases meaning of scenario can have multiple test cases or it gives the idea of what we have to
test

Test cases: it is set of actions and functionality is called test cases

Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before
testing can begin.

Exit Criteria: Exit Criteria defines the items that must be completed before testing can be
concluded.

STLC (Software testing life cycle): It is a step by step procedure or standard procedure to
test any new software that is called software testing life cycle. It is a part of SDLC

Requirements &analysis: A business analyst collect the requirements from client/customer

as per the business need of document and requirements specification BRS, FRS, URS

Test plan: One of the most importance phase, at this stage we are defining the testing
strategies. Test scope, Test Environment, Manual and Automation Testing, Defect Mgmt,
Configuration Mgmt, Risk Mgmt
Team structure and roles and responsibilities, Assumptions, matrix

Entry Criteria: Requirements documents, manual or automation Testing

Exit Criteria: Test strategy, Test plan and test effort estimation documentation.

Test design: Test cases preparations, Test Traceability Matrix for identifying test cases
TESTING
Test cases reviews and approval.

Entry criteria: Requirements documents, Test plan

Exit criteria: Test cases, Test scripts (if automation), Test data
Test execution: Perform the activity and check result or Executing Test cases, capture,
Review and analyze test result
Mark the status as passed failed or blocked

Entry criteria: Test plan document, Test cases, Test data test environment
Exit criteria: Test case execution report. Defect report, RTM
Bug report: Any defects as found assigned to the developers to get them fixed
Entry criteria: Test cases Execution Report (make sure there are no high severity defect
opened) Defect report

Exit criteria: Test closer report, test matrix

Regression &Retest: Testing the application as a whole for the modification in any module
or functionality Difficult to cover all the system in regression testing so typically automation
tools are used for the testing types. & any defects as found assigned to the developers to get
them fixed.

Entry criteria: Test cases Execution Report (make sure there are no high severity defect
opened) Defect report

Exit criteria: Test closer report, test matrix

Test closer: Requirements covered, types of testing performed, deployment
Entry criteria: Test cases Execution Report (make sure there are no high severity defect
opened) Defect report

Exit criteria: Test closer report , test matrix

Bug Life Cycle or Defect Life Cycle:
TESTING

Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when
defect is found and ends when a defect is closed, after ensuring it’s not reproduced.
Defect life cycle is related to the bug found during testing.

The bug has different states in the Life Cycle.

New: When a defect is logged and posted for the first time. Its state is given as new.

Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug
and assigns the bug to developer team.
TESTING
3) Open: At this state the developer has started analyzing and working on the defect fix.

4) Resolved/Fixed/Pending retest: 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.

5) 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.

6) Reopened: If the bug still exists even after the 0bug is fixed by the developer, the
tester changes the status to “reopened”. The bug goes through the life cycle once
again.

7) Closed/ Verified: 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.

8) Rejected: If the developer feels that the bug is not genuine, developer rejects the
bug. Then the state of the bug is changed to “rejected”.

9) 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“.

10) Deferred: If the bug is not related to current build or cannot be fixed in this release
or bug is not important to fix immediately then the project manager.

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 testing. This
traceability matrix ensures that all requirements are covered by test cases.

Error: A mistake in coding program is called an error (At development level)

TESTING
Defect: Mistake found by your testing team is a defect (Testing)

Bug: Defect accepted by the software developer team is called a bug (Testing
level)

Failure: Before releasing the Product any issues is called failure

Priority: When defect should be fixed

The priority status is set based on the customer requirements. For example: If the
company name is misspelled in the home page of the website, then the priority is
high and severity is low to fix it.
Priority can be of following types:
Low: when developer raising the bug fixed immediately.

Medium: When you raising the bug developer will fix it coming built it can
wait until a new build or version is created.

High: The defect must be resolved as soon as possible because the defect is
affecting the application or the product severely. The system cannot be used
until the repair has been done.

Severity: It is the extent to which the defect can affect the software
For example: If an application or web page crashes when a remote link is clicked, in
this case clicking the remote link by an user is rare but the impact of application
crashing is severe. So the severity is high but priority is low.

Severity can be of following types:

TESTING
Blocker: when you trying to login to application user id & password blocked not
allowing to proceeding the home page internal server error full functionality is
blocked
Critical: Any application main functionality of the application is not working.
Major: When you functionality is working I didn’t get any message from (OLA) cab
Minor: it is not affected to any customer business work flow alignment, spelling
mistake
Few very important scenarios related to the severity and priority which are asked
during the interview:
High Priority & High Severity: An error which occurs on the basic functionality of the
application and will not allow the user to use the system. (E.g. A site maintaining the
student details, on saving record if it, doesn’t allow saving the record then this is high
priority and high severity bug.)
High Priority & Low Severity: The spelling mistakes that happens on the cover page
or heading or title of an application.
High Severity & Low Priority: An error which occurs on the functionality of the
application (for which there is no workaround) and will not allow the user to use the
system but on click of link which is rarely used by the end user.
Low Priority and Low Severity: Any cosmetic or spelling issues which is within a
paragraph or in the report (Not on cover page, heading, title).

Agile Methodology: Software Development Life Cycle (SDLC) is a process used by the
software industry to design, develop and test high quality software. It is also called as Software
Development process

Agile is generally defined as an iterative and incremental approach

Iterative:” The process keeping on repeating that is called iterative “

Incremental: “Module or feature will be keep on adding that is called incremental “
Scrum:”Scrum is a framework for developing complex products & system it is grounded in
empirical process and control theory, Scrum employ an iterative and incremental approach to
optimize predictability and control risk”.
TESTING
Scrum Master: Master is responsible for setting up the team, sprint meeting and removes
obstacles to progress

Product owner: The Product Owner creates product backlog, prioritizes the backlog and is
responsible for the delivery of the functionality at each iteration

Scrum Team: Team manages its own work and organizes the work to complete the sprint or
cycle
TESTING

 S/W binding
CEO (chief executive officer)

 Kick off Meeting

(Selection of Po (product owner) will be approved by client)

 Product back log Grooming meeting

stories and requirements
Product back log
refinement
(Po,Sm,St,client)
stories from all users)
(Product owner, client, stakeholders, and together all user
 Sprint planning meeting
(Product owner, client, scrum master, scrum team some user
30 days

 Sprint developers Daily scrum

meetings ,ST,
 Sprint testers PO, client

 Sprint Review meeting (feedback from client)

Not satisfy Satisfy

Sprint retrospective (Sm,St only) Sprint release

TESTING
(CCB)
(Maintaince)

STLC: (Software testing life cycle): It is a step by step procedure or standard procedure to test
any new software that is called software testing life cycle. It is a part of SDLC

Requirements &collections
Requirements &: collections A business analyst collect the requirements from client/customer
as per the business need of document and requirements specification BRS, FRS, URS

System study: Technical team thoroughly Understanding the requirements

Test plan: All the feature related testing plan
Write test cases
Traceability Matrix: We have all lists of requirements we have to make sure that each &
every requirement has got 1 test case at least

Test execution: By looking into the test cases we test the application mark test cases
pass/failed

Defect Tracking: If the feature and functionality is not working according to the customer
requirements Q.A & tester will raise the bug

Preparing test execution report: Prepared by the test lead which test Engineers are
involved in particular module, How many bugs find out how many test cases pass/fail what is
pass test case percentage /what is fail test case percentage all the report .

Retrospect meeting: Team manager will invite the all the test engineers we are involved in
particular module release what went well /not went well what are the mistake we have done.

The list is mostly equivalent to the Test Plan it will cover all Quality Assurance and Testing
Standards.

Testing Checklist:
TESTING

Create System and Acceptance Tests [ ]

Start Acceptance Test Creation [ ]
Identify Test team [ ]
Create Work plan [ ]
Create Test Approach [ ]
Link Acceptance Criteria and Requirements to form the basis of Acceptance Test [ ]
Use a subset of system test cases to form requirements portion of Acceptance Test [ ]
Create scripts for use by the customer to demonstrate that the system meets requirements [ ]
Create a Test schedule. Include people and all other resources. [ ]
Conduct Acceptance Test [ ]
Start System Test Creation [ ]
Identify test team members [ ]
Create Work plan [ ]
Determine Resource Requirements [ ]
Identify productivity tools for testing [ ]
Determine Data Requirements [ ]
Reach an agreement with Data Center [ ]
Create Test Approach [ ]
Identify any facilities that are needed [ ]
Obtain and review existing test material [ ]
Create an inventory of test items [ ]
Identify Design states, conditions, processes, and procedures [ ]
Determine the need for Code-based (white box) testing. Identify conditions. [ ]
Identify all functional requirements [ ]
End inventory creation [ ]
Start Test Case creation [ ]
TESTING
Create Test Cases based on the inventory of test items [ ]
Identify logical groups of business function for the new system [ ]
Divide test cases into functional groups traced to test item inventory [ ]
Design data sets to correspond to test cases [ ]
End Test Case creation [ ]
Review business functions, test cases, and data sets with users [ ]
Get signoff on test design from Project leader and QA [ ]
End Test Design [ ]
Begin Test Preparation [ ]
Obtain Test Support resources [ ]
Outline expected results for each test case [ ]
Obtain Test Data. Validate and trace to test cases [ ]
Prepare detailed Test Scripts for each test case [ ]
Prepare & Document environmental setup procedures. Include backup and recovery plans [ ]
End Test Preparation phase [ ]
Conduct System Test [ ]
Execute Test Scripts [ ]
Compare the actual result to Expected [ ]
Document discrepancies and create problem report [ ]
Prepare maintenance phase input [ ]
Re-execute test group after problem repairs [ ]
Create a final test report, include known bugs list [ ]
Obtain formal signoff [ ]