User Acceptance Testing (UAT)

Käyttäjätestaus on viimeinen validointivaihe, jossa yrityksen tai käyttäjäyhteisön edustajat vahvistavat, että järjestelmä täyttää sille asetetut vaatimukset ja sopii aiottuun tarkoitukseen. Se suoritetaan toiminnallisen testauksen jälkeen, tyypillisesti tuotantoympäristöä muistuttavassa ympäristössä, ja sen tuloksena tehdään päätös julkaisusta.

Se vastaa eri kysymykseen kuin sitä edeltävä testaus. Kehittäjä- ja laadunvarmistustestaus selvittää, toimiiko järjestelmä määritellyllä tavalla; hyväksymistestaus puolestaan ​​selvittää, vastaako määritellyt asiat todella liiketoiminnan tarpeita. Työ voi läpäistä jokaisen toiminnallisen testin ja silti hylätä hyväksynnän, koska määrittely oli puutteellinen, koska prosessia ymmärrettiin väärin tai koska reaalimaailman tapausta, jota kukaan ei ole dokumentoinut, ei ole käsitelty.

Merkittävin sekaannus on hyväksymistestauksen ja käytettävyystestauksen välillä. Hyväksymistestauksessa käytetään liiketoimintaprosessia tuntevia ihmisiä, jotka työskentelevät läpi erilaisia ​​skenaarioita varmistaakseen, että järjestelmä tukee niitä. Käytettävyystestauksessa tarkkaillaan edustavia käyttäjiä, jotka kohtaavat tuotteen ilman ohjausta, jotta voidaan selvittää, voidaanko sitä ymmärtää ja käyttää. Toisen korvaaminen toisella on vakava virhe: järjestelmä voi saada asiantuntevien sidosryhmien hyväksynnän, mutta se voi jäädä käyttökelvottomaksi niille ihmisille, joille se on rakennettu.

Osallistujien valinta määrittää, mitä harjoituksella voidaan löytää. Projektitiimin tai koko ajan mukana olleiden ja järjestelmän toimintatavan tuntevien sidosryhmien suorittama testaus varmistaa, että rakenne vastaa yhteistä ymmärrystä eikä löydä juuri muuta. Järjestelmän tosiasiallisen käyttäjän ja suunnittelukeskusteluun osallistumattomien henkilöiden mukaan ottaminen nostaa esiin aiotun ja todellisen prosessin väliset kuilut.

Skenaariosuunnittelun tulisi seurata todellista työtä eikä ominaisuuslistoja. Järjestelmän tukemien operatiivisten tehtävien läpikäyminen, mukaan lukien hankalat poikkeukset, jotka muodostavat suuren osan todellisesta käytännöstä, löytää ongelmia, joita ominaisuuskohtainen tarkistus ei löydä. Realistinen data on yhtä lailla tärkeää, koska järjestelmät, jotka toimivat oikein puhtaalla testidatalla, epäonnistuvat usein tuotantoympäristön virheellisesti muotoiltujen, epätäydellisten ja epätavallisten tietueiden osalta.

Vaihe on rakenteellisesti altis pakkaamiselle, koska se sijaitsee yleensä jo lipsahtaneen aikataulun lopussa. Hyväksymistestaus suoritetaan sitten murto-osassa suunnitellusta ajasta, kun osallistujat sujauttavat sen normaaleiden vastuidensa väliin, ja löydetyt viat luokitellaan julkaisun jälkeisiksi korjauksiksi. Realistisen keston aikatauluttaminen, osallistujien ajan varmistaminen etukäteen ja havainnon vakavuuden sopiminen etukäteen viivästyttäisi julkaisua estävät sen muuttumisen muodollisuudeksi.

Vika-asioiden triage-kriteereistä tulisi sopia ennen testauksen aloittamista sen sijaan, että niistä neuvoteltaisiin paineen alla löydösten jälkeen. Ongelmakategorioiden määrittäminen, jotka estävät prosessin vapautumisen, mitkä korjataan välittömästi sen jälkeen ja mitkä kirjataan myöhempää käyttöä varten, poistaa väittelyn hetkestä, jolloin kaupallinen paine jatkaa on suurin ja arvio vähiten luotettava.

Koska hyväksyntä vahvistaa soveltuvuuden liiketoimintatarkoitukseen sanomatta mitään siitä, voivatko loppukäyttäjät todella käyttää järjestelmää, tarvitaan molempia validointimuotoja. Käytännössä hyväksymisvaihe suunnitellaan tuotekehitys osana julkaisuprosessia, kun taas erilliseen kysymykseen siitä, pystyvätkö oikeat käyttäjät suorittamaan tehtäviään, vastataan käyttäjän tutkimus, ja sisäisten järjestelmien osalta skenaarioiden toiminnallinen realistisuus riippuu yleensä siitä, onko niihin otettu mukaan IT-osasto ja tiimit, jotka tukevat järjestelmää julkaisun jälkeen.