Case Granlund: Testaaja ja testaava tuotekehitystiimi
Maaret Pyhäjärvi| <[email protected]> | 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