Scribd
Upload
65 views

Test Planning: CSTE Skill Category 4

This document discusses test planning and risk analysis for software testing. It begins by defining key risk concepts and identifying 18 common risks associated with software development phases and ways to mitigate them. It then discusses prerequisites to test planning, how to create a test plan, and developing a test matrix. An effective test plan is described as being repeatable, controllable, providing adequate coverage and starting early in the development process. It should define test objectives, inputs, procedures, acceptance criteria and controls. The planning process involves identifying risks, estimating their magnitude, selecting testing priorities based on probability and impact, and applying risk reduction methods and contingency planning.

Uploaded by

Ankur Singh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
65 views

Test Planning: CSTE Skill Category 4

This document discusses test planning and risk analysis for software testing. It begins by defining key risk concepts and identifying 18 common risks associated with software development phases and ways to mitigate them. It then discusses prerequisites to test planning, how to create a test plan, and developing a test matrix. An effective test plan is described as being repeatable, controllable, providing adequate coverage and starting early in the development process. It should define test objectives, inputs, procedures, acceptance criteria and controls. The planning process involves identifying risks, estimating their magnitude, selecting testing priorities based on probability and impact, and applying risk reduction methods and contingency planning.

Uploaded by

Ankur Singh
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

CSTE Skill Category 4

Test Planning
Risks Prerequisites to Test Planning Create the Test Plan

Presented by: David Thompson QA Engineer II, Albertsons Inc.


1

Risk Concepts & Vocabulary


Test Case Test cases are how the testers validate that a software function meets the Software Specifications Test Data Information used to build a test case Test Script An Online entry of test cases Risk The potential loss to an organization Threat Something Capable of exploiting vulnerability

Vulnerability A design, implementation, or operations flaw that may be exploited by a threat


Control Anything that causes a reduction of risk
Page 224-225 2

Risks Associated with S/W development


Risk #1 Prevalent Phase

Improper Use of Technology

Design

Ways to Mitigate

Interviewing Users (to ensure need) Prototyping

Page 227

Risks Associated with S/W development


Risk #2 Prevalent Phase

Repetition of Errors

Code

Ways to Mitigate

White Box Testing

Page 227

Risks Associated with S/W development


Risk #3 Prevalent Phase

Cascading of Errors

Release / Maintenance

Ways to Mitigate

Regression Testing System Testing

Page 228

Risks Associated with S/W development


Risk #4 Prevalent Phase

Illogical Processing

Design

Ways to Mitigate

Data Validation (Bounds ing, Field verification) Code Review

Page 228

Risks Associated with S/W development


Risk #5 Prevalent Phase

Inability to Translate User Requirements Needs into Technical Design Requirements Ways to Mitigate
Prototyping Interviewing Users

Page 228

Risks Associated with S/W development


Risk #6 Prevalent Phase

Inability to Control Technology

Entire SDLC

Ways to Mitigate
Structured Configuration Management

Page 229

Risks Associated with S/W development


Risk #7 Prevalent Phase

Incorrect Entry of Data

Code Release / Maintenance

Ways to Mitigate
Bounds Testing White Box Testing Data Validation Testing

Page 229

Risks Associated with S/W development


Risk #8 Prevalent Phase

Concentration of Data

Requirements Design

Ways to Mitigate
Security Testing Data Transmission Testing Input / Output Testing Data Normalization 3rd Normal Form
Page 230 10

Risks Associated with S/W development


Risk #9 Prevalent Phase

Inability to React Quickly

Requirements Design Code

Ways to Mitigate
Performance / Load Testing Build Management / CM

Page 231

11

Risks Associated with S/W development


Risk #10 Prevalent Phase

Inability to Substantiate Processing

Design

Ways to Mitigate

Security Testing Security Logs Transaction Logs White Box Testing Back up Scheme CM
Page 231 12

Risks Associated with S/W development


Risk #11 Prevalent Phase

Concentration of Responsibilities

Design

Ways to Mitigate
Security Testing (Security) Policies & Procedures

Page 232

13

Risks Associated with S/W development


Risk #12 Prevalent Phase

Erroneous or Falsified Input Data

Design Maintenance

Ways to Mitigate Data Validation I/O Testing Black Box Testing Security Testing Processes and Procedures
Page 232 14

Risks Associated with S/W development


Risk #13 Prevalent Phase

Misuse by Authorized End Design User Maintenance / Release


Ways to Mitigate Audit Trails Security Testing Processes and Procedures

Page 233

15

Risks Associated with S/W development


Risk #14 Prevalent Phase

Uncontrolled System Access

Design Maintenance

Ways to Mitigate Securing Equipment and Access Processes and Procedures

Page 234

16

Risks Associated with S/W development


Risk #15 Prevalent Phase

Ineffective Security and Privacy Practices for the Application

Design Maintenance / Release

Ways to Mitigate Securing Equipment and Access Processes and Procedures Security Testing Security Logs Created Automatic Emails Generated
Page 234 17

Risks Associated with S/W development


Risk #16 Prevalent Phase

Procedural Errors During Operation

Release Maintenance

Ways to Mitigate Audits Procedures and Policies Configuration Management Checklists CPI
Page 235 18

Risks Associated with S/W development


Risk #17 Prevalent Phase

Program Errors

Design Code Maintenance


Ways to Mitigate White Box Testing Document Reviews Audits Code Reviews Security Testing
Page 236 19

Risks Associated with S/W development


Risk #18 Prevalent Phase

Operating System Flaws

Design

Ways to Mitigate Code Reviews Security Testing Load / Performance Testing

Page 237

20

Risks Associated with S/W development


Risk #18 Prevalent Phase

Communication System Failure

Design Code

Ways to Mitigate Data Transmission Testing Document Reviews Physical Security

Page 238

21

Risks Associated with S/W testing


When conducting risk analysis, two major components are taken into consideration: The probability that the negative event will occur The potential loss or impact associated with the event

Some Primary Testing Risks:


Not Enough Training Us versus Them Lack of Mgmt Understanding Not enough schedule or Budget Rapid Change Having to say no New Technology

Lack of Test Competency Lack of Test Tools Lack of Customer / User Involvement Over Reliance on Independent Testers Testers in a Lose-Lose Situation Test Environment New Developmental Process
22

Page 238-239

Risk Analysis
Testing is a process designed to minimize software risks. To make software testing most effective, it is important to assure all the high risks associated with the software, will be tested first.

Risk Analysis Process


1. Form the Risk Analysis Team
a) b) Knowledge of the Application Understanding of Risk Concepts Risk Checklist Risk Analysis

2.

Identify Risks
a) b)

3.

Estimate the Magnitude of the Risk


a) b) Intuition and Judgment Risk Formula
Risks Ranked by Severity
Page 241-246 23

4.

Select Testing Priorities


a)

Risk Management
Risk management is a totality of activities that are used to minimize both the frequency and the impact associated with risks. After determining risks; need to determine risk appetite (the amount of the loss) management is willing to accept for a given risk.

Risk Reduction Method


1. 2. Risk Frequency X Loss/Occurrence = Total Loss Apply Controls to Minimize Risk
a) b) Reduce the Opportunity for Error Minimize Loss Identify Error prior to Loss Recover Loss

3.

If the Controls Cost less than the Estimated Loss there is a Good Case to Implement the Controls.

Contingency Planning
1. Action Plans should be established for activation when a loss is known to occur for a given risk. The testers should evaluate the adequacy of the contingency plans
Page 246-248 24

Prerequisites to Test Planning


1. 2. 3. 4. Test Objectives assures the project directives are met Acceptance Criteria have the user define this criteria Determine Assumptions have them clearly documented People Issues Watch out if the s/w engineering Director is also the head of QA. Constraints Obvious constraints are test staff size, test budget, and test schedule.

5.

Page 249-250

25

Create the Test Plan


The test plan describes how testing will be accomplished. Its creation is essential to effective testing, and should take about 1/3 of the total test effort. If the plan is developed carefully, test execution, analysis, and reporting will flow smoothly.

A Test Plan should


1. 2. Provide background information on the s/w being tested, test objectives, risks, and specific tests to be performed Have tests that are: Repeatable, controllable, and ensure adequate coverage

The act of designing tests is one of the most effective error prevention mechanisms known..
Page 251 26

How to Write a Good Test Plan


Understand the Characteristics of the Software being developed:
1. 2. 3. 4. 5. 6. 7. 8. 9. Define what it means to meet the project objectives. Understand the core business areas and processes. Assess the severity of potential failures. Identify the components for the system. Assure requirements are testable. Address implementation schedule issues. Address interface and data exchange issues. Evaluate contingency plans for system and activities. Identify vulnerable parts of the system and processes operating outside the information resource management area.

Page 252

27

How to Write a Good Test Plan


Build the Test Plan:
1. Set Test Objectives
a) b) c) d) Referenced by a number Write as a measurable statement Assign a priority Define acceptance criteria Define tests as required Define conceptual test cases to be entered as a test script Define verification tests Prepare software test matrix Identifies schedule, milestones, and resources needed Cannot be completed until the test matrix is completed
Page 253 - 258 28

2.

Develop Test Matrix


a) b) c) d)

3.

Define Test Administration


a) b)

How to Write a Good Test Plan


Develop the Test Matrix:
1. Define Tests as Required
a) b) Referenced by a name and number Contains: Objective, Test Inputs, Test Procedure, Acceptance Criteria, Test Controls when to stop the test, & Reference to what is tested

2. 3.

Define Conceptual Test Cases to be Entered as Test Scripts


a)
a)

Use Case type tests.


Static test performed on a document developed by the team responsible for creating software. A requirements traceability matrix.

Define Verification Tests

4.

Prepare the Software Test Matrix


a)

Page 254 - 257

29

How to Write a Good Test Plan


Write the Test Plan:
1. 2. 3. 4. 5. 6. Start Early Keep the Test Plan Flexible Review the Test Plan Frequently Keep the Test Plan Concise and Readable Calculate the Planning Effort Spend the necessary time to complete the Test Plan

Page 261

30

How to Write a Good Test Plan


Test Plan Standard
There is no one universally accepted standard for test planning. There are many Test Plan Standards available on the Internet from various organizations, for example: MilStd 498, IEEE829, IEEE/EIA 12207. Most Test Plan Standards consist of the following sections.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Test Scope Test Objectives Assumptions Risk Analysis Test Design Roles & Responsibilities Test Schedule & Resources Test Data Management Test Environment Communication Approach Test Tools 1. 2. 3. 4. 5. 6. 7. 8. Scope Referenced Documents Software Test Environment Test Identification Test Schedules Requirements Traceability Notes Appendices

Page 262-263

31

You might also like