Software Testing Life Cycle Unit-3

STLC
• Software Testing Life Cycle process is an integral
part of the Software Development Life Cycle. The
overall aspect of STLC phase deals with testing
and rectifying any error code generating within
the program under various test conditions.

?
• STLC is simply a testing phase in the SDLC
development. Validation and Verification is tried
and tested in this phase. The only limitation of
this cycle is that it is limited to respective
individual phase and is carried out by a group of
skilled testers.

PHASES OF STLC
– Preparing the test strategy &
planning
– Creating the testing
environment
– Writing the test cases/Creating
& Executing the Test Script
– Analysis result and Bug report
– Analyze Bugs and application
errors
– This is a post conditional process
which involves collecting data from end users

Difference Between SDLC and STLC
Software development life cycle(SDLC) and Software Testing Life cycle(STLC) go parallelly.
SDLC (Software Development Life cycle) STLC (Software Test Life Cycle)
SDLC is Software Development Lifecycle,
it is a systematic approach to develop a
software.
The process of testing a software in a well planned and
systematic way is known as software testing life
cycle(STLC).
Requirements gathering
Requirements Analysis is done is this phase, software
requirements are reviewed by test team.
Design
Test Planning, Test analysis and Test design is done in
this phase. Test team reviews design documents and
prepares the test plan.
Coding or development
Test construction and verification is done in this phase,
testers write test cases and finalizes test plan.
Testing
Test Execution and bug reporting, manual testing,
automation testing is done, defects found are
reported. Re-testing and regression testing is also done
in this phase.
Deployment
Final testing and implementation is done is this phase
and final test report is prepared.
Maintenance Maintenance testing is done in this phase.

• Act of reviewing, inspecting, testing, checking,
auditing, or otherwise establishing and
documenting whether items, processes, services
or documents confirm conventional to specified
requirements.
Process of evaluating a system or component to
determine whether the products of a given
development phase satisfy the conditions
imposed at the start of the phase .

• Validation is, according to its ANSI/IEEE
definition, 'the process of evaluating a system
or component during or at the end of the
development process to determine whether it
satisfies specified requirements'.
• Validation is, therefore, 'end-to-end'
verification.

• Software verification asks the question, "Are we
building the product right?” that is, does the
software conform to its specification.
• Software validation asks the question, "Are we
building the right product?"; that is, is the
software doing what the user really requires.

•Techniques of verification
»Reviews
»Inspection
»Walkthrough

• Software reviews is of two type
–i. Software Management Review
–ii. Software Audit Review

Conducted by management representatives to
evaluate the status of work done and to make
decisions regarding downstream activities.
Software management reviews

• A systematic evaluation of a software acquisition,
supply, development, operation, or maintenance
process performed by or on behalf of management
... [and conducted] to monitor progress, determine
the status of plans and schedules, confirm
requirements and their system allocation, or
evaluate the effectiveness of management
approaches used to achieve fitness for purpose.
• Management reviews support decisions about
corrective actions, changes in the allocation of
resources, or changes to the scope of the project.

• Software audit reviews are conducted by personnel
external to the software project, to evaluate
compliance with specifications, standards,
contractual agreements, or other criteria.

• A software audit review, or software audit, is a
type of software review in which one or more
auditors who are not members of the software
development organization conduct "An
independent examination of a software product,
software process, or set of software processes to
assess compliance with specifications, standards,
contractual agreements, or other criteria".

Inspection in software engineering refers to peer
review of any work product by trained
individuals who look for defects using a well
defined process .
An inspection is one of the most common sorts of
review practices found in software projects.
The goal of the inspection is to identify defects

During an inspection the following roles are used.
• Author: The person who created the work product
being inspected.
• Moderator: He is the leader of the inspection. The
moderator plans the inspection and coordinates it.
• Reader: The person reading through the documents,
one item at a time. The other inspectors then point out
defects.
• Recorder/Scribe: The person that documents the
defects that are found during the inspection.
• Inspector: The person that examines the work product
to identify possible defects

The Inspection Process
• Planning: The inspection is planned by the moderator.
• Overview meeting: The author describes the
background of the work product.
• Preparation: Each inspector examines the work product
to identify possible defects.
• Inspection meeting: During this meeting the reader
reads through the work product, part by part and the
inspectors point out the defects for every part.
• Rework: The author makes changes to the work
product according to the action plans from the
inspection meeting.
• Follow-up: The changes by the author are checked to
make sure everything is correct.

Inspection types `
»Code review
»Peer Reviews

• A code review can be done as a special kind of
inspection in which the team examines a sample of
code and fixes any defects in it.
• In a code review, a defect is a block of code which does
not properly implement its requirements, which does
not function as the programmer intended, or which is
not incorrect but could be improved .
• In addition to helping teams find and fix bugs, code
reviews are useful for both cross-training programmers
on the code being reviewed and for helping junior
developers learn new programming techniques.

• Peer reviews are considered an industry best-
practice for detecting software defects early and
learning about software artifacts(software source code).
• The elements of Peer Reviews include the
structured review process, standard of excellence
product checklists, defined roles of participants,
and the forms and reports.

• a walkthrough or walk-through is a form of software
peer review "in which a designer or programmer
leads members of the development team and other
interested parties through a software product, and
the participants ask questions and make comments
about possible errors, violation of development
standards, and other problems“
• A walkthrough is normally organized and directed
by the author of the technical document.

. V-testing Model
•a. Software development V & V
•b. Software Acquisition V & V
•c. Software Supply V & V.

Requirements like Business Requirement
Specification and system Requirement
Specification begin the life cycle model just like the
waterfall model.
 In V- model before development is started, a
system test plan is created.
The test plan focuses on meeting the functionality
specified in the requirements gathering.

This phase focuses on system architecture and
design.
 It provide overview of solution, platform,
system, product and service/process.
 An integration test plan is created in this
phase as well in order to test the
component/modules of the software systems
ability to work together.

The low-level design (LLD) phase is where the
actual software components are designed.
It defines the actual logic for each and every
component of the system.
Class diagram with all the methods and
relation between classes comes under LLD.
Component tests are created in this phase as
well.

• The implementation phase is, again, where all
coding takes place.
• Once coding is complete, the path of execution
continues up the right side of the V where the test
plans developed earlier are now put to use.

• Coding: This is at the bottom of the V-Shape
model. Module design is converted into code
by developers.

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

• Very rigid and least flexible.
• Software is developed during the
implementation phase, so no early prototypes
of the software are produced.
• If any changes happen in midway, then the
test documents along with requirement
documents has to be updated.

Software Testing Life Cycle Unit-3

Recommended

More Related Content

What's hot (20)

Similar to Software Testing Life Cycle Unit-3 (20)

More from Raj vardhan (20)

Recently uploaded (20)

Software Testing Life Cycle Unit-3