Testausmenetelmät

1. Erkki Pöyhönen & Maaret Pyhäjärvi Attribution (Tekijä mainittava) http://creativecommons.org/licenses/by/3.0/ Testausmenetelmät Maaret Pyhäjärvi <maaret.pyhajarvi@iki.fi>

2. Testaajat ovat projektin ajovalot Testaus on tuotteen/järjestelmän kyseenalaistamista arviointitarkoituksessa. Laatu on arvoa jollekin ihmiselle. Virhe on mitä tahansa mikä uhkaa koettua arvoa. Keskeinen kysymys: kenen kokemuksilla ja tuntemuksilla on merkitystä? Tärkeä virhe häiritsee jotakuta joka on tärkeä. Mitä tämä merkitsee testauksen arkeen?

3. Neljä näkökulmaa testauksen merkitykseen Analyyttinen koulukunta Laatukoulukunta • Testaus on puolueetonta, perusteellista ja teknistä, osa tietojenkäsittelytiedettä ja matematiikkaa. • Oikea toiminnallisuus voidaan päättää yksiselitteisesti perustuen malliin tai määrittelyyn suhteessa tiettyyn kriteeristöön • Mitä tekniikoita pitäisi käyttää? • Testaus = laadun varmistus, osa prosessin hallintaa ja olisi tarpeetonta jos prosessissa tehdään asiat oikein • Testaus on ensiaskel kohti prosessikehitystä. • Seuraammeko hyvää prosessia järjestelmäkehityksessä? Rutiinikoulukunta Tilannetekijäohjattu koulukunta • Testaus on työvoimaintensiivinen ja toistoa sisältävä tapa mitata etenemistä ja sen tulee olla ennustettavaa, toistettavaa ja suunniteltua ollakseen kustannustehokasta heikomman osaamisen työvoimalla • Sisäänrakennettu vastustus suunnitelmien muuttamiseen • Kuinka voimme mitata etenemmekö kehitysprojektissa? • Testaus on luovaa oppimista laatuun liittyvistä puolista jotka on oleellisia sidosrymille, ja muistuttaa empiiristä tutkimusta vahvalla psykologiapainotuksella • Keskittyminen osaamiseen yli käytäntöjen ja menetelmien • Mikä testaus olisi kaikken arvokkainta juuri nyt?

4. Esimerkkejä ristiriidoista eri käsitysten välillä • Hyvin erilaisia vastauksia muun muassa seuraaviin kysymyksiin: • Onko olemassa yhteistä termistöä ja mistä sellaista pitäisi hakea? • Mitä on riskiperusteinen testaus? • Voitko testata jos sinulla ei ole kirjallista määrittelyä? • Mikä lasketaan testitapausten suunnittelun tekniikaksi? • Mitä vaaditaan hyvältä testitapausten suunnittelulta? • Onko käytettävyyden testaaminen osa testausta? • Ovatko nykyiset testaajien sertifiointiohjelmat hyödyllisiä? • Kuinka suhtaudumme muutokseen projekteissa? • Onko kelpuutus (validointi) osa testausta? • Voiko hyvälaatuista ohjelmisto tuottaa ilman itsenäistä testausryhmää joka testaa sen ennen julkaisua? • Mitä ongelmia testaus projekteissa ratkoo ja miltä aloilta meidän pitäisi ottaa oppia testausta parantaaksemme?

5. Miksi konteksti on oleellinen käytäntöä valittaessa? Sahara Alaska ?

6. Kontekstiohjatun testauksen periaatteetKaner, Bach, Pettichod: Lessons Learned in Software Testing, 2002. • Käytännön arvo riippuu sen kontekstista. • On hyviä käytäntöjä kontekstiin, mutta ei ole parhaita käytäntöjä . • Ihmiset, jotka toimivat yhdessä, ovat tärkein osa minkä tahansa projektin kontekstia. • Projektit avautuvat ajan myötä tavoilla jotka eivät usein ole ennustettavissa. • Toteutettava tuote on ratkaisu. Jos ongelmaa ei ratkaista, tuote ei toimi. • Hyvä ohjelmistotestaus on haastava älyllinen prosessi. • Vain harkinnan ja kyvyn kautta jota harjoitetaan yhteistyössä projektin läpi, voimme tehdä oikeat asiat oikeaan aikaan testataksemme tuotteemme tehokkaasti. Jos ainoa tuntemasi työkalu on vasara, kaikki muistuttaa kummasti naulaa.

7. Tilannetekijät Ulkoiset tilannetekijät Sisäiset tilannetekijät Sovelluksen ominaisuudet Sovellusalueen ominaisuudet Projektin ominaisuudet Organisaation ominaisuudet Testauksen ominaisuudet

8. Tilannetekijät vaikuttavat menetelmien valintaan • Neljä tapaa suhtautua tilannetekijöihin (=kehitystyön konteksti) • Tilannetekijät unohtava • “Parhaat käytännöt” – kopioidaan toisten onnistumisia mahdollisesti hyvin erilaisista lähtökohdista • Tilannetekijöistä riippuvainen • “Toimii meillä” – ei käsitystä muista tilanteista kuin omasta organisaatiosta • Tilannetekijöitä saneleva • “Muutetaan tilannetekijät” – organisaation muokkaaminen käytäntöihin sopivaksi • Tilannetekijäohjattu • “Ei parhaita käytäntöjä, hyviä käytäntöjä erilaisiin tilanteisiin” – tilannetekijöiden ymmärrys menetelmien valinnan kriteerinä Kyky ratkaista sama ongelma hieman erilaisin menetelmin – tilanteeseen sopivasti – on merkki syvemmästä ymmärryksestä

9. Testaushaasteiden kaksi puolta Testauksen hallinta – Suunnittelu ja seuranta Testaus-toiminta - Määrittely ja suoritus Testaus on paljon enemmän kuin testien suunnittelua ja suoritusta. Testausta tehdään aina toiminnan kontekstissa.

10. Testauksen hallinnan haasteet (1/2) • Raportointi: Testaus tekee tietoiset päätökset laadun suhteen mahdollisiksi. Kuinka testaus raportoi työstään niin että tieto otetaan vastaan ja käytetään? • Viestintä: Testaukseen tarvitaan tietoa testattavista asioista, ja tämä tieto on luonteeltaan jatkuvasti muuttuvaa. Miten viestintä ja yhteistyö hoidetaan tarvittavan tiedon saamisen kannalta? • Lähtötaso: Testausta tehdään useiden osapuolien toimesta eri tasoilla. Kuinka huolehditaan kunkin osapuolen tarvitsemasta lähtötasosta laadun suhteen? • Työmääräarviointi: Testauksessa on paljon tehtäviä ja tarpeellista toistoa. Kuinka etukäteen tiedetään kuinka paljon aikaa ja resursseja tarvitaan työhön jota ollaan tekemässä? • Testaustyypit: Monenlainen testaus voi olla tarpeen. Miten tietää mitä kaikkea testausta voidaan yleensäkään tarvita?

11. Testauksen hallinnan haasteet (2/2) • Logistiikka: Testaus on osa ohjelmistokehitystoimintaa ja sen tulee rytmittyä tukemaan ohjelmistokehitystä. Kuinka testaajat käyttävät työmääränsä oikea-aikaisesti oikeassa paikassa hyödyn maksimoimiseksi? • Lopettaminen: Kaikkea ei voi testata. Kuinka päättää koska testaus voidaan lopettaa eli koska testausta on tarpeeksi? • Missio: Testausta käytetään moneen tarkoitukseen ja sille on monenlaisia odotuksia eri osapuolilta. Mitä vaatimuksia testaukselle kohdistuu? • Opettaminen ja ohjaus: Testaus on haastavaa. Kuinka auttaa testaajia tulemaan hyviksi työssään ja miten tunnistaa hyvä testaaja?

12. Testaustoiminnan haasteet (1/2) • Edustus: Testaajat toimivat edustajina jollekin näkökulmalle. Kuinka testaajat aidosti edustavat tätä näkökulmaa? • Kattavuus: Testattavaa on paljon. Kuinka päätetään mitä testataan ja mitä ei? • Riski: Testejä on kaikkiaan liikaa kullekin ajanhetkelle. Kuinka tiedetään mitkä testit ovat parhaita suoritettavaksi juuri nyt? • Tukirakenteet: Testauksessa tarvitaan muutakin kuin testattava kohde. Mitä ympäristöjä ja välineitä tarvitaan? • Hyönteismyrkky: Testattava kohde tulee immuuniksi samoille testeille ja virheiden löytäminen vaatii testien muuttamista. Kuinka testejä muutetaan tehokkaasti? • Testattavuus: Järjestelmän ja vaatimusten rakenteet vaikuttavat kykyyn tehdä testausta. Kuinka järjestelmä voidaan rakentaa siten että testaaminen on mahdollista ja tehokasta?

13. Testaustoiminnan haasteet (2/2) • Oppiminen: Testattavat järjestelmät ovat monimutkaisia. Kuinka opimme järjestelmän toiminnan? • Suoritus: Testien suorittamiseen on useita vaihtoehtoisia tapoja. Mikä on tehokkain tapa suorittaa tarvittavat testit? • Virheraportointi: Testaus löytää virheitä. Kun löydämme virheen, kuinka toistamme sen ja raportoimme sen tehokkaasti? • Arviointi: Kaikki virheet eivät ole itsestään selviä. Kun virhetilanne tulee kohdalle, kuinka testaaja tunnistaa sen? • Dokumentaatio: Testauksesta pitää jäädä jälki vähintään löydettyjen ja käsiteltyjen virheiden osalta. Mitä dokumentaatiota tarvitaan ja mihin tarkoituksiin?

14. Testauksen rajaus riskiin perustuen • Kaikki testaus perustuu riskille • Huono testaus perustuu riskin tiedostamisesta kieltäytymiselle – “me voidaan testata kaikki” • Testaukseen käytettävissä oleva aika suhteessa työn loputtomuuteen on aina rajallinen • Jossain vaiheessa hyötysuhde laskee selvästi – ei enää yhtä tärkeitä virheitä • Joskus aikataulu muuttaa tärkeät virheet asioiksi joiden kanssa voidaankin elää • Huomioi riski tyypillisen liiketoimintajohtajan näkökulmasta • Riskin otto palkitaan, isosta riskistä isot tuotot (tai tappiot) Jos ei riskiä, ei myöskään testiä – osaatko kuvata riskin jonka takia testaat?

15. Riskiperusteinen testauksen suunnittelu – ja raportointi Lähtien tuoteriskistä: tunnista merkittäviä riskiluokkia. Toiminnallisuus alueittain, ei-toiminnalliset ominaisuudet Lähtien liiketoimintariskistä: tunnista keskeiset toiminnallisuudet järjestelmälle Lähtien projekti- ja prosessiriskistä: mikä voi muuttaa hyvän testauksen huonoksi Riskiperusteinen testitapaussuunnittelu Lähtien tuoteriskeistä: kuvittele asia joka voi mennä pieleen, vahvista tai kumoa testaamalla Muutetaan riskit faktaksi: joko ongelma on tai ei, riski on epävarma Riskit testauksen kokonaisuudessa ja yksityiskohdissa Tuoteriskien tunnistaminen:<osallinen> ei ole tyytyväinen <jos: ehto> Tuoteriskiperusteinen raportointi:<osallinen>: <koettu ongelma>

16. Testausvastuiden jakaminen useiden osapuolien kesken • Testauksen monitasoisuus – eri toimijoita • Päällekäisyyden riski • Toisiin liiallisen luottamisen riski • Monia tapoja organisoida • Esim. Hyväksymistestaus – hyväksytäänkö vielä virheitä, jos ei, onko tarvittava osaaminen ollut mukana aiemmissa vaiheissa? • Testataanko osaa vai kokonaisuutta, entä mitä näkökulmaa? • Oleellinen kysymys luottamuksesta • Millaisilla tavoilla luottamus rakennetaan? • Mitä mekanismeja tarvitaan luottamuksen pitämiseksi? Miten auttaa onnistumaan?

17. Keskeiset roolit testausprojektin onnistumiseen • Testauspäällikkö • Testauksen kokonaiskuva • Projektin tiedustelupalvelun vetäminen • Testaajat • Laatutiedon tuottaminen ja arvottaminen • Tulosten viestintä valiten oikeat taistelut • Projektipäällikkö • Projektin ohjaus testaustiedon perusteella • Projektin ohjaus testattavan kohteen saamiseksi testaukseen • Toteuttajat • Laadukkaan järjestelmän tuottaminen toteutusta ja testausta yhdistellen • Ohjausryhmä • Ensimmäisen tason eskalointi • Yhteinen päätöksenteko

18. PjM CQE PjM CQE  Molempien sopeuduttava toisen osaamiseen ja ajatteluun Erilaisia projektipäälliköitä ja testauksen vetäjiä muutosta ajava CQE PjM negatiivinen suhtautuminen positiivinen suhtautuminen PjM CQE muutosta vastustava

19. Eri tyyppisten testausten tulosten seuranta Havainnot suhteessa kattavuuteen Sisäinen vs. ulkoinen testaus ja havaintojen tyypit Testaajien työn edellytyksistä huolehtiminen Työrauha ja mahdollisuus keskittyä Viestinnän tukeminen – oikeat ihmiset oikeaan paikkaan Tulosten paketointi Työkalut projektipäällikölle oikeiden asioiden edistämiseen Toinen mielipide ja näkökulma Mitä riskejä ei voida hyväksyä Perusteiden oikeellisuuden kyseenalaistus Koontien koordinointi Mitkä muutokset milloinkin testaukseen Havaintojen läpikäynti Yksityiskohdista kokonaiskuvaan Mitä ei vielä ole raportoitu? Testauspäällikön arki – tyypillisiä tehtäviä

20. Testaussuunnitelman laatiminen ja viestiminen • Testaussuunnitelmalla monia muotoja • Kirjallinen dokumentti, kaaviot valkotaululla, suunnitteluun osallistuneiden jaettu ymmärrys yhteisestä suunnasta • Oleellista testaussuunnittelun prosessi, joka on oleellisesti viestintää • Suunnittelu pakottaa kurinalaiseen, ajoissa tehtyyn pohdintaan sen osalta mitä • Testaajat tulevat tekemään ja miksi • Kuinka he tulevat sen tekemään • Kauanko se vie • Mitä resursseja tarvitaan • Mitä se tulee maksamaan Muidenkin kuin testausvastaavan pitää pohtia ajoissa!

21. Mitä sisällyttää testausstrategiaan ”Löytää kaikkein tärkeimmät viat mahdollisimman nopeasti mahdollisimman halvalla” Järjestelmä-kehityksen ympäristö Missio ja tavoitteet Testausprosessi Testaustasot Testausvaiheet (Testikierrokset) Testityypit (Testausympäristöt) Testaustekniikat Laatu-ominaisuudet Korkean tason tuoterakenteet Sovellusalueen riskit Koettu laatu

22. Mitä sisällyttää projektin yleistestaus-suunnitelmaan ”Löytää kaikkein tärkeimmät viat mahdollisimman nopeasti mahdollisimman halvalla” Projekti-ympäristö Missio ja tavoitteet Testausprosessi Testaustasot Testausvaiheet (Testikierrokset) Testityypit (Testausympäristöt) Testaustekniikat Laatu-ominaisuudet Tuoterakenteet Sovelluksen riskit Koettu laatu

23. Yleistestaussuunnitelma Hyväksymistestaussuunnitelma Järjestelmätestaussuunnitelma Integrointitestaussuunnitelma Yksikkötestaussuunnitelma Projektin näkökulma testaussuunnitteluunPol & Van Veenendaal. Tmap – Test Management Approach. Myös testausvaihe- tai testaustyyppi-kohtaisia suunni-telmia: esim. Suorituskykytestaus-suunnitelma. Keskeinen idea: kokonaiskuva ja yksityiskohdat erikseen, suunnitelman omistajuus oikealle tasolle.

24. Tasot, vaiheet ja tyypit Hyväksymistestaus Järjestelmätestaus Integrointitestaus uusintatestausta Yksikkötestaus uusintatestausta

25. Yleistestaussuunnitelman tarkoitus • Yleistestaussuunnitelma on sopimus, joka määrittelee: • Hyväksyttävän riskin tuotetiedon puutteen osalta, jonka johto on halukas ottamaan (laatu – riski – kustannus) • Valitun lähestymistavan, jolla hankitaan tarvittava tieto tuotteen laadusta • Tuloksiin keskittyvän työnjaon kaikille testaustehtäville projektin/tuotteen testauksen osalta • Katsauksen koko testaustyöhön • Sopimuksen sävy on erilainen • Ympäristössä, jossa tarve etsiä syyllisiä • Ympäristössä, jossa suojautuminen ei keskeistä • Sisältöä ei pidä sotkea dokumentoinnin tasoon: dokumentti on vain yksi tapa välittää tieto asianomaisille

26. Yleistestaus-suunnittelu Kenelle yleistestaussuunnitelma on suunnattu? Tahot, jotka tarvitsevat testauksen tuottamaan tietoa Tahot, jotka tekevät testausta testaajat kehittäjät Vastuiden sopiminen kehittäjät päälliköt Testaukselle pienennettävät riskit asiakkaat Kyky täyttää vastuut käyttäjät Tiedon kustannus Kompromissit ja vaikutukset testaukseen

27. Testaus on investointi laatutietoon Varaus yleistestaus-suunnittelussa Riskejä torjuva(+4 mtkk) Kehittävä (+ 10 mtkk) Minimi-resursointi Riskisuunnattu(+3 mtkk) Minimaalinen(+6 mtkk) Tarvetasojen tunnistaminen jättää liikkumavaraa kokonaisuudelle Tuki(3 mtkk)

28. Testitapaus Vakava VAATIMUKSETRISKITKOODI Kysymyksen asettelu – Yleistestaussuunnittelu a. Estää käyttäjän tavoitteita JA meidän mahdollisuuksia korjata tilanne ilman merkittävää kustannusta B …löytääksemme näitä… Koitamme kohdistaa näitä… MITÄMILLOINKUKAKUINKAMIKSI b. Korjaaminen voi olla merkittävä työmäärä ja aiheuttaa uusia virheitä PM b. Estää tekemästä niitä asioita joita pitäisi projektissa T c. Estää käyttäjää tekemästä asioita joita pitäisi MUTTA on helppo korjata kanavan kautta Kattavuus? U D1 V3 V2 …ja kertoaksemme jos on muuta ja millä tasolla tiedämme. 1 2 3 4 5 a x x b x c x x Aika

29. Testiohjattu dokumentointitapa Perustuu Marko Komssin työhön tarkastusten tehostamiseen – Progressive Inspection, asteittain kehittyvä tapa tarkastaa dokumentteja Kolme tärkeintä tarkastussääntöä Merkittävä osa virheistä Tarpeiden tunnistaminen, mikä keskeistä Yleistestaussuunnitelmia eri tarkoituksiin Yleistestaussuunnitelma = Master Test Plan

30. S Scope = Laajuus (testauksen kohteet, mitä testata, mitä ei testata) P People = Ihmiset (koulutus, vastuut, aikataulu) A Approach = Lähestymistapa (testaukseen otettava lähestymistapa) C Criteria = Kriteerit (aloitus- /lopetuskriteerit, keskeytys-/jatkamiskriteerit) E Environment = Ympäristö (testausympäristötarpeet) D Deliverables = Tuotokset (mitä testausprosessin osana toimitetaan) I Incidentals = Satunnaiset (esittely, tunnistus (dokumentin), hyväksyvät auktoriteetit) R Risks = Riskit (riskit ja torjunta) T Tasks = Tehtävät (testauksen tehtävät, jotka kuuluvat testausprosessiin) Testaussuunnitelman muistisäännötMorgan, Peter. 2003. Dig the SPACEDIRT. Professional Tester, October 2003. pp. 24- 25

31. Testauksen suunnittelun keskeisimmät periaatteetCem Kaner, A Course in Black Box Software Testing (Professional Version), Summer-2002, www.testingeducation.org • Kaikkea ei voi kiinnittää • Vaikeita priorisointipäätöksiä pitää tehdä ja monet rajoitteet eivät ole hallinnassasi • Voit vaikuttaa useisiin rajoitteisiin selittämällä asiaa muille projektin osapuolille – vaatii enemmän kuin nimen saaminen suunnitelman alle • Todellisuus on tärkeämpää kuin kyky osoittaa joku muu syylliseksi • Tehtävänäsi on hallita projektitason riskejä sisältäen sekä kustannukset, aikataulut, ihmisten välisen dynamiikan että projektin toteuttamat ominaisuudet ja luotettavuuden

32. Testauksen tilanteen ja tulosten kuvaaminen erilaisille sidosryhmille • Eri sidosryhmillä erilaisia tarpeita: • Liiketoiminnan edustajat • Ohjelmistokehitystoiminnan vastuulliset • Projektin vastuulliset • Projektin osalliset • Tyypilliset keinot • Testilokit: tiedot testeistä suhteessa versioihin ja ympäristöihin, tyypillinen testihallinnan työkalutuen alue • Laaturaportit: tiedot tunnetuista ongelmista ja testauksen kattavuudesta • Testauksen yhteenvetoraportit: mitä tehtiin ja tiedetään

33. Kts. Lisämateriaali mittareista

34. Testaus Virheiden luova löytäminen Priorisointi, oikeat valinnat Kommunikaatio Oikea viestintä oikeille ihmisille Teknologia Toteutusteknologiat Toimintaympäristöt Toimintatavat Organisaation erityispiirteet Sovitut pelisäännöt, prosessit Liiketoimintanäkökulma Kokonaiskuva Vaikeat valinnat hyvän ja riittävän välillä Suunnittelu ja hallinta Yhteistyö muiden kanssa Testausosaamisen laajuus Testaaja osaa vähän kaikkea ja jotain vähän enemmänkin. Kaikkea ei vaadita yhdeltä yksilöltä, ryhmässä on voimaa.

35. Testauksen yleisosaaja Arkkitehtuuri-painotus Hallinnollinen painotus Testauksen erikoisosaaja Kasvu testaajasta testausosaajaksi Laaja osaaminen monista testausasioista Kaksi suuntaa: Sovellualue- vs. teknologiasuuntautunut ”ihan vaan hyvä testauksessa”, riskien ja seurausten ymmärrys ”toisten opastaminen ja ohjaaminen” Syvällinen osaaminen järjestelmätyypistä tai testaustyypistä

36. Kuka haluaa olla testaaja?Lähde: Erkki Pöyhönen. 2004. Itsenäisesti ajattelevaa, laatusuuntautunutta henkilöä, jolla on laaja liiketoiminta- ja teknologiaymmärrys sekä loistavat ihmissuhdetaidot haetaan epäkiitolliseen työhön, jossa on huonot ylenemis-mahdollisuudet, palkka alle keskipalkan ja alhainen status organisaatiossa. Pakollisena vaatimuksena kyky työskennellä jatkuvan paineen alaisena ja tuottaa jatkuvasti hyviä tuloksia riittämättömään tietoon perustuen.

37. Henkilökohtaisesti Vastuu omasta tulevaisuudesta Malleja saman roolin ihmisiltä Mitä haluaisit osata mitä muut osaavat Pyydä neuvomaan, antamaan palautetta, harjoittele! Tee valintoja Paljon kokonaisuudesta Paljon yhdestä osasta Kaikkea ei pysty saamaan, varsinkaan kerralla, alue liian laaja! Muiden kokemukset ja ajatukset kirjoissa Organisaationa Perustiedot samalle tasolle Testauskurssit Mentorointi Aikaa oppimiselle sopivalla oppimismuodolla Lupa kasvaa ja erikoistua Mahdollisuudet sopivaan tulevaisuuteen Arvostus myös rahassa! Testauskompetenssin kehittäminen

38. Vaatimukset testauksen näkökulmasta • Riippuen organisaatiokulttuurista • Vaatimukset oletettavasti löytyvät kirjattuna sovituista dokumenteista, sisältäen kokousmuistiot muutoksista TAI • Vaatimukset ovat mikä tahansa sellainen toive tai odotus, joka merkitsee jollekin merkittävälle sidosryhmälle • Todellisuudessa harvoin testaus rajataan vain selkeiden kirjallisten vaatimusten perusteella – testisuunnittelu laajentaa käsityksiin ja rivien välistä luettaviin asioihin • Eri sidosryhmät odottavat eri asioita, pitävät eri asioita tärkeinä. • Eivät tiedä mitä haluavat, ainakaan yksityiskohtaisella tasolla. • Halu ja tärkeys muuttuu ajan myötä opittaessa lisää ympäristötekijöistä ja tarpeista. ”Jos odotat saavasi vaatimukset paperinippuna joka on leimattu yleispätevän totuuden leimalla, etsi toinen työ” – Kaner et al, Lessons Learned in Software Testing Parhaissakin tapauksissa dokumentaatio on epätäydellistä ja moniselitteistä, mutta silti valaisevaa ja avuksi.

39. Vaatimukset vs. Testaus-näkökulma vaatimuksiin Vaatimus-näkökulma keskittyy tarkkojen vaatimusten dokumentoin-tiin ”näin sovittiin suullisesti” ”yleiset pelisäännöt ja kikat” Dokumen-toimaton Testaus keskittyy kaikkiin näkökulmiin; toteutus tarvitsee yksinkertai-suutta! ”tekijät eri mieltä, mutta tekstistä ei huomaa” Dokumen-toitu Suora Epäsuora

40. Oppikirjamääritelmä: Testitapaus käyttää yhtä tiettyä tilannetta tai ehtoa testattavassa järjestelmässä. Testitapaus kuvaa mitä testata ja miten, ja ohjaa testaajaa (tai testausvälinettä) joka suorittaa testauksen. Tämä ohjaus sisältää ohjeita testin alustamiseen ja suorittamiseen, sekä siihen mitä käyttäytymisiä tarkkailla ja kuinka arvioida lopputulos. Tarkoitus Tulos MITÄ? Askeleet Käyttöohjeet MITEN? Vaihtoehtoiskustannus: ajan jota käyttää määritelläkseen/ dokumentoidakseen testit yksityiskohtaisesti, voisi käyttää myös muuhun. Mihin käytettynä aika on arvokkainta? Mikä on testitapaus?

41. Yksityiskohtaisten ohjeiden tarve? • Onko oikea toiminnallisuus kuvattu testien ulkopuolella? • Toteutuspuolen toiminnallisuus- ja arkkitehtuurimäärittelyt • Kuinka tehdään –ohjeet • Odotus testauksen tekijöiden taidoille • Satunnainen poikkeaminen testaustehtäviin, ei aikaa ajatella - “Vain yksi dokumentti testaajalle” • Testaajalta odotetaan pohdintaa ja laajennoksia • Dokumentaation omistajuus ja ylläpidon huomiointi • Testaus etenkin kaipaa dokumentaatiota ylläpitovaiheeseen • Voiko olettaa että kenenkään muun ylläpitämä dokumentaatio palvelee testauksen tarkoituksia? • Suojautumisen tarve • Tiukan aikataulun tiukat prioriteetit ja niiden seuraukset usein vaikeaymmärtää etukäteen • Oman ja asiakasorganisaation kulttuuri vaikuttaa merkittävästi

42. Odotetut tulokset testauksessa Näyttää mielestäni ihan hyvältä... Testaajan pitää haluta nähdä virheitä vaikka virhettä ei osattu testitapaukseen ennustaakaan Oikeanlainen toiminta pitää kyetä tunnistamaan - joskus se vaatii analysointia etukäteen.

43. Virhetilanteen tunnistaminen • Testaajan perustavaa laatua olevaa osaamista • Oltava jokaisella testausta tekevällä: puutteesta seuraa testien suoritus ilman tuloksia • Merkittävimpiä kehittämiskohteita henkilökohtaisen tuottavuuden lisäämiseksi • Monenlaisia virheitä • Kosmeettinen: kirjoitusvirheet, ulkoasu, yhdenmukaisuus • Toiminnallinen: kaatumiset ja jumittumiset, väärä toiminnallisuus • Tarkoitukseen sopivuus: ei ratkaise käyttäjän ongelmaa, vaikea ymmärtää • Vinoumat vaikuttavat arviointiin • Omat kokemukset, läheisten kokemukset, epämiellyttävien ihmisten kokemukset… • Lähiaikojen kokemukset, menneet kokemukset • Isot epäonnistumiset jotka koettu osuneeksi omaan nilkkaan

44. Testitapaukset syötteenä Tee niin ajoissa kuin mahdollista Muuta tarvittaessa Käytä testimäärittelyä ankkuroimaan koska homma on tehty Auttaa suojaamaan kiireisessä ympäristössä Auttaa ihmisiä jotka vaativat aikaa konseptien sisäistämiseen Pääasialliset haasteet: Testien kohdistus ja arvo Oikea dokumentointitaso Testitapaukset tuloksena Aloita heti alussa Valmistaudu muuttamaan rakennetta Näytä jatkuvasti, hae kommentteja ja palautetta. Käytä aktiivisesti oppimistyökaluna: mitä tiesin, miten se on muuttunut? Tarkentuu ja muuttuu koko projektin läpi Pääasialliset haasteet: Priorisointiosaaminen Oppimisosaaminen Kaksi tapaa ajatella koska testitapausten pitää olla valmiita

45. Mitä prioriteetti tarkoittaa? • Prioriteetin 1 (korkein) testejä: • Ajetaan usein (uusintatestausoletus) • Toistetaan kaikissa tarvittavissa ympäristöissä (ympäristökattavuusoletus) • Edustavat minkä tahansa toiminnallisuuden peruskäyttöä (positiivisten testien oletus) • Perustuvat näkyviin ominaisuuksiin joissa näkyviä ja todennäköisiä virheitä (työmäärän hyödyntämisen teho –oletus) • Priorisointi vihjaa suoritusjärjestyksestä, jossa tavoitteena voi olla: • Optimointi loppukäyttäjänäkökulmasta • Optimointi ajoissa saatavalle palautteelle pahoista virheistä (aikataulu) • Optimointi uusintatestaukselle • Optimointi testien valinnalle eri ympäristöihin • Optimointi virheiden havaitsemiseen • Optimointi koodin kattamiseksi • Optimointi kunnian suojaamiseksi • Optimointi riskien kattamiseksi • Optimointi luotettavuuteen luottamisen kasvattamiseksi • Optimointi perustuen siihen millä paras mahdollisuus löytää virheitä

46. Testitapausten katselmoinnista tulee helposti Ryhmäkokous aiheena “jep, onhan nämä testitapauksia” Lisätyön tunnistamisen mekanismi, joka kasvattaa työn yli käytettävissä olevien työmäärien Testitapausmäärittelyn rakenteet vaikuttavat merkittävästi katselmoinnin tehokkuuteen: vaiheittainen katselmointi kokonaisuuksista yksityiskohtiin Katselmoitavia asioita: Kattavuus Puuttuvat asiat Päällekäisyydet Kohdistus suhteessa tavoitteeseen Meidän vai muiden suoritettava Riskifokus Priorisointi Priorisoinnin tausta-ajatuksen selkeys Prioriteettien oikeellisuus Yksityiskohdat Oikeat ohjeet oikealle kohderyhmälle Testitapausten katselmointi