@Tampereen Teknillinen Yliopisto, 12.11.2012 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
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 kk-julkaisut tuotantoon Eka testaaja Etätestaus NYT Ryhti: 8 + minä kehittämässä, +1 etätestaaja, 8 tuotehallintatiimissä Raisu: 5 + minä kehittämässä, 1 tuotepäällikkö Raisu 4 arkkitehtuurimuutos Raisu 4 tuotantoon
Testausprosessin muutos ENNEN JÄLKEEN OK TP TUKI OK TP TUKI Toteutus&testaus Hyväksymistestaus Havaintoprosessi Toteutus&testaus Hyväksymistestaus Havaintoprosessi Testausympäristöt Järjestelmätestaus Testausympäristöt Testaus hoidettiin kahdessa porukassa, joilla yhteiset tukirakenteet. Toteuttaja vastasi sekä laadusta että laatutiedosta ulkoa ohjatuissa työmääräpuitteissa oman tietotaitonsa rajoissa. Lisätään panostus järjestelmätestaukseen, laatutavoitteiden asettamiseen ja toiminnan parantamiseen. Panos& kohdistussuunnittelu laadulle Tuotepäälliköt testasivat työmäärän ohjaamana kulloinkin tärkeimmiltä tuntuvat asiat. Työmäärät koettiin usein riittämättöminä. Toteuttajien ja tuotepäälliköiden vastuut pysyvät samana, mutta voivat pyytää tukea laatutiedon tuottamiseen testausvastaavalta. Toimintamallien aktiivinen muuttaminen. Toiminnan parantaminen
Katsaus minun maailmaani 1.4. 11.11.2012 Kaikki Jirassa (tehtävät ja havainnot) Minun raportoimani Etätestaaja Ra: 434 Ra: 169 2011.5 13 % 2012.9 1.6 %
Tavoitteita kehittämisessä Parannettu perusnäkyvyys laatuun Tutkivaa testausta; ominaisuus, prosessi ja tuote kerrallaan pätkissä Suunnittelumekanismin perusremppa lähiaikoina 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
Version aloituspalaveri Viikkopalaveri Viikkopalaveri Viikkopalaveri Version aloituspalaveri Asiakasversion julkaisu TK:n tehtävä KP:n tehtävä Asialistalla version testauskohteiden testauspainotukset Testaustyökuorman tarkistus ja tasaus tiimissä Version toteutus ja testaus viikon sykleissä RYHTI Asialistalla version testauskohteiden testauspainotukset 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ä Toteutus ja testaus Toteutus ja testaus Toteutus ja testaus Järjestelmätestaus Toteutus ja testaus Test-Fix-Finalize Korjausversio (branch) Viikko 1 Viikko 2 Viikko 3 Viikko 4 Viikko 1 Seuraavan version suunnittelu ja speksaus palaveri Julkaisun valmistelu Toistotestaus: ongelmien toistokaavat Perustestaus: toteuttajien tekemä testaus Muutostestaus: täydentävä testaus eri henkilön toimesta OK:n prosessivastaavat, arkkitehdin ja testaajan osallistuminen, kuukausipalaverit prosesseittain Seuraavan version suunnittelu ja toteutusversion julkaisu Prosessitestaus @KP (Järjestelmähyväksyntä) Issuetestaus @KP Issuetestaus @KP Issuetestaus @KP Hyväksyntä Hyväksyntä Hyväksyntä Hyväksyntä
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 Get up to speed quickly Generalist Domain knowledge Ignorance is important Need of Mastery Developer Thorough understanding Specialist Knowledge of product internals Expertise is important Model user behavior Focus on what can go wrong Focus on severity of problem Focus of Modeling Model system design Focus on how it can work Focus on interest of problem Practical Empirical: What is observed Sceptics Focus of Thinking Theoretical How it is designed Believers Tolerate tedium Comfortable with conflict Report problems Tedium and Conflict 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
Määrittelyt / SBE Laatutilanteen kokonaiskuva RYHTI OK Testauksen kehittämisen tilannekartta Yksikkötestit (automatisoitu) Jira-testaus Selaintestaus Havaintoprosessi Rakenneanalyysi Koodikatselmointi Toiminnallisuustestaus Regressiotestiautomaatio / SBE Suorituskykytestaus Tietoturvatestaus TUKI Testausympäristöt TP Prosessitestaus Panos&kohdistus suunnittelu Koontiprosessi Korjaustarpeide n priorisointi Toiminnan parantaminen Jira-testaus Tilanne kohtuullinen Kehitettävää Paljon kehitettävää
Määrittelyt / SBE Laatutilanteen kokonaiskuva RAISU OK Testauksen kehittämisen tilannekartta Yksikkötestit (automatisoitu) Toiminnallisuustestaus 1 Jira-testaus Koodikatselmointi Selaintestaus 1 Suorituskykytestaus Rakenneanalyysi Regressiotestiautomaatio / SBE Tietoturvatestaus TUKI TP Testausympäristöt Havaintoprosessi Prosessitestaus Panos&kohdistus suunnittelu Koontiprosessi Korjaustarpeide n priorisointi 1 Toiminnan parantaminen Jira-testaus Tilanne kohtuullinen Kehitettävää Paljon kehitettävää
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 nontester roles