Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Transkriptio

1 1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto

2 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei testaus sinänsä 5 Testaus tuottaa tietoa laadusta 6 ja muutakin tietoa 7 Asenne testaukseen bugi on iloinen asia! 8 Koska testataan? 9 Mitä kaikkea pitää testata 10 Laatu syntyy kahdesta suunnasta 12 Testauksen taktiikoita 13 Testausta pitää suunnitella 14 ja muuttaa suunnitelmia 15 Testaus on vain yksi laadunvarmistuksen tapa 16 Testattavuus 17

3 Sisällysluettelo 2/2 Hyvä testaus on monimuotoista 18 Konteksti vaikuttaa testaukseen 19 Testiautomaatiosta apua? 20 Testauksesta pitää jäädä jälki 21 Muuta 22 Top 10 pointit 23

4 4(23) Esityksen tarkoitus Nostaa esille tärkeimpiä asioita ohjelmistoprojektissa tehtävästä testauksesta Avata testauksen ajattelumalleja niille, joille se on vierasta Muistuttaa aihetta jo tuntevia perusasioista (ja varmaan esillä on muutama uusikin asia) Kannustaa testaukseen se on hienoa ja tärkeää!

5 5(23) Laatu on tärkeää, ei testaus sinänsä Softien pitää olla riittävän laadukkaita Käyttäjän kannalta Maksavan asiakkaan kannalta Tuoteliiketoiminnan kannalta Oman ammatillisen eheyden kannalta ammattilainen tekee hyvää työtä Mitä kaikkea tapahtuu, jos laatu ei ole kunnossa: Ohjelmistojen ongelmia poimintoja mediasta

6 6(23) Testaus tuottaa tietoa laadusta Mikä toimii, mikä ei Mitä voi ja pitää korjata Millaisia vikoja on osviittaa niiden jäljittämiseen Millainen on tuotteen kokonaistilanne Tietoa päätöksenteon tueksi Onko tuote riittävän kypsä päästettäväksi myyntiin tai toimitettavaksi asiakkaalle Lanseerauksen riskit

7 7(23) ja muutakin tietoa Testauksen avulla opitaan ymmärtämään ohjelmistoa Toimiiko sen logiikka oikeasti niin kuin on ajateltu Testaamalla voidaan selvittää mm. Käyttäjien toimintaa (käytettävyystestit) Preferenssejä millaiset ratkaisut tuntuvat parhailta Softan toimintaa vaikkapa kuormitettuna Uuden teknologian soveltuvuutta tarkoitukseen

8 Asenne testaukseen bugi on iloinen asia! 8(23) Testaus ei ole välttämätön paha, vaan välttämätön hyvä! Testaus ei ole mekanistista rutiinityötä, vaan intellektuaalista, luovaa aivotyötä Monet suhtautuvat siihen aivan intohimoisesti. Syitä ks. Testauksessa ollaan raakoja, ideana on löytää bugeja rikkomalla softa Testaus on yhteinen asia, koskee kaikkia projektissa Agilessa toiminto on "done", vasta kun se on testattu Jokainen bugi on tärkeää uutta tietoa bugitiedosta pitää iloita Bugeja ei pidä ottaa henkilökohtaisesti oppikaa niistä yhdessä

9 9(23) Koska testataan? Löydetyt virheet pitää ehtiä korjaamaankin Testausta ei saa jättää projektin loppuun Silloin ovat aika ja rahat loppuneet Testausta pitää alkaa tehdä heti, kun on jotain testattavaa Niinpä pitää tuottaa nopeasti jotain testattavaa: esim. tärkeimmät toiminnot, jotka pitää saada ensin kuntoon, tsekkaus, että uusi teknologia toimii oikeasti jne Ja tehdä testausta koko ajan kaikilla tasoilla Koodille, käyttöliittymän kautta

10 10(23) Mitä kaikkea pitää testata 1/2 Testauksella pitää löytää ennen kaikkea isoimmat ongelmat Mihin asioihin liittyy isoin riski? Eniten käytetyt toiminnot Asiat, joiden on pakko toimia kunnolla tai tapahtuu jotain ikävää (fyysinen turvallisuus, tietoturvallisuus, raha-asiat) Pakolliset testattavat asiat pakottavat standardit Uudet asiat uusi tekniikka, uusi koodaaja Riskianalyysissä mietittävä riskejä asiakkaan kannalta

11 11(23) Mitä kaikkea pitää testata 2/2 Laatumalli mitä kaikkia ominaisuuksia tarvitaan, mikä on oleellista? Mietittävä kaikki laadun osatekijät, jotta kaikki tärkeä voidaan "varmistaa" eikä mitään unohdu Toiminnallisuus, käytettävyys, tietoturvallisuus, suorituskyky, luotettavuus, lokalisointi, yhteensopivuus ja -toimivuus Kaikkea ei aina testata, vaan varmistetaan katselmoinneilla ja muilla keinoilla (ylläpidettävyys, siirrettävyys)

12 12(23) Laatu syntyy kahdesta suunnasta Tuotteen tarkastelu top-down Bisnesprosessit, käyttötapaukset, käyttäjätarinat, toiminnot Järjestelmätestaus Hyvä koodi Oikein toimiva, robusti koodi, joka kestää mitä tahansa Vakaa alusta toimintojen kehittelylle Yksikkö- ja integrointitestaus

13 13(23) Testauksen taktiikoita Tunne realistinen softan ympäristö ja liioittele kaikkea Pyri rikkomaan softa Samaan aikaan keskittyminen ja avoimuus uusille havainnoille Muista, että bugeja on aina, ne pitää vain luovasti kaivaa esille

14 14(23) Testausta pitää suunnitella Projektin päätestaussuunnitelma tai projektisuunnitelman osa Miten projektissa aiotaan hoitaa testaus Vastuut Resursointi Työkalut, laitteet Erityiset suunnitelmat erityisille testaustehtäville Käytettävyystestaus, tietoturvatestaus, suorituskykytestaus Suunnitelmien ei tarvitse olla pitkiä tärkeintä on yhteinen ymmärrys Koska softa muuttuu matkan varrella, ei detaljeja kannata suunnitella liian aikaisin

15 15(23) ja muuttaa suunnitelmia Kun softan suunnitelmat muuttuvat, pitää testauksenkin suunnitelmia muuttaa Jokin osa-alue voi osoittautua ongelmalliseksi ja sen testaamiseen pitää panostaa enemmän Voidaan huomata, että testaukseen ylipäätään kannattaa laittaa enemmän resursseja (ehkä joskus toisinkin päin) Ylipäätään: tilannetta pitää seurata ja mukautua muutoksiin olipa projektimalli ketterä tai ei

16 Testaus on vain yksi laadunvarmistuksen tapa 16(23) Hyvä laatu syntyy monien toimintamallien yhteispelillä Testauksen ohella tarvitaan muunlaista hyvää työtä Hyvää suunnittelua Katselmointeja ja tarkastuksia Koodin staattista analyysiä Jne

17 17(23) Testattavuus Miten helppo softaa on testata? Unohtuu "aina" Arkkitehtuuri Rajapinnat Käyttöliittymän automatisoitavuus Jne

18 18(23) Hyvä testaus on monimuotoista Systemaattinen, suunniteltu testaus Istuminen alas ja miettiminen, mitä asioita pitää testata suunnitelmallisesti, tarkasti, testitapauksiakin suunnitellen (tietty syöte tuleeko tietty tulos) Perustuu usein spekseihin Tutkiva testaus Tuotteen ottaminen vastaan "as is" Tutustuminen avoimin mielin uusiin toimintoihin Eteneminen havaintojen ja testaajan vainun varassa.edellyttää osaamista Regressiotestaus eihän mitään ole rikottu, kun softaa on kehitetty, muutettu, korjattu?

19 19(23) Konteksti vaikuttaa testaukseen Tietysti: Isoja turvallisuuskriittisiä järjestelmiä pitää testata eri tavalla kuin pieniä apuohjelmia Ei ole "yhden koon" testausprosesseja tai menettelyjä Vaikuttavia asioita Projektin vaadittu kriittisyys/eheystaso (miten turvallinen, luotettava) Pakolliset standardit Kokonaislaatu mikä on oleellista Laatutavoitteet Elinkaarimalli Projektin organisointi Teknologia ja testattavuus Kulttuuri, tottumukset, odotukset Budjetti Aikataulu Jne

20 20(23) Testiautomaatiosta apua? Automaatio kannattaa vain, jos testejä toistetaan samanlaisina monta kertaa Automaatio ei auta, jos testit ovat huonoja (johtajia voi toki hämätä kertomalla testi automaateista) Ensin opeteltava testaamaan hyvin manuaalisesti Yksikkötestit ovat tärkeä automatisointikohde Ne ovat turvaverkko koodia refaktoroidessa, kehitettäessä, muutettaessa

21 21(23) Testauksesta pitää jäädä jälki Bugit kannattaa kirjata ylös, jotta niistä saadaan tieto kaikille ja ne eivät unohdu Merkitään korjaukset, mutta historiatietoa ei kannata hävittää

22 Muuta 22(23) OHJ-3060 Ohjelmistojen testaus (syksyllä 2012)

23 23(23) Top 10 pointit 1. Testaus pitää ottaa vakavasti, mutta siitä pitää iloita 2. Testaus on osa kypsän softakehittäjän arkista toimintaa 3. Aloita testaus aikaisin ja tee sitä jatkuvasti 4. Testaukseen pitää olla aikaa vasta testattu on "done" 5. Ymmärrä käyttöä ja tuotteen riskejä 6. Priorisoi testausta ja panosta tärkeimpien asioiden testaukseen 7. Kehittäjän ja käyttäjän ajattelumallit ovat aina erilaiset hyväksymistestaus on asiakkaan asia ja haaste 8. Testauksessa ei ole hopealuoteja 9. Hyvä testaus on monimuotoista 10. Testaustavat pitää sovittaa kontekstiin, projektin kriittiisyyteen ja tuotteen vaatimuksiin