SDLC TDLC

1
SDLC - TDLC
Author Varaprasada Rao Imandi

• We Break Codes and Make System Fail

2
Introduction of Defects
3
Relative cost of Software Defects (Industry
Examples)

• The cost of fixing defects escalates as we move
  the project towards field use.

4
Error removal cost over SDLC
5
Testing Life Cycle - VV Process Model
Test Strategy Review
Test Audit
Test Strategy/ Plan
System Test Case Review
System Test Design
Integration Test Case Review
Integration Test Design
Test Scripts Development
Hand off to VV team
6
Preamble of Verification

• Prevention is better than cure

7
Types of Reviews

• Reviews
• Walkthroughs
• Inspections
• Audits

8
Types of Reviews

• Walkthrough
• Informal
• Driven by author
• Objective not to find defects, but to improve the
  document
• More proactive
• Brainstorming happens to improve
• for training and building the document/code

• Inspections
• Formal
• Done by domain experts
• Focus is on finding defects
• Input documents and standards
• No point in reviewing a document that has not
  stabilized

9
Purpose of Inspections

• Detect defects early
• Permit mid-course corrections
• Emphasize quality throughout development
• Improve the product under review

10
Definition of Inspection (Review)

• A formal evaluation technique in which software
  requirements, design, or code are examined in
  detail by a group of persons other than the
  author(s) to detect faults, violations of
  development standards and other problems.
• IEEE Std
  729-1983

11
History of Inspection Technique

• Developed by Michael Fagan at IBM, Kingston NY
  Lab.
• He published a paper in 1976, describing the
  method.
• The technique was first used for code.
• Later moved on to requirements, design etc.

12
Benefits of a Review

• Problems identified early - better project
  management, less surprises
• Less effort, less cost, schedule benefit

13
Roles

• 1. Review Leader/Moderator
• 2. Reader
• 3. Recorder
• 4. Author
• 5. Reviewer

14
Testing Life Cycle VV Process
Design Phase Testing Activities

• Develop Test cases to ensure that product is on
  par with Software Requirement Specification
  Document (SRS).
• Verify Test Cases Test Scripts by peer reviews.
• Preparation of traceability matrix from system
  requirements

15
Testing Life Cycle VV Process
Requirements
Identify the customer and work together to
negotiate product level requirements.
Testing related activities during Requirement
phase

• Creation and finalization of testing templates
• Creation of over-all Test Plan and Test Strategy
• Capturing Acceptance criteria and preparation of
  
• Acceptance Test Plan

16
Testing Life Cycle VV Process
Testing activities in System Testing phase

• System testing is done for validating the product
  with respect to client requirements
• Testing can be in multiple rounds
• Defect found during system test should be logged
  into Defect Tracking System.
• Test logs and defects are captured and
  maintained.
• Review of all the test documents

Testing activities in Integration Testing phase

• This testing is conducted in parallel with
  integration of various applications (or
  components)
• Testing the product with its external and
  internal interfaces without using drivers and
  stubs.
• Incremental approach while integrating the
  interfaces.

17
Testing Life Cycle VV Process
Testing activities during Release phase/
Acceptance Phase

• Acceptance testing is conducted at the customer
  location.
• Resolves all defects reported by the customer
  during Acceptance Testing
• Conduct Root Cause Analysis (RCA) for those
  defects reported by customer during acceptance
  testing

18
Testing Life Cycle VV Process
QA Vs QC
Quality Assurance A set of activities designed
to ensure that the development and maintenance
process are continuously improved to produce
products that meets specifications.
Quality Control The process by which product
quality is compared and detected w.r.t
requirements and other relevant specifications,
focus is in detection and removal.
19
Quality Assurance Vs Quality Control

• QC
• QC activities focus on finding defects in
  specific deliverables.
• QC is product oriented.
• Oriented to detection.
• Inspection and ensuring work product meets the
  requirements.

• QA
• QA activities ensure that
• the process is defined and
• appropriate.
• QA is process oriented.
• Oriented to prevention.
• Monitoring and improving
• process.

20
Testing Life Cycle VV Process
Test Strategy

• Test strategy is a statement/plan level of
  overall approach of testing to meet the business
  and test objectives.
• It identifies the methods, techniques and tools
  to be used for testing .
• It can be a project or an organization specific.
• An effective strategy has to meet the project and
  business objectives
• Acceptance test plan This plan specifies the
  criteria for client acceptance of the final
  tested product including Features/functionalities
  to be tested and traceability information.

21
Testing Life Cycle VV Process
Test Strategy - Approach

• Test approach will detail the way the testing to
  be carried out based on the objectives.
• Types of testing to be done like Unit,
  Integration and system testing
• The method of testing like BlackBox, White-Box
  etc.,
• Details of any automated testing to be done

22
System Analysis and Design
Test Planning

• Documenting assumptions
• Requirements tracing
• Schedule / Miles stones
• Resources
• Change Management (Version control/ Updating test
  cases)
• Suspension and Resumption criteria.

23
System Analysis and Design
Estimation of error distribution in different
phases..
24
System Analysis and Design
Test Execution
Unit Testing

• Unit level testing is typically done as white box
  testing.
• Unit testing is done at module level.
• Objective is to exercise all parts of the
  program.
• Drivers are used to feed the data to the program
  to test it.
• Test stubs are used to stub for the functions
  which are outside the module

25
System Analysis and Design
Test Execution
Integration Testing

• Tests partial systems composed of integrated
  components
• Integration testing is Black-Box testing
• Main difficulty in integration testing is
  localizing errors
• There are two approaches to integration testing
• Top-down approach Start from the top level
  module and integrate individual components and
  stub the rest of the system
• Bottom - up approach Integrate individual
  components from lower level module until whole
  system is integrated .

26
System Analysis and Design
Test Execution
System Testing
The testing of a complete system prior to
delivery. The purpose of system testing is to
identify defects that will only surface when a
complete system is assembled. That is,defects
that cannot be attributed to individual components
or the interaction between two components.
System testing includes testing of performance,
security, configuration sensitivity, startup and
recovery from failure modes.
27
Testing Types

• Black-Box testing
• not based on any knowledge of internal design or
  code.
• tests are based on requirements and functionality
• White box testing
• based on knowledge of the internal program design
  and code.
• tests are based on coverage of code statements,
  branches, paths, conditions.

28
Testing Types
Performance Testing Performance testing of an
Application is basically the process of
understanding how the application and its
operating environment respond at various user
load levels. Performance Testing comprises of
Load Testing,Stress Testing, Contention Testing
and Configuration Testing.
29
Testing Types
Load Testing An application under heavy loads,
such as testing of a web site under a range of
loads to determine at what point the systems
response time degrades or fails.
Stress Testing Testing conducted to evaluate a
system or component at or beyond the limits of
its specified requirements.
Configuration Testing The objective of
Configuration testing is to determine the minimal
and optimal hardware and software configuration
requirements to have acceptable response time for
a given load.
30
Smoke / Sanity
Smoke Testing Smoke testing is a shallow and wide
approach to the application. You test all areas
of the applicationwithout getting too deep. This
is also known as a Build Verification test.
Sanity Testing sanity testing is usually narrow
and deep. That is they lookat only a few areas
but all aspects of that part of the application.
A smoke test is scripted--either using a written
set of tests or an automated test--whereas a
sanity test is usually unscripted.
31
Thank you so much...
THE END