Kokeneen testaajan kristallipallo

Joulukalenteritestausta muuttuvassa ympäristössä

2011-11-09T07:49:00.000-08:00

Intouduin tänään testitapauksia kouluttaessani uuteen vertauskuvaan selittäessäni testauksen haasteita ja dynamiikkaa. Joulunajan uhkaavasti lähestyessä meidän perheessä on alettu kovasti himoitsemaan joulukalenteria hyvissä ajoin. Kokemus taas muistuttaa, että meidän perheessä on pahoja tapoja muuttaa hyvissä ajoin hankitun suklaajoulukalenterin tarkoitettua tilaa niin että jotenkin kummasti osasta luukkuja katoaa se suklaapala, luukku sulkeutuu mahdollisimman huomiota herättämättömästi ja pettymys kadonneesta suklaasta iskee sitten joinain joulukuun päivinä.

Tälläisen kevyesti rosmotun suklaakalenterin tilanteen selvittelyssä on paljon yhtymäkohtia testaukseen. Minua oikeastaan kiinnostaisi osua vain niihin luukkuihin joista suklaa on kadonnut, mutta kun sitä ei ulkopuolelle huomaa. Kun luukkuja on katettavaksi vain 24, kaikkien avaaminen on tietysti mahdollista. Asiaa kuitenkin voisi lähestyä myös riskipohjaisesti, koittaen tunnistaa vääntyneitä kulmia tai helposti avattavia luukkuja.

Kun luukkuja availee, luukun avaaminen vie sen oman lyhyen aikansa. Kun luukunavaustesti onnistuu löytämään bugin, setvimiseen liittyvät toimet vievät merkittävästi enempi. Korjauksen jälkeen pitää vielä vahdata että korjaus on toiminut ja pysyy toimineena - tilanne kun meidän kalentereissa on varsin dynaaminen.

Jos testauksessa varaa aikaa 24 * avaamisaika, taustaolettama on ettei setvittävää löydy tai toistotarvetta ole. Kuitenkin bugeja etsiessä testausbudjettiin on laskettava virheen raportointiaika (että muutkin tietää mistä se suklaa puuttui) ja uudelleentestaus virheen korjauksen jälkeen. Jos kaikki palat olisivat kadoksissa - näin pahaa tilannetta ei vielä ole tullut vastaan - testaus veisi 48 avaamisaikayksikköä ja 24 raportointiaikayksikköä.

Kun kattavuus näin yksiulotteisesti voidaan kuvata, elämä on vielä testausta paljon helpompaa. Niin että testaukseen verratessa voisi sitten vielä ajatella että kyseessä on monikerroksinen kalenteri, jossa suklaapala voi olla kadoksissa mistä vaan suunnalta, ja että aika kaikkien luukkujen avaamiseen ei vain riitä, joten jollain riskipohjaisella periaatteella asiaa voi haarukoida.

Poimimani opit IIR:n Testing Forumista

2010-09-01T11:15:00.000-07:00

Jaoin erilaisten pienten porukoiden kanssa sähköpostilla poimintojani ja tulkintojani IIR:n Testing Forum -seminaarista viime viikolta. Pitkät piuhat, tajusin julkisissa liikennevälineissä ikkunasta tuijotellessani (luovia hetkiä...) että voisi sen tietysti ilman enempää selitystä jakaa näinkin.

Samat saatesanat kuin muillekin joille sen pienessä piirissä laitoin: saa kysyä että mitä ihmettä jollain tarkotan. Tulkintavirheet ovat omiani, saatan kuulla mitä sattuu kun sille päälle satun.

Pirkko Lankinen, TeliaSonera: Best in Class IT
- laitettu laatumenetelmistöä järjestykseen merkittävällä investoinnilla, erityisesti roolimäärittelyjä ja incident/problem/change management –rajapintoja.
- Accenture ollut arvioimassa kypsyyttä, mielenkiintoinen lähinnä esitetty vertailu jossa Banking & Finance –sektori oli varsin heikko organisaatiolleen tarjoaman tuen kypsyydessä
- merkittävänä motivaattorina kaukoulkoistus, josta saatu kustannussäästöjä

Vasco Duarte, Nokia: How Testing Can Revolutionize our R&D organizations?
- Hauskasti tuotu esiin suomen ja kiinan kustannusero: 9.4 kertaa kalliimpaa suomessa
- Tarvittava tuottavuusparannus (10x) mahdollinen paradigmamuutoksella --> ketterät menetelmät vaikkei sanaa kertaakaan mainittu esityksessä
- Havainnollisti hienosti hiljaisen tiedon siirtämisen tärkeyttä ohjelmistoprojekteissa - ”handover loses implicit knowledge”
- Perusteli ensimmäisen puhujan kumoon sanomatta sitä suoraan: roolipohjaisuus luo handovereita, kun jokainen hoitaa omaa tonttiaan.
- Testaus ei ole sama kuin tarkastaminen. Testaus tuottaa myös uutta tietoa, vaatimuksia.
- Määrittely ei ole tulos (output), se on muistin tuki (refresher)

Jani Haapio, NSN: Miten karsia turha testaus pois, ja löytää testauksen ydinkohdat?
- Siirrytty 1,5 vuotta sitten ketteriin menetelmiin, suuria muutoksia testauksen organisoinnille
- Lyhennetty, aikarajattu kokonaisuuden testaus pakottanut priorisointikäytäntöihin joita olisi tarvittu ennenkin. Priorisointi 3 kk välein yhdessä asiakkaan kanssa.
- 3000 toimintotestiä, 200 järjestelmätestiä. Priorisointi testitapauksille ja painotukset laatukriteereille.
- Tutkiva testitapaussuunnittelu: testit syntyvät lopuksi tulevalle muistin tueksi, motivaationa erityisesti työn siirtely useiden paikkakuntien/maiden välillä ja vastuu tukemisesta siirron jälkeen jos ei dokumentointia riittävästi. ”Kysymyksiä vanhasta työstä ei budjetoida”
- Valmiin määritelmälle Intian kehitystiimien kanssa vaadittu että dokumentaatio on sovitussa paikassa, helposti unohtunut levynkulmalle josta ei löydy pyydettäessä

Jouni Koivuneva, VR-yhtymä: Miten laadunvarmistus toimii, kun mukana on useita rajapintoja ja toimittajia
- Case, jossa kiinnitettynä lyhyt aikataulu suhteessa muutosten laajuuteen. Muutokset websivujen ulkoasuun: kuvat, värit, fontit, ei sisältömuutoksia.
- Oppeina tiukat rajaukset mitä ei saa tehdä ja yksilön sankarillinen suoritus
- Huvittavia tarinoita: Toimittajan suuresta työmäärästä katosi merkittävä osuus haastamalla että itse tekee jonkin osan. Puhujalla ajatus siitä että toimittajalla työmäärät määräytyvät asiakkaan maksukyvyn, eikä tehtävän työn perusteella
- Keskeisin oppi: aikataulua pitää laskea lopusta päin ja karsia laajuutta ajoissa.

Erkki Pöyhönen, Tieto: Hyväksymistestauksen haasteita
- Erilaisia organisointitapoja, joskus toimittaja hoitaa hyväksymistestauksen, joskus asiakas testaa toimittajan testitapauksilla.
- Keskusteltiin kovasti toimittajien etiikasta jos ei ohjaa asiakasta oikeaan ja tarkoituksenmukaiseen suuntaan

Tuula Pääkkönen, Nokia: Pohdintoja testaajan ammattitaidon kehittämisestä ja testausverkostoista
- Testaukseen päädytään monenlaisesta suunnasta, ja kasvutarpeet ovat yhtä moninaisia
- Sertifiointimalleja on paljon. Koulutustakin on saatavilla yhä enemmän, jopa osana perustutkintoja.

Olli-Pekka Puolitaival, VTT: Mallipohjainen testaus
- Piirretään kuvia siitä miten ohjelmistoa käytetään, ja luodaan automaattisesti testitapaukset, vältetään testien kirjoittaminen yksityiskohtaisesti
- Ylläpidon etuja korostettiin: mallin muuttaminen helpompaa kuin skriptien

Mika Katara, TTY: Älypuhelinsovellusten mallipohjainen käyttöliittymätestaus
- Testattu useita markkinoilla olevia puhelinsovelluksia, joista löydetty merkittäviä virheitä määrällisesti ja sisällöllisesti – testaus käyttöliittymän kautta
- Yhdistetty loki kameralla otettuun kuvaan tekstityksellä: pitkien ketjujen analysointi vaatii tukea joka ei pakota suorittamaan testiä uudelleen
- Löytää erityisesti toiminnallisuuksien rinnakkaisuuden ongelmia pitkäkestoisessa käytössä (luotettavuustestaus)
- Työkalusetti avoimen lähdekoodin tarttumattomalla lisenssillä saatavilla, hakevat myös yrityskumppaneita
- Omia pohdintoja:
o mallinnuksessa jatkokäytön arvon oltava hidastumista suurempi
--> dokumentointi, todisteet – tarvitaanko oikeasti?
--> bugien toistaminen
--> uudet virheet (pitkäkestoinen käyttö, rinnakkaisuus)
o mallinnuksen vaatima analysointi vaikuttaa eri tavalla eri ihmisiin
--> fokuksen supistuminen
--> kurinalaisuuden lisääntyminen, tavoitteellisuus
--> tekniikkaan ”hukkuminen”, ongelmat työkalujen kanssa

Tero Vuorenmaa, Softability & Matti Antila, Microsoft: Testaus ja laadunvarmistus osana tuotteen elinkaaren hallintaa Visual Studio ja Team Foundation Server –ratkaisussa
- Microsoftilla on nyt myös testaajan työkalut, vastaavat kuin Quality Center
- Elinkaaren hallinta tarkoittaa sitä että muistetaan että ensimmäinen projekti on vasta alku järjestelmän olemassaololle, kustannuksista suuri osa nk. ylläpitovaiheessa

Elina Partanen, Aktia: Tietoturvan huomioiminen verkkopalveluiden testausvaiheissa
- Hyödynnetty eri rooleja tietoturvatestaamiseen oman organisaation rajallisuus huomioiden: testaajat huomioivat toiminnallisuutta, toteuttajat rakentavat ja testaavat sovituin pelisäännöin tietoturvaa osana yksikkötestejä, ammattimainen tietoturva-auditointi kerran vuodessa
- haasteena ollut erityisesti ylläpito ja pienkehitys, joissa helposti unohtunut perushyökkäysten huomiointi
- Tykästyneet Burbsuiteen, pitäisi varmaan joskus huvikseen vilkuilla
- Vaadittua toimintaa tuetaan ohjein ja koulutuksin: asiakas tilaa toimittajan jokaisen kehittäjän kustannuksellaan koulutukseen ja maksaa koulutustunneista (4 h / hlö)

Blogin kirjoituksen haasteista

2010-08-31T09:45:00.000-07:00

Kirjoitteluni aiheet tuntuvat pyörivän erilaisten kriisinpoikasten ympärillä... Tällä kertaa inspiraationa aiempaan kirjoitelmaani tullut kommentti siitä että eikös blogeja enää lueta ja kommentoida.

Keräsin alkuvuodesta listan suomenkielisiä testausblogeja. Olen säännöllisen epäsäännöllisesti surffailut näitä läpi, ja huomannut että enimmäksen trendi tuntuu olevan että alkuun jaksetaan ja sitten kadotaan. Toki löytyy ajatonta tekstiä, josta voisi jatkaa keskustelua vaikka kuinka pitkään alustuksen tai aloituksen jälkeen. Toisaalta taas asioista jotenkin ajattelee keskusteltavan tuoreeltaan.

Huvittavaa sinänsä, mutta minun bloggaamisestani hävisi sekin vähä energia ja aika kun ensin kirjoittelin hetken testausOSYn linkedin-palstalla ja sitten hurahdin kevyesti twitteriin. Tosiasia kuitenkin on että ajan ollessa rajallinen luonnonvara 160 merkkiä testauksesta päivässä on aika paljon helpompaa kuin oikeasti jonkin tarinan kirjoittaminen.

Lisäksi olisi yksinkertaisesti helpompaa, jos useampi kirjoittaisi samaan blogiin, niin ei tarttisi surffailla ihan niin moneen suuntaan.

Pienenä huvittavana yksityiskohtana: minulla on parikymmentä aloitettua blogijuttua, joita en ole suoriutunut kirjoittamaan otsikkoa ja paria riviä pidemmälle... Joskus vielä - ihan kohta. Mutta ensin, vielä muutama hyvä tiivistelmä testisuunnittelun erityispiirteistä uudelle lempitestaussektorilleni.

Testauspäällikkökriisi

2010-08-26T11:44:00.000-07:00

Huomaan toistuvasti palaavani pienen turhautumisen tunteen kanssa nykyiseen titteliini: "testauspäällikkö". Kirjoittelin aiemmin siitä kuinka kierolta tuntuu, että testaajasta tulee testauspäällikkö ja toteuttajasta arkkitehti. Edelleen päällikkyys tuntuu tarpeettomalta ja väärään suuntaan ohjaavalta.

Muistan lukeneeni jotain trendilistaa lempiguruiltani, jossa yhtenä trendinä mainittiin että projektinhallinta ja testauksenhallinta yhdistyvät tulevaisuudessa. Testaus jää erikseen, eriytyy, ehkä jopa löytää paikkansa - näin ainakin itse ajattelen.

Testauspäällikkönä minun odotetaan - ulkopuolelta - olevan hallinnollisesti suuntautunut. Minun odotetaan suunnittelevan, ohjaavan, tuottavan mittareita. Ja joku muu onnekas saa tehdä lempityötäni, testausta. Voin mentoroida, opastaa, valmentaa ja kannustaa. Rohkaista ja antaa vinkkejä. Voin vähän tehdä itsekin, mutta odotukset ovat vahvasti muualla.

Sanojen ei pitäisi sitoa, eikä vaivata. Koen silti että jopa aivan samalla työkuvalla, olisin aina mieluummin "testausasiantuntija" kuin päällikkö.

Minun kolleegani, projektipäälliköt tiimissäni, ovat loistavia. Selviäisivät testausasioista siinä kuin mistä tahansa muustakin. Jostain syystä testauspäällikön olemassa olo vaikuttaa enemmän jopa itsetuntoa alentavasti, kun eivät sitten ihan samalla tasolla osaa jokaista detaljia testauksesta.

Odotan innolla ensi viikkoa - saan kolleegan, jolta odotan tukea pohdinnassa tulevasta testauspäällikköroolista.

Kuilu vaatimusten ja toimivan välillä

2010-06-03T12:04:00.000-07:00

Vietin taas pari päivää opastaen mukavaa porukkaa testitapausten suunnittelussa. Tästä porukasta ja keskusteluista minulle jäi erityisesti pohdittavaksi, että kuinka yleistä lopulta on, että vaatimukset rajaavat testausta kohtuuttomalla tavalla.

Cem Kanerin materiaaleja muistinvaraisesti lainaten, vaatimukset ovat fiktiota. Parhaimmillaan ne ovat käyttökelpoisia, hyödyllisiä, avuksi.

Jäin pohtimaan, että onko tämä yksi niitä keskeisiä eroja tuoteliiketoiminnan ja projektiliiketoiminnan välillä. Suppealla otoksella kummastakin ei tietysti halua vetää liian pitkälle meneviä johtopäätöksiä, mutta tuntuma on, että projektien tilaamisessa ja toimittamisessa on jotain, joka ohjaa tarpeettomassa määrin siihen, että asiakkaan tarpeita ei koiteta täyttää, vaan vain asioita joita on "vaadittu". Testaajaa jopa kielletään testaamasta mitään muuta kuin vaatimuksissa mainittuja asioita. Muita asioita testataan sitten kun tämän toimituksen osalta ollaan turvassa (aikataulussa / luvatussa laajuudessa), ja asiakas tajuaa että ei saanutkaan täytettyä tarvettaan, mutta vielä uskoo siihen että oma vikahan se toki oli kun ei osannut vaatia.

Jokseenkin hahmotan, että tokihan jokaisesta tunnista pitää saada laskuttaa. Mitta sitä en hahmota, että voidaanko ihan vakavissaan lähteä siitä, että tehtäisiin projekti, joka täyttää vaatimukset ilman väliä siitä millaista tarvetta vaatimukset olivat kuvaavinaan. Kai se on sinänsä luonnollinen vastareaktio muodissa oleville kiinteähintaisille toimituksille.

Viksumman testaamisen hidasteita asiakas-toimittajamaailmassa

2010-05-30T10:52:00.001-07:00

Olen viime aikoina miettinyt varsin paljon taas tutkivaa testausta, asiakas-toimittajaprojektien näkökulmasta. Matkalla voi olla muutamia hidasteita:

- suunnittelun ja testaamisen erilainen hinnoittelu. Jos sattuu olemaan tilanne, jossa testaustyötä hinnoitellaan eri lailla riippuen sen vaativuudesta ja on luokiteltu, että suunnittelu on vaativaa ja testaaminen ei, tiessä on kyllä pieni kuoppa. Osittain tämä luokittelu kerjää sitä että tehtävät annetaan eri henkilöille, osittain sitä että valmistaudutaan mahdollisimman paljon, jopa yli sen hyödyllisen ja oikeasti tarpeellisen. Erityisesti haasteelliseksi muodostuu se että haluaisin sen halvemmalla hinnalla tehtävän työn sisältävän merkittävässä määrin nk. kalliimman hinnan töitä. Oikeasti noissa tilanteissa kyllä sanotaan että 100 tuntia testaukseen liittyvää työtä olisi keskimäärin jotain kahden hinnan väliltä.

- vaatimukset. Elisabeth Hendricksonilla oli jossain esityksessään oivaltava kommentti siitä, että lähes jokainen bugi on lopulta - toteuttajansa näkökulmasta - muutos vaatimuksiin. Jos ei ole ajateltu yllättävää vuorovaikutusta käyttöliittymän kanssa, vääränlaista syötettä naapuriohjelmalta tai että joku voisi joskus käydä kahvilla kesken tekemisen ja ohjelma ei tässä tilanteessa toimi, onhan se jollain tapaa perusteltua sanoa, että pyydetään uusia asioita. Mitä tarkempaan vaatimusdetaljiin mennään - jopa pseudokoodaukseen - sitä sidotummaksi suhteessa vaatimuksiin muuttuvat myös testaajan kädet.

- suojautumistarve. Varsin monesti sopimukseen ja projektisuunnitelmiin on osattu kirjata, että testit toimitetaan ennakkoon, ja toimittaja varaa luonnollisesti itsekin aikaa varmistaakseen, että luovutuksen tai hyväksynnän testit läpäistään. Se on paljon helpompaa toimittajan näkökulmassa, jos kerrotaan mahdollisimman täsmällisesti mitä aiotaan kokeilla ja miten. Niinpä asiakkaita tulee helposti ohjattu pois tutkivasta testauksesta, enemmän ennakkoon kirjattuun tyyliin.

- ajoitukset. Kun jostain on sovittu hankinnan alkuun, tuntuu että muuttaminen on tuskallista. Prosesseja pitäisi kehittää projektien ulkopuolella, erillisissä projekteissa, etteivät sotkisi tämän suunnitelmia ja työmääriä. Ja kun testausta tupataan valmistelemaan vasta kun projektin puitteet muuten on sovittu, aika on harvoin suoraan oikea.

Hidasteita, ei esteitä. Taidan alkaa miettiä seuraavaksi hyväksymistestausprosessia, ja siihen rakenteita, jotka sallivat ja tukevat fiksua testaamista.

Hyväksymistestauksen dokumentaation jakaminen toimittajalle

2010-05-21T10:52:00.000-07:00

Keväällä IIR:n seminaarissa muutamassakin puheenvuorossa pohdittiin hyväksymistestauspuheenvuorojen osalta periaatetta dokumentaation jakelussa toimittajalle.

Testitapausten osalta silloin taisi vallitseva käsitys olla, että parempi olla antamatta. Syyt olivat kaiketi:
- Huoli siitä että toimittaja testaa vain näillä testeillä ja kokonaisuutena saadaan huonompaa laatua
- Riippuvuudet asiakkaan materiaaleihin aikataulullisesti sovittuina aiheuttavat tarpeettomia paineita asiakaspäässä materiaalin viimeistelyyn
- Asiakkaan materiaalin odottaminen antaa epävirallisen luvan luovuttaa oman testauksen valmistelun yrityksen kanssa ja vähentää vastuunottoa

Testitapausten osalta olen edelleen eri mieltä. Minusta ne kannattaa antaa. Parempi että edes ne toimivat, kuin että viimeisen hyväksymistestin aikana tarvitsee niistäkin huomata etteivät toimi. Kun lähtökohtaisesti lähtee siitä että testi ei ole äärimmäisen toistettava vaan lähinnä muistilistan omainen, näkisin että riskiä siitä että toimittaja kuvittelee vastuun testisuunnittelusta siirtyneen asiakaspäähän olisi hallittavissa. Ja korostetusti kannattaa varata oikeus ja mahdollisuus tutkivaan testaukseen, joka vielä entisestään täydentää suunniteltua kokonaisuutta.

Testaussuunnitelmat ovat minusta paljon haastavampi kysymys. Erityisesti nykymaailmassa missä lähestulkoon järjestelmä kuin järjestelmä koostuu eri tekijöiden osista, en aina ole ihan vakuuttunut että haluaisin avata kaikille osapuolille kaikki näkökulmat riskeihin, mitä osana hyväksymistestausta pitää pohtia. Jotkut asiat kun ovat vaan meidän organisaatiolle. Ja ainakaan minua ei kiinnosta tästä syystä että kirjaan suunnitelmaani nk. arkaluonteisia asioita ja arvioita pohjana riskiarvioilleni, kirjoittaa toista "siistittyä" suunnitelmaa. Sen osalta minusta saa riittää, että testaamme. Jos siinä on jotain minkä kertominen auttaa viestintää, pidän aiheesta mielellään silmäkkäin session. Ja sekin on tietysti lähestulkoon aina.

Paljonko testauksen pitää tuottaa hyötyä?

2010-04-20T10:42:00.000-07:00

Vuodet testaushommissa ovat opettaneet, että testaajan tuottama lisäarvo ei ole lainkaan niin suoraviivaista, että testitapausten suunnittelun, suorituksen tai virhemäärien mittaamisella saataisiin kiinni sen tuottamasta arvosta. Testausnäkökulmalla ja testauksella on arvoa, se on hyödyllistä - usein.

Tämä ei kuitenkaan ole itsestäänselvyys. Olen aistivinani että testaus on tullut muotiin erityisesti asiakas-toimittajasuhteissa jopa siinä määrin, että koen että näissä tilanteissa vastaan on osunut kohtia, joissa testausotsikon alla tehty työ ei ehkä tuotakaan kovasti lisäarvoa.

Jos testauksessa käytetään varsin mittava työmäärä, tuotetaan kertakäyttötestitapauksia ko. projektin näkökulmaan ja katselmoidaan niitä suurella panoksella ja lopulta ei juurikaan löydetä ongelmia, voi minusta jo perustellusti miettiä että olikohan panokset oikein asetetut. Etenkin, jos jälkeen tulevat testausvaiheet osoittavat, että löydettävää kuitenkin olisi ollut.

Jos kohdalle osuu projekti, jonka osalta on perusteltua sanoa ettei se testaamalla juurikaan parane erilaisten reunaehtojen vuoksi, onko enää järkevää suositella että kuitenkin testaukseen panostetaan, ja vielä suuremmassa määrin. Vai voisiko testausihminen suositella jopa testaajien poistamista ja muiden ratkaisijoiden lisäämistä? Voisiko otos olla kattavuutta parempi tavoite hyötyjä ajatellen?

Välillä jää sellainen fiilis kaivertamaan, että erityisesti testauspalveluja tarjoavat osaoptimoivat testauksen, eivätkä ajattele testausta osana arvoketjua. Samoja tavoitteita voisi edistää halvemmilla ja tehokkaammilla keinoilla. Vai onko testausasiantuntijan kädet tosiaan niin sidottu ettei lähimaailmaa saa nytkäytettyä lähemmäs raiteita? En usko.

Me ollaan testaajia kaikki

2010-03-03T11:09:00.000-08:00

Jossain verkossa surffaillessani GoogleAds päätti näyttää minulle kohdistetusti mainoksen, jossa Reaktor etsi "koodaavaa pääarkkitehtiä". Paikka ei ole kyllä missään määrin minulle kohdistettu, mutta termiin liittyvä teema sattui olemaan testauspuolelta juuri pohdiskelun alla.

Jos mietitään karkeasti ohjelmistokehityksen rooleja, niitä olisi kaiketi kolme: vaatimuskaveri, toteutuskaveri ja testauskaveri. Näistä kuka vaan voisi nk. edetä urallaan hallintovaihteelle ja ryhtyä vaikka projektipäälliköksi. Toteutuskaverista tulee kuitenkin omalla vaihteellaan edetessään arkkitehti, ja testauskaverista testauspäällikkö.

Erityisesti olen ihmetellyt viime aikoina sitä, että toteuttaja joka pomppaa projektipäälliköksi ei yleensä enää kuvaa itseään koodaajana. Testaaja joka siirtyy testauspäälliköksi on hyvinkin vahvasti edelleen testaaja. Erityisesti tämä jäi minua mietityttämään sen vuoksi, että olen ollut huomaavinani, että varsin monet testausasiantuntijat eivät olekaan henkilökohtaisesti vuosikausiin testanneet. Toiset, kuten minä, testaavat kepoisasti silloin tällöin, nauttien pinnallisista mutta silti korjauskelpoisista virheistä joita rajatussa ajassa voi löytää. Koen tiettyä tuskaa, kun niin suuri osa ajasta kuluu ohjatessa, neuvotellessa, mittareita kehitellessä ja nauttien katsoessa kun toiset tekevät rakastamaani työtä hyvin. Kai se on jonkinasteista kateutta. :)

Olen vakuuttunut, että testaus on sekä taito että ajatusmalli. Taito katoaa jos työtä ei harjoita. Ajatusmalli säilyy. Taitopuolella etääntyminen on liian helppoa, kuvaten työtä edelleen kuitenkin samalla sanalla - me ollaan testaajia kaikki, nekin meistä jotka eivät ehdi muilta testaustöiltään testaamaan.

Testauksen opettaminen - onko kaikki vaan peruskursseja?

2010-02-24T11:10:00.000-08:00

Tieturin testausseminaarissa Tieturin testauskouluttaja Teppo Heikurinen kertoi puheenvuorossaan testaajien erilaisista profiileista ja tarpeista. Osana puheenvuoroaan Teppo esitti myös varsin vahvan väitteen siitä että kaikki testauskoulutus Suomessa on vain peruskursseja, joka luonnollisesti särähti omaan testauskouluttajakorvaani. Mitä ovat perusasiat ja mikä on edistyneempää testauksessa.

James Bach on mielestäni upeasti kuvannut suuren osan testauskurssisisällöistä termillä "testing folklore" - testauksen kansantiedettä. Kerromme kursseilla tarinoita testauksesta, opimmekin tarinoiden perusteella. Itse näkisin että opimme sekä perusasioita, että syvemmälle meneviä.

Toinen suuntaus testauskursseissa on sitten yritys opettaa testaamaan, eikä vain sujuvasti puhumaan testauksesta. Tässä suuntauksessa yleensä lähdetään siitä että testaus ei tapahtu paperiopetuksella, vaan testaukselle tarvitaan asennettu kohde. Ja niiltä osin kuin opetus tapahtuu luokkahuoneessa ilman konetta, harjoituspainotteisuus kuvista ja teksteistä analysoiden on vahvoilla.

Mikä on siis peruskurssi? Mitä ovat "testauksen perusteet"? Uskoisin pääseväni ISTQB-sertifikaattia syvemmälle, ja tuntuu pahalta ajatella että koulutan 20 päivää perusteita silti asioita suuressa määrin toistamatta. Niinkin toki voi olla.

Luin Cem Kanerin materiaalia tutkivasta testausautomaatiosta (exploratory test automation). Materiaalissa johdantona oli erinomainen jäsennys siitä että lähtien taidottomasta, edeten pikkukikkojen kautta tuottavaan ja lopulta oikeasti testausta osaavaan vaatii aikalailla erilaista koulutusta. Suhteessa tähän tunnustan: opetukseni taso on edelleen pikkukikkojen (quicktests, techniques) tasolla. Kuten Cem Kaner asian muotoili: "There are generically useful approaches to test design, like quicktests and tours and other basic techniques, but I think we add our greatest value when we apply a deeper understanding of the application. Testing instructors don’t teach this well because it takes so long to build a classroom-wide understanding of an application that is complex enough to be interesting."

Perusteissa siis mennään. Ja perusteissakin on eroja. :)

Oppeja testitapauksia vastaan

2010-02-24T10:40:00.000-08:00

Olin viime vuonna lukenut nopeasti James Bachin esitysmateriaalin testitapauksia vastaan, ja eksyin siihen enemmän ajatuksella siivotessani kirjanmerkkejäni. Alkuperäisteos jota jäin pohtimaan löytyy täältä:
http://www.satisfice.com/presentations/againsttestcases.pdf

Erityisen viehättävä osa materiaalissa oli testauspandemiasanaleikit, 3 * OCD:
- Obsessive Case Disorder. Pakonomainen tarve uskoa ja antaa muiden uskoa että testitapausten suunnittelu on niin keskeinen aktiviteetti, että se sisältää kaiken testausajattelun ja suoritus on sitten mekaanista. Yleensähän annamme uskoa, kun ei vaan joka kerta jaksa selittää. On helpompaa sanoa että aikaa on varattava testitapausten suunnittelulle, eikä koittaa selittää että aikaa on itse asiassa varattava siihen että ehditään perehtyä vaatimusdokumentaatioon kirjattuihin lupauksiin ja olettamiin.
- Obsessive Counting Disorder. Pakonomainen tarve laskea testitapauksia, joiden laskemisella ei oikeasti ole niin suurta merkitystä. Pieni määrä ei korreloi huonon testauksen kanssa. Mutta, itse ainakin taas tänään totesin, että testitapausten laskeminen suhteessa jonkinlaiseen ideaan kattavuuskriteeristä antaa edes jonkinlaisen tuntuman siihen minkä verran lisää pitäisi vielä suunnitella / kirjata. Tarpeellista ja hyödyllistä tällä tasolla vain kun ei ole oikein vakuuttunut tekemisen otteesta muutenkaan.
- Overspecified Cases Disease. Epäjohdonmukainen pakkomielle kohdella ihmisiä automaatiorobotteina aivan liian tarkan dokumentaation myötä. Muodostuu usein sitten myös itseään toteuttavaksi ennusteeksi, suunnittelu oli jonkun muun nakki ja minä vaan kliksuttelen ja katson mitä käskettiin...

Pandemia - maailmanlaajuinen vitsaus - sinänsä ainakin minulle kolkuttelee jotain tosi tuttua...

Erinomaisia korostuksia myös siitä miksi testitapausten lukumäärään pitäisi aina suhtautua varauksella:
- eri suoritusaika muuttaa testitapausta: jos samaa asiaa katsoo kolmatta kertaa, ei varmasti tee samaa testiä, saattaa tehdä suppeampaa tai laajempaa
- testien suunnittelu on subjektiivista: vaikka sovittaisiin yhteinen muoto ja määrä, silti on vaihtelua, koska testauksen kohteet ovat erilaisia
- testaajat eivät edes noudata testitapauksia: monestihan testitapauksia kuittaillaan suoritetuksi sitten kun "tähän liittyvät vapaat tarkastelut on ehkä jo riittävässä määrin tehty". Olen joskus itsekin ihmetellyt kun viiden minuutin tarkistus kesti testaajalla kaksi viikkoa, ympärillä oli vaan aika monta asiaa jotka tähän tehtävään piti mahduttaa.
- sama testi automaation ja ihmisen suorittamana ei ole sama testi. Ihmisen päässä tapahtuu asioita joita ei voida siirtää automaatioon, mutta joskus se ei haittaa - jos se vain tiedostetaan.

Itse kirjoitan testitapauksia, periaatteella muistilistaa testattavien asioiden monipuolisuudesta. Minua vaivaa ainakin aika vahvasti tuo OCD v.2 jossa lasketaan asioita, mutta laskemisesta haen puitteita enkä absoluuttista totuutta. Ja tilanteesta riippuen tulisi laskettua vähän eri asioita, riippuen paljolti siitä mitä voi laskea puitteiden vuoksi. Testitapaukset on helpoimmasta päästä laskettavia asioita testauksessa.

Kohtuulliset odotukset testaustoimittajalle

2010-02-24T08:52:00.000-08:00

Tehtyäni takinkäännön - edelleen uskollisena testaukselle - ohjelmistotuoteliiketoiminnasta omiin räätälöitäviin tilaustyönä hankittaviin järjestelmiin, olen jäänyt monesti pohtimaan odotuksia kohtuulliselle testaukselle.

Päivän listani on asioita jotka ovat minusta kovin kohtuullisia, mutta jättävät silti miettimään:

- Testaaminen asiakasnäkökulmasta
Tuoteliiketoiminnassa oli selvää, että järjestelmätestausporukka epäonnistuu pahasti, jos hyvin tehdyt vaatimusmäärittelyt otetaan liian kirjaimellisesti, eikä edes koiteta merkittävässä määrin huomioida asiakkaan / käyttäjän hiljaisia vaatimuksia sekä kaikkea sitä teknistä nippelinappelitietoa, joka voi jäädä vaatimusten ja määrittelyjen väliin. Räätälöitävien järjestelmien peruselementti tuntuisi olevan "vaatimusmäärittely" joka kuvaa tilatun järjestelmän, jota tarkennetaan ja jonka rivien väliin jääneet yksityiskohdat ovat aina muutospyyntöjä. Ja eivät löydy toimittajan testauksissa. Niinpä asiakkaan testaajien ja toimittajan testaajien välillä on kuilu, joka korostuu kahdenlaisessa hyväksymistestauksessa: on aivan eri asia suorittaa sopimushyväksymistestausta kuin tuotantoonhyväksymistestausta - valitettavasti.

- Näkyvyys ja raportointi projektiin testauksen kautta
Tuoteliiketoiminnassa tuntui varsin selkeältä katsoa tehtävää testausta kokonaisuutena mittarein. Työmäärän kulumisen lisäksi kiinnosti testauksella saatu lisäarvo, niin kattavuuden kuin tulostenkin osalta. Räätälöityjen maailmassa en pidä itsestään selvänä että testauksesta saisi mitään muuta raporttia kuin että budjetoidut tunnit nyt tuli käytettyä. Aiemmassa elämässä tästä minulla onkin ollut tosi ikäviä kokemuksia, ja toivon että ne kokemukset eivät päätyisi värittämään tulevaisuutta toistuvin kaavoin.

- Mallipohjan täyttäminen ajatuksella
Kun testaussuunnitelmassa pitää miettiä mallipohjan ohjauksella jotain, sitä jotenkin ajattelisi ja kuvittelisi että viime kädessä sisällöllä on merkitystä. Muoto on tärkeä kun luetaan rutiininomaisesti toistuvia suunnitelmia ja halutaan katsoa vastaavat teemat vastaavassa järjestyksessä, mutta silloinkin hyvän ja heikon suunnitelman erottaa ajattelu ja asioiden huomioiminen eikä vaan vakioliturgian kirjaaminen.

- Riskienhallinta - testauksen edellytykset voivat olla projektin tuho
Tuoteliiketoiminnan jälkeen on vaikeaa myös nähdä syitä siihen että testauksen on arvostussyistä oltava oma organisaationosansa tai että testaus pitää ehdottomasti projektoida omana kokonaisuutenaan, että saadaan kertoa realistista tilannetta kokeilluista ja ei-toimivista asioista. Minua ei henkilökohtaisesti yhtään lohduta että olin oikeassa kun sanoin että testaus voi voi tapahtua kahdessa viikossa jos testausympäristö ei toimi, jos siinä vaiheessa projekti on myöhässä eikä ole tullut edes ehdotettua vaihtoehtoista jonkinasteista lisäkustannusta toipumissuunnitelmaksi niille keskeisimmille riskeille.

Listan viimeistä pidän jo vähän edistyneempänä kamana, mutta muita ihan peruskaurana. Saas nähdä miten mieli vielä muuttuu...

Havainnot, virheet ja vaatimukset

2010-01-18T11:00:00.000-08:00

En ole koskaan välittänyt mitenkään erityisesti ISEB/ISTQB:n terminologiasta, joka jaottelultaan on sinänsä selkiyttävä:
- error (virhe) on jotain mitä ihminen tekee.
- fault/defect (vika) on jotain mitä syntyy ohjelmistoon ihmisten tekemisten seurauksena
- failure (häiriö) on se mitä testaaja näkee kun ohjelmisto ei toimi

Tästä on päästy aina ihaniin keskusteluihin: virhetietokannat ovatkin itse asiassa häiriötietokantoja.

Olen tykännyt vetää mutkat suoriksi suomen kielellä, koska minusta tuo erottelu ja yritys täsmälliseen kielenkäyttöön ei ole koskaan taipunut suuhuni käytännön tasolla. On virheitä jotka ihmiset tekevät, on virheitä joita ohjelmistossa on ja virheitä joita näkyy ohjelmistoja käytettäessä.

Lempimääritelmäni testaajan kirjaamille havainnolle tulee kirjasta Lessons Learned in Software Testing: "Bug = anything that might bug a user". Korvaan sanan user = käyttäjä kuitenkin sanalla stakeholder = sidosryhmä. Testaajana lähtökohtaisesti minua ei oikeastaan ensisijaisesti kiinnosta että onko havaintoni virhe ohjelmistossa, virhe määrittelyissä vai muuten vaan keskeiseltä tuntuva parannusehdotus. Toki usein projekteissa seuraavana pohdiskeluna lajittelen havaintoni - periaatteena siis kuka mielestäni maksaa korjauksen. Ja kiitän onneani silloin kun sillä ei ole väliä, niinkuin tuoteliiketoiminnassa usein on ja asiakas-toimittajasuhteissa juuri koskaan ei ole.

Lähdin tätä päivän pohdintaa kuitenkin kirjoittamaan ajatuksenani virheen (vapaasti määritellen) ja vaatimuksen ero. Kuuntelin Elisabeth Hendricksonin esitystä XP-testauksesta ja ihastuin yhteen hänen pointeistaan. Hän kertoi kokemuksestaan ja oivalluksestaan että toteuttajien kanssa rinta rinnan työskennellessään oli tajunnut, että monet asiat joita hän testaajana tuo esiin palautteena ovat itse asiassa toteuttajan näkökulmasta uusia vaatimuksia. Toteuttaja ei ehkä koskaan ollut kuullut / ajatellut vaatimusta että cross-site scripting -hyökkäys ei pitäisi olla sallittua.

Toimin nyt lähellä liiketoimintaa ja asiakasta. Henkisesti ainakin toistaiseksi vastustan ajatusta että vaatimukset pitäisi tilaajan toimesta kertoa äärimmäisellä yksityiskohtien tasolla ja korostaa jokaista yksityiskohtaa: "kyllä, me tosiaan sammutamme tietokoneet käskystä viikonlopuksi" ja "ei, emme sammuta tietokoneitamme joka työpäivän päätteeksi ja joskus emme haluaisi sammuttaa niitä kuukausiin".

On vaatimuksia ja vaatimuksia. Osa ohjelmistovaatimuksista voi ja pitää mielestäni kohtuudella tulla tekijäporukalta. Ketterien menetelmien osana on oivallettu että testaaja, tutkivaa testausta hyödyntäen, pystyy työstämään tälläisiä tekijäporukan tasoisia vaatimuksia yhteentoimivuudesta, pitkistä ketjuista ja erilaisista oleellisista tilanteista. Tämä tieto ei kuitenkaan ole testaajan salatiedettä, vaan koko tiimin opiskelusisältöä.

Muistiinpano itselle: pitäisi taas tarkastella mihin vaatimusten hallinnan kirjallisuus nykyään ehdottaa tuon rajan menevän. Jo vuosia sitten tiedettiin ettei vaatimusdokumentaatioon saa kirjattua lähellekään kaikkea.

Ihanan latautuneita sanoja. Jatkan siis havaintojen tekemistä.

Enkelin kärsivällisyys ja elefantin muisti

2010-01-15T12:35:00.000-08:00

Kun tekee testaushommia ketjutettujen järjestelmien kanssa, tulee erityisen vahvasti sellainen fiilis että oma kärsivällisyys ja kapasiteetti ei meinaa riittää asioiden käsittelyyn ja läpivientiin.

Tässä testausmaailmassa ongelman löytäminen ei ole haaste. Ongelmien välissä luoviminen pidemmän päälle niin että löytää niistä merkittävän osan kun vanhoja ei tule korjattua on haaste. Ja ongelmista viestiminen on haaste.

Ensin pääsee yleensä keskustelemaan siitä että onko tehty havainto ongelmasta yleensäkään ongelma, vai voisiko jotenkin jo ihan käyttäjänä / testaajana tehdä jotain toisin - "eihän kukaan tee noin, ei ainakaan pitäisi". Sitten keskustelu jatkuu siitä onko havainto ongelmasta virhe suhteessa määrittelyyn vaiko määrittelymuutos, ja miten nämä määritellään. Lopulta vielä saatetaan ehdottaa että ketjussa korjaus pitäisi ollakin jossain ihan muualla kuin missä itse sitä kuvittelisi intuitiivisesti tarvittavan.

Tuntuu että testauksen tekeminen katoaa, kun testaajalta vaaditaan - otsikon mukaisesti - enkelin kärsivällisyys ja elefantin muisti.

Ketterien menetelmien korostuneita hyviä puolia on stop-and-fix mentaliteetti ja laatuvelan välttäminen. Valitettavasti vaan juuri tämä osa on yksi niitä vaikeammasta päästä olevia toteutettavia osia ketterään tekemiseen.

Parasta ennen päivämäärät testeillä

2010-01-08T13:19:00.000-08:00

Projektipäällikkö on testauspäällikön ystävä. Onneksi näin välillä, valitettavasti ei vain aina. Aihetta pureskellessani erästä esitystä varten jäin miettimään erilaisia ongelmallisia suhteita projektipäälliköihin testauspäällikkönä toimiessani, ja olemaan hymyillen kiitollinen siitä hyvästä mitä joskus osuu kohdalle.

Ongelmalliset suhteet keskittyivät yleisesti ymmärryksen ja viestinnän ongelmiin. Jos itse on kovasti testaukseen ihastunut ja toisen osapuolen mielestä se on välttämätön paha ja oikeastaan sellaisenakin aika hyödytön, saattaa päätyä painokkaisiinkin sanakäänteisiin.

Eräs kohdalleni osunut varsin yleinen viestinnän ongelma projektipäälliköiden kanssa on koittaa selittää että testin tulokset eivät pysy vakiona. Erityisen tuskaisaksi tämä minulla on muodostunut ympäristöissä joissa on vahvasti mukana kaupallinen testauksen hallinnan työkalu, ja projektipäällikkö on "aseistettu" testauksen mittarein. Voi sitä projektipäällikköparkaa, joka koittaa tulkita edes kevyesti iteratiivisessa projektissa suoraan mittarista että onkos nyt kaikki testit suoritettu kertaalleen, kun minä mokoma omassa roolissani menen ja tyhjennän koko listan säännöllisin väliajoin.

Tästä pohdinnasta mieleeni muistui keskustelu erään kolleegan kanssa muutamia vuosia sitten. Hänellä oli ajatus parasta ennen päivämäärien käytöstä prosessidokumentaatiossa. Idea kaikessa yksinkertaisuudessaan oli että sen sijaan että prosessikuvaukseen pitäisi kirjoittaa päivä jolloin se on luotu, pitäisi viestinnällisistä syistä sanoa että kun se on ollut riittävän kauan olemassa, siihen pitäisi suhtautua vähän samoin kuin vanhentuneeseen maitopurkkiin.

Parasta ennen päivämäärät voisivat toimia testitapauksillakin mainiosti. Olen koittanut peukkulaaturaportoinnin yhteydessä harrastaa kolmatta peukkua kuvaamaan muutoksen määrää, eli tahtia jolla varaan oikeuden muuttaa mieltäni laadusta. Ajatusta vaatii minulta vielä hauduttelua, mutta tuntumaksi ajattelusta jäi että jokusen projektipäällikön kanssa olisi ollut yhteiselo helpompaa jos tälläisen konseptin olisi heti projektin alusta lanseerannut. Testien tulokset happanevat ja se kuinka nopeasti riippuu ympäristötekijöistä. Pitääkö ne sitten korvata tuoreemmilla onkin kokonaan toinen kysymys...

Pohdin projektipäälliköitä, mittareita ja ikuista viestinnän vaikeutta, kun muistiini palautui keskustelu muutaman vuoden takaa erään kolleegan kanssa parasta ennen päivämääristä ohjelmistoprosessidokumentaatiossa.

Sanominen, lukeminen ja kuuleminen - viestinnän kaksisuuntaisuus

2009-11-09T08:32:00.000-08:00

Kävin keskustelua kursseista, opetustavoista ja opetussisällöistä osana työpajamme jälkipyykkiä. Keskustelu oli varsin lyhyttä ja lähtökohdiltaan varsin erimielistä. Toisaalta tavoitteena tuskin onkaan saavuttaa yhtenäistä näkökulmaa.

Olen kritisoinut taustalla erään kurssitoimittajan ketterän testauksen kurssimateriaalia. Julkaisen lähiaikoina kritiikkini tarkasteltavaksi, ja vastaavasti minulla on käynnissä oma analyysi omien materiaalieni parantamiseksi että saisin pois osan omista vähintään yhtä räikeistä virheistäni.

Voisin varmaan hoitaa palautteen antamisen helpommin omaksuttavassa muodossa, mutta uskon että ihmiset huomaavat johdattelun. Jos on sanottavaa, sen voisi sanoa, ja jos toinen osapuoli on tuttu, asian voisi ottaa asiana eikä henkilökohtaisena.

Olen kiitollinen saamastani lyhyestä palautteesta oman opetustyylini osalta: minulle on jonkin kuulijajoukon osalta muodostunut maine että minulle on olemassa vain yksi tapa tehdä asioita, esim. ketterässä testauksessa.

Jäin miettimään tätä, ja totesin parannettavaa. Minun on entisestään tarpeen korostaa materiaalieni case-pohjaisuutta. En usko prosesseihin ja ohjeisiin, vaan esimerkkeihin ja ristiriitaisuuksiin niissä. Kuvittelen puhuessani sanovani että minun kokemissani tilanteissa näin, ja olen jopa toistuvasti muuttanut materiaaliani ketterän testauksen suhteen erottaakseni "näin sanotaan yleisissä ohjeissa" ja "tälläisessa maailmassa minä olen kokenut tälläista".

Esitystilanteessa sanominen ei ole sama kuin kuuleminen. Tarkoitukset ja merkitykset värittyvät puolin ja toisin aina viestintätilanteessa. Erityisen keskeisten ja vaikeiden asioiden kanssa dialogiin on varattava aikaa ja tukea. Sama pätee lukemisen suhteen: saatan tulkita liikaa esim. siihen että kalvolla otsikolla Scrum kerrotaan olevan kolme backlogia: product, sprint ja test. Ehkä siinä tosiaan tarkoitetaan että jos testaus on erillinen tiimi, heillä voi olla oma sprint backloginsa. Teksti ei kerro.

Kaikenlainen viestintä on kaksisuuntaista, paitsi jos tyydytään siihen että todetaan erimielisyys ilmaistun muodon kanssa. Itse tavoittelen muutosta parempaan, joka viime kädessä vaatii dialogia.

Kun luette kirjoittamaani tai olette eri mieltä sanomani kanssa, antakaa minulle tilaisuus muuttaa mieltäni tai selittää mitä itse asiassa tarkoitan.

Niin tai näin, taustalla tässä pohdinnassa on perusolettama omista kokemuksistani: ketterässä kehityksessä testauksella voidaan saada aikaan jotain hyvää, mutta toisaalta sen perinteisillä muodoilla voidaan syödä merkittävästi hyötyjä kokonaisuudelta.

Ketterän testauksen työpaja, tuoreita ajatuksia

2009-11-09T08:18:00.000-08:00

Tänään oli ketterän testauksen työpaja, jossa edustettuna varsin monenlaista ketterän kehityksen, testauksen ja perinteisen testauksen osaamista. Porukassa ei kukaan ollut täydellinen juniori kaikkien suhteen, mutta matkaa yhteiseen ymmärrykseen on aika paljon.

Minulle korostui keskusteluissa että joukosta löytyi kolmenlaista "ketterää kehitystä ja testausta":
- "ketteryys koska niin päätettiin"
- "ketteryys koettuna, mutta puolimatkassa"
- "ketteryys koettuna, aika pitkällä"

Joukostamme löytyi jokunen joka katseli organisaationsa ketterän kehityksen pyrkimyksiä vielä isona kokoelmana haasteita, joka tuntui pitkälti estävältä. Oltiin huolissaan laadusta joka pitää selvittää vasta lopussa (ei kovin ketterää), dokumentoinnin puutteesta tässä tilanteessa, testauksen mukanaolosta ja mahdollisuuksista yleensäkin. Kokonaisuus yksittäisen tiimin ulkopuolelta kuulosti lähinnä vesiputoukselta, jossa jokainen vaihe oli muotoiltu scrum-pakettiin. Yleisesti nämä olivat erilaisia Scrummerfall ja ScrumBut -toteutuksia.

Toinen korostunut joukko oli niitä joilla ei ole laajamittaista automatisoitua testausta eikä varsinkaan hyväksymistestiohjattua kehitystapaa, mutta joiden osalta kuitenkin kokemus oli merkittävän, ja hyödyllisen eron omaaminen perinteiseen kehitykseen ja testaukseen. Laatuvastuu on tiimeillä, ja tiimit ovat ehkä jossain komponenttitiimin ja ominaisuustiimin puolessa välissä.

Kolmas korostunut joukko olivat nk. aidot agilistit. Korostuneesti minulle jäi vaikutelma että tässä porukassa oli varsin vähän pitkään testausta - manuaalista sellaista - tehneitä ihmisiä, joskin kohtuullisen pitkään mukana olleita oli. Tämän porukan testausedustusto oli järjestäin ohjelmointitaitoisia.

Jään hauduttelemaan ajatuksiani, mutta pidin erityisen yllättävänä omaa reaktiotani siihen että testaaja ei olisi sovellusalueen osaaja. Toki, asiakas-toimittaja-tilanteissa tulee vastaan minullekin paljon tilanteita, joissa en tunne sovellusaluetta. Testaajana minulla, ainakin omasta mielestäni, keskeisenä taitona on oppia nopeasti vähän kerrallaan ja sitä kautta vaikka en koskaan varmasti muotoudu esim. asiakashallintasovellusten supersovellusalueosaajaksi, kohtuullinen osaaja ja tehokas testaaja voin olla.

Pitäisi varmaan työstää ajatuksella niitä testauksellisia osaamisia, mitä Microsoft-kirja jota juuri luin kuvasti tittelillä "tester dna".

Ja käytäntöjen osalta, tuo kolmijaottelu voisi olla varsin hyödyllinen pohja koulutusmateriaaleissani. Siinäkin on vielä paljon vaihtelua, mutta voisi edes vähän saada otteen että missä skaalalla oikein mennään.

Se pieni ero: testaus ja laatutietoon reagointi

2009-10-23T11:24:00.000-07:00

Päivitin ulkoasun ja sisällön osalta websivujani http://www.testauskirja.com/. Laitoin tietoa päivityksistä jonkinlaiselle kohderyhmälle, ja ensimmäisenä päivänä sain postilla viestin:

"Sivuilla eivät ääkköset näy oikein... olisikohan pitänyt testata / testauttaa jossain ennen julkaisemista..."

Testaajana viesti oli minusta äärimmäisen inspiroiva. Olen kuullut vastaavan kommentin lukemattomia kertoja ohjelmistoprojekteissa, ja lähestulkoon aina pitänyt sitä jonkinasteisen testauksen ymmärtämättömyyden osoituksena. Ymmärtämättömyyttä voi kuitenkin aina koittaa korjata.

Itse ajattelen jotakuinkin näin:

Testaus / testaamattomuus on aivan eri asia kuin laatutietoon reagointi
Testauksella löydetään virheitä. Testaamattomuudella voidaan jäädä ilman laatutietoa. Testauksen osalta mikään ei suoraan lupaa, että tietoon virheestä reagoidaan "toivotusti" korjauksella. Tietoon voidaan reagoida myös päättämällä elää virheen kanssa - pidempään tai lyhyemmän aikaa.

Korjauspäätöksissä pitää miettiä kustannusta suhteessa hyötyihin - kokonaisuutena
Testaajana pitäisin kovasti moitteettomasta laadusta, mutta olen oppinut olemaan ylpeä tunnetusta laadusta. Suorien kustannusten lisäksi pitää miettiä vaihtoehtoiskustannukset: mitä muuta, mahdollisesti tärkeämpää, jää saavuttamatta kun aika päätetään kiinnittää tähän. Virheen korjaaminen on aikaa pois joltain muulta. Uuden palvelun lisäarvo alkaa toteutua vasta kun se on käyttäjillä.

Korjauspäätöksien virheet ovat yleisempiä kuin testaamattomuus
Tiesin ennestään että sivujen osalta skandit eivät toimi tietyillä selaimien ja asetusten yhdistelmällä. Voin piiloutua sen taakse että olen itse asiassa laiska ja surkea kehittäjä, jopa websivuille, ja en osannut tehokkaasti arpoa oikeaa merkistökoodia sivuilleni niin että merkit näkyisivät kaikilla oikein. Voin myös piiloutua sen taakse että aivan sama merkistö-ongelma on ollut vuosikausia testausOSY:n sivuilla, koska nekin minä olen laiskana kehittäjänä tehnyt.
Sen sijaan että piiloutuisin, ottaisin mieluummin ajattelutavaksi sen että tein päätöksen korjaamattomuudesta. Päätös voi olla väärä, mutta päätös kuitenkin.
Sen sijaan että pohditaan että olisiko pitänyt testata, voidaan puida teinkö oikean päätöksen asiakkaideni palvelemisen kannalta priorisoidessani korjauksen ulos "julkaisusta".

Laatupalautteeseen reagointi
Laatupalautteen saaminen (virheraportit) on itse asiassa kivaa. Se käynnistää pohdinnan siitä että olisiko jotain opittavaa, ja jos olisi, mitä.
Testausopeista (tai markkinoinnin opeista) voisi kerätä sen että vain joka kymmenes tyytymätön valittaa. Tämäkin tosin taitaa päteä vain sovelluksiin/palveluihin joilla on merkitystä - ja voisin kyseenalaistaa minun websiteni merkityksen käyttäjäkunnalle valituskynnyksen osalta. Voisin myös ajatella, että ongelma ei ole joko yleinen tai niin häiritsevä että olisi muuttanut asioita minun kannaltani, koska mittareita (näen sivuittain osumien määrän) näyttäisi siltä että aika moni on jaksanut ainakin klikkailla useampia sivuja auki. Testaajana kuitenkin ehkä olettaisi, että ihmiset eivät vaan valita...

Aidosti mielenkiintoinen kysymys onkin: vaikuttaako skandien rikkinäisyys / sivujeni rumuus siihen että joku ei enää uskoisi että osaan testata ja opettaa testausta, koska en osaa korjata?

Kuinkas noiden isojen julkisten epäonnistumisten kanssa saisi kirjoittelijat tajuamaan että kysymys ei ole siitä että olisi pitänyt testata / testauttaa, vaan että olisi pitänyt korjata / korjauttaa. Ja sitä ennen, päättää oikein korjaustarpeen tärkeydestä.

Virheetön järjestelmä tuotannossa

2009-10-11T11:00:00.000-07:00

Järjestelen parhaillaan ketterän testauksen työpajaa marraskuun alkuun, ja osallistujia läpi käydessäni koin monta vau-tunnetta katsellessani millaista porukkaa Suomesta löytyykään. Sen sijaan yksi erityinen lause jossain ilmoittautumisien perusteissa pisti silmään: jollakulla oli kokemuksia useista peräkkäisistä järjestelmäversioista jotka olivat virheettömiä tuotannossa.

Olen vuosien varrella ollut jokusessa projektissa mukana vaihtelevissa rooleissa, ja joudun tunnustamaan että minun kohdalleni tuollaista tilannetta ei ole osunut. Varsin vähävirheisiä järjestelmiä tuotantoon on viety, mutta virheetön - ei todellakaan. Ketterien menetelmien mukanaan tuoma stop-and-fix -periaate auttaa todella paljon laadun kanssa, mutta ainakin minun kokemuksissani vielä varsin usein tulee kaksi virheraporttia, joista vain toisen voi korjata kun suurten käyttäjämäärien ja vaihtelevien profiilien kanssa ihmiset eivät vain koe laatua ja virheettömyyttä samalla tapaa.

Asiaa hetken hauduteltuani jään odottamaan innolla määritelmää virheettömyydelle. Mieleeni tuli nimittäin montakin projektia, jossa virhe määritellään varsin suppeasti suhteessa tarkoitettuun toiminnallisuuteen, ja yleensä vielä dokumentaatioon. Sitä ei ketterän projektin osalta määritelmäksi nopeasti leimaisi.

Järjestelmiä, joista ei ole löytynyt yhtään tuotantokorjaustarvetta ennen ympäristön muuttumista on kohdalle kyllä tullut. Nekin tapaukset ovat kyllä kaukana virheettömistä.

Miten testaus kehittyy?

2009-10-10T12:35:00.000-07:00

Olen viettänyt iltaa lukien arvostamieni testausgurujen blogeja, pyrkien päivittämään tietojani siitä mitä maailmassa oikeastaan tapahtuukaan. Erityisen inspiraation pohdiskelulle löysin jälleen James Bachin blogista.

Olen viime aikoina kokenut jonkinasteista epämukavuutta lukiessani Jamesin kirjoituksia. James on pitkään ollut yksi ehdottomista testausidoleistani, ehdottoman taitava testaaja, joka myös kuvailee tekemisiään ja antaa sitä kautta muille mahdollisuuden ottaa valitsemiaan oppeja. Kokemani epämukavuus johti siihen että lähes raukkamaisesti päätin kirjoittaa suomeksi, kunnes uskallan asetella sanani niin etten päädy väärään keskusteluun.

James Bachin blogin viimeisin kirjoitus käsitteli James Whittakerin uusinta kirjaa, jota jokunen varsin merkittävä testausihminen, James Bach mukaanlukien, on pitänyt jonkinasteisena huijauksena. Varsinaista otsikon perusteella odotettavaa asiaa koettiin jossain arvostelussa olevan sivumäärällisesti liian vähän, ja viittausten puute tutkivan testauksen keskeisiin hahmoihin ei myöskään saanut suitsutusta. Ilmeisesti lisäksi koettiin että koko termiä käytettiin väärin.

Olen viime aikoina lukenut James Whittakerin kirjaa, ja edes luettuani toisten gurujen kommentteja, ei mielipiteeni kirjasta muuttunut. Minua ei haitannut että varsinainen sisältö oli ehkä lyhyessä osassa kirjaa, koska muukin sisältö oli minulle oleellista. Olen kahlannut läpi puolet, ja pitänyt siitä mitä olen lukenut. Olen lukiessa jäsentänyt omia ajatuksiani ja saanut uusia ideoita - myös rivien välistä lukien.

Palatakseni kirjoitukseni otsikkoon: miten testaus kehittyy? Jäin pohtimaan sitä että jos tutkivan testauksen jäsentämiseen liittyy pelko siitä että päätyy melko kovan kritiikin kohteeksi, uskaltaako sitä oikeasti asioita yrittää viedä eteenpäin? Kirjoittelin yhdellä listalla jokunen viikko takaperin tutkivan testauksen hallinnoinnin ajatuskehikostani, jonka huomasin olevan erilainen kuin sessiopohjainen testauksen hallinta, vaikka paljon samaa onkin. En vielä säikähtänyt, mutta muistissa on tuoreesti että kun keskustelun avaa, siinä saa samalla sitoutua mahdollisesti aikamoiseen pyöritykseen ja selittelyyn. Ehkä kyse on osittain siitä että englanti ei ole äidinkieleni, mutta ennen kaikkea kuitenkin kirjallisen viestinnän haastavuudesta.

Jos keskustelu käy liian kuumana ja ilmaisut vahvoina, aika iso osa ihmisistä vieraantuu keskustelusta. Aikaa ei vain ole riittävästi, ja oma luottamus taitoihin ja tietoihin horjuu, kokemuksista huolimatta. Auttaakohan tämä uudenoloinen ilmapiiri testausta kehittymään? Nakuttava tuntuma jossain vihjailee, että kohta on valittava gurunsa että ei saa aikaan keskusteluissa vahvoja torjumisreaktioita puolin ja toisin.

Vaatimusten palvonta ja testauksen ohjaus

2009-09-29T04:07:00.000-07:00

Olen viettänyt lähiaikoina aikaa perinteisen kehityksen, joskin inkrementaalisuudella maustetun, parissa. Teemat ovat hieman erilaisia kuin ketterän kehityksen ja testauksen osalta, ja ajattelin nyt lyhyesti tarttua yhteen lempiteemoistani: vaatimusten keskeiseen rooliin.

Perinteisissä projekteissa on varsin suuri kunnioitus vaatimuksia ja vaatimusmäärittelyjä kohtaan. Porukoissa nyökytellään, kun asiakas-toimittajasuhteessa toimittajalta tulee kohtuullisen kokoisia hintalappuja muutoksille, maustettuna kommentein "ymmärtämättömyydestä sakotetaan". Odotukset tilaajan taidoille määritellä asiat oikein ovat melkoiset, ja sitä myös muutoshallinnan perusteena on hyvä käyttää.

Vaatimuksia kunnioitetaan jopa siinä määrin että käytän siitä sanaa palvonta. Vaatimusten kanssa vietetään mahdollisesti vuosia ennen kuin mitään toteutetaan. Vaatimusdokumentit muodostuvat argumentoinnin aseiksi, eivätkä työkaluiksi tekemiselle.

Viimeisin inspiraation lähde tälle kirjoitelmalle oli oletus että "vaatimuksia vastenhan niitä testitapauksia on suunniteltava, ei sinne mitään muuta saa lähteä soveltamaan".

Minusta vaatimustenpalvonta on yksi yleisistä tehottoman ja heikkotuloksisen testauksen piirteistä. Vaatimuksia sopii palvoa toteuttajan testeissä, nehän kertovat asiat jotka on tarpeen vahvistaa. Testaajan näkökulmasta isossa osassa on etsiä asioita jotka jäävät vaatimusten väliin, ovat moniselitteisiä mahdollisesta hyvästä yrityksestä huolimatta.

Jos (kun) projektit lähtevät vaatimusten kirjaamiseen "yksiselitteisesti", saadaan aikaan uskomaton dokumentaatiomäärä, johon helposti haudataan merkittävääkin tietoa. Ei tämä silti tarkoita että mitään ei kirjata, mutta palvontaan viittaavat elementit ovat yleensä ikäviä.

Vaatimuksia vasten testisuunnittelu on eri asia kuin vaatimuksia hyödyntävä testisuunnittelu. Näkisin jälkimmäisen toivottuna tilana, jossa kirjatut vaatimukset asettavat rajoja sille mitä kohtuullisesti voidaan pitää "virheenä". Testaus voi ja toivottavasti löytää myös niitä "muutospyyntöjä" joiden puutteen vuoksi järjestelmät eivät käytännössä toimi. Rajaus näiden kahden välillä on varsinaista taiteilua. Viime kädessä kysymys tuntuu kuitenkin olevan rahasta: kenelle, keneltä ja kuinka paljon?

Testauksen joustavuus ketterään kehitykseen

2009-05-19T06:41:00.000-07:00

Ajatusten jäsentely ajan kanssa johtaa minulla aina siihen että "testaan" omia tuotoksiani eli kurssimateriaaleja ja laitan niitä uusiksi isommalla kädellä. Nyt ajattelun kohteena on ollut ketterän testauksen kurssi, josta on taas versio IIR:n kanssa ensi viikolla. Menossa versio 10 materiaaleistani - aika vähän jäljellä perusideaa lukuunottamatta vaikka alkuperäinenkin oli vähintään kohtuullinen paketti.

Eräs asia jota olen erityisesti tässä pohtinut on testauksen jostavuus, jota tarvitaan ketterän kehityksen mukana elämiseksi. Tähän pohdintaan minua inspiroi erityisesti eräs keskustelu (perinteiseen) hyväksymistestaukseen liittyen kun projektit tehdään "ketterin menetelmin".

Perinteisesti testauksen joustavuus tehdään jotakuinkin näin:

suunnitelmia kokonaisuudelle ja yksityiskohdille laatiessa kaikki priorisoidaan
suunnitelmiin rakennetaan mahdollisimman iso puskuri yllätyksille korostamalla testauskierroksia, korjaustarvetta ja regressiotestausta - käytännössä kuitenkin leikataan yleensä osa kokonaistoiveesta pois kun "ei niin paljon voi kuitenkaan testaukseen aikaa / työtä laittaa"
joustotarpeen kohdalle sattuessa tiputetaan alemman prioriteetin asiat pois - jos kyetään. Monesti on käynyt niinkin että ne on saatu tehtyä esteiden vallitessa ja ne tärkeät jutut vielä odottaa tekemistään
kun tiputtelu ei riitä, heitetään suunnitelma nurkkaan ja tehdään uusi, jotta saadaan aikaan parasta työtä käytettävissä olevien rajoitteiden puitteissa. Uusi suunnitelma voi olla "tehdään nyt vaan testausta kunnes on pakko lopettaa".
keskitytään neuvottelemaan minimikorjauksista eli lasketaan laatua alimman mahdollisen hyväksyttävän laadun rajalle ja keskitytään siihen että kompromissi on edes jossain määrin tiedostettu

Ketterissä menetelmissä on varsin toisenlainen tapa ajatella testauksen joustotarvetta. Osittain ajattelumallissa tuntuu että ei vaan jousteta, kun lukee erilaisia keskusteluja valmiin määritelmästä (definition of done) - ihan kuin testaus olisi aina sama juttu jokaisen tuotteen tehtävälistan alkion osalta. Käytännössä kuitenkin joustavuutta testauksessa tarvitaan aina.

Tein oman alustavan listani esimerkeistä joissa huomaan että jouduttiin opettelemaan joustamaan monipuolisemmin testauskäytännöin jo ennen kuin ketterät menetelmät tulivat käyttöön.

Testauksen ajurina lisäarvo, ei testitapauslista
Suhtautuminen muutoksiin - saako virheitä korjata?
Tiivis yhteistyö toteuttajien ja testaajien kesken
Testauksen kuuleminen arvokkaana tiedonlähteenä
Erikoistumisen keventäminen - komponenttitestaajasta sovellustestaajaksi
Jatkuva ohjelmistotoiimitus asiakkaille koekäyttöön palautteen saamiseksi testauksen laadusta
Säännöllinen, usein tapahtuva integrointi
Vaatimuksista haetaan tukea, ei "oikeita vastauksia"
Dokumentoinnista ennen tekemistä dokumentointiin tekemisen yhteydessä
Laadusta puhuminen ryhmäkokemuksena

Testauksen ajurina lisäarvo, ei testitapauslista
Etsimme kokeilujen kautta keinoja tehostaa testausta ja yhdessä projektissa sovittiin yhdessä sidosryhmien kanssa että vaivalla suunnitellut testitapaukset laitettaisiin projektin ajaksi sivuun.

Projekteissa yleensä käytettiin merkittävä osa ajasta olemassaolevien ominaisuuksien mukanaolemisen varmistamiseen, regressiotestauksella. Sitä oli optimoitu ja priorisoitu, ja tuloksena oli varsin järkevästi dokumentoidut testitapausmäärittelyt. Suhteessa testitapauksiin ja niiden prioriteetteihin, oli sovittu että tietyn prioriteetin testit pitää suorittaa ennen julkaisua kokonaisuudessaan ja toisen luokan osittain. Varsin perinteinen ja normaali tapa.

Sovimme kuitenkin käytännöksi projektissa sen että aikaa varattiin testaukselle saman verran suhteessa kehitykseen kuin tyypillisessä projektissa. Sen sijaan että testaajaa kannustettaisiin käymään läpi perustarkistukset, kannustus olikin virhekattavuuden maksimoimiseen. Tehtävänantona: löytäkää niin monta merkittävää virhettä kuin annetussa työmäärässä kykenette!

Tulokset löydöksille olivat merkittäviä. Virheet löytyivät sopivammassa aikataulussa suhteessa kehitykseen (jokainen päivä oli oman suunnitelmansa kohde) ja niitä löytyi enemmän.

Pieni muistutus siitä että kerta hyviä tuloksia ei tarkoita pysyviä tuloksia saatiin myös: yhden kerran puhtaan speksin tiputtamisen taktiikka toimi, kun perusidea kattavuudesta oli selkärangassa aiemman speksin käytön perusteella. Aika hoitaa muistin pyyhkimisen, joten tukirakenteita tarvitaan. Edelleen kuitenkin testejä joustavuusmielessä voi ohjata niiden tuottaman tiedon arvokkuuden perusteella.

Suhtautuminen muutoksiin - saako virheitä korjata?
Testauksessa on usein opittu varomaan ja välttelemään muutoksia. Jokainen muutos ohjelmistoon saattaa nollata siihen mennessä tehdyn testauksen perusteella saavutetun tietotason, erityisesti jos muutoksia tehdään ajattelematta kokonaisuutta.

Yleinen joustotapa, jossa muutosraadit päättävät mitkä muutokset ovat riittävän arvokkaita päästäkseen mukaan ja mitä vältetään, on joustoa riittävän laadun osalta. Se toimii mainiosti projektin loppuvaiheissa, mutta muutoksen välttäminen alusta saakka ei tunnu kovin joustavalta.

Kokeilimme ennen ketteriä menetelmiä projektissa vanhojen tunnettujen ongelmien priorisoimista mahdolliseen korjaukseen periaatteena "mihinkäs se olisi hävinnyt kun ei sitä olla ainakaan tarkoituksella korjattu". Toteuttajien ohjaus oli että korjata saa, siinä on hyvää listaa asioista joita voi toteuttaa jos on odotusaikaa. Kuitenkin toteuttajia muistutettiin myös siitä, että uusien vaatimuksien / ominaisuuksien edistäminen on tärkeintä.

Lopputuloksena saatiin korjattua satoja ongelmia ja asiakaslausunto laadusta: "betalaatu on parempaa kuin aikaisempi julkaisulaatu". Testauksen kannalta erityinen oivallus oli että varhaiset korjaukset itse asiassa helpottivat työtä, mutta meillähän olikin aivan erinomaisia toteuttajia vaikka joskus jotain yllätyksiä regressiomielessä tuleekin.

Tiivis yhteistyö toteuttajien ja testaajien kesken
Keskustelut testaajien sijoittelusta organisaatiossa vellovat yleensä suuntaan jos toiseenkin, mutta koin organisoinnista tehdyt valinnat yhtenä joustavuuden aikaansaamisen onnistumistekijänä. Kun testaajat ja toteuttajat olivat samojen henkilöesimiesten alaisia, nämä eivät voineet vahingossakaan rakentaa raja-aitoja alaistensa välille, vaan onnistumisen kriteerit olivat yhteisiä.

Pelkäsin jossain vaiheessa että tästä seuraisi testaajien siiloutuminen toisilta testaajilta, mutta itse asiassa testaajien yhteistyön saavuttaminen virtuaalitiimiajatuksin oli kertaluokkaa helpompaa kuin vastaava organisaatiossa toisin päin eli toteuttajien kanssa.

Joustavuudessa ei toki vielä ennen ketteriä menetelmiä menty niin pitkälle kuin että ehdotettaisiin että toimitaan päivittäin samoissa tiimeissä ja nähdään jakamaan tekemisiä päivittäin (aivan ihana käytäntö) tai että istuttaisiin vielä samoissa yhteisissä tiimihuoneissa niin että asioita voi tehdä koko ajan yhteistyössä niin tarvittaessa.

Testauksen kuuleminen arvokkaana tiedonlähteenä
Testauksen aseman ja arvostuksen olemassaolo auttoi paljon suuntamaan energioita parempaan ja tuloksia tuottavampaan suuntaan. Kun omaa eloaan ei tarvitse perustella joka välissä, ehtii yllättäviä asioita.

Asemaa arvokkaana tietolähteenä ei kuitenkaan saa jos ei sellainen ole. Testaus ei ole arvokas tietolähde lähtökohtaisesti. Muistin tämän erityisen selkeästi viimeaikojen kokemusten perusteella, jossa tuotettiin paljon dokumentaatiota heikolla uudelleenkäyttöasteella (vaikka uskottiinkin että voisi niitä ehkä hyödyntää myöhemminkin) ja vähän ongelmia korjattavaksi / käsiteltäväksi.

Arvokasta tietoa voi tuottaa varsin monella foorumilla. Erityisen tärkeäksi koin asiallisen toiminnan projektin ohjauksesta päättävässä ohjausryhmässä ja oikean julkaisulaadun - korkealla tietotasolla - tarjoamisen päätöksentekijöille.

Eikä fiksu testausta ymmärtävä "sponsori" korkealla organisaatiossa tee lainkaan pahaa toimintaympäristölle. Sellaisen olemassaoloa ei välttämättä edes tiedosta ennen kuin sen menettää...

Jatkuva ohjelmistotoimitus asiakkaille koekäyttöön palautteen saamiseksi testauksen laadusta
Jo ennen ketterien menetelmien käyttöönottoa vastineena huoleen siitä että tiedämmekö testauksemme perusteella oikeasti laadusta vai luulemmeko vaan kehiteltiin vastineita. Loimme eräässä projektissa jatkuvan betatoimituksen konseptin, jossa ominaisuuksia ja korjauksia toimitettiin säännöllisesti ihan oikeille käyttäjillekin. Tämä kokemus oli varsin arvokas miettiessä rakenteita miten ketterien menetelmien yhteydessä voitaisiin julkaista joka inkrementin päätteeksi.

Olimme aika huolissaan laadusta suhteessa inkrementtien aikana tiukaksi toisinaan priorisoitavaan testaukseen. Jonkin kerran tuli opittua painotuksista myös kantapään kautta löytämällä sisäisesti mahdollisia asioita ulkoisesti, mutta enimmäkseen tuli opittua että aivan niin monet asiat eivät todellakaan hajoa muutosten seurauksena. Ja muutoksista puhuminen tiimissä aidolla tahdolla asioiden hyvin tekemiseen on erittäin voimallinen käytäntö vähentämään varmuuden vuoksi -testauksen määrää.

Säännöllinen, usein tapahtuva integrointi
Muistaen joitain projekteja menneisyydessä muistan hyvin kuinka muutosta välteltiin. Erityisesti osana hyväksymistestauksia uusien versioiden saaminen testaukseen oli lähestulkoon mörkö. Muistan alistumistunteen kun hyväksyttiin kerran kahdessa viikossa suunnitellun version toimittamisen sijaan kaksi kertaa viikossa uusi versio ekalla viikolla, ja aina aloitettiin alusta.

Jatkuva integrointi ketterissä menetelmissä oli minulle varsinainen mörkö. Olin juuri jotensakin onneksi oppinut toimimaan vanhojen kokemusten jälkeen projektissa jossa harrastettiin säännöllistä, useita kertoja viikossa tapahtuvaa integrointia. Näihin versioihin sai melkein tietoa mikä muuttui versioiden välillä, ja yllätyksiäkin tuli.

En oman kokemuspohjani perusteella olisi uskonut että voisin muutamaa vuotta myöhemmin uskoa että jatkuva integrointi itse asiassa helpottaa testauksen työtä. Ja että matkalla kohti sitä tahdin tiivistäminen opettaa keskeisiä asioita testauksen joustavuudesta.

Vaatimuksista haetaan tukea, ei "oikeita vastauksia"
Projekteissa oli varsin yleinen testauksen joustavuutta helpottava käytäntö vaatimuksiin suhtautumisen kanssa. Sen sijaan että vaatimuksia olisi kohdeltu "tilausmäärittelynä", tuoteliiketoimintatausta oli auttanut projekteja jo tajuamaan että oikeita vastauksia loppukäyttäjien erilaisten toiveiden ja tarpeiden kanssa ei ole, vaan asioista on hyvä keskustella ja täydentää ymmärtämystä ajoissa.

Vaatimuksista ei siis haettu "oikeita tuloksia" ja testauksen absoluuttista vastausta, vaan lähinnä tukea kattavuuden ajatteluun ja inspiraatioiden lähtökohtaa.

Dokumentoinnista ennen tekemistä dokumentointiin tekemisen yhteydessä
Testitapausten dokumentoinnissa oltiin myös omaksuttu joustavampi käytäntö projekteille. Sen sijaan että olisi oletettu että testitapausmäärittely on valmis testauksen alkaessa, silloin oletettiin olevan valmiina ensimmäinen runko - sen hetken käsitys valmistelutyön perusteella.

Dokumentoinnin osalta ajatusmaailma oli projektin loppuhetkissä sekä tulevissa projekteissa - elinkaariajattelussa.

Erikoistumisen keventäminen - komponenttitestaajasta sovellustestaajaksi
Organisoinnissa vanhastaan palkattiin aina testaaja tiettyyn tarkoitukseen, yleensä tunnistettuun aukkoon. Se tarkoitti sitä että jokaisella testaajalla oli yksilöllinen työnkuva sen komponentin tai testaustason osalta mihin oli tullut rekrytoiduksi. Vaikka ei ollut erityisesti mitään syitä olla laajentamatta suppeaksi muodostuvaa erikoistumista, jotenkin rekrykuponkien tiedot koettiin ohjaavina.

Iso joustavuuteen liittyvä oivallus oli kun usean eri toisiinsa liittyvän komponentin testaajat alettiinkin nähdä sovellustestaajina omien komponenttiensa erikoistuntemuksella, jota oli tarkoitus levittää saman sovellusalueen kolleegoille. Ja kun tätä oivallusta vielä laajennettiin ymmärtämällä sovellustestaus järjestelmätestauksen näkökulmana, saatiin vähennettyä vielä vähän lisää testauksen sisäistä erikoistumista.

Laadusta puhuminen ryhmäkokemuksena
Viimeisenä, mutta ei toki vähäisimpänä jousto-oivalluksena listasin laadusta puhumisen mittareiden lisäksi laadullisesti. Ryhmän kokemusten ja tuntemusten yhteenveto auttoi määrällisen aineiston tulkinnassa ja ohjasi projektista päättävää ohjausryhmään syvällisempiin ja järkevämpiin päätöksiin laadusta. Toki oli tarpeen muistaa, että meistä kaikille aikataulu oli laadun kokemuksen suurimpia kriteerejä, josta ei kevein perustein haluttaisi joustaa... Projektit ovat erilaisia.

Testaustaitojen hiominen automaatiota harkitessa

2009-05-11T10:54:00.000-07:00

Toistuvasti monien testaajien kanssa jutellessani huomaan omaavani jossain määrin erilaisen tavan ajatella regressiotestausta ja regressiotestauksen automatisoinnin tarvetta. Minulle ei ole itsestään selvää että pitäisi olla perusregressiotestisetti, jota ajetaan kerta toisensa jälkeen.

Asiaa pohdittuani olen päätynyt siihen, että merkittävä näkemysero on syntynyt sisäsyntyisestä tarpeestani tehdä hyvää testausta olemalla motivoitunut testaustyöhön. Jos suostuisin itselleni myöntämään että on olemassa testaustyyppi, jossa samojen askelten toistaminen ilman itselleen annettavia perusteita muutoksesta on olemassa, kokisin sen työn tekemisen lähinnä häiritsevänä. Sen sijaan ajattelen regressiotestausta älyllisesti vielä monimutkaisempana optimointihaasteena.

Jokainen rikkoutuminen ohjelmistoille tapahtuu syystä. Emme aina ymmärrä ja näe näitä syitä, mutta se ei ole syy olla yrittämättä ymmärtää ja korvata ymmärtämättömyyttä aivottomalla toistolla. Koska syy on jonkinlainen muutos, minä en koe toistavani samaa testiä, vaan etsin uutta tietoa.

Tästä ajattelumallista seuraa ainakin minulle tarve oppia ja kehittää testauksellisia taitojani, etten päädy tekemään asioita liikaa varmuuden vuoksi. Eräs loistava harjoitus minulle ainakin on ollut yrittää tunnistaa asioita joita testaan "kun ne nyt vaan pitää testata" ja alkaa seuraamaan oletuksieni todenperäisyyttä. Kaivan omia muistilokeroitani, kyselen kolleegoilta ja luen virheraporttikannasta todistusaineistoa siitä että on perusteltua tehdä juuri tämä temppu jatkuvasti. Jos en onnistu syitä löytämään, kokeilen varovasti ja tarkoituksella jättää tempun tekemättä kerran - ja seuraan mitä tapahtuu. Palaan ehkä temppuun vielä jossain vaiheessa, ajoituksen itse tarkkaan miettien. Tarkoitukseni on aktiivisesti löytää asioita joita en sitten ehkä kuitenkaan lähtisi testaamaan.

On vaikeaa oppia irti vinoumista, joihin on kasvanut. Olen itse aloittanut testaushommat lokalisointitestauksen parissa, ja vasta vuosia sen jälkeen tajusin että yksi iso oppi oli puolivahingossa syöpynyt lähes selkärankaani. Uskoin vakaasti alkuaikojen kokemusteni perusteella, että eri kieliset windows-käyttöjärjestelmät ovat merkittävässä määrin erilaisia niiden päällä toimivan ohjelmiston kannalta. Tämä usko sai minut vuosia toistamaan testejä suomen- ja englanninkielisissä käyttöjärjestelmissä ilman merkittäviä tuloksia. Oppi piti toki paikkaansa varsin suuressakin määrin alkuaikojeni softalle ja silloisille käyttöjärjestelmille, mutta testauksen onneksi maailma - ja käyttöjärjestelmien toteutustapa - muuttuu. Niilläkin tunneilla olisin voinut löytää jotain tärkeää ja merkittävää - ja löydänkin, tulevaisuudessa.

Tämä pohdinta tulee minulle usein esiin automaation kanssa. Ei ole itsestään selvää että usein käsin toistettava testi kannattaa automatisoida. Jos sillä ei ole koskaan (oletettavasti) saavutettavissa tuloksia käsin, miksi automaatio, joka on askelta ihmistä tyhmempi, tuottaisi erinomaisia tuloksia?

Automaatiolla on paikkansa. Kun se paikalleen laitetaan, sitä tarvitsee ylläpitää ja käyttää, ja sen tuloksia analysoida. Kun tekemistä on muutenkin paljon, voisi kannattaa ensin päättää / miettiä mitä jättää tekemättä. Etenkin kun kaikkea testausta / testauksen automatisointia ei tarvitse tehdä "testaajan näkökulmasta" vaan toteuttajilla on kyvykkyys itsekin löytää monia virheitä ohjelmistoistaan.

Kokeneen testaajan ja kokeneen testaajan eroista

2009-05-07T23:52:00.000-07:00

Päivän oppimispohdintojeni keskeisenä teemana on "kokeneen testaajan" erot. Testausidolini Cem Kaner sanoi jossakin rekrytointia käsittelevässä tekstissään vapaasti muotoillen että on testaajia joilla on viiden vuoden kokemus ja testaajia joilla on viisi vuoden kokemusta. Jatkoin ajatusta, että on myös ihmisiä joilla ei ole vuodenkaan kokemusta, mutta vähintään viiden vuoden positiivinen asenne, jolla saadaan aikaan saman verran tuloksia kuin sillä viiden vuoden kokemuksella.

Teema päätyi pohdintoihini kun vedin yhteen kurssipalautteet tutkivan testauksen työkurssini koeversiolta tiistailta. Annettujen arvosanojen keskiarvo kokonaisuudessaan oli 4,1/5. Joukosta löytyi yksi jolla oli muihin nähden vahvasti eriävä mielipide: 2,1/5. Kommenteista löytyi viitteitä siihen että kokenut testaaja ei tälläistä sisältöä tarvitse, itsestäänselvyyksiä, sopii lähinnä ammattikorkeakouluihin. Kuitenkin tilassa oli tämän kokeneen testaajan lisäksi 18 muuta, joista minun ymmärtääkseni 17 on kokeneita testaajia. Muut kokivat opit tärkeinä ja arvokkaina. Mistä siis syntyy tälläinen ero?

Ihmisillä on oikeus mielipiteisiinsä ja jokaisen mielipiteet ovat perusteltuja heille itselleen. Minä näen tässä itselleni loistavan tilaisuuden oppia. Vaikka oppimiseni spekuloinnin kautta olisikin täysin epätodellinen suhteessa opin aloittaneen tarkoituksiin, koen että se on minulle arvokasta.

Osa testaajista on tehnyt vuosia testausta ilman että heiltä on vaadittu itseohjautuvuutta tai sisäistä kurinalaisuutta - ulkoiset kyttäysmekanismit tehtävien suorittamiselle ovat aivan oma lukunsa; oppimista siitä mitä ja miten testataan; tai tuloksia löydettyjen virheiden eikä vain kuitatun kattavuuden kautta. Näille ihmisille tehtävät jaetaan yksityiskohtien tasolla "katso nämä testitapaukset" ja töitä seurataan ja tuetaan jatkuvasti muistutellen. Virheistä oleellisia ovat vain ne, jotka ovat poikkeamia odotetusta lopputuloksesta. Jos muut ovat oleellisia, ei se ainakaan ole minusta kiinni, voi toki korjata testiskriptin niin että sama virhe ei seuraavan kerran mene ohi. Valitettavasti vaan virheiden syntyminen on sen verran luovaa että ihan samaan kohtaan tuskin kauhean usein isketään.

Kokeneen testaajan, joka on kokenut koneenosana toimija, voi korvata automaatiolla tai vaikka intialaisella. Kokenutta testaaja joka oppii jatkuvasti ympäristöstään ei voi korvata automaatiolla - ja intialaisistakin tarvitaan sitä olemassaolevaa ajattelukykyistä osaa. Kokematon testaaja joka oppii on joka päivä päivän oppien verran parempi. Siihen meidän pitäisi minun nähdäkseni kaikkiaan testauksessa pyrkiä - koko ajan eteenpäin.

Testaamisen lopettamisen haasteet

2009-05-07T03:17:00.001-07:00

Luulin taas oppineeni / oivaltaneeni jotakin, joka on tarpeen laittaa muistiin. Kun puhutaan testauksen kattavuuden saavuttamisesta, joukosta tuntuu löytyvän toimintatavoissaan kahta ääripäätä - ja tietysti erilaisia välimuotoja:

Ne jotka luulevat että ihan vähän testausta on tarpeeksi ja lopettaminen tehdään kuvitellen että "kaikki on testattu"
Ne jotka tiedostava kuinka laaja ja monipuolinen ongelmakenttä testauksessa on ja eivät ole vielä oppineet priorisoimaan vaan koittavat jokaisen idean osalta sisällyttää vielä senkin ilman riskiperusteista perustelua saati sitten tuloksia - kunnes sovellus julkaistaan lähestulkoon käsistä repien

Henkilökohtainen tuntumani on että enemmistö kohtaamistani vielä edustaa vaihtoehtoa 1, ja siksi ehkä kokemus koekurssilla jossa "kaksi puolituntista sessiota riittää" -lausunto muuttui testaamisen ja jäsentämisen kautta "tässähän on hommia kuukaudeksi" -lausunnoksi, tuntui erityisen palkitsevalta.

Olen kuitenkin osunut aika moneen sellaiseenkin joka ei sitten millään haluaisi ohjelmistoa käsistään päästää. Pitää miettiä miten sitä taitoa opettaisi, ja toisaalta, onko olettamani siitä että se on tavallaan jatko-oppien askel ollenkaan todellinen.

Näistä löytyy vielä (ainakin) kolmas muunnelma joka vaatii erilaista lähestymistapaa oppimiseen: kaverit tiedostavat vaatimusten monipuolisuuden ja tietävät miten paljon tehtävää testauksessa olisi ja eivät osaa jättää sitä tekemättä, mutta eivät tuota tuloksia edes varsin bugisella ohjelmistolla koska eivät tunnista virheitä ilman valmista vastausta siitä mitkä asiat pitää raportoida.

Testauksen kohteista oppimismielessä

2009-05-07T03:03:00.000-07:00

Olen pohtinut viime aikoina erityisen paljon kurssitarkoituksiin soveltuvan testattavan ohjelmiston valintaa. Tutkivan testauksen työkurssilleni viimeisille kierroksille pääsi kaksi vaihtoehtoa:

TestLink: testauksen hallinnan Open Source -työkalu
FreeMind: ideakarttatyökalu

Päädyin valinnassani Freemindiin.

TestLinkin osalta minulle itselleni testatessa kävi siten, että löysin itse asiassa kohtuullisen vähän bugeja, mutta suhteessa sitäkin enemmän puuttuvia ominaisuuksia. Kuten testaushallintatyökalut yleensäkin, tämä sai minut taas lähinnä toivomaan että toimisi jollain tapaa niinkuin minä toivoisin ja tukisi paremmin tutkivaa testausta. En pitänyt tausta-ajatuksesta jonka synnytin puolivahingossa, jossa kehittelin tapoja nyt kuitenkin tehdä ne asiat tällä työkalulla kun se kerran käsillä on.

Freemindin osalta valitsin 0.9.0 RC3 -version. Ajattelin alkuun että avoimen lähdekoodin projektit ovat paremman laadun maineessa kuin perinteiset suljetut ohjelmistot, ehkä tämä olisikin erityisen vaikea kohde sen osalta että virheitä olisi vaikea löytää. Kuitenkin osoittautui että vaikka itsekin valmistellessa tuli aika monta havaintoa tehtyä, 19 testaajaa huoneessa päivän ajan löysi niitä lähestulkoon liikaa. Tässä korostui se että kun laadussa on tarpeeksi toivomisen varaa, yksityiskohdat helposti piilottavat toisia alleen, ja laatukokemuksen perustaminen järkevälle tasolle vaatii aika paljon harkintaa.

Kurssin aikana jäin edelleen pohtimaan eteenpäin hyvää testauksen kohdetta oppimis- ja opetusmielessä:

Riittävän buginen ohjelmisto saa tuntemaan että sai jotain aikaan. Toisaalta sen kanssa pääsee aivan liian helpolla.
Liian bugiton ohjelmisto korostaa sitä että testaus voi olla myös varmistumista, eikä aina ongelmien metsästystä.
Täydellinen olisi sinänsä kompromissi näiden väliltä: jotain helppoa löydettäväksi, jotta saisi itsevarmuutta uusille ja epävarmoille. Enemmistö kuitenkin vaikeaa, silti virheitä sisältävää. Tekniikoille ja ajatusmalleille tarvitsee myös purtavaa, mutta vaikeus lisää opetukseen tarvittavaa aikaa.

Olisikohan paras tapa saavuttaa tämä alkamalla kirjoitella niitä FreeMindin bugiraportteja sisään projektin tietokantoihin? Kaikkiaan minusta pohjaksi erittäin lupaava ohjelmisto, näin niinkuin testauskohdemielessä.

Testauksen hallinnan työkalutuki

2009-04-28T01:42:00.000-07:00

Olin viime viikolla HP:n käyttäjäkerhon tapaamisessa mukana panelistin ominaisuudessa ja pääsin kuulemaan esityksiä testaushallinnan työkalutuen ympärillä. Ja tietysti osallistumaan keskusteluun omalta osaltani. Minun työkalunegatiivisuuteni oli kutsujieni tiedossa - tai negatiivisuus on aika vahva ilmaus, olen vain vahvasti varovainen hyötyjen arvioinnin osalta enkä pidä "ei mitään" vastakandidaattina keskitetyn tietokannan kaupallisille välineille mahdollisia työkaluja vertaillessa.

Tilaisuus oli varsin inspiroiva monenkin asian osalta. Jaettavaksi jäi muistiin muutamia tarinoita:

1. Olen huomaamattani muuttanut mieltäni
2. Tarve täydelliselle jäljitettävyydelle testaushallinnan perusteena on lähinnä surullinen
3. Realistiset hyötyarvioinnit haastavia

Olen huomaamattani muuttanut mieltäni

Eräs osallistujista saa minun pisteeni suurimman pohdiskelun aloittamisesta kommentillaan tilaisuuden jälkipuinneissa. Puhuttuani testaushallinnan työkalutuesta osana paneelia olin tehnyt ilmeisesti jossain määrin selväksi varovaisen välttelevän asenteeni kaupallisiin testaushallinnan välineisiin. Testauksellinen kolleega muistutti minua siitä että olen puhunut samasta aiheesta varsin toisella painotuksella Conformiqilla työskentelyn aikoinani, kertoen että minulla on vahva usko siihen että ilman kaupallista testaushallinnan välinettä ei pärjää.

Rehellisyyden nimissä minun täytyy tunnustaa että en todellakaan enää muistanut mitä olen aikanaan puhunut, mutta vanhoja materiaaleja kaivelemalla pieniä muistoja palaa mieleen. Koko harjoitus muistutti siitä miksi mielellään laitan jäsennyksiäni näkyville enkä enää pelkää väärässä olemista niin etten voisi näkemyksiäni jakaa - se on loistava keino oppia jotain itsestään.

Tämä ei ole ainoa käännös mielipiteissäni. Suhteeni testitapauksiin on toinen iso tunnistamani täyskäännös. Mutta se on toisen kirjoitelman asia.

Koen että en kuitenkaan ehkä ihan täyskäännöstä ole tehnyt, vaikkakin vahvasti eri tavalla asian selvästi näen. Kokemukset F-Securella osoittivat että "väline" voi olla paljon muutakin kuin kaupallinen kantapohjainen työkalu. F-Securen kokemuksien Word-Excel -kokonaisuus oli sinänsä paljon enemmän kuin mitä olen tottunut näiltä kaupallisilta välineiltä saamaan. Keskeistä olikin prosessin ja sen dynamiikan fiksu ja yksinkertainen mukaantuominen: testiloki, joka auttaa hallinnoimaan toistotarpeeseen liittyviä päätöksiä on aivan kriittinen. Ja sen puutteellisuus on yksi suurimmista asioista joka minua kaupallisissa testauksen hallinnan välineissä häiritsee.

Tarve täydelliselle jäljitettävyydelle testaushallinnan perusteena on lähinnä surullinen

Osana paneelia keskustelimme työkalujen tarpeellisuudesta ja hyödyistä. Perustellessani sitä miksi erityisesti ketterien projektien osana koen että nykyiset testaushallinnan työkalut saattavat tuoda enemmän hidasteita kuin tehosteita, yhtenä anekdotaalisena toteamuksena työkalun hyödyllisyydestä nostettiin esiin tarina testaajasta, joka suoritti tuntien testit minuutissa: työkalu toimi keskeisenä ongelman näkyviin tuojana.

Jäin tämän maininnan osalta pohtimaan sitä että jos työkalun osalta kyttäyskulttuuri todella on yksi suuria hyötyjä, kuinka surullinen testauksen toimintaympäristö voikaan olla. Jos tämä todella olisi yksi painokkaimmista tarpeistamme testihallinnan työkaluihin, olisin erityisen surullinen testauksen puolesta.

Ketterien menetelmien tiimeissä tiimin sisäinen näkyvyys on minun kokemuksieni mukaan jo vahva keino nähdä jos joltakulta hommat lipeävät aivan ala-arvoiseen minimiin, mutta tiimi on keino auttaa toisia positiivisesti oppimaan mikä on odotettu standardi. Annettu anekdootti muistutti minua siitä että ehkä vielä meillä testauksessa voi olla kohdalla lievästi surullinen tilanne, jossa toiminnasta irrallaan oleva esimies työkalun mittareiden perusteella arvioi onnistumistamme ja yleensäkin töiden tekemistä. Taisimme kuitenkin kaikki tiedostaa että vaikka näitäkin tilanteita löytyy, se tuskin on tarkoituksenmukainen tila ylläpidettäväksi pidemmän päälle.

Realistiset hyötyarvioinnit haastavia

Esityksissä tuli esiin, kuten yleensäkin työkaluinvestoinneista puhuttaessa, hyötyjen arviointi. Yhdessä esityksessä jopa vilauteltiin kyselytyökalua, jonka avulla voi paikallistaa hyödyt ja muuttaa ne rahaksi osana investointipäätöstä. Ihanan houkutteleva ajatus, mutta varovaisuus ja negatiivisuus nostivat minulle taas päätään. Työkalut, vaikka kuinka sisältävätkin räätälöitävissä olevan prosessin, asettavat yleisesti prosessille tiettyjä reunaehtoja dokumentointiolettaman suhteen. Miten tuottavuuteen vaikuttaa dokumentointiin liittyvät kustannukset? Ovatko dokumentoidut testit todella uudelleenkäytettäviä ja niille joille ovat, ovatko ne uudelleenkäytettyinä oikeasti hyödyllisiä? Jos ne ovat hyödyllisiä, miksi ne ovat hyödyllisiä, ja olisiko muita keinoja vähentää toistotarvetta?

Minua hämmentää edelleen yleiseltä tuntuva ajatus että työkalut vain säästävät aikaa. Entäs ne ylimääräiset kliksuttelut joita jokainen testaaja joutuu tekemään kymmeniä ellei satoja päivässä saadakseen datan määrämitalliseksi? Entä testitapauksen pakottaminen annettuun mallipohjaan työkalussa, johon se ei nyt oikeastaan sovi juuri tällä tekniikalla tehtynä? Entä kiertoreitit joita joutuu kehittelemään että saa asian tehtyä niinkuin haluaisi ja tarvitsisi? Mitenkä ylläpito kun mikään työkalussa ei houkuta oppimaan (lisää dokumentointia), muuttamaan prioriteettia (taas lisää dokumentointia) ja toimimaan kokonaisuuden eduksi kun ohjelmisto muuttuu jatkuvasti - ja syystä, suuntana parempi ohjelmisto.