Case Granlund: Testaaja ja testaava...

Case Granlund: Testaaja ja testaava tuotekehitystiimi

Maaret Pyhäjärvi| <maaret@iki.fi> | Twitter: maaretp

Testausasiantuntija @ Granlund Oy | Yrittäjä | TestausOSY:n ohryläinen

Erkki Pöyhönen & Maaret Pyhäjärvi Nimeä | Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/ http://creativecommons.org/licenses/by/1.0/fi/deed.en

@Tampereen Teknillinen Yliopisto, 12.11.2012

Puhujasta: Kokemuksia testauksesta ja testaajan työstä

monipuoliselta pohjalta • Aloitin testauksen parissa -95: lokalisointitestausta kreikankieliselle

ohjelmistokäännökselle

• Alihankkijana erilaisissa projekteissa: siirtymä lokalisointitestauksesta toiminnallisuustestaukseen

• Kokeilin toteuttajan roolia kuviteltuani ettei testaajaa arvosteta: arvostusongelma ei ole roolikohtainen

• Testauksen opetusta TKK:lla, julkisia seminaaripuheenvuoroja ja kursseja

• Testauksen tutkijana, testauskonsulttina, opettajana, testausvastaavana ja testaajana

• F-Securella ohjelmistotuoteliiketoiminnan ja ketterien menetelmien kanssa

• Eläkevakuutussektorilla toimittajaorganisaatiossa ja asiakasorganisaatiossa (Ilmarinen) testauspäällikkönä

• Granlundilla ainoana testaajana kuukausijulkaisuja tuottavissa kahdessa kehitystiimissä

• Sivuhommina yrittäjänä 2005 alkaen kouluttelee testausaiheita erilaisissa yhteyksissä

Case Granlund

Ryhti 4 tuotantoon

Raisu 4 tuotantoon

Eka testaaja

Etä-testaus

Raisu 4 arkkitehtuuri-

muutos

kk-julkaisut tuotantoon

NYT

Ryhti: 8 + minä kehittämässä, +1 etätestaaja,

8 tuotehallintatiimissä Raisu: 5 + minä kehittämässä,

1 tuotepäällikkö

Testausprosessin muutos

ENNEN JÄLKEEN

OK

Toteutus&testaus

TP

Hyväksymistestaus

TUKI

Havaintoprosessi

Testausympäristöt

OK

Toteutus&testaus

Järjestelmätestaus

TP

Hyväksymistestaus

TUKI

Havaintoprosessi

Testausympäristöt

Panos& kohdistussuunnittelu

laadulle

Toiminnan parantaminen

Testaus hoidettiin kahdessa porukassa, joilla yhteiset tukirakenteet.

Toteuttaja vastasi sekä laadusta että

laatutiedosta ulkoa ohjatuissa työmääräpuitteissa oman tietotaitonsa

rajoissa.

Tuotepäälliköt testasivat työmäärän ohjaamana kulloinkin tärkeimmiltä tuntuvat asiat. Työmäärät koettiin

usein riittämättöminä.

Lisätään panostus järjestelmätestaukseen,

laatutavoitteiden asettamiseen ja toiminnan parantamiseen.

Toteuttajien ja tuotepäälliköiden

vastuut pysyvät samana, mutta voivat pyytää tukea laatutiedon tuottamiseen

testausvastaavalta. Toimintamallien aktiivinen

muuttaminen.

Katsaus minun maailmaani 1.4. – 11.11.2012

Kaikki Jirassa (tehtävät ja havainnot)

Minun raportoimani Ra: 169

Ra: 434

Etätestaaja

2011.5 13 % 2012.9 1.6 %

Tavoitteita kehittämisessä lähiaikoina…

Parannettu perusnäkyvyys laatuun

Tutkivaa testausta; ominaisuus, prosessi ja tuote kerrallaan pätkissä

Suunnittelumekanismin perusremppa

Tarinapistearviointi, valmiin määritelmä joka sisältää testauksen ja muiden rinnakkaisten asioiden tehtävät

Arvo vs. hukka – mittareita läpimenolle

Stabilointiviikko

Jokainen testaa ja korjaa ja täydentää automaatiotestejä viimeisen viikon ennen julkaisua

”Hidastetaan ennen parkkeeraamista” – tavoite lyhentää parkkeerausaikaa (automaatio)

Testiautomaatio tehokkainta reittiä

Yksikkötestaus: kohdistettua palautetta

Rajapintatestaus: komponenttiin kohdistettua palautetta

Käyttöliittymätestaus, yhdistettynä määrittelyyn esimerkein (SBE)

OK

Ei OK

Ei OK

Bug: 4 h Bug Resolved: 1 h

Feature Resolved: 4 h

Testauksella erillinen työlista

Testausmalli

Ryhti

• Toteuttajien omatestaus & suorituskykymittaus

• Järjestelmätestaus riskialttiille kohteille

• Tuotepäälliköiden hyväksymistestaus

• Havainnot tuotantokäytöstä – Loki

– Asiakasyhteydenotot

Raisu

• Toteuttajien automatisoitu yksikkötestaus (testi jälkeen –kehitystapa)

• Toteuttajien omatestaus

• Arkkitehdin suorituskykytestaus

• Muutostestaus järjestelmätasolla

• Käyttäjätestaus

Viikko 1 Viikko 3 Viikko 4 Viikko 1 Viikko 2

Toteutus ja testaus Toteutus ja testaus Toteutus ja testaus Toteutus ja testaus

Version toteutus ja testaus

Hyväksyntä Hyväksyntä Hyväksyntä Hyväksyntä

Seuraavan version suunnittelu ja speksaus Julkaisun valmistelu

Seuraavan version suunnittelu

TK:n tehtävä

KP:n tehtävä

viikon sykleissä

ja toteutusversion julkaisu

§ Version aloituspalaveri § Version aloituspalaveri Asiakasversion julkaisu Viikkopalaveri Viikkopalaveri Viikkopalaveri

Järjestelmätestaus Test-Fix-Finalize

Asialistalla version testauskohteiden testauspainotukset

Asialistalla version testauskohteiden testauspainotukset

Toistotestaus: ongelmien toistokaavat Perustestaus: toteuttajien tekemä testaus Muutostestaus: täydentävä testaus eri henkilön toimesta

Testaustyökuorman tarkistus ja tasaus tiimissä

Valmiin määritelmä: vaatimukset sille että asian voi siirtää hyväksyntään

Testausta ja korjauksia (uudet) Yksikkötestien laajentamista ja viimeistelyä, dokumentointia Pienen riskin bugikorjauksia (vanhat) Testiautomaation täydentämistä

palaveri

Korjausversio (branch)

Prosessitestaus @KP (Järjestelmähyväksyntä) OK:n prosessivastaavat, arkkitehdin ja

testaajan osallistuminen, kuukausipalaverit prosesseittain

Issuetestaus @KP Issuetestaus @KP Issuetestaus @KP

RYHTI

Ryhti: Something Refactored

• One developer was assigned a major rewrite task – Goal: maintainability improvement

– 50 old known issues, out of which 30 got fixed, 20 not

– UI facelift, dropping non-core functionalities

• Tester + Product specialist assigned to test – 150 new issues to lists

• Side by side work cut down the timeframe for the change by 1/3

• Impact to quality is speculation, but likely to be better with collaboration (0.32 % -> 0.13 % in crashes per use)

I work with development productivity – helping us meet the right target in a shorter timeframe

PPP Test Case Documentation

• Step 1: Time before tester (word)

– 39 pages, 46 test cases, 3 pieces of relevant info

• Step 2: Getting started with learning (mindmap)

– 98 features to test

• Step 3: Reusable checklist (excel / gsheet)

– 59 things to consider, few dimensions

• Next step: Living documentation (feature files)

– First we learn what breaks in this area (refactored codebase from 18000 lines to 8400 lines) and if unit tests could catch that, then we consider this

– In last three months, ~20 bug fixes, no regression reported, delivered to customer monthly 25123 uses 09/2012

Testauksen suunnittelu

Ryhti: Paritestausta 2012

”Olen liian arvokas testaamaan”

”Ohho”

”Kuinka paljon ja koska?”

Tester vs. Developer Source: Adapted from Bret Pettichord. 2000. Testers and Developers Think Differently

Tester Developer

Need of Mastery

Focus of Modeling

Focus of Thinking

Tedium and Conflict

Get up to speed quickly Generalist

Domain knowledge Ignorance is important

Thorough understanding Specialist

Knowledge of product internals Expertise is important

Model user behavior Focus on what can go wrong Focus on severity of problem

Model system design Focus on how it can work

Focus on interest of problem

Practical Empirical: What is

observed Sceptics

Theoretical How it is designed

Believers

Tolerate tedium Comfortable with conflict

Report problems

Automate tedium Avoid conflict

Understand problems

17

Ryhti: Oivalluksia virheiden luonteesta

• Virheen toistokaavasta korjaukseen 2 tuntia – Ei yhtään esimerkkiä virheestä, jonka

korjaaminen veisi pidempään

• Asiakassuhteen rakentuminen – Virheet syy yhteydenottoon, nopea

reagointi voi tuoda yhteisen onnistumisen kokemuksen

Raisu: Oivalluksia virheiden luonteesta

• Monet virheistä määrittelyn puutteita – Esim. Raportti (järjestys, ei yksi vaan

monta)

• Lisämäärittely ei tuottanut enempää lisätyötä testauksen kautta kuin ”ajoissa” – Ei vaikutuksia arkkitehtuuriin

– Luonnollisia laajennoksia toteutettuun

Testaajien lisäämisestä

• Yhdellä testaajalla oli selvä, että testaus hoidetaan edelleen toteuttajien ja tuotepäälliköiden voimin

• Kahdella testaajalla tuotepäälliköiden testauskuorma keventynyt – mahdollisuus keskittyä muuhun – 1.5 testaajaa vs. 8 tuotepäällikköä, riski

TUKI

Testaus-ympäristöt

Havainto-prosessi

Panos&kohdistussuunnittelu

Toiminnan parantaminen

Koontiprosessi

OK

TP

Prosessi- testaus

Korjaustarpeiden priorisointi

Jira-testaus Mää

ritt

ely

t /

SB

E

Rakenne-analyysi

Koodi-katselmointi

Yksikkötestit (automatisoitu)

Toiminnallisuus-testaus

Selaintestaus

Laa

tuti

lant

een

koko

nais

kuva

Regressiotestiau-tomaatio / SBE

Suorituskyky-testaus

Tietoturva-testaus

Jira-testaus

Tilanne kohtuullinen Kehitettävää Paljon kehitettävää

Testauksen kehittämisen tilannekartta

RYHTI

TUKI

Testaus-ympäristöt

Havainto-prosessi

Panos&kohdistussuunnittelu

Toiminnan parantaminen

Koontiprosessi

OK

TP

Prosessi- testaus

Korjaustarpeiden priorisointi

Jira-testaus Mää

ritt

ely

t /

SB

E

Rakenne-analyysi

Koodi-katselmointi

Yksikkötestit (automatisoitu)

Toiminnallisuus-testaus

Selain- testaus

Laa

tuti

lant

een

koko

nais

kuva

Regressiotestiau-tomaatio / SBE

Suorituskyky-testaus

Tietoturva-testaus

Jira-testaus 1

1

Tilanne kohtuullinen Kehitettävää Paljon kehitettävää

Testauksen kehittämisen tilannekartta

RAISU

1

Quality Source: Gojko Adjic

To End This With

• Been in testing a while and will be a lot longer

• Can’t imagine a field of software engineering with more variance available in what you can learn and become

• It’s not just about the testing by testers, testing is for everyone – Everyone can do it, but only some can do it

really well: these some include also non-tester roles