Regressiojumppaa

Silloin tällöin peruslaiskalle iskee tarve kuntokuurille. Eihän kroppa pysy kunnossa, jollei siitä pidä vähän huolta. Silloin saattaa löytää itsensä surffaamasta kuntokeskusten tarjontaa tai ohjeita treeniohjelman rakentamiseen itse. Yksi vaihtoehto on miettiä, mitkä osat kehosta kipeimmin kaipaavat kohennusta, ja rakentaa sitten joogaohjelma, joka parhaiten tukee juuri näiden alueiden ylläpitoa.

Hathajooga tarjoaa runsaan valikoiman erilaisia liikkeitä, joilla jokaisella on omat positiiviset vaikutuksensa. Ohjelma koostetaan keräämällä joukko liikkeitä ja laittamalla ne sopivaan järjestykseen. Suunnittelussa huomioon otettavia asioita ovat ainakin:

• Mikä on treenauksen tavoite, eli millaisia asioita on tarpeen sisällyttää treeniin.
• Mitkä liikkeet sopivat lämmittelyyn, mitkä taas vaativat lämmittelyä ennen kuin niitä voi tehdä.
• Vastaliikkeet. Monien voimakkaiden venytysten jälkeen on hyvä tehdä vastaliike, jotta keho saa optimaalisella tavalla kuormitusta.
• Flow, missä järjestyksessä liikkeiden suorittaminen tuntuu mahdollisimman luontevalta.
• Harjoitukseen kerralla käytettävissä oleva aika, sekä kuinka usein se on tarkoitus suorittaa.
• Harjoitukseen käytettävissä oleva tila.
• Henkilökohtaiset mieltymykset, eli mikä on kivaa.

Kun ohjelma sitten on rakennettu, sitä suoritetaan suunnitelman mukaisella tahdilla. Jos käy niin hyvin, että kunto pääsee kohenemaan, tai tavoitteita on jostain muusta syystä tarpeen tarkastella uudelleen, ohjelmaa kehitetään lisäämällä, poistamalla tai muokkaamalla siihen kuuluvia liikkeitä.

Prosessi on yllättävän lähellä regressiotestauksen suunnittelua. Myös siinä mietitään tavoitteet, eli mitkä ovat ne asiat, joiden toimivuus on tarpeen varmistaa. Lisäksi on tarpeen pohtia, missä vaiheissa regressiotestit suoritetaan. Ylläpitovaiheessa pitäisi olla selvää, että regressiotestikierros tehdään ennen jokaista julkaisua. Testattavan järjestelmän muuttuessa myös regressiotestien sisältöä voi joutua tarkastelemaan kriittisesti. Regressiotestaukseen sisällytettävien testien laajuuteen vaikuttaa testaukseen käytettävissä oleva aika sekä budjetti. Nämä asiat vaikuttavat myös silloin, kun regressiotestausta automatisoidaan, sillä myös automatisointi vie aikaa, ja automaattitestauksenkin tulokset on analysoitava. Jos taas testit suoritetaan käsityönä, tehtävän mielekkyyden ylläpitämisen kannalta on hyvä sisällyttää suunnitteluun myös ajatus siitä, miten siitä saisi jollain tapaa kiinnostavaa testaajalle. Tehokkuutta ja mielekkyyttä lisää myös testien järjestäminen tavalla, jolla edeltävät testitapaukset mahdollisimman luontevasti valmistelevat seuraavien testitapausten alkuehdot. Joskus voi olla tarkoituksenmukaista sisällyttää suunnitelmaan myös luodun testimateriaalin poistaminen.

Korkean tason tavoitteena joogaajalla on kehon toimintakunnon ylläpito, regressiotestaajalla taas testattavan järjestelmän toimivuuden ylläpito. Testi ei toki itsessään toimivuutta paranna, vaan se vain paljastaa ne paikat, jotka ovat ajan myötä päässeet rupsahtamaan ja kaipaavat nyt tarkempaa huomiota. Vähän niin kuin aloittelevan kuntoilijan lihaskipu paljastaa paikat, jotka ovat päässeet liian vähällä sohvaperunan elämässä.

Testaaja - koodarin vihollinen vai puolustaja?

Testaajien ja kehittäjien yhteistyö ei ole aina ihan kitkatonta.

Kun testaajan eteen tuodaan jotain valmiiksi väitettyä, jonka testaaminen on hidasta koska koko ajan löytyy raportoitavaa, on haasteellista tuoda löydöksiä esiin tavalla, jota hiukankin herkkähipiäinen kehittäjä ei kokisi osin henkilökohtaisuuksiin menevänä nipottamisena. Aikataulu- ja budjettipaineet kiristävät molempien pinnaa, samoin kaikenlaiset "tyhmät" virheet.

Erityisesti kun kyse on valmisohjelmistoon tehtävistä muutoksista, vastaan voi myös tulla vanhaan koodiin liittyviä ongelmia, joiden kiertämisen haasteellisuus siirtää helposti keskustelun korjaustavan etsinnästä bugin merkityksen vähäisyyden perusteluun. Näissä tilanteissa osapuolten voi olla vaikea nähdä tekevänsä yhteistyötä, ennemminkin tuntemukset molemmin puolin risteilevät ärtymyksessä, miksi muutenkin niukkaa aikaa on käytettävä johonkin näin turhauttavaan.

Testaajan tehtävä ei kuitenkaan ole mollata kehittäjää väärin tehdystä työstä, vaan auttaa tätä tekemään työnsä hyvin.

Erityisesti silloin kun testauksesta puhutaan laadunvarmistuksena, testaajan tehtävä on merkittäviä virheitä löytäessään viedä projektin johtoon viestiä, että kehittäjien mahdollisuudet tehdä työnsä hyvin on taattava.

Laatua kun on vaikea saada aikaan, jos sen tekijöillä ei ole tarpeeksi aikaa, tarpeeksi mahdollisuuksia keskittyä, tai tarpeeksi ohjausta.

Harva koodari tekee ihan vaan piittaamattomuuttaan virheitä, ja kokonaisuuden kannalta edullisinta olisi, jos mahdollisimman moni toimintalogiikkaan liittyvä tai muuten merkittävä virhe jäisi kiinni jo silloin kun niitä ollaan kirjoittamassa.

Tässä mielessä olisi myös hienoa, jos testausta ei nähtäisi vain valmiin tuotteen toiminnan verifiointina.

Testaaja voi auttaa ehkäisemään virheitä mm. katselmoimalla määritys- ja suunnitteludokumentteja, esittämällä kysymyksiä sprinttipalavereissa, keskustelemalla rakenteilla olevasta toiminnallisuudesta kehittäjien kanssa, käymällä kehittäjän kanssa demoluonteisesti läpi toteutettua toiminnallisuutta, ja testaamalla hyvinkin keskeneräistä (kunhan hänellä on tieto siitä, mitä voi testata ja minkä ei ole tarkoituskaan vielä toimia). Tärkeää on löytää yhteinen tavoite tekemiselle.

Laatu ei parane testaamalla, vaan tekemällä paremmin.

Mites se mobiili?

Kun itse ensimmäisen kerran päädyin testaamaan selainkäyttöistä sovellusta, ohjeena oli testata Firefoxilla ja IE:llä. Edelleen osassa projekteista testausta rajataan tältä pohjalta, mutta tilanne on muuttumassa, ja varmaankin jo nyt monissa projekteissa tällainen rajaus perustuu tottumukseen, ei analysoituihin tarpeisiin.

Mobiili ei ole tulevaisuutta. Se on tätä päivää.

Testaajilla lienee aina ollut haasteena perustella palkkansa maksajalle, miksi testaus vie niin paljon aikaa. Moni asiakas kokee, että järjestelmätoimittajan testaus maksaa liian paljon, eikä organisaation omaan testaukseen ole mahdollisuutta varata tarpeeksi aikaa. Tämä tilanne ei mobiilin myötä ainakaan helpotu, ja sen joka haluaa olla osa tulevaisuuden kaupankäyntiä, on syytä ymmärtää ainakin jollain tasolla, miksi testaamisesta täytyy maksaa entistäkin enemmän.

Siinä missä pöytäkoneella käytettävän järjestelmän toimiminen "kaikilla selaimilla" tarkoittaa testaamista noin kymmenellä selaimella (mikä sekin on paljon), järjestelmän toiminnan varmistaminen kaikilla mobiililaitteilla ei ole mahdollista. Harvalla projektilla on resursseja hankkia kaikkia markkinoilla olevia laitteita, saati testaajia käyttämään niitä niin, että perusteellisen testikierroksen tulokset saataisiin projektin aikataulun puitteissa. On siis paitsi panostettava entistä enemmän testaukseen, myös tehtävä valintoja, mitä ja millä testataan ja kuinka perusteellisesti.

Jos kysymys on esimerkiksi asiakasyrityksen sisäiseen käyttöön tulevasta järjestelmästä, tehtävä on kohtuullisen helppo, koska järjestelmän ei välttämättä tarvitse toimia muilla laitteilla kuin niillä mitä tämä yritys hankkii henkilöstölleen työvälineiksi. Julkisen palvelun taas olisi oikeastaan hyvä toimia kaikilla laitteilla, tai ainakin niistä yleisimmillä. Jos loppukäyttäjä ei pääse käsiksi kaipaamaansa tietoon tai vaikkapa verkkokaupan toiminnallisuudet eivät toimi hänen käyttämällään laitteella, hän käyttää rahansa jossakin muualla.

Mobiililaitteista olisi siis löydettävä setti, joka on riittävän edustava varmistamaan palvelun toiminnan valtaosalla sen potentiaalisista käyttäjistä. Ja projektin aikataulutuksessa ja budjetoinnissa pitäisi ottaa huomioon se työmäärä, joka vaaditaan riittävän perusteelliseen testaamiseen näillä laitteilla.

Mobiilitestauksen haasteet eivät pääty tähän. Jos sitä ei muisteta projektikäytännöistä sopiessa, saattaa käydä niin, että esimerkiksi tietoturvasyistä tehtyjen rajauksien vuoksi mobiililaitteilla ei ole käytännössä mahdollista päästä käsiksi testattavaan ympäristöön. Näiden ongelmien ja niihin liittyvien vastuiden setviminen vie myös aikaa.

Sekä laitehintoihin että IP-rajauksiin liittyviä ongelmia voidaan kiertää käyttämällä emulaattoreita. Kuinka hyvin niillä tehty testaus sitten vastaa testausta todellisilla laitteilla - sitä voi joskus olla vaikea tietää. Lisäksi emulaattoreiden löytäminen kaikille oleellisille laitteille voi sekin olla haasteellista, ja sen jälkeenkin on vielä käytettävä aika siihen testaamiseen.

Mobiilitestaus on siis väistämättä kallista, mutta sen laiminlyönti voi tulla paljon kalliimmaksi. Mitä myöhemmässä vaiheessa ongelmat ilmenevät, sitä kalliimpaa on niiden korjaus, ja kaikkein kalleimpia ovat tuotantokäytössä ilmenevät virheet.


ps. Mobiilisivusto ei testaamalla pelastu, jos sen suunnittelussa ei ole osattu huomioida käytettävyyttä eri tyyppisillä päätelaitteilla.

Kuinka rakennetaan muutosvastarinta

Sujuvatko IT-projektisi turhan helposti? Ovatko asiakkaat liiankin tyytyväisiä? Ei hätää, tässä muutama vinkki, joilla saat työhösi uutta haastetta.

Älä ole kiinnostunut asiakkaan prosesseista, vaan minimoi tuotettavan tiedon määrää

Jo määritysvaiheessa kannattaa unohtaa asiakkaan käyttäjäroolit sekä niihin liittyvät tehtävät ja tavoitteet. Älä osoita kiinnostusta sen selvittämiseen, mitä asiakkaan todelliset käyttäjäryhmät ovat, mitä he tarvitsevat tai saavatko he äänensä kuuluviin. Määritystyöpajojen ensisijainen tehtävä on juoda kahvia ja jutella mukavia samalla kun selataan läpi irrallisia vaatimuksia ja tuotetaan sisällötöntä dokumentaatiota erilaisten johtajien luettavaksi.

Parasta on, jos saat määritystyöhön nakitettua henkilön, joka ei ymmärrä mitään asiakkaan toimialasta eikä myymästään teknologiasta, mutta osaa poliittisen jargonin jolla voidaan antaa kaikille käsitys että tässä nyt määritetään jotain vaikkei oikeasti määritetäkään. Jos myyt valmissoftaa, älä ainakaan esittele tuotteen demoympäristöä asiakkaalle - hehän saattaisivat vaikka ymmärtää, mistä määritystä tehtäessä puhutaan.

Suunnittelu- ja toteutusvaiheessa panosta vain siihen, että koodaaja pääsee mahdollisimman helpolla. Pyydetty toiminnallisuus on olemassa, jos sen yksinkertaisin käyttötapaus on mahdollista viedä läpi. Ei väliä, onko normaalin ihmisen mahdollista muistaa prosessin läpiviemisen vaatima akrobatia, tai löytyykö käyttöliittymästä kaikki tarvittava sen tekemiseen. Tärkeintä on, että ratkaisu on olemassa.

Panosta käyttöliittymän sekavuuteen

Pidä huolta, että käyttöliittymässä näkyy käyttäjälle moninkertainen määrä toiminnallisuuksia siihen nähden mitä hän tarvitsee. Parasta on, jos joukossa on viattoman näköisiä toiminnallisuuksia, joiden käyttäminen aiheuttaa katastrofin. Ja lupaavan ja tarpeellisen näköisiä toiminnallisuuksia, jotka eivät tee mitään. Ja toiminnallisuuksia, joista kukaan ei tiedä, mitä ne ovat ja miksi ne ovat siellä, saati seuraisiko niiden piilottamisesta katastrofi.

Jos käyttöliittymässä on personointeja kuten asiakkaan nimi, kirjoita se väärin. Tai kopioi toiminnallisuus toiselta asiakkaalta ja jätä vaihtamatta nimi, jotta käyttäjät varmasti ymmärtäisivät, ettei tätä järjestelmää heitä varten rakenneta.

Pyydä asiakkaalta vastauksia samoihin kysymyksiin useampaan kertaan

Älä lue projektissa tuotettua määritysdokumentaatiota. Älä pidä sitä ajantasalla. Pyydä asiakkaalta tietoa listoina, joiden merkityksiä he eivät ymmärrä, ja pyydä tätä tietoa kuukauden päästä uudelleen hukattuasi ensimmäisen version tai todettuasi ettei sen sisältö kuitenkaan vastaa asiakkaan tarpeita.

Älä näytä asiakasta ja teknisiä asiantuntijoita toisilleen, vaan pidä välissä suodattimena henkilöä joka ei ymmärrä heistä kumpaakaan, ja jolla ei riitä aika tehtäviensä hoitamiseen.

Kouluta keskeneräisellä järjestelmällä

Mikään ei ole parempi tapa pelotella ja hämmentää tulevia käyttäjiä kuin koulutusten järjestäminen heti kun jotain likipitäen pystyssä pysyvää on saatu asennettua. Oppi uppoaa parhaiten, kun koulutuksessa toistuvat fraasit "tämä olisi järkevämpää tehdä vähän toisella tavalla, mutta koska siinä on nyt bugi niin tehdään vähän vaikeammalla ja epäintuitiivisemmalla tavalla" sekä "sitten kun tämä valmistuu, niin tänne tulee näkyviin sellainen toiminto jonka kautta voitte tehdä sitä-ja-tätä". Parasta on, että järjestelmän ollessa koulutuksessa riittävän keskeneräinen, asiakas pääsee käyttämään sitä itse vasta kuukausia myöhemmin, mihin mennessä kaikki opitut tiedonmuruset ovat ehtineet unohtua.

Kikkaile raportoinnin kanssa, jotta asiakas aloittaisi hyväksymistestauksen vaikka toteutus on kesken

Tekee aina hyvää asiakassuhteelle väittää kirkkain silmin että kaikki toimii, kun seuraavana päivänä asiakas kokeilee itse ja saa todeta että mikään ei toimi. Ja kuinka mielenkiintoista onkaan selvittää, miten monta kertaa asiakas suostuu aloittamaan hyväksymistestauksen.

Tee toiminnallisia muutoksia kun järjestelmä on jo asiakastestauksessa tai pilotoinnissa

Jos tuntuu, että joku juttu olisi sitten kuitenkin järkevämpi jollain toisella tavalla, muuta se toimimaan järkevämmin. Ja jää sitten odottamaan, huomaako kukaan eroa, ja jos huomaa, keksiikö millaiseksi toiminnallisuus on muuttunut. Älä ainakaan päivitä käyttöohjetta muutoksen mukaiseksi, älä kerro kouluttajille, testaajille äläkä asiakkaille. Suunnittele valmiiksi ylimielinen vastaus, kun joku onneton kuolevainen uskaltautuu kysymään asiasta tai raportoi muutoksen bugina.

Älä ota asiakkaan ongelmia vakavasti

Kun asiakas on tyytymätön, totea että he eivät vain osaa käyttää järjestelmää, ja siksi heidän pitäisi ostaa lisää koulutusta. Toista tätä viestiä, vaikka asiakas olisi jo maksanut useammasta ekstrakoulutuspäivästä kuin mitä olit sisällyttänyt alkuperäiseen tarjoukseesi riittävänä koulutuspakettina järjestelmän käyttöönottamiseksi.

Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan.