Life of a pragmatic tester

Post on 21-May-2015

171 Views

Category:

Software

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

There are not only one correct solution to many of the tasks we do within testing, we need a toolbox of many different tools and the pragmatism to acknowledge that we cannot use the same every time - there are no one size fits all :-)

Transcript

Life of a Pragmatic Tester

1

Gitte Ottosen

Gitte.ottosen@capgemini-sogeti.dk

@Godtesen

A bit about the company

The company:

• Sogeti is a leading provider of structured testing solutions

• Part of the Sogeti Group, which brings together more than 20,000 professionals in 15 countries and is present in over 100 locations in Europe, USA and India

• Creators of the globally recognized methodologies TMap NEXT ® and TPI NEXT®

2

And About Me

About me:

• I AM CERTIFIED ISEB Practitioner, TMap test engineer, Certified Scrum master, Certified Agile Test (CAT) Trainer, TPI NEXT Foundation…And I am probably not done yet

• Worked in the Royal Danish Air force for 9 years

• Tested complex mission critical systems the last 19 years

• Read a lot of books… about a lot of “stuff”

• Participate in conferences – to learn and share

• Part of networks – to learn and share

• I was a scout for 10 years – learning by doing

• I am doing a lot of crafts and creative stuff that stimulates my brain

• Sometimes I am just looking at the fish in my aquariums …

3

Why this Presentation

• Context driven vs. Standards driven

• Agile vs. Waterfall/v-model

• Life is not black and white

• A tool belt with many tools

4

A Quote from Cem Kaner

5

Controversy good. Polarization bad.

In a socioeconomic milieu that seems bent on becoming even more

polarized, it is no surprise that some of the rhetoric within the software

testing community has been going that way too.

It sells well. It gets people excited. But I don’t see how polarization will help

us make products safer and more pleasant to use or improve our working

conditions as we make those products.

Cem Kaner: Context-driven.com

6

Let’s get started

Product Risk Analysis - TMap

7

Critical succes factors Change request Requirements

Business processes etc.

Allocating test design techniques

6

Client Determining risk class

Assignment and test goals

Creating test cases

Determining test intensity Result Risk Time Costs

Test execution

Risk table

8

Test goal Characteristic Damage Chance of Failure

Risk Class

1.1 Functions work correctly

Functionality H H A

User-friendliness

M L C

1.2 Payment methods accepted

Functionality M M B

Security H M B

1.3 Sale traceable Functionality M L C

2.1 Tickets printed fast and easily

Performance M L C

2.2 Prizes are found fast Performance L L C

2.3 FO application works as intended

Functionality M M B

Suitability M M B

.. .. .. .. ..

A visual risk assessment

9

Likelihood

Impact

Creating the Test Strategy

• Test strategy table

• Formal documentation

• Test strategy table in an agile context

• User story risk quadrants

• SFDIPOT

10

From Product Risk to Test strategy

11

Characteristic

- test goal RC UAT Test type Technique

Functionality

1.1 functions work correctly A functional test DCT-eq

1.2 payment methods accepted B I implicit with the regression test -

1.3 sale traceable C functional test DCT-eq

2.3 FO application works as intended B functional test ECT-mcdc

User-friendliness

1.1 functions work correctly C usability test SYN-checklist

Performance

2.1 tickets printed fast and easily C real life test -

2.2 prizes are found fast C real life test -

Security

1.2 payment methods accepted B user with knowlegde of security Checklist, EG

Suitability

2.3 FO application works as intended B process test PCT-test depth 1

Risk analyses Test strategy

IEEE 829

• Test plan identified

• Introduction

• Test items

• Features to be tested

• Features not to be tested

• Approacch

• Item pass/fail criteria

• Suspension criteria and resumption requirements

• Test deliverables

• Testing tasks

• Environmental needs

• Responsibilities

• Staffing and training needs

• Schedule

• Risks and contingencies

• Approvals

TMap

• Introduction

• Assignment formulation

– Scope

– Assumptions and preconditions

– Acceptants and acceptance criteria

• Documentation

• Test Strategy

• Approach

• Organization

• Infrastructure

• Management

• Test process risks and countermeasures

• Global estimation and planning

Formal Documentation

12

Agile Test Strategy

13

Source: Leo van der Aalst – No test levels needed in agile software testmanagement

User Story Risk Quadrants

14

Source: Pascal Dafour, http://pascaldufour.wordpress.com/

SFDIPOT

15

From Test Strategy to Test Plan

• Formal test execution plan

• Staying in the test strategy table

• The test execution board

• Using a tool

16

Formal Test Execution Plan, example

• Introduction

• Structuring the test

• Approach

• Test cases

• Test data

• Test environments and test stubs

• Test Organization

• The customer’s participation in the test

• Test Criteria

• Schedule

• Risks and mitigations

• Test Deliverables

17

From Strategy to Implementation

18

Source: Leo van der Aalst – No test levels needed in agile software testmanagement

The Test Board

19

Ready to test In progress Done Execute again

Impediments/

Defects

Test task Blocked

Using a Test Management ”tool”

20

But what About Test Cases?

• Scripted

• Scenarios

• Checklists

• Charters

21

• When?

• Formal acceptance test cases

• Inexperienced testers

• Changing group of testers

• Very complex test situations

• Regression tests?

• Test case title

• Purpose

• Requirement addressed

• Prerequisites

• Procedure steps

• Test result

Traditional - Scripted

22

Making Scripted more Creative

23

Checklist

24

Create new document

From local template

From network template

From blank

Open document

Position

Local drive

Network drive

..

Type

Same version

Earlier version

Illegal format

How to open

From explorer

From xx

Print

Scenario Description

25

Exploratory Charter

Learn

Test design

Explore

Analyse

26

Communicating status

• Progress

– In sprints

– For test phases

• Final reports

– Internal

– External

27

Formal Reports

28

Becoming more visual – on page reports

29

Mindmap as dashboard

30

The Smiley Dashboard

31

It’s All About Context

32

33

One size doesn’t fit all

top related