Ajatuksia ketterästä ohjelmistokehityksestä ja laadusta 2012-11-26 1
Quality Manager & Specialist, Testing /Cybercom Finland CMMI, TMMI FiSTB:n varapuheenjohtaja ja hallituksen jäsen (http://www.fistb.fi) ISTQB : Main responsibility person of social media marketing at Marketing working group DI: Tietojohtaminen, hypermedia, teollisuustalous Diplomityön aihe: Tiedonsiirron haasteet ohjelmistotestauksessa (2008) Aiempi koulutus: Tradenomi, Tietotekniikka (mekaanikko YO) Harrastukset: suunnistus, juoksu, maastopyöräily, koripallo (katsomossa)... 2012-11-26 2
Agenda Part I: Miksi prosessien parantaminen on aina Hot Topic? Laadusta ja laaduttomuudesta Mitä on ketterä ohjelmistokehitys /Agile Manifesto? Agile Manifesto vs. testauksen näkökulma ja periaatteet Part II: Case Whale Watch 2012-11-26 3
Miksi prosessien parantaminen? Process Improvement Google: n.163 000 000 tulosta (0,26 sekuntia) Mitä yleisesti ottaen halutaan ohjelmistoprojektilta? Onnistuminen Tehdään oikeita asioita Kustannusten minimointi Asiakastyytyväisyys 2012-11-26 4
Miksi prosessien parantaminen on niin vaikeaa? 10 8 6 4 2 Series1 0 1 2 3 4 5 6 7 8 9 10 Series1 Idea Käyttöönotto Käyttö R.I.P. 2012-11-26 5
Testaajan ympäristöä Scrum Agile XP CMMI TMMI Jira Testlink Automatisointi Selenium Käytettävyys Vesiputous Testitasot Viat Vaatimukset Yksikkötestaus Integraatiotestaus Järjestelmätestaus Hyväksymistestaus Automatisointi Daily Scrum Katselmoinnit Palaverit Sprint Backlog Sprint Review Retrospektiivit Muutokset Vian korjaaminen Varmistustestaus Versionhallinta SVN Muutostenhallinta Tutkiva testaus Regressiotestaus Testaussuunnitelma Testitapaukset PDCA Sprintti Product Backlog Product Owner Lean Suorituskyky Tietoturva 2012-11-26 6
Mistä asiakas haluaa maksaa? 2012-11-26 7
Mistä asiakas ei halua maksaa? Hukka (Muda) Kuljetukset Varastot Liike Odotusaika Ylituotanto Yliprosessointi Viat (=vikojen etsimiseen ja niiden korjaamiseen käytetty aika) 2012-11-26 8
Mitä on ketterä ohjelmistokehitys? 2012-11-26 9
Agile Manifesto 2012-11-26 11
Agile Manifesto - periaate 1/12 Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti. Missä vaiheessa testaus kannattaa aloittaa? Testausperiaatteita: Aikainen testaus, virheettömyyden harhaluulo 2012-11-26 12
Agile Manifesto - periaate 2/12 Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi. Testaaja: What a f Vaatimusten- ja muutostenhallinta! Testausperiaatteita: Testaus on tilanneriippuvaista. Regressio (automatisoitu) 2012-11-26 13
Agile Manifesto - periaate 3/12 Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä. OK Nopea sykli ja pienemmät kokonaisuudet, joihin voidaan keskittyä paremmin. Suunnittelu, järjestelmä-, regressio- ja hyväksymistestaus, tutkiva testaus, automatisointi, käytettävyys, katselmoinnit jne. Automatisoinnin hyödyntäminen Onko testaaja 100% työllistetty? 2012-11-26 14
Agile Manifesto - periaate 4/12 Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan. Miksi näin ei aina toimita? Liiketoiminnan edustajia: Tuotteen omistaja (ROI, tuotettavien ominaisuuksien tärkeysjärjestys), asiakas jne. Testaaja: Testausnäkökulma mukana jo alussa. Scrum -tiimi on vastuussa tuotteen teknisestä toteutuksesta ja laadusta. 2012-11-26 15
Agile Manifesto - periaate 5/12 Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat työn tehtyä. OK Tämä on ehdottoman tärkeä seikka koko tiimille. Testaaja: Puitteisiin voitaneen laskea myös testaustyökalut. 2012-11-26 16
Agile Manifesto - periaate 6/12 Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu. Scrum: Koko tiimi on samassa tilassa Tiedon siirtymiselle on hyvät edellytykset. Kaikkea ei kannata eikä voi laittaa Jiraan mutta Testaaja vs. kehittäjä: Testaaja on osa tiimiä! 2012-11-26 17
Agile Manifesto - periaate 7/12 Toimiva ohjelmisto on edistymisen ensisijainen mittari. Tämä ei yksistään riitä, vaan pitää täyttää ja mielellään ylittää loppukäyttäjien vaatimukset. Testauksen rooli korostuu! Testausperiaatteita: Virheettömyyden harhaluulo Asiakastyytyväisyys! 2012-11-26 18
Agile Manifesto - periaate 8/12 Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen. If they have an interest in working overtime, remove it. Development isn't something you can do for 60 hours a week and stay productive, and there are numerous studies out there that prove this. If overtime pay is the issue, get rid of it and improve their base pay so they're getting what they're worth. http://programmers.stackexchange.com/questions/158954/how-to-stop-avoid-over-time-on-a-scrum-team 2012-11-26 19
Agile Manifesto - periaate 9/12 Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä. Ei rautalankavirityksille! Yksikkötestit: Ohjelmoijan kirjoittamat yksikkötestit palvelevat ohjelmiston rakenteen kehittämistä. Testaaja: Bugeja, bugeja, bugeja 2012-11-26 20
Agile Manifesto - periaate 10/12 Yksinkertaisuus - tekemättä jätettävän työn maksimointi - on oleellista. OK Projektissa on aina rajalliset resurssit. Kaiken testaaminen (syötteiden ja esiehtojen kaikki yhdistelmät) ei ole mahdollista lukuun ottamatta triviaaleja tapauksia. Täydellisen testauksen sijaan pitäisi käyttää riskianalyysia ja priorisointia testauksen kohdistamisessa. 2012-11-26 21
Agile Manifesto - periaate 11/12 Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itse organisoituvissa tiimeissä. Jos tämä pitää paikkansa, niin se todennäköisesti helpottaa testauksen työtä. Ainakin tämä antaa hyvät edellytykset korkealle laadulle. 2012-11-26 22
Agile Manifesto - periaate 12/12 Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti. OK Prosessimainen ajattelu ja toiminnan jatkuva parantaminen on välttämätöntä kilpailukyvyn säilyttämisen kannalta. Katselmoinnit, bugit, retrospektiivit, projektipalaverit, mittarit jne. 2012-11-26 23
Case Whale Watch testausstrategia Kuinka ketterästi edetään? 2012-11-26 24
As a user I want to see 2012-11-26 25
Testattava ohjelmisto 2012-11-26 26
Toteutustapa 2012-11-26 27
Kustannuksia Ketterä tiimi tekemässä verkkopalvelun projektitoimitusta 10-20% Sulautetun ohjelmiston uusi versio 80% 2012-11-26 28
Bugien seurauksia Whale Watch Alus joutuu keskelle myrskyä ja Valaita ei nähdä Asiakas myöhästyy aluksesta 2012-11-26 29
Case Whale Watch - Testausstrategia Missio: Haluamme auttaa asiakkaita näkemään valaita mahdollisimman mukavasti ja aina 100% turvallisesti Idea: Testausstrategia ottaa huomioon käyttäjien vaatimukset sekä tuotteen riskit ja siinä hyödynnetään eri testaustasoja ja - menetelmiä. Määritelmä: Testausstrategia on korkean tason kuvaus käytettävistä testaustasoista ja testauksesta näillä tasoilla. Voidaan tehdä organisaatio- tai projektitasolla (yhdelle tai useammalle projektille) (ISTQB 2010) 2012-11-26 30
Whale Watch - Testausstrategia Suorituskykyskannaus Tietoturvaskannaus Hyväksymistestit Beetatestit Tuotteen omistaja tuotteen vision ja pitkän tähtäimen suunnitelman perusteella Julkaisu ¼ vuosi Testausstrategia ½ vuosi Sprintti 3 viikkoa Päivittäin Hyväksymistestit Regressiotestit Tietoturvatestaus Retrospektiivi Yksikkötestit Integraatiotestit Daily Scrum (Systeemitestit) 2012-11-26 31
Whale Watch - Testausstrategia Testauksen tarkoituksena meillä on arvioida, vastaavatko tuotteet niille asetettuja vaatimuksia, sekä osoittaa, että ne sopivat suunniteltuun käyttöönsä turvallisesti ja löytää virheitä. Testausstrategia ottaa huomioon tuotteiden riskitason ja priorisoidut vaatimukset ja siinä hyödynnetään eri testaustasoja ja -menetelmiä. Suunnittelemme testauksen projekteihin iteratiivisen kehitysmallin mukaisesti ja testauksen lähestymistavassa hyödynnetään hyviksi havaittuja testausperiaatteita. Testausstrategia tarkennetaan aina tuotekohtaisesti tuotteen pidemmän aikavälin suunnitelman eli Road Mapin perusteella. Ohjelmistokehitykseen kuuluvat yksikkö- ja integraatiotestit, joiden lisäksi testausasiantuntija suorittaa sprinteissä systeemitestausta. Sprinttien alussa suunnitellaan alustavat testitapaukset sprintin työlistan toiminnallisuuksien perusteella ja niitä tarkennetaan sprintin aikana. Sprintin lopulla suoritetaan aina sprintin työlistaan perustuvat sprintin hyväksymistestit. Noudatamme testauksessa aikaisen testauksen periaatetta eli systeemi- ja suorituskykytestausta toteutetaan sprinteissä heti, kun se ohjelmiston kehityskaaressa on mahdollista. Systeemitestauksen tukena käytetään tutkivaa testausta erityisesti riskialttiisiin alueisiin. Osa regressiotesteistä, yksikkötestit, suorituskyky- ja tietoturvaskannaus ovat automatisoituja. Suorituskyky- ja tietoturvaskannaus pyritään suorittamaan ainakin kriittisille toiminnoille. Tällaisissa tapauksissa suorituskykyskannaus pyritään suorittamaan kolmen sprintin välein ja tietoturvaskannaus suoritetaan projektissa kaksi kertaa: Puolessa välissä projektia ja ennen viimeistä sprinttiä, jolloin tarvittaviin muutoksiin jää riittävästi aikaa. 2012-11-26 32
Virheenkäsittelyprosessi 2012-11-26 33
Vikaluokituksia Vikoja raportoitaessa on olennaista käyttää selkeää vakavuusluokittelua. Seuraavassa taulukossa esitetään suositus vikojen vakavuusluokitteluksi. JIRA-luokitus Emergency High Medium Low Käyttöohje Kriittinen vika, joka estää järjestelmän käytön/testauksen jatkamisen (Esim. sisään kirjautuminen ei onnistu) Vakava vika, joka osittain estää järjestelmän käytön/testauksen suorittamisen (Esim. raportin ajo ei onnistu) Käyttöä haittaava vika mutta ei estä järjestelmän käyttöä (Esim. tietyt hakuehdot eivät toimi) Vähäpätöinen vika (Esim. ulkoasu ei ole paras mahdollinen) 2012-11-26 34
Mittareita: Vikamäärät DDR (Defect Discovery Rate): Uusien vikojen löytymistiheys on yksi keskeisimmistä testauksen tarjoamista mittareista ja sen (yhdessä muiden mittareiden) perusteella voidaan arvioida, koska tuote on riittävän valmis toimitettavaksi asiakkaan käyttöön. Jossakin vaiheessa testauksen kustannukset ohittavat testauksesta saatavan hyödyn. 2012-11-26 35
Mittareita: Vikamäärät DDR (Defect Discovery Rate): Erityisesti riskipohjaisessa lähestymistavassa toinen hyvä mittari on vakavien virheiden määrän pienentyminen. Molemmissa mittareissa kannattaa hyödyntää aiempien tuotteiden trendejä laadittaessa ennusteita sopivasta julkaisun ajankohdasta. 2012-11-26 36
Mittareita: Testauksen tehokkuus Olemassa olevien vikojen määrä Tuotanto 200 50 100 30 Vaatimusten muodostaminen 120 Suunnittelu 130 Ohjelmointi ja yksikkötestaus 130 110 60 Integraatiotestaus Systeemitestaus Hyväksymistestaus 80 40 100 20 50 30 Löydettyjen vikojen määrä DRE = Systeemitesteissä löydetyt viat Systeemitesteissä löydetyt viat + Hyväksymistesteissä ja tuotannossa löydetyt viat DRE = 50 50+60 = 0.45 (normaalit arvot asettuvat välille 65-70%) 2012-11-26 37
Ja paljon muuta. Kiitos! 2012-11-26 38
Luettavaa Agile Manifesto: http://agilemanifesto.org/iso/fi/ Lean: Womack, James P.; Daniel T. Jones, and Daniel Roos (1990). The Machine That Changed the World. Ohno, Taiichi (1988). Toyota Production System. Productivity Press. p. 8. ISBN 0-915299-14-3. Jne Scrum: http://scrumalliance.org/ Testausperiaatteita: ISTQB : Perustason sertifikaattisisältö (s. 14): (Foundation Level Syllabus). http://www.fistb.fi/sites/fistb.ttlry.mearra.com/files/fl%20syllabus%2020101 123_0.pdf Craig, Rick D. & Jaskiel, Stefan P.: Systematic Software testing. STQE Publishing 2007 2012-11-26 39
2012-11-26 40