Mitä kannattaa hankkia, kun lähtee testausostoksille?
Pysähdyimme perjantaina pohtimaan testaajan työtä höyryävän tuoreen kahvikupin äärellä. Siinä syvällisiä pohtiessa päätimme tarkentaa siihen, mikä on testaajan työn tärkein tulos?
Vastauksia löytyy toki yhtä paljon, kuin testaajia. Toisen mielestä testauksessa on kysymys laadun parantamisesta, toisen mielestä homman nimi on mittaustulosten tuottamisessa. Kolmas taas väittää, että testaaja rakentaa luottamusta tuotteen laatuun ja neljännen mielestä testaaja taas tuhoaa luottamusta.
Vastauksia sateli ihan liikaa siinä stormatessa, joten päätimme yksinkertaistaa ongelmaa tässä valinnan paikassa.
Jos testauksen budjetti asetetaan tuskallisen tiukaksi ja kulutasoa pitäisi vielä entisestään leikata, niin mitä jäisi jäljelle?
- Testispeksit ja caset? Roskiin
- Testitulosten mittarointi? Roskiin
- Testaussuunnittelu? Roskiin
- Automaatio? Roskiin
- Tarkistustyöt? Roskiin
- Testauksenhallintajärjestelmät? Roskiin
Aika suuri siivu siitä testaajan päivittäisestä työstä päätyi meidän pöydässä roskikseen, mutta yksi juttu siihen jäi. Mikäpä luulette sen olleen?
Niinpä: Bugithan siihen jäivät. Ne kertovat mitä vikaa softassa on. Ne kertovat miksi se maksava loppuasiakas saattaa valittaa tai olla tyytymätön. Ne kertovat mitkä sudenkuopat kannattaa julkaistessa välttää. Kaikessa yksinkertaisuudessaan ne ovat
Things that Bug you
Entäpä jos ensikerralla testausta ostaessasi päättäisitkin hankkia vain sen konkreettisimman tuloksen? Osta ensikerralla vain bugit!
Suosittelemme myös:
Milloin kannattaa testata?
Testaaja. Tuo aikamme Nostradamus ja tulevaisuutemme moukarimies, on tuohtunut ja pyörittelee peukaloitaan. Mitä aikaisemmin testauksen aloittaa,...
Mikä on kun ei taidot riitä?
Ilma oli sakea, tunnelma tiivis ja noin 100 kilttiä koululaista nojautui kuuntelemaan väkeviä tarinoita myynnin ihmeellisestä maailmasta. Istuin...
Koin eilen oivalluksen yhden ruotsalaiskolleegan kanssa jutellessa. Se tärkein asia hyvällä ja hyväksi tunnetulla testaajalla saattaa olla olemassaolo: merkittävässä määrin bugittomampaa toteutusta syntyy ihan vaan jo sillä, että uskoo jäävänsä kiinni kohdassa jossa asia palaa omalle pöydälle.
Syntymättä jääneet bugit olemassaolon vuoksi, syntymättä jääneet hyvän yhteistyön vuoksi ja lopulta, ne löytyneet bugit kun vielä tuli sitä suorittavaakin testausta tehtyä!
Testaus on fantastinen asia lukemattomista syistä ja yksi tämmöinen seikka on se, että testauksesta niin moni asia on tosi yhtä aikaa. Testausta voi tehdä niiin monella tavalla, lukuisilla tyyleillä ja loputtomalle määrälle asioita, ideoita tai tuotoksia. Meistä jokainen testaa lähes joka päivä!
Jos tuotteesta ostaa vain bugit, niin sitä voi tavallaan pitää vaihtoehtona loppukäyttäjän tekemälle testaukselle. Valitettavan usein juuri loppukäyttäjä on se joka sitten ilmoittaa ne bugit ja edes ilman laskukaavoja väitän, että tämä on testauksen ylivoimaisesti kallein muoto. Jos bugit ostaa testauksen ammattilaisilta ennen kuin ne päätyvät loppukäyttäjälle, niin sitä voi pitää järkevänä toimintana.
Testaus on kuitenkin niin paljon muutakin kun vain ne bugit. Testaus on olennaisessa asemassa kun modernia softaa tehdään. Testaus kertoo myös sellaisia määreitä kuin vaikkapas ”näyttää hyvältä / ei näytä hyvältä / tuota kun muuttaa, niin sitten näyttää hyvältä / ei tunnu hyvältä / tuntuu hyvältä / vaikea käyttää / helppo käyttää” ja niin edelleen. Hyvä testaus kykenee osoittamaan puutteet alkuperäisestä ideasta. Hyvä testaus kykenee sanomaan, että tuo ei tule toimimaan tai että tuolla on hyvä mahdollisuus toimia, ennen kuin koodaaja on kirjoittanut riviäkään. Minulla olisi itseasiassa helpompi kirjoittaa lista niistä asioista mihin hyvä testaus ei pysty, kuin että mihin hyvä testaus pystyy. Hyvä testaus pystyy mihin vain, suorastaan ihmeisiin.
Mitä hyvä bugirapsa sisältää?
Ainoa oleellinen seikka on virheen kuvaus niin, että tuotepäällikkö voi tehdä päätöksen milloin (jos koskaan) virhe korjataan.
Kosmeettisia virheitä on turha edes raportoida. Niiden pyöritteleminen bugijärjestelmässä syö vain aikaa. Ei nitä kukaan korjaa.
Vaistoanko hieman ironian poikasta tuossa Arin kommentissa 😉
Jos määrittelemme kosmeettisen virheen puhtaaksi graaffiseksi virheeksi (huonon näköinen / ei laadukkaan näköinen) käyttöliittymässä, niin sellainen virhe on osalle tuotteista korkeimman prioriteetin virhe. Tuote jolla on käyttäjiä rajallinen joukko kuten sisäinen työkalu, niin kosmeettisilla virheillä saattaa olla pienempi painoarvo. Puolestaan tuote jota käyttää tuhannet ihmiset, niin kosmeettinen virhe nousee korkealle prioriteetille. Puhutaan mielikuvista.
On esimerkkejä kun markkinoille on tuotu tuotteita joissa on pahojakin toiminnallisia virheitä, mutta käyttöliittymä tiptop ja viimeiseen asti siistitty ja hurjia myyntejä ovat tehneet. Riippuu laitteesta, että onko kosmeettisella virheellä kuinka suuri painoarvo.
Ammattitestaaja on oikeassa, sanavalintani oli huono. Tarkoitin ”kosmeettisella” virheellä sellaista virhettä, jolla ei ole tuotteen (myynnin jne.) kannalta oleellista merkitystä. Kokenut ja osaava testaaja osaa itse arvioida, mikä juuri hänen projektissaan on keskeistä.
Jos myymme bugeja tuotteesta eikö olisi kuitenkin järkevää raportoida kaikki ja sanoa että tässä nämä viat nyt ovat, päättäkää itse mitä korjaatte niistä. Kokenut testaaja osaa kyllä suurimmalle osalle vioista antaa jonkinnäköisen prioriteetti ehdotuksen mutta asiakashan saa itse päättää mitä vikailmoituksille tekee. Tässä tilanteessa vastuu viallisesta tuotteesta siirtyy testaajalta asiakkaalle eikä testausta pitäisi silloin syyttää.
Myöskin nämä ”kosmeettiset” viat ovat varsin aikaavieviä selvittää ja korjata jos virhe on protokolla tasolla ja vasta käyttöliittymän testaus muiden alustojen kanssa aiheuttaa tilanteen jossa tämä ”kosmeettinen” haitta aiheuttaa vakavia ongelmia.
Olen muuten taas korostetusti viime aikoina huomannut, kuinka uskomattoman epälineaarista on tärkeys ja korjaamisen haastavuus. Olen osunut ilmeisen onnekkaisiin kohtiin, sillä silmiini osuvista virheistä yllättävänkin harva on ollut missään määrin merkittävä korjaustyömäärältään, laskien tähän siis mukaan myös regressiotestauksen tarpeen. Ja kyse ei ole sovellusalueen kannalta kosmeettisista virheistä.
Myöskin on tullut mielenkiinnolla seurattua ”trendiä” siitä että laatu ja testaus ovat kuolleita. Testaukseen investoimisen voisi korvata julkaisujärjestelmillä joilla voidaan julkaista pienelle vaihtelevan kokoiselle porukalle kerrallaan ja vetää versio pois jos jääneet ongelmat ovat olleet riittävän vakavia. Kun miljoonista käyttäjistä pakkobetaamiseen ottaa kerrallaan 1000, ei kukaan ehdi edes erityisesti ärsyyntyä. Selkeyden vuoksi kuitenkin todettakoon, etten ihan käänny vielä tähän automaatiotestaus + julkaisujärjestelmätrendiin, vaikka se onkin tiettyjen sovellusalueiden osalta oikeasti houkutteleva ja varmasti varteenotettavakin vaihtoehto.
Maaretin havainnot ovat mielenkiintoisia.
Varsinaisen päivätyöni ohella teen runsaasti testausta pelimaailmassa harrastepohjalta. Peliteollisuudessa on ollut tapana jo hyvän aikaa testauttaa tuotteita juuri tuolla pienellä valikoidulla porukalla. Tämän huomioni sanottuani joudun kuitenkin toteamaan, että joillain suurilla pelitaloilla saattaa olla jopa satoja ammattimaisia pelitestaajia listoillaan. Taannoin eräs korealainen pelitalo oikein mainosti peliään, että nyt se on kunnolla sisäisesti testattu ennen kuin menivät edes alpha-testiin. Poikkeus siis vahvistaa säännön, tai sitten toisin päin.
Voisikos asian yhteenvetää seuraavasti: testaus on hyvin monimuotoinen ala joka edelleenkin hakee ”uriaan” voimakkaasti. Hieman ajan hengestä riippuen, tietyt tyylit nousevat trendeiksi ja niitä osa soveltaa omassa toiminnassaan. Muutamia vuosia sitten oli suorastaan kliimaksin omainen hypetys siitä kuinka kaikki testaus kuuluu Aasiaan tai vähintäänkin Suomen rajojen ulkopuolelle. Kun katson tilannetta nyt, niin näen täyskäännösen tässä asiassa. Toki offshore on yksi malli monien joukossa edelleenkin, mutta se on enää vain nimenomaan se yksi malli – ei ainoa malli. Tämä siis henkilökohtainen kokemukseni omasta perspektiivistäni katsottuna.
Mainiota keskustelua testauksen trendeistä ihmiset! Ilo kuulla näin paljon näkökulmia meitä kaikkia koskevaan asiaan!
Minusta tuntuu, että softakehityksen palveluiden ostaminen on toiminut tunti tai urakkapohjaisesti tähän asti. Maksetaan kulutetusta työajasta joko etukäteen tehdyn työmääräarvion perusteella tai toteutuneiden tuntien perusteella.
Pohdinnan paikka onkin siinä, että jos asiakas kysyisi sinulta testaajana seuraavaa:
”Haluaisin ostaa sinulta ainoastaan työsi tulokset. Haluan maksaa sinulle vain jokaisesta löytämästäsi bugista. Jos et bugeja löydä, ei tipu tiliäkään. Jos taas teet hyvän saldon bugien metsästyksessä, tipahtaa oikein kiva tilikin.”
Olisiko sinulla kanttia ottaa haaste vastaan? Silloin ensikuun tilipussi on juuri niin lihava kuin mitä sinä onnistuit bugjea löytämään?
Pohdinnan paikka on siis kai tässä tapauksessa se onko työn tekijä tai tilaaja kumpikaan valmiita nyrjäyttämään ajatusmaailmaa uusille urille? Voisiko tämä ”Maksat vain tuloksista” -malli olla yksi tulevaisuuden trendeistä?
Itse hieman karsastan testaustyön arviointia raportoitujen bugimäärien perusteella. Työssäni törmään todella useasti vikaraportteihin jotka ovat todella vaikea toistaa ja loppukäyttäjän näkökulmasta ajateltuna on yhdentekevää korjataanko sitä vai ei. Hyödyttömiä vikaraportteja vieläkin pahempi on se että jos palkanmaksu riippuu raporttien kuukausittaisesta määrästä voidaan vikaraporttien kirjoitusta alkaa roikuttamaan jotta palkkaa tulisi sopivasti myöhemminkin. Vikatietokantojen trandejä seuratessa voi huomata kuinka viikon päättyessä tulee joiltain testaustiimeiltä yleensä järkyttävä määrä vikoja. Veikkaisin että näissä tiimeissä on asetettu joitain tavoitteita vikojen raportoinnista 🙂
Olisin valmis kokeilemaan ”maksat vain tuloksista” -mallia. Tähän sisältyy kuitenkin iso mutta. Haluaako asiakas ostaa minulta muita testauspalveluita kuten raportoinnit, analysoinnit, tuotteen kehittäminen, testauskoulutukset jne. Tuossa siis joitakin esimerkkejä siitä mitä tyypillisesti projekteissa teen. Tämä uusi malli sopii mielestäni paremmin black box tyyppiseen projektiin. Oletetaan siis, että puhumme black box -projektista.
Ratkaisevassa asemassa on bugin hinta ja jos siitä päästään sopimukseen, niin olisin enemmän kuin valmis kokeilemaan ”maksat vain tuloksista” -mallia. Projektissa jos tuota sovellettaisiin, niin kokisin luontevaksi hybridi-mallin eli sovitaan kuukausittainen peruskorvaus ja siihen päälle lisäkorvaus löydetyistä bugeista. Projektissa kun on niin paljon muutakin työtä bugien lisäksi, että sitä ei voi jättää huomiotta.
Morjensta Jani & Ammattitestaaja,
Lienet Jani ihan oikeassa siinä, että projektikohtaisesti ajateltuna bugien roikottelu ja virhetilastoiden peukalointi saattaa olla riski. Varsinkin pitkissä projekteissa tätä tapahtuu minusta hälyyttävän paljon. Samaa asiaa olemme pureskelleet myös aikaisemmin: http://ohjelmistotestaus.fi/2011/01/nyt-on-poonukset-pelissa/
Eikö siis olisikin erinomainen idea tehdä kuukausi tai kaksi kunnon bughuntingia yhteen projektiin ja sen jälkeen hypätä jo seuraavaan? Silloin ei tulisi kaunisteltuja rapsoja ja virheitä ei tarvitsisi roikotella. Siitä hyötyisivät ihan kaikki koko tuotantoketjussa.
Ammattitestaajan kommentista huomasin, että meillä on yhä taipumus puhua ”muista testauspalveluista”. Tämän tekstin yhteydessä puhuisin itse ainoastaan ”muista testauksen tuloksista” 🙂
Ratkaisevassa asemassa on toki bugin hinta. Sehän on koko toimintamallin kulmakivi. Mikä siis on se hinta, että homma on kannattavaa sekä tilaajalle, että toimittajalle??? Sehän ei selviä kuin kokeilemalla!
Testataan homma siis näin:
Lähetä minulle softatuotteesi testattavaksi, niin minä lupaan testata sen sinulle hintaan 79,-/bugi! Soita siis 040 572 7204 ja kysy Anttia. Näytetään yhdessä kaikille miten homma hoidetaan uudella tavalla!
Hmm.. meniköhän nyt liian halvalla? 😀
Äkkiä nimittäin käy aika hyväksi diiliksi tuo tarjous, jos laskee montako bugia minun olisi etsittävä yhden kuukausipalkan(+sivukulut) tienaamiseksi.
Hmm.. 79 eskoa per bugi 🙂 Itse laskin, että voisin bugin myydä 300-400 eur/kpl. Perustelen hintani sillä, että tyypillinen löytämäni bugi on isohkon tutkimuksen tuotos ja jonkinlaisessa suhteessahan sen täytyy olla perinteiseen tuntihinnoitteluun. Otan myös huomioon sen, että erilaisista tuotteista löytyy kovin erisuuruinen määrä bugeja – aina niitä löytyy, mutta ei yhtä paljon. Lisäksi tulee huomioida softan kehityskaari – missä vaiheessa kehitystä softa on.
Jos osallistun projektiin joka on aivan alussa, niin kehtaanko edes puhua kovin aikaisessa vaiheessa bugeista kun ideaa ollaan vasta vääntämässä tuotteeksi. Tällöin koen antavani näitä “muita testauksen tuloksia” ja silloin hintani sovitaan tavanomaisesti etukäteen.
Jokatapauksessa painotan, että olen avoin uusille tyyleille ja malleille ja innolla odotan milloin saan kokeilla tätä ”enempi bugeja, enempi palkkaa” -mallia.
Puhut asiaa Ammattitestaaja,
Myydessämme työn tuloksia taidamme olla ennen kokemattomalla maaperällä. Kun minä nyt heitin hintani hatusta, niin pysyn siinä. Tarkistan omaa hinnoitteluani viimeistään vuoden vaihteessa KUN kysyntä räjähtää käsiin 😉
Onkos hinta per bugi kiinteä riippumatta siitä onko bugi validi, parannusehdotus speksin raameissa tai niin mitätön että päätetään ettei sitä korjata? Kyllähän niitä bugeja on helppo raapustaa kantaan mutta miten tilaajan tyytyväisyyttä mitataan jos löydetyistä bugeista suurin osa onkin ominaisuuksia joita ei vielä tiedetty :)Uskallatko antaa takuun että kaikki bugit joista maksan johtuvat minun applikaatiostani eikä esim. frameworkin asettamista rajoituksista?
Jännän äärellä ollaan. Lähtökohtaisesti tuo kiinteähintainen bugi on kyllä kutkuttava. Jani ja Ammattitestaaja tosin ovat löytäneet yhtä herkullisia ongelmakohtia. Pari kysymystä kommentoijille:
Jani, jos bugi on vakava, niin onko sillä loppukäyttäjän näkökulmasta väliä, että löytyykö bugi sinun applikaatiosta vai frameworkistä? Joku ratkaisu pitäisi kait kuitenkin keksiä.
Ammattitestaaja, hyvä huomio tuo bugin hinta. Toisaalta, ammattilaiset ymmärtävät jo bugin hinnasta, että kuinka syvälle ytimeen meneviä bugeja voidaan löytää. Jos haluaa maksaa bugista 79 euroa, ei voine olettaa, että siihen rahaan kaivetaan virhettä tuntikaupalla?
Voi hyvin olla, ennen lopullisen mielipiteen muodostamista tätä menetelmää pitäisi päästä testaamaan 🙂
No miten olisi esimerkiksi copy paste aikaisemmissa iphoneissa. Varmaan melko moni olisi tästä raportoinut vian, mutta olisiko asiakas siitä maksanut kaikille tuotetta testaaville? Olisikohan palkkiota maksettu edes ensimmäiselle vian raportoijalle koska puute oli kuitenkin tuotehallinnalla tiedossa… Loppukäyttäjäähän tällaisen tutun ja turvallisen toiminnon puute ilman muuta risoo 🙂
Jaakko, voi olla niin, että kaikki asiakkaat eivät ole ”ammattilaisia” eivätkä välttämättä kykene suhteuttamaan bugin hintaa mihinkään. Tosin kyllä tuosta 79 eurosta voi saada tuntuman, että ei se kovin kallis ole. Siitä ei kuitenkaan voi suoraan päätellä, että ne kaikkein työläimmät ja syvimmällä olevat bugit jäisivät skoopin ulkopuolelle. Mielestäni asiakkaalla on oikeus olettaa tilaukseen sisältyvän niin pienet kuin isotkin bugit jos toisin ei sovita.
Jani, hyvä huomio. En tosin tunne tuon copy&pasten puuttumisen taustaa. Jos Applella olisi selkeä kanava, mihin bugirapsan voi tipauttaa ja sinne tulisi kymmeniä tai satoja raportteja copy&pasten puuttumisesta, niin Apple voisi siitä raporteista päätellä ainakin sen, ett käyttäjät haluavat toiminnon. Jos puute on tuotehallinnon tiedossa, niin ainakin tuo mekanismi johtaisi sen pohdintaan, että pitäisikö seuraavaan päivitykseen copy&paste lisätä.
Ammattitestaaja, tuo on totta. Ehkä tuollainen kiinteähintainen bugipalvelu pitäisi kohdistaa hyvin rajattuun alueeseen. Esimerkiksi käyttöliittymän ongelmiin tai selkeisiin toiminnallisuuksiin. Pintaa syvemmälle vöngittäessä pitäisi ehkä olla toisenlainen hinnoittelumalli.
Jos me hinnoittelemme 79,-/bugi ja vika onkin määrittelyssä, niin paljonko maksaa tehdä muutos määrittelyyn, suunnitteluun, koodiin, siirrot, testauksen?
Ikös voisi mennä niin, että me LÖYDÄMME bugin 79,/bugi ja teille jää hommaksi korjata ne. Onko sitten joku löydöd bugi (tai onko se jo tiedossa), niin se on eri. Joku sanoi, että ”It’s a bug if it bugs someone who matters”.
Itse varmasti rikastuisin kertaheitolla, kun kirjaisin ylös kaikki mahdolliset havainnot. Laskutusasioissa saattaisi tulla vääntäminen, koska asias ei todennäköisesti kelpuuta kaikkia omia havaintojani ”bugeina” vaikka ne bugaisivat minua.
Lasku-per-bugi -mallin tulee mielestäni perustua siihen, että asiakas hyväksyy raportoidut bugit ja maksaa siis niistä mitkä hyväksyy. Itse en oikein näe tuossa muuta mahdollisuutta.
Tässähän se uusi testauksen liiketoimintamalli sitten jalostuukin kätevästi 🙂
Ammattitestaajan idea siitä, että asiakas seuloo ja hyväksyy myytävät bugit on varmasti järkevä. Silloin on vain varauduttava siihen, että yhden bugin hintataso varmaankin nousee juuri sinne 300-400e tietämille. Tämä johtuu siitä, että eihän kenenkään kannata tehdä duunia tappiolla.
Toisaalta taas, jos työn tavoite on raportoida Pekan määrittelemän mukaisesti kaikki vastaantulevat bugit (”It’s a bug if it bugs someone who matters”), niin silloin yksittäisen löydöksen hintakin voi olla matalampi. Väittäisin, että näin myös lopputulos on parempi, sillä tilaajalle jää käteen paljon arvokasta tietoa
1.siitä miten softa ei toimi ja
2.siitä miten softa itseasiassa toimiikin (oudosti?)
Minusta tässä keskustelussa on helppoa takertua pohtimaan yksittäisen bugin määritelmää ja entä-jos-tilanteita. Minä kuitenkin väitän, että hiusten halkominen on turhaa. Pohjimmiltaan kysymys on ainoastaan siitä mihin keskimääräiseen hintaan erinomainen lopputulos saavutettiin.
Kirjoittelin juuri eilen viimeisimmästä hyväksymistestausprojektistani, jossa viiden viikon ja viiden ihmisen työllä (plus toinen mokoma valmisteluihin) löydettiin viisi virhettä ja viisi määrittelymuutosta.
Jos tästä sitten laskee että paljonko pitäisi tuloksen hinnaksi tulla, niin pitäisi saada yhdestä tuloksesta 25 päivän palkka.
Testauksen ainoa tulos ei ole bugit, vaan myöskin maksamisen arvoista ainakin tässä tilanteessa on se että tiedetään että testaajien osaamisen ollessa kohdillaan tässä tiimissä, nyt tiedetään aika monta sataa tilannetta joissa ei ole bugeja.
Niin että vielä hetki kannattaa analysoida tota 79 € / bugi -hintaa. Ja katsoa vaikka vertailun vuoksi mitä utestin kautta jo tuolla bisnesmallilla maksetaan. Utestistä suurimmasta päästä olevia kritiikkejä on ollut bugien alhainen ja tasainen hinta, sillä siinä missä alkuun saattaa olla helppoa (tai tosi vaikeaa), on ainakin selvää että edistyneempien asioiden kanssa menee vaan enempi aikaa.
Painottaisin vielä, että lasku-per-bugi -malli on vain ja ainoastaan yksi testaamisen liiketoimintamalli monien joukossa. Joillekkin tuotteille/asiakkaille tuo voi sopia ja toisille passaa taas paremmin toisenlainen malli.
Hyvä on muistaa myös se, että testauksen tulos on sekin, että ei löydy yhtään bugia (tämän kohdan voimme toki aukaista, mutta otetaan siitä joskus uusi aihe). Ei siis voida mennä sellaiseen moodiin, että virheitä aletaan keksimään tikusta, koska muuten jäädään ilman palkkaa. Se ei ole hyvää testausta. Hyvää testausta on se, että työn kohde analysoidaan oikein ja siihen sovelletaan oikeaa testausmallia.
Lasku-per-bugi sopii osalle projekteista ja jos soveltaisin sitä omassa tämän hetkisessä tekemisessäni, niin lasku per bugi olisi useita satoja euroja. Etsin bugeja ns. pintaa syvemmältä ja tutkimustyö saattaa viedä joskus montakin päivää. Löytämäni bugit ovat luokassa ”jytky”. Toisessa projektissa tilanne voi olla toinen ja siksi rakastan testaamista niin paljon kuin rakastan 🙂
Edellisten kommentien perusteella sanoisin, että bugin hinta pitäisi olla mielestäni pikemminkin alhaisempi kuin korkeampi. Palvelun kohderyhmänä on asiakkaat, joiden tuotteesta löytyy ”kohtuullisesti” bugeja. Eli esim. vaikkapa tuoreen, nopeasti kehitetyn webbipalvelun kattavampi testaus ennen launchia (jota ovat aiemmin testanneet vain omat developerit).
Sitten kun mennään raskaampiin järjestelmiin, joiden on ”pakko toimia”, niin tämänkaltainen palvelu ei varmaankaan ole sopiva. Mutta voisiko olettaa, että niissä jo lähtökohtaisesti laadunvarmistus on toisella mallilla eivätkä he edes hae tämänkaltaista palvelua.
Benchmarkatkaa (hui, en osannut kääntää sanaa) oletettua hintalappia tuolle viimeksi esitetylle kontekstille Utestin vastaavaan. Juuri tuossa kuulin että vaikka ovat sentään hinnoittelumalliin tuoneet ”mainelisän” jolla voi saada kymmenkertaisen palkkion, lähtökohtaisesti bugista (vain hyväksytyt, ensimmäinen raportti) maksetaan paria euroa.
Eli kalliilla ostaisin vielä Anttia 75 € hinnallakin.