making quality visible in product engineering

Making QA Visible

by JAN PETTER HAGBERGCOLOMBO FRI 14. JUNE 2013

in product engineering

A quality assurance company should champion processes that build quality into the code from the start rather than test qualityin later

Mary Poppendieck

my talk today

how we have made QA an integral part of what we do, and why we do it

why do we need to focus on

qualityassurance?

?#1

Product Engineering is all about “not counting your chickens before they hatch”

?#2

what’s on the outside (design), must match what’s on the inside (code)

?#3

time is money

how will focusing on QA

improveyour time to market ?

?you don’t want to end up here

bad quality meansadministration overhead waste of valuable time

bad released quality meanshandling of defects in your

released version which will interrupt the flow in your

current project

doing things right the firsttime allows you to free up time for creativity and ingenuity

?things we have

donethat we find useful

Making Quality

visible

5

first have a

vision

our vision is to deliver software solutions which positively influence the individual user, by making their daily tasks more efficient, easier and

funThe SuperOffice vision statement - 1990

second

build a culture

we discussed…How we really wanted to develop

our software

How we wanted to be proud of not only the software we created, butalso how we created it

In product development there is no such thing as

it works on my machine

it is just a 10 min job

a favorite hero who solves your

current problems with dazzling

programming

= problems!

our mindset is that

we are all

product developer

s

…and we allparticipate in the

system tests

third reviews & retrospectives

each phase produces deliverables that should be «tested» before handed over to the next phase in the development process

document inspectionFormal quality verification of a finalized document. May be used on all documents. Document updated.

1/3 presentationA small informal presentation of a solution aimed to generate discussion and maybe alternative solutions

backlog meetingsPresentation of User Stories

code reviewQuality Assurance of code or unit test code before feature complete or after implementation of bugfix

pair testing Developer gets help with dev.test from a tester. Bugs found are fixed

differenttypesofreviews

projectretrospective

Regardless of what we discover, we understand and truly

believe that everyone did the best job they could, given what

they knew at the time, their skills and abilities, the resources available, and the

situation at handNorman L. Kerth

why project retrospectives?the exercises build trustreally visualizes the QA

aspect

you learn a lot in projects

Project Retrospectives – a handbook for team members

by Norman L. Kerth

fourth

process improvements should bean evolutionnot a revolution

-> 97 - Source Control system- Developers tested during weekends when product was considered finished

1997 - The developers tested at the end of the development cycle- BugTracker, our own implemented bug database- Improved our Release Test routines

1998 - We introduced a common coding StyleGuide- Specification and Technical design templates was introduced- Bought a professional bug tracking system - DevTrack

1999 - A dedicated test person was hired- Code Reviews introduced- Rational Rose and UML was introduced- Nightly builds- Milestones with testing of each Milestone- First Project Review

2000 - We enhanced the templates for Specification and Technical design

2002 - Test Procedures were introduced- Two persons on the Test team

2003 - StateZero DB created which is a DB you know the content of.

2004 - Developers Test (checklist)- Unit Tests on NetServer

2005 - Three persons on the Test team- 1/3 Reviews and Document Inspections

2006 - QA Plan template and QA Progress Plan template- Smoke test introduced- Hired Hans Schaefer to help us with analyzing our test work

2007 - Sri Lanka test resources was hired (3 people)- SCRUM introduced

2008 - Improved our Beta program- More Test people hired

2009 - SCRUM used in our largest project so far SuperOffice 7.0 win & web- Sri Lanka test resource now counts 3 more people = 6 people, 4 people in Norway

- One tester on each team

2011 - Microsoft TFS tool introduced, supports working with the SCRUM as an Agile method- SCRUM used in all of our projects

SCRUM process makes QA work visible

sprint test

functional test

TDD

testing is part of daily work

backlog meeting sprint

planning

visibility of statusapply rules and more…

one tool

fifth

empathy withthe user

problem?Product Developers have little or no contact with the users of the software they build

frequent releases

will give you quick feedback from your users and increase the quality awareness among your product developers

beta program «testing carried out by real users in real environments»

the beta program can be anopportunity to let your product developers get to know your users

in this talk

Making QA visible in Product

Engineering

have a vision

culture - we are all product

dev.

bring everyone on-board

find defects early with

reviews

feedback from customers

successful implementation of QA in every aspect of what you do will give you the ability to

do more!

thankyou!

aboutme

I am experienced in most roles involved in software development after 20 years in the business. I have worked both in the ISV industry as well as a consultant. After many years as a programmer, I started to look closer to the processes and methods used in software development and how to improve these.

With a special interest in delivering good quality software on time I have build up the QA team in SuperOffice and also embraced Agile methodologies as the development process to be used within the company.

Today I am working with offshoring, distributed teams, processes in R&D and as SCRUM master. I am also the QA Manger in SuperOffice

SuperOffice have 200 employees, 42 of us work in R&D