Layoutin testaus

Nettisivuston ulkoasu on osa brändin rakentamista. Siksi myös ulkoasun virheettömyys on tärkeää. Oman haasteensa testaukseen tuo se, mobiililaitteiden merkitys netinkäytössä kasvaa koko ajan, ja mobiililaitteiden kirjo on valtava. Ulkoasu ei myöskään aina tarkoita vain sitä, näyttääkö jokin näkymä kivalta, vaan joskus ulkoasuvirheet voivat myös piilottaa informaatiota tai toiminnallisuuksia.

Ulkoasun oikeellisuus on helpointa verifioida luomalla testisivuja täsmälleen visuaalisen suunnitelman mukaisilla sisällöillä. Tällöin virheet väreissä, fonteissa, kuvapaikkojen ja ikonien koossa, elementtien keskinäisessä sijoittelussa, marginaaleissa jne. on suhteellisen helppo huomata yksinkertaisesti vertaamalla visuaaliseen suunnitelmaan. Kuvasta kannattaa etsiä linjoja, joiden avulla voit tarkistaa eri elementtien keskinäisen asemoinnin, esim. vierekkäisten palstojen otsikkopalkkien ylä- ja alareunat, tai näyttääkö teksti tai kuva keskitetyltä pysty- tai vaakasuunnassa. Tarkista myös, onko käyttöliittymän eri osien välillä esim. vaaka- tai pystyviivoja erottamassa elementtejä toisistaan, ja jos näillä elementeillä on esimerkiksi keskenään erilaiset taustavärit, vaihtuuko taustaväri täsmälleen tuon erottavan viivan kohdalla vai ei. Jos tekstien eteen tulee jossain checkboxeja tms. listamerkkejä, tarkista niiden asemoituminen suhteessa ko. rivin tekstiin. Muista myös hover-efektit, aktiiviset linkit ja käydyt linkit, sekä milloin hiiren kursori indikoi alla olevan linkin.

Lisäksi on tärkeää luoda testisivuja, joiden sisällöt eivät ole ihan niin nättejä.

Tyypillisiä esimerkkejä tilanteista, jotka luovat ulkoasuongelmia, ovat

• tavanomaista pidemmät sanat
• rivittyvät kuvatekstit
• rivittyvät linkin nimet
• bannerien määrän muuttuminen
• eri määrä sisältöä vierekkäisissä listaelementeissä
• kuvattoman uutisen julkaisu listalla, joka näyttää uutisista ingressikuvia
• kuvagallerian kuvien rivittyminen niin että viimeinen rivi ei ole täynnä kuvia
• bulletpoint-listat rivittyvillä tekstinpätkillä

Lisäksi huomio kannattaa kiinnittää myös seuraaviin

• Onko käytössä eri tyyppisiä mutta keskenään saman näköisiä listaelementtejä (esim. blogilista, uutislista, tapahtumalista)? Jos niitä näytetään samalla sivulla, ovatko marginaalit yms. oikeasti samanlaiset?
• Kieliversiot ja niihin liittyvien merkistöjen näkyminen. Nappien tekstien mahtuminen nappeihinsa.
• Sivujen leveydet. Onko esim. jollain sivulla "turha" vierityspalkki kertomassa, että sivu onkin leveämpi kuin sen pitäisi
• Sivukarttasivu, hakutulossivu, palautelomakesivu yms. Näistä ei aina ole visuaalista suunnitelmaa olemassa, mutta yhtä kaikki niidenkin tulisi näyttää hyvältä.
• Elementtien kulmien pyöristykset, liukuvärit
• Murupolku

Responsiivista sivustoa testattaessa tarkista myös mm.

• Pysyykö kuvien kuvasuhde vakiona eri selaimen leveyksillä? Venyvät kuvat eivät ole hyvää brändin rakentamista
• Navigaation saavutettavuus

Mitä muuta testaisit?

Lomaketestaus

Alla muistilistaa asioista, jotka voivat olla relevantteja testattaessa täytettäviä www-lomakkeita mutta myös muita toiminnallisesti vastaavia kohteita kuten erilaisia tietokortteja. Lista ei ole täydellinen, se ei esim. ota kantaa tietoturvaan liittyviin asioihin kuten sql-injektioihin tai captcha-toiminnon testaamiseen. Toisaalta se on myös ehkä jo turhankin pitkä testisession tueksi. Millaista listaa itse käyttäisit?

• Löytyvätkö vaaditut kentät? Onko ne nimetty oikein? Onko ylimääräisiä kenttiä?
• Onko pakollisia kenttiä? Onko ne merkitty asteriskein? Voiko lomakkeen merkitä valmiiksi täyttämättä pakollisia kenttiä? Onko ehdollisia tai vaihtoehtoisia vaatimuksia, ja toimivatko ne oikein kaikissa tilanteissa?
• Validoidaanko syötteiden sisältöjä, esim. sähköpostiosoitteen muoto? Toimivatko validoinnit? Esim. puhelinnumeron voi syöttää monella tavalla, välilyönneillä, väliviivoilla, maakoodilla,..
• Onko päivämäärä/kellonaika-kenttiä? Missä formaatissa aika syötetään niihin ja validoidaanko syötteitä?
• Onko rajoitteita käytettävistä merkeistä, ja miten se toimii?
• Kuinka monta merkkiä kenttään voi syöttää? Kulkeeko maksimimerkkimäärä myös rajapinnan yli ja tallentuuko se tietokantaan oikein?
• Checkboxit, radiobuttonit
• Voiko käyttöliittymässä lisätä kenttiä? Voiko niitä poistaa, järjestää tai vaihtaa toisenlaisiin? Hajoaako käyttöliittymä tätä kokeiltaessa? Poistuvatko oikeat kentät, tulevatko lisättävät kentät oikeaan paikkaan?
• Voiko käyttäjä lisätä kuvia tai liitetiedostoja? Sallitut tiedostotyypit? Tiedostojen sallitut koot? Voiko dokumentteja liittää useita? Voiko liitettyjä dokumentteja poistaa? Onko tiedostonlisäyskontrolleja yksi vai useampia? Jos useampia, toimivatko ne toisistaan riippumattomasti? Mitä käyttöliittymälle tapahtuu tiedostoja lisättäessä ja poistettaessa?
• Onko lomakkeella ohje-toiminnallisuuksia? Ovatko ne siellä missä pitääkin ja toimivatko ne?
• Onko lomakkeella linkkejä? Vievätkö ne sinne minne pitääkin?
• Voiko kentästä toiseen liikkua tabulaattorilla? Voiko kaikki kentät täyttää näin? Mitä tapahtuu jos käyttäjä painaa enteriä?
• Onko sivuja useampia kuin yksi? Voiko eteen ja taakse liikkua menettämättä täytettyjä tietoja?
• Onko esikatselutoimintoa? Näyttääkö se kaikki tiedot oikein? Voiko siitä palata muokkaamaan tietoja? Jäävätkö muokkaukset voimaan?
• Onko toimintoa kenttien tyhjentämiseen? Tyhjentääkö se ne kaikki? Ovatko ne tyhjiä myös esikatselussa ja lähetettäessä?
• Toimiiko lähettäminen? Mitä sen jälkeen tapahtuu, mitä käyttäjälle näytetään? Toimiiko tulostaminen? Tuleeko sähköpostivahvistus ja sisältääkö se tarvittavat tiedot?
• Onko kieliversioita?
• Tuetut selaimet ja laitteet?

Ninjakin tarvitsee mestaria

Testaus on käsityöläisammatti, jonka oppimiseen on vain yksi tie: harjoitus. Työn tekeminen ja tulosten kriittinen analysointi ovat edellytys sille, että voi osata testausta.

Käsityöläisammatit eivät kuitenkaan ole kehittyneet vain yksittäisten ihmisten kekseliäisyyden varassa. Ammattilaiseksi kehitytään mestarin ohjauksessa, ja mestareista parhaat ovat hakeneet oppia useammaltakin mestarilta, tyypillisesti myös ulkomailta.

Tavallaan testausta voidaan verrata myös kamppailulajien harjoittelemiseen. Opetellaan uusia tekniikoita, hiotaan niitä, opetellaan tunnistamaan tilanteita joissa niitä käytetään, ja opetellaan käyttämään niitä tehokkaasti. Hyvät harjoitukset rakennetaan vastaamaan mahdollisimman realistisia todellisia tilanteita.

Myös jokaisella dojolla on oma mestarinsa, jonka oppeja seurataan, vaikka opetuksesta tyypillisesti huolehtiikin joku muu.

Nykypäivänä emme ole täysin suullisen tiedon varassa. Kirjastoista ja netistä löytää tietoa niin käsitöistä, kamppailulajeista kuin testauksestakin. Pyörää ei tarvitse keksiä kokonaan itse, vaikka ei mestarin ohjauksesta saisikaan nauttia.

Silti, ilman ohjausta voi olla vaikea löytää tietään parhaan tiedon luo. Tarvitaan myös mahdollisuuksia kysymiseen ja keskustelemiseen. Näihinkin netti tarjoaa onneksi mahdollisuuksia.

Netin kautta mestari ei kuitenkaan voi korjata virheellistä ranteen asentoa tai jalan väärää liikerataa. Tekniikan hioutumiseen on mahdollisuuksia vain siellä, missä oppija itse näkee tarpeen kehittymiselle.

Voiko myöskään testauksessa koskaan toteuttaa täyttä potentiaaliaan, jos ei saa tilaisuuksia harjoitella yhdessä mestarin kanssa?

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.