Tämä on lista yleisimmin käytetyistä ohjelmistojen testaustermeistä, jotka projektipäälliköiden, uusien testauspäälliköiden ja liiketoiminnan testaajien on hyvä tietää. Tämä testaussanasto on tarkoitettu sinulle, joka olet tekemässä tietojärjestelmän käyttöönottoprojektia ja ohjelmiston testaus ei ole kovinkaan tuttua. Sanasto on kirjoitettu liiketoimintavetoisen testauksen näkökulmasta – testauksen, jolla on tarkoitus varmistaa, että käyttöönotettava ohjelmisto toimii kuten pitääkin.
Testaussanastoa on avattu ymmärrettävästi vinkkien ja esimerkkien avulla. Sanastoa päivitetään aktiivisesti eli jos huomaat, että ollennainen termi puuttuu tai selitys ontuu, kerro siitä meille kommenteissa!
Testauksen termit
Tämä ei ole, eikä yritäkään olla, täydellinen lista testauksen termeistä, mutta jos olet ihmetellyt, mistä kollegasi puhuvat, kun kuulet sanoja savutestaus, UAT tai regressiotestaus, olet tullut oikeaan paikkaan. (Jos etsit täydellistä listaa testaussanastosta, sellainen löytyy ISTQB:n sivuilta.)
Ohjelmistotestaus ei ole salatiedettä, vaan ymmärrettävä ja tärkeä osa kaikkia tietojärjestelmäprojekteja. Kuka tahansa osaa testata pienellä opastuksella ja hyvän testausohjelmiston tuella.
Testaussanasto
Datamigraatio (Data Migration)
Datamigraatiossa siirretään tietoja tietojärjestelmästä toiseen. Tyypillisesti siirrettäviä tietoja on paljon, ja siirtoa tehdessä dataa joudutaan muokkaamaan uuteen järjestelmään sopivaksi. Siirron yhteydessä halutaan myös selkeyttää, yhtenäistää ja siivota dataa.
Datamigraatio viimeistellään usein järjestelmien käyttöönottovaiheessa, jolloin saadaan tuorein data vietyä uuteen järjestelmään. Datamigraatiossa halutaan automatisoida tietojen vientiä niin paljon kuin mahdollista ajan ja resurssien säästämiseksi sekä datan laadun säilyttämiseksi.
ERP-projekti / Toiminnanohjausjärjestelmän käyttöönotto (ERP-project, Enterprise Resource Planning)
ERP eli toiminnanohjausjärjestelmä on tietojärjestelmä, jolla hallitaan useita yrityksen toimintoja. Tyypillisesti sen keskiössä on talous, jonka ympärille tulee esim. tuotantoa, varastonhallintaa, palkanlaskentaa, projektitoimintaa tai muuta toimintaa ohjaavaa, integroitua järjestelmää.
ERP-projektien ongelma on, että usein yritys ei ymmärrä niiden tuomaa muutosta koko laajuudessaan. ERP-projektit vaikuttavat ohjelmiston ohella tyypillisesti koko yrityksen päivittäiseen toimintaan ja aiheuttavat laajoja organisaation ja työnkuvien muutoksia. ERP-projektin hallinta vaatii osaamista projektipäälliköltä, testauspäälliköltä ja operatiivista toimintaa ohjaavilta ihmisiltä, että kaikki projektiin liittyvä muutos ja projektin scope pysyy hallinnassa.
Havainto / löydös / poikkeama (Incident, issue)
Havainto, joka tehdään testatessa. Havainto ei ole välttämättä virhe, vaan se voi olla mitä vaan kirjoitusvirheestä huonoon rivitykseen tai toimintoon, joka ei toimi parhaalla mahdollisella tavalla. Havainnosta voi myöhemmin tulla vaikka virheraportti tai kehitysehdotus. Pääasia on, että kaikki havainnot kirjataan.
Havaintojen / virheiden hallinta (Incident Management)
Prosessi, jolla havainnot raportoidaan, korjataan, osoitetaan uudelleentestattaviksi ja todetaan toimiviksi. Esimerkiksi niin, että testaaja löytää havainnon, kirjaa sen testausohjelmistoon ja osoittaa sitten testauspäällikölle. Testauspäällikkö varmistaa, että kyseessä on oikea havainto ja osoittaa sen toimittajan konsultille korjattavaksi. Konsultti ilmoittaa testauspäällikkölle kun havainto on korjattu, joka taas osoittaa virheen uudelleentestaukseen testaajalle.
Hyväksymistestaus, hyväksyntätestaus (Acceptance testing, UAT, User Acceptance Testing)
Hyväksymistestaus on viimeinen validointi, jossa testataan, että liiketoiminnan prosessit toimivat alusta loppuun asti juuri niin kuin pitääkin ennen ohjelmiston käyttöönottoa. Hyväksymistestaus täytyy tehdä mahdollisimman valmiissa toimintaympäristössä ja oikealla datalla. Kaiken, myös esimerkiksi liittymien tulisi jo tässä vaiheessa toimia. Muuten ei yksinkertaisesti olla tekemässä hyväksymistestausta.
Integraatiotestaus, integrointitestaus (Integration testing)
Testataan eri ohjelmistojen välisiä liittymiä eli integraatioita. Varmistetaan, että data liikkuu ohjelmistojen välillä oikea-aikaisesti, oikeassa muodossa ja oikein arvoin.
Ketterä ohjelmistokehitys (Agile software development)
Kokoelma ohjelmiston kehitysmetodeja, joissa ratkaisut toteutetaan yhteistyössä toimittajan ja asiakkaan kanssa itseohjautuvien moniosaajaatiimien avulla. Ketterät kehitysmetodit ovat ohjelmistokeskeisiä, nopeaan muutokseen, reagointiin ja kommunikaatioon perustuvia kehitysmalleja, joissa pyritään tekemään iteraatioita ohjelmistosta nopealla syklillä. Ketteriä menetelmiä ohjelmiston kehitykseen ja testaukseen on kymmeniä erilaisia, esimerkkeinä Scrum, DevOps ja SAFe. Ohjelmistojen käyttöönottoprojektit ovat usein hybridiprojekteja, joissa projektia hallitaan perinteisimmin, vesiputousmetodein ja itse ohjelmiston kehitystä tehdään ketterästi.
Konversiot / Tietojen konvertointi (Data conversion)
Konversiossa muutetaan tietoja tai tiedostoja yhdestä formaatista toiseen. Konversioita tehdään yleensä tietojärjestelmien käyttöönotoissa, kun vanhan järjestelmän tieto viedään uuteen järjestelmään, mutta välissä data pitää konvertoida yhteensopivaksi uuden järjestelmän kanssa.
Kuormitustestaus, suorituskykytestaus (Load, performance testing)
Testaus, jolla mitataan toimiiko ohjelmisto, kun sitä kuormitetaan. On aina hyvä varmistaa ohjelmiston toimivuus rasituksen alla ennen käyttöönottoa. Ohjelmisto voi toimia moitteettomasti muutamalla testikäyttäjällä, mutta lakata toimimasta kun tuotantokäyttö alkaa ja kuormitusta tulee enemmän.
Käyttäjätarina (User story)
Termi, jota käytetään usein ketterässä kehityksessä. Käyttäjätarina on tapa kirjoittaa auki liiketoiminnan vaatimukset selkokielellä.
Käyttötapaus (Use case)
Tietty liiketoiminnan prosessi tai osa prosessista kuvattuna selkokielellä.
Käyttöönottoharjoitus (Go-Live Practice)
Kenraaliharjoitus, joka tehdään IT-projektissa ennen ohjelmiston käyttöönottoa. Käyttöönottoharjoituksen tarkoituksena on varmistaa, että kaikki käyttöönottoon liittyvät tehtävät ehditään tekemään käyttöönotolle varatussa aikaikkunassa ja varmistaa, että käytössä on täydellinen lista käyttöönoton tehtävistä.
Käyttöönottoharjoitus on parasta tehdä, kun hyväksymistestaus aloitetaan. Käyttöönottoharjoitukselle varataan sama aika, kuin suunnitellulle käyttöönotolle. Esimerkiksi jos käyttöönotto tehdään viikonloppuna, varataan harjoitukselle vastaava aika (normaaleina työpäivinä).
Käyttöönottoharjoituksessa tehdään kaikki suunnitellut tehtävät, kuten datakonversiot ja migraatiot, simuloidaan järjestelmien sammuttaminen, ja integraatioiden käynnistäminen. Kun käyttöönottoharjoitus tehdään oikean käyttöönoton lailla, saadaan myös laadukas hyväksymistestaus, joka suoritetaan oikealla, tuoreella datalla ja tuotantoa vastaavassa ympäristössä.
Laatuportti (Quality Gate)
Tarkastuspiste projektin vaiheiden välillä, jolla on tietyt laadulliset kriteerit portin läpäisylle. Portin tarkoituksena on varmistaa, että edellinen vaihe on laadullisesti riittävän hyvällä mallilla ja seuraavaan vaiheeseen voidaan edetä. Esimerkiksi, jos projekti on jaettu toimituspaketteihin, ei kannata aloittaa seuraavan toimituspaketin toteutusta, jos edellisessä toimituspaketissa on liikaa virheitä avoimena. Laatuongelmilla on tapana kasaantua ja tehdä testaus hitaaksi tai mahdottomaksi kun virheitä on liikaa auki.
Liiketoimintaprosesseihin perustuva testaus (Business process-based testing)
Tapa testata, jossa liiketoiminta puretaan prosesseiksi esimerkiksi kaavioiden ja käyttötapausten avulla ja testitapaukset kirjoitetaan niiden pohjalta. Tämä on erittäin toimiva tapa testata nimenomaan ohjelmiston soveltuvuutta yrityksen liiketoimintaan. Prosesseihin perustuva testaus mahdollistaa myös kehitysprojektin johtamisen. Kun liiketoimintaprosessit piirretään auki, puretaan käyttötapauksiksi ja niihin liitetään testitapaukset, voidaan seurata määrittelyjen edistymistä, testauksen kattavuutta ja testitapausten valmistelua sekä testauksen edistymistä prosessitasolla. Liiketoimintaprosesseihin perustuva testaus on hyvä tapa varmistaa käyttöönotettavan ohjelmiston laatu.
Loppukäyttäjä (End User)
Loppukäyttäjiä ovat ne henkilöt, jotka tulevat käyttämään käyttöönotettavaa ohjelmistoa. Ohjelmiston pitää toimia heidän päivittäisessä työssään ja helpottaa heidän työskentelyään
Manuaalinen testaus (Manual testing)
Manuaalisessa testauksessa testaaja varmistaa, että ohjelmisto toimii kuten pitääkin suorittamalla prosessin tai toiminnon testattavalla ohjelmistolla. Testaus on usein ennalta suunniteltu ja jaoteltu testitapauksiin. Testitapauksissa prosessi on pilkottu testitapauksen askeleisiin, joka on tyypillisesti yksi suoritettava toiminto, esimerkiksi “lisää myyntitilaukselle X tuotetta Y kappaletta”. Testitapauksen askeleella on usein myös odotettu lopputulos, jolla varmistetaan, että järjestelmä toimi kuten pitääkin, esimerkiksi “tarkista, että laskulle tuli X tuotetta Y kappaletta”. Ennalta suunnitellut testitapaukset ovat tärkeitä testauksen laadun, luotettavuuden ja kattavuuden arvioinnin takia. Jos testaus ei ole suunniteltua ja vain ”kokeillaan” ohjelmistoa, testauksen tulokset ovat äärimmäisen epäluotettavia ja kriittisiäkin virheitä pääsee helposti tuotantoon asti.
Muutoksenhallinta, muutostenhallinta (Change management)
Tapa hallita projektinaikaisia muutoksia. Projektin aikana tulee kehitysehdotuksia ja avoimia asioita ratkaistavaksi ja on tärkeää, että projektilaisilla on tapa raportoida ne. Kehitysehdotukset käsitellään sovitun prosessin mukaisesti nopeasti, eivätkä ne saa jäädä roikkumaan. Esimerkiksi kun projektilaisella tulee kehitysehdotus, hän kirjaa sen projektinhallintaohjelmistoon. Kehitysehdotus käsitellään seuraavassa projektipalaverissa, jossa se joko hyväksytään tai hylätään. Tärkeää on, että kehitysehdotus huomioidaan ja siitä tehdään perusteltu päätös. Muutoksenhallinta on tyypillisesti osa-alue, jossa projektit ajautuvat ongelmiin. Jos muutosta ei hallita järjestelmällisesti, projekti saattaa karata käsistä ja muuttua hallitsemattomaksi.
Määrittelyvaihe (Specification phase)
Projektin vaihe vaatimusten keruun jälkeen, jossa määritellään, eli piirretään ja kirjoitetaan auki, miten liiketoiminnan prosessien halutaan projektin jälkeen toimivan. Määrittelyt voidaan jakaa esimerkiksi liiketoimintaprosessien mukaan käyttötapauksiksi. Tärkeää on, että määrittelyt ovat sellaisella tasolla, että a) toimittaja ymmärtää selkeästi, miten asiakas haluaa toimia, b) liiketoiminnan ihmiset ymmärtävät, miten ohjelmisto tulee toimimaan ja c) määrittelydokumenteista voidaan kirjoittaa testitapaukset, joilla validoidaan, että ohjelmisto toimii kuten pitääkin.
Negatiivinen testaus (Negative testing)
Varmistetaan, että ohjelmisto ei anna käyttää arvoja tai syötteitä, joita sen ei pidäkään hyväksyä. Eli syötetään tahallaan vääriä arvoja ja varmistetaan, että ohjelmisto ilmoittaa niistä.
Odotettu tulos, odotettu lopputulos (Expected result)
Lopputulema, jonka testauksen pitäisi tuottaa, jos kaikki menee kuten pitääkin.
Ohjelmiston testaus (Software testing)
Testauksen tarkoituksena on saada selville, vastaako ohjelmisto sille asetettuja liiketoiminnan vaatimuksia ja toimiiko ohjelmisto kuten pitääkin. Ohjelmiston käyttöönottoprojektissa fiksuinta on testata ohjelmistoa liiketoiminnan tarpeita vastaan. Suoritetaan niitä toimenpiteitä, joita ohjelmistolla tehtäisiin tuotantokäytössä ja katsotaan, tukeeko ohjelmisto meidän prosessejamme ja toimiiko se niin kuin halusimme.
Prioriteetti, tärkeys (Priority)
Prioriteetti kertoo tekijälle, missä järjestyksessä tehtävät pitää suorittaa. Testaajalle se kertoo, missä järjestyksessä testitapaukset pitää testata ja konsultille, missä järjestyksessä virheet korjataan. Prioriteetteja on usein 3-4 eri tasoa kiireettömästä kriittiseen. Esimerkiksi 1. Kriittinen (tehdään heti) 2. Korkea (tehdään kun kriittiset on tehty) 3. Matala (ei kiirettä).
Proof of Concept, POC
POCin on nimensä mukaisesti tarkoitus todentaa, että ohjelmisto toimii siihen tarkoitukseen, johon sitä ollaan hankkimassa. IT-projektissa POC on todella hyvä tapa kilpailuttaa ja vertailla toimittajia. Määritellään ohjelmistolla tavoiteltavat ydinprosessit, joita halutaan kehittää, ja pyydetään toimittajia demoamaan konkreettisesti, miten prosessi menee heidän tuotteellaan. Tekemällä POC potentiaalisten toimittajien kanssa saadaan selkeä kuva ohjelmistojen toiminnasta. Niitä voidaan vertailla ja pisteyttää keskenään ja valita ohjelmisto, joka tukee haluttuja prosesseja parhaiten.
Regressiotestaus (Regression testing)
Jo kertaalleen testatun ohjelmiston uudelleentestaus sen jälkeen, kun ohjelmistoon on tehty muutoksia. Tarkoituksena on varmistaa, että tehdyt muutokset eivät ole rikkoneet mitään aiemmin toimivaksi todettua.
Savutestaus, savutesti (Smoke test)
Nopea, alustava testaus, jossa käydään läpi version tärkeimmät toiminnallisuudet ja arvioidaan, onko versio riittävän vakaa tarkempaan testaukseen. Vastaa kysymykseen: Toimiiko se ollenkaan?
Scope /Laajuus projektinhallinnassa (Scope)
Laajuudella määritetään, mikä kaikki kuuluu projektin piiriin ja mikä ei. Projektin laajuus on syytä määrittää tarkasti. Tehdään yhdessä selkeä rajanveto, että nämä asiat tai ominaisuudet toteutetaan projektin aikana, nämä taas jätetään odottamaan esimerkiksi kehitysversiota. Tarkoituksena on saada ohjelmisto tuotantokäyttöön, ja projektin scopen laajeneminen on yksi suuri syy siihen, miksi tuotantoon meno viivästyy. Viivästyksien välttämiseksi tee vaatimusten keräys ja määrittely huolellisesti ja lyö scope lukkoon niiden perusteella. Jos ja kun kehitysehdotuksia tulee projektin aikana, tee niistä omat kehitysversionsa, jotka toteutetaan, kun pääprojektin tavoitteet on saavutettu.
Systeemitestaus (System testing)
Vaihe integraatiotestauksen jälkeen, jossa arvioidaan koko järjestelmän toimivuutta, kun integraatiot ovat käytössä.
Testauksen hyväksymiskriteerit (Acceptance criteria)
Ennen testauksen tai koko projektin aloitusta on hyvä määrittää kriteerit, joilla todetaan, että ohjelmisto toimii niin kuin pitääkin. Ohjelmistoprojektissa ”toimiva ohjelmisto” voi olla toimittajan mielestä sellainen, jolla parin kiertotien kautta saadaan toiminto suoritettua. Asiakkaan mielestä ohjelmisto ei taas toimi lainkaan. Toiminto pitää saada suoritettua tehokkaasti ilman turhia kiertoteitä, jotta se voidaan todeta toimivan niin kuin pitääkin. Toimivan ohjelmiston kriteerit on parasta määrittää jo sopimusta tehdessä.
Testauksen kattavuus
Testatessa on tärkeä varmistaa, että kaikki liiketoiminnan prosessit on huomioitu eli katettu testitapauksilla. Parhaiten tämä onnistuu, kun liiketoimintaprosessit piirretään auki prosesseiksi, prosessit pilkotaan käyttötapauksiksi ja käyttötapauksiin liitetään testitapaukset. Näin voidaan olla varmoja, että testitapaukset kattavat kaikki olennaiset liiketoimintaprosessit, eikä mikään jää testaamatta.
Testausautomaatio, automaattitestaus (Test automation)
Testausautomaatio-ohjelmistoja voidaan käyttää automatisoimaan toistuvia testauksia kehitettävään ohjelmistoon. Testausautomaatio on hyvä työkalu ohjelmistotoimittajan työkalupakissa, koska he kehittävät samaa ohjelmistoa ja testausautomaatio voi auttaa esimerkiksi regressiotestausten automatisoinnissa. Testausautomaatio ei yleensä ole hyödyllinen asiakkaalle, joka on ottamassa käyttöön uutta ohjelmistoa. Siinä tapauksessa testaukset ovat kertaluonteisia, eikä ohjelmiston toimivuuden testaus ole, eikä sen tule olla, asiakkaan harteilla. Asiakkaan tulee keskittyä varmistamaan, että ohjelmisto tukee heidän liiketoimintansa prosesseja ja tämä tapahtuu käytännössä manuaalisella testauksella.
Testausohjelmisto, testaustyökalu, testauksenhallintaohjelmisto (test management tool, test management software)
Ohjelmisto, joka auttaa testauksen suunnittelussa, testitapausten luonnissa, organisoimisessa ja testauksessa. Testausohjelmisto auttaa hahmottamaan testauksen kattavuuden ja seuraamaan testauksen edistymistä reaaliajassa. Testausohjelmisto voi myös auttaa virheiden raportoinnissa, virheiden korjausten seurauksessa sekä toimia yhteistyöalustana kaikille kehitysprojektin osapuolille. Excel ei ole testaustyökalu. Esimerkiksi ProjectTOP on suomalainen, suomenkielinen testausohjelmisto.
Testauspäällikkö / Testausvastaava (Test Manager)
Testauspäällikkö nimensä mukaisesta vastaa ohjelmiston testauksesta, sekä siitä, että kaikki toimii käyttöönotossa. Testauspäällikkö on syytä ottaa ohjelmistoprojektiin mukaan heti projektia suunnitellessa, koska testaus ja miten se on suunniteltu suoritettavan, vaikuttaa koko projektiin. Projektin alussa testauspäällikkö tekee testaussuunnitelman, jossa määritetään miten käyttöönotettavan ohjelmiston laatu, tullaan varmistamaan. Projektin edetessä testauspäällikkö huolehtii testauksen resurssoinnista, testausprojektien suunnittelusta, testauksen kattavuudesta, testitapausten kirjoituksesta, testauksesta ja virheiden korjauksesta. IT-projekteissa toteutuksen aikana testaus on tyypillisesti yksi tärkeimpiä edistymisen mittareita ja nimenomaan testaus kertoo, onko ohjelmisto valmis käyttöönotettavaksi.
Testaussuunnitelma, kokonaistestaussuunnitelma (Test plan, master test plan)
Suunnitelma siitä, miten käyttöönotettavan ohjelmiston laatu tullaan varmistamaan. Testaussuunnitelma on tehtävä samaan aikaan projektisuunnitelman kanssa, eli projektin alkuvaiheessa. Testaus on olennainen osa kehitysprojektia. Se on linkissä vaatimuksiin ja prosesseihin, joita kerätään projektin alussa, ja jotka ovat projektin laadullisia mittareita koko projektin läpi. Testaussuunnitelmassa on tärkeää sopia testausprosessi yhdessä toimittajan kanssa ja huomioida myös virheiden- ja muutoksenhallinta. Testaussuunnitelmassa otetaan kantaa siihen, kuka on vastuussa mistäkin testauksen osa-alueesta ja pidetään yllä testaukseen liittyviä riskejä. Testaussuunnitelmassa huomioidaan, miten testauksen kattavuutta mitataan ja miten testauksen edistymistä raportoidaan. Testaussuunnitelmassa määritetään etukäteen testauksen aloitus- ja hyväksymiskriteerit.
Testitapaus (Test case)
Ennalta suunnitellut testauksen ehdot, syötteet, askeleet ja odotetut lopputulokset, joilla varmistetaan, että tietty prosessi tai toiminto toimii kuten pitääkin. Esimerkiksi jos testataan myyntitilauksen syöttämistä, voidaan määrittää:
- Ehdot (valitse kotimainen asiakas, valitse tuote, jota ei ole saldolla)
- Syötteet (valitse asiakas numero 123, lisää tuotetta X 100 kappaletta)
- Askeleet (tallenna myyntitilaus, vapauta tilaus keräilyyn)
- Odotetut lopputulokset (myyntitilaus syntyy asiakkaalle X, tuote, jota ei ole saldolla, siirtyy jälkitoimitukseen)
Suunnitelmallisen testauksen etuna on, että testataan järjestelmällisesti ja liiketoiminnan kannalta merkityksellisiä tapahtumia. Virheiden raportointi on helppoa, kun testitapaukset on suunniteltu etukäteen ja virheet ovat toistettavissa ja siten myös korjattavissa. Järjestelmällisen testauksen avulla löydetään virheitä, jotka helposti lipsahtaisivat tuotantoon asti.
Vaatimusmäärittely (Requirements definition)
Vaatimukset ovat lista toimintoja ja toiveita, jotka tulevan ohjelmiston pitää täyttää. Laadukkas vaatimusmäärittely on onnistuneen hankinnan perusta. Vaatimukset muodostavat käyttöönottoprojektin selkärangan ja vastaavat osaltaan kysymykseen, mitä kaikkea ohjelmiston täytyy tehdä. Vaatimukset kulkevat usein koko projektin läpi. Vaatimuksia voidaan hyödyntää prosessikuvien piirtämisessä, toimittavalinnassa, muutosten hallinnassa ja testitapausten kirjoituksessa. Kun projektin jokaisessa vaiheessa varmistetaan, että vaatimukset täyttyvät, käyttäjät tulevat saamaan haluamansa ohjelmiston. Lue lisää vaatimusmäärittelystä.
Vaatimusten keruuvaihe (Requirement gathering phase)
Vaihe kehitysprojektin alkupäässä, jossa kysytään käyttäjiltä mitä käyttöönotettavalta ohjelmistolta halutaan ja mitä hyötyjä ohjelmistolla tavoitellaan. Mitä ominaisuuksia käyttäjät toivovat uudelta ohjelmistolta ja mikä hyödyntäisi heidän päivittäistä työtään eniten? Mitä vaatimuksia ohjelmiston pitää täyttää, jotta saavutetaan kehitysprojektilla tavoiteltavat hyödyt? Lue lisää vaatimusmäärittelystä osana hankintaprojektia.
Vakavuus (Severity)
Vakavuus kertoo löydetyn virheen vaikutuksen toimintaan. Vakavuustasoja on usein 3-4 kosmeettisesta käytön estävään. Esimerkiksi 1. Käytön estävä 2. Vakava 3. Vähäinen 4. Kosmeettinen.
Vesiputousmallin ja ketterän kehityksen yhdistelmä, hybridi kehitysmalli (Hybrid between waterfall and agile development)
Aidosti ketterä kehitys vaatii paljon organisaatiolta. Siitä syystä varsinkin suuremmat organisaatiot käyttävät usein vesiputousmallin ja ketterän kehityksen yhdistelmää. Siinä yhdistyvät suunnitelmallinen projektinhallinta ja ketterä kehitysvaihe. Eli ohjelmiston kehitykseen sovelletaan ketteriä menetelmiä, muuten projekti aikataulutetaan ja suunnitellaan järjestelmällisesti. Usein suurempi organisaatio ei lähde projektiin tietämättä aikataulua tai hintalappua ja sitoutuminen aidosti ketterään toimintaan vaatii organisaatiolta paljon osaamista ja resursseja. Hybridiprojektit ovat järkevä tapa toteuttaa suuria tietojärjestelmäprojekteja.
Vesiputousmallinen kehitys (Waterfall)
Vesiputousmallin kehitysprojektissa projekti jaetaan vaiheisiin, jotka mennään läpi yksi kerrallaan. Vaiheet ovat tyypillisesti vaatimusten keruu – määrittely – toteutus – testaus – käyttöönotto. Usein vaiheet menevät ainakin jonkin verran päällekkäin ja käytössä on myös jonkinlainen hybridimalli vesiputousmallisen ja ketterän projektin välistä. Vesiputousmallisen kehitysprojektin hyviä puolia on se, että jos määrittelyt tehdään projektin alussa hyvin, projektin aikana tulee vähemmän yllätyksiä ja projektin edistymistä on helpompi seurata.
Yksikkötestaus (Unit testing)
Testataan yksittäisiä toimintoja tyypillisesti koodausvirheiden varalta. Tämä on toimittajan kehittäjien tekemää työtä, jossa varmistetaan, että tehty kehitys toimii teknisesti ennen kuin se asennetaan asiakkaalle.
