Skype coachausta

Moro kaikki,

Jos kiinnostaa saada Skypen kautta coachausta, niin ei muuta kun yhteys meikäläiseen. Sovitaan aika ja pidetään noin 1,5 tunnin coachaus sessio. Tämä siis sen takia, että minä kaipaan harjoitusta ja lisäksi coachauksen avulla voi ratkoa ongelmia, parantaa motivaatiota tai vaikka pitää pieniä kriittisen ajattelun harjoituksia. Eli Skypellä yhteys minuun (anttipekkamarjamaki), sovitaan ajankohta ja aihealue, ja sitten ratkotaan ongelmia.

Tätä viestiä saa levittää vaikkapa oman organisaation testaajien, testauspäälliköiden ja laatuihmisten kesken, ja vaikkapa organisaation ulkopuolelle, jos siltä tuntuu. Pääasia, että sana leviää ja saadaan Suomeen lisää coaching-kulttuuria.

Semmoista tällä kertaa. :)

- Peksi

TestausOSY on saanut uuden puheenjohtajan

Tervehdys, testauskollegat!

Kuten osa teistä onkin jo lukenut TestausOSY:n sähköposteista, valta on vaihtunut TestausOSY:ssä. Maaret Pyhäjärvi on päättänyt vetäytyä puheenjohtajan roolista syrjään ja mahdollistanut uuden naaman osaamisyhteisön puheenjohtajaksi. Tämä uusi puheenjohtaja on siis allekirjoittanut. Nimikin on, ja se on Pekka Marjamäki.

Tässä pari sanaa minusta: Kun olin noin nelivuotias, päätin että en ole Antti-Pekka vaan pelkkä Pekka. Nyt olen 27-vuotias testaajankloppi. Olen sellainen keskivertosuomalainen.  Asun siis Tampereella (asuu suuressa kaupungissa) vaimoni Virpin (naimisissa) ja 4-vuotiaan tyttäreni Sofian (1+ lapsi) kanssa. Kotona loikoilee kaksi koiraa (kultainennoutaja, beagle). Ajan tila-autoa (tila-auto), harrastan musiikkia eri muodoissa, miniatyyrimaalaamista sekä lukemista (työ, harrastuksia). Melko keskivertomies siis. :)

Vaikka siis asun Tampereella, olen töissä Helsingin Ruoholahdessa F-secure Oyj:ssä. Teen täällä tutkivaa testausta Maintenance-ryhmässä. Kohteena ovat pääsääntöisesti ”legacy” tuotteet eli käytännössä kaikki F-secure tuotteet, mitä asiakkailla jo on. Niistä testaan oikeastaan kaikkia liikkuvia osia, mutta nyttemmin fokus on ollut päivityksien testaamisessa. Aikaisemmin olin Tamperelaisessa logistiikka-alan järjestelmiä tekevässä Logia Software Oy:ssä, jossa toimin testauspäällikkönä ennen siirtymistäni F-securelle. Koulutukseltani olen datanom. Intohimonani on testaus ja laatu. Kirjoitan blogia ja artikkeleita lehtiin (yksi on vasta julkaistu, mutta odottakaas vaan!), twiittaan, yritän päästä tilaisuuksiin kertomaan kokemuksista ja ajatuksistani, ja lisäksi yritän kehittyä lukemalla kirjoja kaikennäköisistä aiheista ja kirjoittamalla niistä. Ja VR:n kyydissä huristellessa on aikaa näille harrasteille ihan mukavasti. ;)

Nyt puheenjohtajantyön jättävä Maaret on ollut minulle henkilökohtainen innoittaja siitä asti kun aloitin testaajan urani vuoden 2007 tienoolla. Minulla ei ollut hajuakaan testauksesta eikä sen suunnittelusta, joten guuglailin suomalaisia testaajia, joista Maaret oli jonkin hakusanayhdistelmän tuottaman listan ykkösenä. Otettuani asiasta selvää huomasin, että häneltä voisi yrittää kinuta hieman lisäapua taitojeni pönkittämiseksi ja aloin pommittamaan häntä viestein, jotta saisin häneltä materiaalia luettavaksi. Muutaman slidesetin jälkeen maailma alkoi jo näyttää kirkkaammalta. Maaret on ollut mukana jokaisessa testausurani käännekohdassa: Kun vuonna 2007 aloitin testauksen, oli Maaret inspiraationi. Kun vuonna 2011 osallistuin Michael Boltonin Rapid Software Testing –kurssille, oli Maaret kurssilla järkeistämässä yli-innokkuuttani. Kun nyt vuodenvaihteessa tulin töihin F-securelle, olin ”täyttämässä Maaretin saappaita”. Nyt 2012 saan kunnian olla hänen seuraajansa TestausOSY:n puheenjohtajana.

Ilmoituksessaan jättää puheenjohtajan tehtävät, Maaret mainitsi, että ”testausammattilaisen tulisi jättää paikat (testausdokumentaatio ja tavat toimia) parempaan kuntoon lähtiessään”. Voin kaikkien puolesta vastata, että siinä hän on onnistunut.

Nyt on siis meikäläisen vuoro yrittää tähdätä samaan.  Samuel Beckett sanoi loistavasti:

"Ever tried. Ever failed. No matter. Try again. Fail again. Fail better." 

Olkoon se minun puheenjohtajanmottoni. :)

Minuun voi ottaa yhteyttä yhteisön asioissa, testausasioissa ja ihan vaikka muutenkin, joko sähköpostilla (antti-pekka.marjamaki(at)f-secure.com), Skypellä (anttipekkamarjamaki) tai puhelimella (040-8297484). Mitään SLA:ta en voi antaa, mutta testailkaa mikä noista tuottaa nopeimman vastauksen.

Ei kai tässä muuta kuin yrittämään, oppimaan ja (lopulta/toivottavasti) onnistumaan. Hyvää kesää kaikille!

Terveisin,
Pekka Marjamäki

PS: Jos et vielä ole jäsen tässä maanmainiossa osaamisyhteisössä, niin liity ilmaiseksi tämän linkin kautta!

Heuristisen testauksen workshop Tampereella 2.5.

2.5. keskiviikkona on ilmainen workshop aiheesta “Mind map -pohjainen heuristinen testaus”. Tilaisuuden järjestää Pekka Marjamäki F-secure Oy:stä.

Tilaisuuden pituus on noin 90 minuuttia ja se alkaa kello 16:30. Osallistujamäärä on periaatteessa vapaa, mutta teoreettinen maksimi on 30.

Tarkoituksena on ensin käydä vähän teoriaa heuristisesta testauksesta ja sitten testataan porukalla ja väännetään miellekarttoja! Tilaisuudessa tarvitaan oma läppäri tai laite, jolla pystyy käyttämään vapaasti valittavaa Mind map –softaa. Jos tätä ei ole saatavilla, niin on mahdollista pariutua sellaisen kanssa, jolla ko. laite löytyy (kunhan vaan ilmoittaa asiasta). Suosittelen XMind softaa, sillä sitä voi käyttää ilman asentamista (ohjeet http://www.xmind.net/downloads/)

Paikkana on Tampereella sijaitsevan Logia Software Oy:n toimitilat. Osoite on Åkerlundinkatu 11 C, Tullintorin kupeessa. Käynti rakennukseen sisäpihalla sijaitsevasta pääovesta. Ilmoittautuminen tiskille. Osallistujat tullaan hakemaan odotusaulasta hieman ennen puoli viittä.

Lisätietoja antaa allekirjoittanut (antti-pekka.marjamaki(at)f-secure.com; Twitter: @pekkamarjamaki; Skype: anttipekkamarjamaki)


PS. Jos mielenkiintoa on rutkasti, niin uskon, että onnistunee myös Helsingin päässä jossakin vaiheessa. Tästä ei ole vielä kuitenkaan tietoa vielä.

Mikset sää kirjota tänne enää mitään?

"Et oo tainnu jaksaa päivittää blogias ihan vähään aikaan", sanoi tyttö.
"Ai en vai? Oon kyllä kirjoitellut vaikka kuinka paljon ja jopa sellaista, joka herättää keskustelua", vastasi poika.
"Ai... Ei täällä oo kyllä mitään", vastasi tyttö ja osoitti blogia.

Niinpä. Vaihdettuani työpaikkaa viime marraskuussa siirryin lähes puhtaasti lontoonkielelle. Osoitteesta http://how-do-i-test.blogspot.com löytyy nyt suurin osa kirjoituksistani. Tämä johtuu puhtaasti siitä, että työkieleni on nykyään englanti ja työtoverini ovat 80% ulkomaankielisiä.

Tämä ei kuitenkaan tarkoita, että suomenkielinen blogi jäisi unholaan. Yritän suometaa joitakin tekstejä, joita pidän sen arvoisina, jotta niitä voi suomeksikin kommentoida. Nyt olen valitettavasti kiireinen tuon lontoonkielisen puolenk kanssa, joten se tulee olemaan pääasiallinen aktiviteetti nyt ainakin jonkin aikaa.

Älkää kuitenkaan huolestuko vaan lukekaa tuota sisarblogia, sillä siellä on asiaa taas yllinkyllin!

Palaillaan!

T:Peksi

Testausta SOA-maailmassa

Inspiroiduin tässä, oman projektini tiimoilta, jakamaan ajatuksia SOA maailman testauksesta. En ole vielä blogiini paljoakaan kirjoittanut puhtaasti testaukseen liittyvistä asioista, joten kokemuksien jakamiseksi voisin tässä hieman valottaa miten meillä SOA maailmassa on testattu. Tämä on siis puhtaasti minun näkökulmani oman testaustiimini toiminnasta eikä edusta koko yrityksen testausmalleja, jne jne. (Perinteinen "The following comments and statements are not the official..." -lakiteksti.) =) Lisäksi tämä ei ole projektikertomus vaan "testauskertomus", jossa paljon valonhohdetta kehitys ja projektiympäristöstä jää varmasti puuttumaan. Pahoittelut siitä: Te teette hyvää työtä, äijät ja gimmat! Jos olen jonkin yksityiskohdan tai muun unohtanut, vääristänyt tai kärjistänyt, niin pyydän syvästi anteeksi niiltä, joita se loukkaa. Tämä on minun näkemykseni tästä ko. projektista ja sisältää tunnelatauksella kirjoitettua kuvausta, josta kaikki ei ole 100% tarkkaa.

Hieman taustaa:

Kyseessä on siis monikansallinen SOA maailmaan toteutettu nelitasoarkkitehtuuripalvelu, jossa integroidaan puolisen tusinaa räätälöityä palvelua ja järjestelmää yhdeksi kokonaiskattavaksi palveluksi. Integraatioalustana toimii SonicESB ja SOA malli on webservice-pohjainen toteutus. Ohjelmoinnissa on käytetty pääasiassa C# ja Javaa (useita eri järjestelmiä). Palvelut ovat webbisovelluksia MySQL kannoilla. Tarkempaa tietoa en tässä lähde jakamaan, mutta perusperiaate on se, että meillä on integraatioputkia asiakkailta meille, jossa dataa puljataan ja tehdään sillä erilaisia temppuja, ja sitten putkea pitkin takaisin laitetaan jalostettua dataa. Simple, fun, "iz all good".

Vaan testaus tässä SOA-maailmassa osoittautui hieman erityyppiseksi kuin olin aiemmissa projekteissani testausta harrastanut. Projekti alkoi 2010 keväällä ja jatkuu vieläkin. Tuolloin keväällä luotiin kattavat testaussuunnitelmat sekä testitapaukset. Testausstrategia oli periytynyt aiemmasta php-MySQL-sovelluksesta, joten strategia oli kohtuu simppeli. Toiminnallista testausta, suorituskykytestausta integraatio ja systeemitestaustasolla. Yksikkötestit eivät juurikaan meikäläistä huolettaneet, olihan se kehittäjien peruskauraa. Testausautomaatiota ei juurikaan ollut, mutta toisessa yksikössä kehitetty CI-prosessi alkoi kiinnostamaan.

Jo alussa totesin, että ketterän kehityksen yhdistäminen SOA-maailmaan loi SUURIA kuoppia testaussuunnittelussa eikä IEEE-standardien mukainen testaussuunnittelu onnistunut sprinttimaailmassa. Siirryinkin testauksessa sulavasti "Definition of Done" -tyyppiseen testaukseen, jossa testitapaukset toimivat tukipilarina sekä "heuristiikkana" toiminnallisuuksien testaamisessa. Tämä malli oli toimiva jo toteutetuissa GUI:ssa ja perus bisneslogiikka toteutuksissa. Testejä tehtiin ja toiminnallisuuksia saatiin vietyä usein jopa asiakkaalle asti.

Ongelmat alkoivat kasaantua, kun SOA nosti rumaa päätään. Integroitiin pari järjestelmää ja liitettiin käyttöliittymä webserviceiden kautta taustalogiikkaan. Lisäksi integraatioputki asiakkaalta vaati testausta. Lähes kaikki integraatiotason testaus pamahti työpöydälle samaan aikaan ja testidataa ei ollut kenelläkään. Päivien työ kului konffatessa testidataa ja automatisoimalla integraatiotestejä - samalla koko toteutus muuttui pikkuhiljaa ja testit vanhentuivat. Päivitysrumbaan tuli kokoajan uutta testattavaa ja ylityöt alkoivat paukkua.

Syksyyn mennessä olimme saaneet ketterään tiimiimme toisen testaajan, joka samoin tein kiinnitettiin teknisempään testaukseen hänen ohjelmointitaustastaan johtuen. Työn määrä ei vaan mitenkään ottanut vähentyäkseen, kun mentiin kokoajan syvemmälle integraatio- ja järjestelmäintegraatiotasoille.

Joulun koittaessa 2010 olimme tilanteessa, jossa meillä oli kuusi järjestelmää, jotka kaikki käyttivät integraatioalustaa ja kommunikoivat toistensa kanssa ja releasepäivä lähestyi. Hain apua CI-porukalta ja aikaan saatiinkin Jenkinsillä kivasti ajettavat testisetit. Lisäksi yksikkötason ESB-prosessitestaaja saatiin refaktoroimaan prosesseja ja automatisoimaan testit. Lisäksi JMeterin suorituskykytestit sekä Soap-kuomitustestit saatiin (osittain) automatisoitua ja päästiin hieman lähemmäs hyvää testikattavuutta.

Joulu tuli ja Joulun alla piti olla suuri release, mutta vaikka testit menivät läpi, järjestelmä ei toiminut. Testiinluovutustilaisuudessa integraatiokerros lakkasi vastaamasta ja homma päättyi siihen. Testausta suovittiin ja ohjelmoijien kykyä tehdä toimivaa koodia. Jokainen taisi mennä itseensä ja silloinen tekninen projektipäällikkökin vaihtoi puljua. Kaaos oli taattu.

Saimme kuitenkin projektin urille hiomalla ja aikatauluja rukkaamalla, ja ennen kaikkea asiakkaan luottamuksen takaisin. Testaus tehtiin ketterämmin ja paremmassa yhteistyössä kehittäjien kanssa. Yksikkötestausta painotettiin ja suorituskykytestien perusteella tehtiin refaktorointia kiireen ohella. Ensimmäinen versio saatiin siis pilottiin vaikka meillä oli tiedossa X-määrä melko pahojakin vikoja. Pilotti oli kankeaa ja integraatiokerros takkuili. Ympäristöjen kanssa oli ongelmaa.

Toukokuu läheni ja siirryimme testauksessa jäykästä IEEE dokumentointimallista Boltonin kouluttamaan RST-malliin, jossa meillä oli sekä sessiopohjainen testauksen hallinta että tutkivan testauksen menetelmät käytössä. Saimme kymmenkertaistettua vian löytötahdin ja saimme pienennettyä testaussykliä kehittäjien kanssa. Tulosta saatiin! Lisäksi ympäristöongelmien kanssa päästiin eteenpäin ja stabiiliutta saatiin. Ensimmäinen KUNNON pilottiinsiirto saatiin toukokuussa ja pilotti ulkomailla eteni hyvin. Kiitosta tuli uuden testausprosessin myötä ja kehittäjiä kiiteltiin ja jopa koko projektiryhmä sai pienen kannustuspalkinnon.

Tässä vaiheessa alkoi kuitenkin pilvet kasaantua, kun päätettiin tehdä datamallin muutos integraatiokerrokseen. Asian piti olla kohtalaisen läpihuutojuttu: muutetaan kirjastot, rajapinnat, muutetaan arkkitehtuuria nopeuttamiseksi, refaktoroidaan komponentteja, yhdistellään... WHAT?! Tämä läpihuutojuttu osoittautuikin käytännössä KAIKKEEN vaikuttavaksi ("God bless that SOA!") ja testaus oli avainasemassa näiden muutosten läpiviennissä.

Kaikki testit jouduttiin päivittämään ja vielä yhtä aikaa. Kaikki ketjut piti uudelleensuunnitella, jokainen kanta-assertio tarkistaa. Kehittäjät olivat tehneet siis muutokset lokaalisti ja jokainen omat muutoksensa. Nyt niiden ollessa samassa korissa me testaajat olimme pulassa... Tai olemme. Tuo on tämänhetkinen tilanne.

--

Aiemmin sanoin "vähän taustaa", mutta tästä muodostuikin melko kattava kertomus. Mitä tästä jäi käteen? Paljon ylityötä? Kritiikkiä? Koloja asiakassuhteessa? Mitä me opimme (tai opimme edelleen)?

Illan pimeinä tunteina, kun muu testausporukka on jo lähetetty lataamaan akkuja, saatan istua koneella ja etsiä vastauksia kysymyksiin. Miten testaus on järkevä organisoida SOA maailmassa? Mihin sijoittaa se vähä määrä testauspanosta, joka meillä on antaa tälle projektille?

Mietin testauksen alihankintaa, jossa toteutamme testitapaukset ja alihankkijaryhmä saa testata softan etu- ja takaperin. Vaan sen verran olen oppinut, että SOA maailmassa täytyy olla ketterä ja liian skriptatut testitapaukset ja -ideat muodostuvat päivitystaakaksi, josta ei ole pakoa. Ketteryys on siis avain. Vaan miten ketteröitetään testausta?

Lähdimme hyväksi havaittua tutkivan testauksen lähestymistapaa hyväksikäyttäen kartoittamaan tilanteita ja riippuvuuksia. Saimme paremmin tietoa käyttämällä taitoamme ja tietoamme koostamaan järjestelmästä kokonaiskuvan kaikkine integraatioineen ja rajapintoineen. Päätimme pitää tiettyjä osa-alueita mustina laatikkoina ja kriittisiin solmukohtiin syvennyimme tarkemmin. Automaatiota parannettiin parametrisoimalla testitapauksia tehokkaammin ja jopa poistamalla päivityshelvetiksi muodostuneita tapauksia. Testasimme myös aikaisemmin kuin aiemmin, jolloin saimme tietää riippuvuuksia ennen niiden toteuttamista.

Testauspolitiikka alkoi muuttumaan "pass/fail" -tyyppisestä "kaikki testit menevät läpi, mutta ne löytävät/eivät löydä vikoja, poikkeamia, riskejä, huomioita, häiriöitä, jne." -tyyppiseen. Pyrimme tuomaan asoita esille enemmänkin tarinana kuin punainen/vihreä -periaatteella. Me halusimme antaa tietoa järjestelmästä kehittäjille ja projektin päättäjille.

Myös strategia päivittyi jäykästä ketterään. Tekniikat olivat testaajien kontekstiin sopiviksi valittavia ja työkaluja käytettiin parhaiden taitojen mukaisesti (ei parhaiden käytäntöjen). Saimme työkaluista irti sellaisia ominaisuuksia, joita emme olleen aiemmin käyttäneet johtuen käytänteistä. Pystyimme tekemään pidempiä ketjutuksia ja tarkempia assertioita ja kantatarkistuksia. Heuristinen lähestymistapa systeemitestaukseen vei meidän kauemmas ja lähemmäs testattavaa softaa (välillä rautaa) ja nosti aivan uudenlaisia vikoja ja puutteita järjestelmästä. Vaikka vikojen määrä on tähtitieteellinen verrattuna projektin aiempiin vaiheisiin, niin laatu on noussut - ihmiset ottavat opikseen huomioista, riskeistä, kysymyksistä. Testaus nostaa esiin asioita, joita kukaan ei ole ennen ajatellut. Testaus nostaa esiin asioita, mitä harva on aiemmin edes tajunnut! Testaajat eivät etsi vain bugeja vaan testaajat kertovat kaikesta, mitä havainnoivat.

Testaus tarjoaa enemmän tietoa kuin koskaan aiemmin ja se vie meitä eteenpäin. Ja nyt mennään taas eteenpäin, että saadaan tämä projektivaihe kunnialla maaliin!

Testausheuristiikat 7/7

SUOMEKSI?
Lupailin kääntää nämä heuristiikat suomeksi jossakin vaiheessa. Näistä voisi siis muodostaa musitisääntöinä:

CIDTESTD voisi olla KATTIVAT eli Kehittäjä, Asiakas, Testaustiimi, Testauksen kohde, Informaatio, Välineet, Aikataulu, Testaustuotteet. "Kattivat, tuo kissojen kuningas!"

SFDPOT voisi olla RADKAT eli Rakenne, Alusta, Data, Käyttö, Aika, Toiminnallisuus. "Radkat, tuo kissojen radioaktiivinen supersankari!"

HICCUPPS voisi olla HYVLOTTA eli Historia, Yrityskuva, Verrokkituotteet, Lupaukset, Odotukset, Tarkoitus, Tuote ja Asetukset. "Hyvä Lotta!"

CRUSSPICSTMPL voisi olla KASTLLTSYKSYT eli Kykynevyys, Asennettavuus, Suorituskyky, Turvallisuus, Luotettavuus, Lokalisointi, Testattavuus, Siirrettävyys, Ylläpidettävyys, Käytettävyys, Skaalautuvuus, Yhteensopivuus ja Tuettavuus. "Sade on kastellut syksyt"

FDSFSCURA voisi sitten olla KATSTSKVR eli Ketjutestaus, Automaatiotestaus, Toiminnallinen testaus, Skenaariotestaus, Toimialakohtainen testaus, Stressitestaus, Käyttäjätestaus, Väitetestaus ja Riskitestaus. "Katsastuskaveri"

Tämä on viimeinen ns. heuristiikkablogaus, jonka teen osittain työn puolesta. Jatkossa pyrin kertomaan heuristiikoista miten itse niitä käytän ja miten saan niistä mahdollisimman paljon irti. Tässä kuitenkin niille, jotka "kinusivat" noita RST-heuristiikkoja suomeksi. ;)

Testausheuristiikat 6/7

FDSFSCURA
Tekniikkoihin ja lähestymistapoihin pureutuva FDSFSCURA tarjoaa on omiaan kertomaan MITEN ja MITÄ kannattaa testata. Tekniikoita ovat siis: F = Function Testing, D = Domain Testing, S = Stress Testing, F = Flow Testing, S = Scenario Testing, C = Claims Testing, U = User Testing, R = Risk Testing, A = Automatic Testing. Tällä pyritään valottamaan sitä, että on useampiakin tapoja tehdä testausta kyseiseen tuotteeseen.

Toiminnallinen testaus on käytännössä sitä, että testataan "mitä voi tehdä". Tunnistetaan funktioiden ja toiminnallisuuksien tarkoamat ominaisuudet ja testataan niihin liittyviä asioita. Hyvä mittaamaan kykyä luotettavuuden sijaan. Toiminnallinen testaus on yleensä mukana muissakin heuristiikoissa tavalla tai toisella, mutta tässä tarkoitetaan nimenomaan toiminnallisuuden tarkastamista, että "se toimii oikein".

Toimialakohtainen testaus liittyy yleensä dataan. Kattamalla erilaisia datakombinaatioilla voidaan löytää asioita, joita puhtaasti toiminnallinen testaus ei löydä. Esimerkiksi vakuutusalalla on useita testaustekniikoita, testi-ideoita ja variaatioita, jotka koskevat vain ko. alaa. Myös logistiikka-ala, pankkiala, jne. sisältävät oman toimialan erikoistapauksia.

Stressitestauksella pyritään kyykyttämään järjestelmää parhaalla mahdollisella tavalla. Näin saadaan esiin muistivuotoja, validointivirheitä ym. jotka nousevat esiin vain paineen alla. Tietokantatasolla saadaan massatestauksella aikaan mahdolliset lukkotilanteet sekä datan ylikirjautuminen tai kirjautumatta jääminen.

Ketjuttamisella voidaan testata toimintoja toisen perään. Voidaan myös testata prosessia niin, että jätetään pakollisia toimintoja välistä tai tullaan prosessiin keskeltä mukaan. Näin löydetään ongelmia, jotka eivät ole riippuvaisia yhden toiminnallisuuden asioista. Mallipohjaisessa testauksessa testausautomaatiolla voidaan toteuttaa helpostikin pitkiäkin ketjuja sekä niiden variaatioita.

Skenaariotestauksella testataan asioita tuotteen ympäriltä sekä liittymistä. Skenaario on eräänlainen käyttötapaus, mutta joka on lähemmin yhteydessä todelliseen käyttöön ja ympäröiviin asioihin. Käyttötapauksia hyväksikäyttäen voidaan luoda sellaisia skenaarioita, missä on muuttujina esimerkiksi alusta, käyttäjän taito, aika, data ja/tai muut muuttujat.

Väitetestauksella tarkoitetaan siis määrityksiä, lupauksia, vaateita. Niitä testataan sekä tuotetta vasten ja tuotetta testataan niitä vasten. Tarkoitus on sekä tarkentaa "väitettä" ja tuotetta. Väitteet voidaan myös poimia asiakkaan tai tuotteen omistajan puheesta ja testata, josko "luvataan liikoja".

Käyttäjätestaus liittyy usein käyttäjän kykyihin käyttää järjestelmää. Miten punavihersokea pystyy aistimaan dashboradin elementit? Miten ummikko pystyy käyttämään kompleksista toiminnanohjausjärjestelmää? Entä käyttäjät, jotka käyttävät suoraan ohjeesta? Entä käyttäjät, jotka kokeilevat ja testailevat tuotetta?

Riskitestauksella pyritään tunnistamaan riskejä ja yrittämään toteuttaa ne. Voiko riskin toteuttaa järjestelmällä? Voiko siitä seurata ongelmia? Tässä kannattaa käyttää hyväksi asiantuntemusta myös liiketoiminnasta ja kehittäjiltä, jotta voidaan löytää ne suurimmat rsikit omaavat osa-alueet. Riskitestauksella voidaan myös mitigoida riskejä tai nostaa esiin uusia riskejä.

Automaatiotestaus tarkoittaa käytännössä testi ajamista tuhanisa kertoja tai automatisoimalla testin muuttumaan hieman. Näin voidaan nopeasti kehittää suuri määrä testejä joilla voidaan löytää ongelmia, joita manuaalinen testaus ei löydä. Esimerkiksi Brute force -tietoturvatestaus löytää helpommin aukkoja tietoturvasta kuin manuaalisesta samojen testien ajaminen. Lisäksi tietoturvatestausta harvemmin kannattaa toteuttaa manuaalisesti, sillä usein tietoturva-aukkoja etsitään koneitse.