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ä.
Friday, 13 April 2012
Thursday, 12 January 2012
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
"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
Friday, 11 November 2011
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:
--
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!
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!
Saturday, 5 November 2011
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. ;)
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. ;)
Monday, 17 October 2011
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.
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.
Wednesday, 12 October 2011
Testaajat eivät ehdi testata
Oli taas yksi niistä päivistä eilen, että aloin miettimään ammattivalintaani. Rakastan testausta ja kaikkea siihen liittyvää, mutta erityisesti pidän testaamisesta (ei testauksesta). Meillä oli miesvajausta ja päätin heittää hallinnollisen viittani naulakkoon ja kääriä hihat.
Istuttuani testauspenkkiin ajattelin nopeasti ajaa savutestisetit läpi ja aloittaa kunnon testauksen. Kopeana ja ylpeänä aloin ajamaan rajapintatestejä, jotka kaikki napsahtivat punaiselle. "Pannahinen" sanoin. Oletin ensimmäisenä, että vika on järjestelmässä. Tarkistin tilanteen ja totesin, että systeemi käy ja kukkuu. Olin ampunut testit väärään endpointiin.
Korjasin testit ja ajoin ne uudelleen. Noin 40% meni punaiselle. "Pannahinen" sanoin. "Eipäs tämä järjestelmä toimi yhtään niinkuin pitäisi!" Sitten tarkistelin virheilmoituksia ja assertioita. Näemmä olin innostuksissani päivittänyt testejä niin, että testit sisälsivät tyhjiä elementtejä, jotka rikkoivat testit.
Korjasin taas testit ja nyt sain kaikki paitsi 10 vihreiksi. "Pannahinen" sanoin ja pyyrin toisen testaajan katsomaan tuloksia. Hän vain totesi, että "toimiihan tuo. Olen sitä käyttöliittymän läpi testannut jo puoli tuntia."
--
Kun on pidemmän aikaa tekemättä jotakin, niin taidot ruostuvat - faktahan se on. Ne vaan eivät ruostu meidän päässämme. Me olemme omasta mielestämme edelleen niitä "huipputestaajia" ja "buginmetsästäjiä", mitä olimme puoli vuotta sitten. Kun pääsee sorvin ääreen uudelleen, niin hetki siinä menee palautellessa niitä taitoja taas sormenpäihin.
Tämän aion välttää jatkossa tekemällä harjoitteita, joita itse annan testaajilleni. Esimerkiksi ParkCalc-tyyppisiä testausrupeamia (kiitos plyytinen), joilla pystytään harjoittamaan kriittistä ajattelua ja testi-ideoiden kehittämistä.
Istuttuani testauspenkkiin ajattelin nopeasti ajaa savutestisetit läpi ja aloittaa kunnon testauksen. Kopeana ja ylpeänä aloin ajamaan rajapintatestejä, jotka kaikki napsahtivat punaiselle. "Pannahinen" sanoin. Oletin ensimmäisenä, että vika on järjestelmässä. Tarkistin tilanteen ja totesin, että systeemi käy ja kukkuu. Olin ampunut testit väärään endpointiin.
Korjasin testit ja ajoin ne uudelleen. Noin 40% meni punaiselle. "Pannahinen" sanoin. "Eipäs tämä järjestelmä toimi yhtään niinkuin pitäisi!" Sitten tarkistelin virheilmoituksia ja assertioita. Näemmä olin innostuksissani päivittänyt testejä niin, että testit sisälsivät tyhjiä elementtejä, jotka rikkoivat testit.
Korjasin taas testit ja nyt sain kaikki paitsi 10 vihreiksi. "Pannahinen" sanoin ja pyyrin toisen testaajan katsomaan tuloksia. Hän vain totesi, että "toimiihan tuo. Olen sitä käyttöliittymän läpi testannut jo puoli tuntia."
--
Kun on pidemmän aikaa tekemättä jotakin, niin taidot ruostuvat - faktahan se on. Ne vaan eivät ruostu meidän päässämme. Me olemme omasta mielestämme edelleen niitä "huipputestaajia" ja "buginmetsästäjiä", mitä olimme puoli vuotta sitten. Kun pääsee sorvin ääreen uudelleen, niin hetki siinä menee palautellessa niitä taitoja taas sormenpäihin.
Tämän aion välttää jatkossa tekemällä harjoitteita, joita itse annan testaajilleni. Esimerkiksi ParkCalc-tyyppisiä testausrupeamia (kiitos plyytinen), joilla pystytään harjoittamaan kriittistä ajattelua ja testi-ideoiden kehittämistä.
Tuesday, 30 August 2011
Testausheuristiikat 5/7
CRUSSPICSTMPL
Tämä heuristiikka pureutuu laatuun. Tämä kattaa käytännössä kaikki "itility"-asiat (plus pari muuta). En käy tässä läpi muuta kuin englanninkielisen sisällön: C = Capability, R = Reliability, U = Usability, S = Security, S = Scalability, P = Performance, I = Installability, C = Compatibility, S = Supportability, T = Testability, M = Maintainability, P = Portability, L = Localizability. Jokainen laatukriteeri saattaa nostaa tai laskea toisen kriteerin tärkeyttä, ja puutteet yhdessä voivat johtaa puutteeseen toisessa. Kaikesta huolimatta laadulliset puutteet johtavat tuotteen arvon vähenemiseen.
Kyvykkyys tai kykenevyys (näiden "itilyjen" suomentaminen on melko hankalaa joskus) viittaa siihen, että onko järjestelmällä kyky käsitellä tiettyjä asioita. Onko järjestelmällä oikeuksia suorittaa sisäisiä tai ulkoisia toimintoja. Hyvänä esimerkkinä luku ja kirjoitusoikeudet. Tämä voisi ehkä liipata läheltä "auhtorizability"-sanaa (vaikka se ei ehkä sana olekaan).
Luotettavuus on periaatteessa itseään selittävä asia, jolla mitataan järjestelmän kykyä suorittaa prosesseja pitkällä ajalla virheettä.
Käytettävyys on oma tieteenalansa sellaisenaan, joten en tässä puutu käytettävyyteen sen kummemmin. Käytettävyys saattaa kuitenkin vähentää esimerkiksi turvallisuutta, jos käyttäjälle näytetään käytettävyyden nimissä näytetään käyttäjälle tietoja, joita hänen ei ole pakko nähdä. Turvallisuus tuo omalta osaltaan ristiriitaa monen laatukriteerin tarkasteluun. Voidaanko luoda esimerkiksi käytettävyyttä ilman että turvallisuus kärsii? Voidaanko luoda turvallisuutta ilman että suorituskyky tai asennettavuus kärsii? Turvallisuusaspekteja on lisäksi lukematon määrä, joten laatukriteerien keskenäinen priorisointi turvallisuutta vasten on joskus vaikeaa.
Skaalautuvuus tarkoittaa järjestelmän kykyä tukea kasvua. Suorituskyky tarkoittaa järjestelmän kykyä suoriutua tietomääristä, jotka järjestelmää tällä hetkellä kuormittaa (tai oletetuista raja-arvoista).
Asennettavuus on käytännössä kykyä tulla asennetuksi eri alustoille. Tämä ei ole validi esimerkiksi webbisoftissa muuten kuin selaimen yhteydessä tarkasteltaessa. Yhteensopivuus liittyy myös selaimiin, mutta myös kaikkiin järjestelmiin jotka kommunikoivat toistensa kanssa. Siirrettävyys koskee osittain asennettavuutta, mutta tämä liittyy siis softan siirtämistä uuteen rautaan, tms.
Tuettavuus, ylläpidettävyys ja testattavuus ovat ominaisuuksia, joitka tukevat laatua vaikka eivät sellaisenaan suoraan heikennä tai vahvista laatua. Ylläpidettävyydellä voidaan helpottaa jatkokehitystä, debugausta, jne. kun taas tuettavuudella tarkoitetaan kykyä jatkaa elinkaarta matalalilla kuluilla. Eli tukeminen ei tule kalliimmaksi kuin uuden softan tekeminen alusta.
Lokalisointi on maakohtaistamista eli kilisyyksiä tai aikavyöhykkeitä. Lokalisaatio tulee erityisen tärkeäksi, kun palvelua käytetään ympäri maailmaa, valtiota.
Tämä heuristiikka pureutuu laatuun. Tämä kattaa käytännössä kaikki "itility"-asiat (plus pari muuta). En käy tässä läpi muuta kuin englanninkielisen sisällön: C = Capability, R = Reliability, U = Usability, S = Security, S = Scalability, P = Performance, I = Installability, C = Compatibility, S = Supportability, T = Testability, M = Maintainability, P = Portability, L = Localizability. Jokainen laatukriteeri saattaa nostaa tai laskea toisen kriteerin tärkeyttä, ja puutteet yhdessä voivat johtaa puutteeseen toisessa. Kaikesta huolimatta laadulliset puutteet johtavat tuotteen arvon vähenemiseen.
Kyvykkyys tai kykenevyys (näiden "itilyjen" suomentaminen on melko hankalaa joskus) viittaa siihen, että onko järjestelmällä kyky käsitellä tiettyjä asioita. Onko järjestelmällä oikeuksia suorittaa sisäisiä tai ulkoisia toimintoja. Hyvänä esimerkkinä luku ja kirjoitusoikeudet. Tämä voisi ehkä liipata läheltä "auhtorizability"-sanaa (vaikka se ei ehkä sana olekaan).
Luotettavuus on periaatteessa itseään selittävä asia, jolla mitataan järjestelmän kykyä suorittaa prosesseja pitkällä ajalla virheettä.
Käytettävyys on oma tieteenalansa sellaisenaan, joten en tässä puutu käytettävyyteen sen kummemmin. Käytettävyys saattaa kuitenkin vähentää esimerkiksi turvallisuutta, jos käyttäjälle näytetään käytettävyyden nimissä näytetään käyttäjälle tietoja, joita hänen ei ole pakko nähdä. Turvallisuus tuo omalta osaltaan ristiriitaa monen laatukriteerin tarkasteluun. Voidaanko luoda esimerkiksi käytettävyyttä ilman että turvallisuus kärsii? Voidaanko luoda turvallisuutta ilman että suorituskyky tai asennettavuus kärsii? Turvallisuusaspekteja on lisäksi lukematon määrä, joten laatukriteerien keskenäinen priorisointi turvallisuutta vasten on joskus vaikeaa.
Skaalautuvuus tarkoittaa järjestelmän kykyä tukea kasvua. Suorituskyky tarkoittaa järjestelmän kykyä suoriutua tietomääristä, jotka järjestelmää tällä hetkellä kuormittaa (tai oletetuista raja-arvoista).
Asennettavuus on käytännössä kykyä tulla asennetuksi eri alustoille. Tämä ei ole validi esimerkiksi webbisoftissa muuten kuin selaimen yhteydessä tarkasteltaessa. Yhteensopivuus liittyy myös selaimiin, mutta myös kaikkiin järjestelmiin jotka kommunikoivat toistensa kanssa. Siirrettävyys koskee osittain asennettavuutta, mutta tämä liittyy siis softan siirtämistä uuteen rautaan, tms.
Tuettavuus, ylläpidettävyys ja testattavuus ovat ominaisuuksia, joitka tukevat laatua vaikka eivät sellaisenaan suoraan heikennä tai vahvista laatua. Ylläpidettävyydellä voidaan helpottaa jatkokehitystä, debugausta, jne. kun taas tuettavuudella tarkoitetaan kykyä jatkaa elinkaarta matalalilla kuluilla. Eli tukeminen ei tule kalliimmaksi kuin uuden softan tekeminen alusta.
Lokalisointi on maakohtaistamista eli kilisyyksiä tai aikavyöhykkeitä. Lokalisaatio tulee erityisen tärkeäksi, kun palvelua käytetään ympäri maailmaa, valtiota.
Subscribe to:
Posts (Atom)