Kuten jossain vaiheessa mainitsin kehitin järjestelmää tietynlaisella sovelletulla ad-hoc xp mallilla. Ensin ideoin, sitten koodasin toiminnon. Sen jälkeen testasin sitä niin paljon kun viitsin, pystyin ja jaksoin. Ja sitten vain koodi käyttöön.
Mikä tässä tavassa on hyvää:
- Toimivaa koodia valmistuu koko ajan. Tämä mahdollistaa sen, että sovellusta voi kehittää omassa tahdissa. Tunti silloin tällöin toi aina uusia toiminnallisuuksia.
- Perus "use case" tuli testattua aika hyvin. Eli toiminnallisuus teki juuri sen mitä sen oli tarkoituskin.
- Motivaatio pysyi korkealla, kun näki käden jäljen koko ajan.
Kehitysmetodologiaa valittaessa arvioi omat mahdollisuutesi reagoida virheisiin ja syntyvän riskin tasosta. Jos teet sovellusta itsellesi, voit varmasti ottaa riskejäkin vapaammin.
Mikäs sitten oli huonoa:
- Testaus oli/on ehdottoman vajavaista [tästä lisää myöhemmin]. Kuten sanottu, suurin osa testauksesta kohdistui juuri tuohon perus toimintaan. Mutta raja-arvoja ja virhetilanteita ei juurikaan tullut testattua. Tämä sopi hyvin tähän vaiheeseen ohjelmointia, missä prioriteetti oli saada toimivaa softaa ulos mahdollisimman pian.
- Virheitä alkoi löytymään. Tämä on tietenkin seurausta vajavaisesta suunnittelusta ja puutteellisesta testaamisesta.
Se onko tämä ongelma riippuu sinusta, ja palvelun suosiosta. Jos pystyt reagoimaan virheisiin nopeasti, ei todellisia ongelmia pääse syntymään. Ja jos palvelu on vielä alkutaipaleella, ei imagollisia tappioitakaan juuri tule. Tämä on haastajan / pienen palvelun etuoikeus.
www.mutteri.com:in tapauksessa olin varautunut siihen, että lopullinen käyttötestaus tapahtuu vasta oikeilla käyttäjillä. Minä en ollut perehtynyt varsinaisesti testaamiseen, testausmetodologioihin tai testaustyökaluihin. Luotin siihen, että pieni tuntematon palvelu, jolla ei vielä ole hävittävää, saa paljon anteeksi.
Ei kommentteja:
Lähetä kommentti