Software Testing Life Cycle and Requirements Traceability Matrix, Lecture notes of Software Engineering

Download Software Testing Life Cycle and Requirements Traceability Matrix and more Lecture notes Software Engineering in PDF only on Docsity!

Testing in Software Life Cycle

Software Testing

Lecture 4

Software Testing Life Cycle(STLC)

Reference: https://www.guru99.com/software-testing-life-cycle.html http://www.softwaretestingclass.com/software-testing-life-cycle-stlc

Requirement Traceability Matrix ( RTM)

• (^) RTM captures all requirements proposed by the client or software

development team and their traceability in a single document

delivered at the conclusion of the life-cycle.

• (^) In other words, it is a document that maps and traces user

requirement with test cases.

• (^) The main purpose of RTM is to see that all test cases are covered so

that no functionality should miss while doing Software testing.

Why RTM is Important?

• (^) The main agenda of every tester should be to understand the

client’s requirement and make sure that the output product should

be defect-free. To achieve this goal, every QA should understand the

requirement thoroughly and create positive and negative test cases.

RTM Example

RTM Can

• Show the requirement coverage in the number

of test cases

• Design status as well as execution status for the

specific test case

• If there is any User Acceptance Test to be done

by the users, then UAT status can also be

captured in the same matrix.

• The related defects and the current state can

also be mentioned in the same matrix.

STLC Phases

STLC Stage Entry Criteria Activity Exit Criteria Deliverables Requirement Analysis Requirements Document available (both functional and non functional) Acceptance criteria defined. Application architectural document available. Analyze business functionality to know the business modules and module specific functionalities. Identify all transactions in the modules. Identify all the user profiles. Gather user interface/ authentication, geographic spread requirements. 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). Signed off RTM Test automation feasibility report signed off by the client RTM Automation feasibility report (if applicable

STLC Phases

STLC Stage Entry Criteria Activity Exit Criteria Deliverables Test case developmen t Requirements Documents RTM and test plan Automation analysis report Create test cases, test design, automation scripts (where applicable) Review and baseline test cases and scripts Create test data Reviewed and signed test Cases/scripts Reviewed and signed test data Test cases/scripts Test data

STLC Phases

STLC Stage Entry Criteria Activity Exit Criteria Deliverables Test Environment setup System Design and architecture documents are available Environment set-up plan is available Understand the required architecture, environment set-up Prepare hardware and software development requirement list Finalize connectivity requirements Prepare environment setup checklist Setup test Environment and test data Perform smoke test on the build Accept/reject the build depending on smoke test result Environment setup is working as per the plan and checklist Test data setup is complete Smoke test is successful Environment ready with test data set up Smoke Test Results.

STLC Phases

STLC Stage Entry Criteria Activity Exit Criteria Deliverables Test Execution Baselined RTM, Test Plan , Test case/scripts are available Test environment is ready Test data set up is done Unit/Integration test report for the build to be tested is available Execute tests as per plan Document test results, and log defects for failed cases Update test plans/test cases, if necessary Map defects to test cases in RTM Retest the defect fixes Regression Testing of application Track the defects to closure All tests planned are executed Defects logged and tracked to closure Completed RTM with execution status Test cases updated with results Defect reports

V Model

• The V-model is a type of SDLC model where

process executes in a sequential manner in V-

shape.

• Each phase must be completed before the

next phase begins.

• Testing of the phase is planned in parallel with

corresponding phase of development in V

model.

V-Model

Developers Life Cycle

(Verification)

Tester’s Life Cycle

(Validation)

Verification & Validation

Verification Validation

Verification addresses the concern: "Are

you building it right?"

Validation addresses the concern: "Are

you building the right thing?"

Ensures that the software system meets

all the functionality.

Ensures that the functionalities meet the

Proposed behavior.

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.

It has static activities, as it includes

collecting reviews, walkthroughs, and

inspections to verify a software.

It has dynamic activities, as it includes

executing the software against the

requirements.

V-Model

• (^) Requirements definition

The needs and requirements of the customer or the future system

user are gathered, specified, and approved. Thus, the purpose of

the system and the desired characteristics are defined.

->The test plan focuses on meeting the functionality specified in

the requirements gathering.

• (^) Functional System Design/System Design

This step maps requirements onto functions and dialogues of the

new system.

• (^) It’s the phase where system engineers analyze and understand the

business of the proposed system by studying the user requirements

document. They figure out possibilities and techniques by which

the user requirements can be implemented. If any of the

requirements are not feasible, the user is informed of the issue.

V-Model

• Technical/High level system design:

This step designs the implementation of the system. This

includes the definition of interfaces to the system environment

and decomposing the system into smaller, understandable

subsystems (system architecture). Each subsystem can then be

developed as independently as possible.

• Component/Low Level specification:

This step defines each subsystem, including its task, behavior,

inner structure, and interfaces to other subsystems.

• Programming:

Each specified component (module, unit, class) is coded in a

programming language.