Miksi tarvitsemme käyttäjän hyväksymistestausta (UAT)?

Kirjoittaja: Judy Howell
Luomispäivä: 5 Heinäkuu 2021
Päivityspäivä: 1 Heinäkuu 2024
Anonim
Miksi tarvitsemme käyttäjän hyväksymistestausta (UAT)? - Tekniikka
Miksi tarvitsemme käyttäjän hyväksymistestausta (UAT)? - Tekniikka

Sisältö



Lähde: Lightcome / iStockphoto

Ottaa mukaan:

Kun ohjelmisto on läpikäynyt yksikkö-, integraatio- ja järjestelmätestauksen, hyväksyntätestauksen tarve saattaa tuntua tarpeettomalta. Miksi käyttäjän hyväksymistestaus (UAT) on edelleen tärkeä? Täältä voit oppia hyvin UAT: n eduista ja miksi sen ainutlaatuisuus.

Esittely ja kuole!

Oletko koskaan järjestänyt asiakasesittelyä tai koulutusta, ja jotain murtuu puoliväliin? Tai oletko koskaan antanut jollekin ohjeita ja tajunnut, että olet unohtanut jotain, tai se ei toiminut aivan kuten odotit? Jokaisessa näissä tapauksissa omaksut loppukäyttäjän näkökulman ja työskentelet kyseisen persoonan ohjelmistojen kanssa. Todennäköisesti olet tehnyt jotain eri tavalla, koska ajattelit pikemminkin käyttäjää kuin kehittäjää.


Astu käyttäjien kenkiin

Käyttäjien hyväksyntätestauksen (UAT) ainutlaatuinen kulma on testata ohjelmisto loppukäyttäjänä. Ohjelmisto on rakennettu antamaan käyttäjille konkreettisia tuloksia. Esimerkiksi verkkokauppasivustoilla asiakkaat voivat ostaa tuotteita. Kun asiakas tekee tilauksen, verkkokauppasivusto-ohjelmisto ilmoittaa myymälän ylläpitäjälle, jotta valittu tuote voidaan vetää ja pakata lähetettäväksi. Ohjelmiston käyttäjiä voi olla erityyppisiä, joten tämän testausvaiheen avulla kehitysryhmä voi varmistaa, että loppukäyttäjät saavuttavat odotetut ohjelmistotulokset.

Lyhyt UAT-historia

Ennen Internetin syntymistä suurin osa ohjelmistoista otettiin käyttöön tunnetuille käyttäjäyleisöille. Jos yritys kehitti ohjelmiston asiakkaalle, nimetyllä johtajalla oli valtuudet tarkistaa, että ohjelmisto täyttää sopimusehdot. Tämän oli tarkoitus edustaa pistettä, jossa ohjelmisto oli "tarkoituksenmukainen", mikä saavutettiin valitsemalla loppukäyttäjien edustajat testaamaan ja toimittamaan raportti tuloksista. Koska käyttäjät olivat tunnettuja, suljettuja ryhmiä, jokainen voitiin kouluttaa ohjelmiston käyttöön, tyypillisesti erittäin yksityiskohtaisten testivaiheiden avulla. Päivän motto oli, että yksityiskohdat olivat parempia.


Kun web-asiakkaille kehitettiin yhä enemmän ohjelmistoja, loppukäyttäjäyleisö tuli avoimemmaksi. Kaikkia todennäköisiä loppukäyttäjiä ei enää voitu tunnistaa ja kouluttaa, joten ohjelmistosuunnittelussa oli painotettava paljon enemmän käytettävyyttä ja sen oli oltava helposti ymmärrettävää - jopa minimaalisesti annetulla tiedolla. Joten UAT: n piti muuttua näiden vaatimusten täyttämiseksi.

UAT kertoo, kuinka käyttökelpoinen järjestelmä on

Joten, UAT ei vain kerro meille tietyn ohjelmiston toiminnallisuuden laajuutta, vaan myös kertoo meille kuinka käyttökelpoinen se on. Suurin osa UAT: sta suoritetaan parhaiten sellaisten henkilöiden keskuudessa, jotka ymmärtävät kohdennetun loppukäyttäjän, joka kokee ohjelmiston vähällä ennakkotiedolla ja voi antaa todellisen kuvan ohjelmistojen helppokäyttöisyydestä ja parantamisen tarpeista.

Kuka voi suorittaa UAT: n?

Kehittäjinä testattaessa ohjelmistoja he muistavat yksityiskohdat järjestelmän kirjoittamisesta. Tämä tieto voi vaikuttaa testaamiseen, ja kehittäjät voivat ottaa erilaisia ​​vaiheita kuin loppukäyttäjät, esimerkiksi suorittaa vaiheet nopeammin tai hylätä hienoja yksityiskohtia, jotka loppukäyttäjät saattavat hämmentää. Siksi kehittäjät eivät ole parhaita UAT-ehdokkaita. Joten kuka on?

Monet organisaatiot käyttävät erityisiä testausryhmiä, jotka eivät ole mukana teknisessä suunnittelussa ja kehittämisessä. Pienemmät organisaatiot joko osoittavat testauksen henkilöstölle, joka ei ole kehitystyöntekijää, kuten henkilöille, jotka suorittavat hallinnollisia tehtäviä, tai käyttävät ulkopuolisen yrityksen palveluita. Jotkut organisaatiot käyttävät niin sanottua "käytävätestausta", jossa he kirjaimellisesti käsin valitsevat henkilökunnan jäsenet, jotka eivät ole aktiivisesti mukana projektissa, ja pyytävät heitä kokeilemaan järjestelmää loppukäyttäjien näkökulmasta. Esimerkki olisi tuotteen tilaaminen verkosta.

Sisäisen testauksen jälkeen voi tapahtua pilotti- tai beetatestausvaiheita, jolloin ohjelmisto annetaan pienille "oikeiden" käyttäjien ryhmille, joita kutsutaan käyttämään tuotetta ilmaiseksi tai huomattavan alennuksen kanssa vastineeksi yksityiskohtaisesta käyttöpalautteesta.

Ei vikoja, ei stressiä - vaiheittaiset ohjeet elämää muuttavien ohjelmistojen luomiseen tuhoamatta elämääsi


Et voi parantaa ohjelmointitaitojasi, kun kukaan ei välitä ohjelmiston laadusta.

Progressiiviset UAT-vaiheet vaihtelevalla yleisöllä lisäävät luottamusta ohjelmistojen käytettävyyteen. Yhdistettynä iteratiivisen kehitysvaiheen kanssa voidaan suorittaa useita UAT-jaksoja uusien ominaisuuksien testaamiseksi niiden toimittamisen yhteydessä, samalla kun varmennetaan aiemmat toiminnallisuudet.

Hyvät UAT-testaajat ovat uteliaita näkemään, mitä tapahtuu, jos he kulkevat eri reittejä tiettyyn tavoitteeseen. Loppujen lopuksi kaikki lähestyvät ohjelmistojen käyttöä eri tavoin, joten jos pieni ryhmä ihmisiä voi kattaa monia mahdollisuuksia, ohjelmistojen luottamus käyttötapaan on suurempi.

Menestys ja epäonnistuminen virtaavat

UAT-prosessien tulisi varmistaa, että jokainen ohjelmiston käyttäjän tyyppi saa konkreettisia tuloksia, joita tarvitaan sekä menestykseen että epäonnistumiseen.

Menestysvirrassa loppukäyttäjä kävelee pois odotetulla tuloksella, kuten esimerkiksi tilaamalla tuotetta. Vikavirtassa ohjelmisto tukee loppukäyttäjää jonkinlaisen virheskenaarion kautta, esimerkiksi kun asiakas antaa virheellisiä luottokorttitietoja.

Toimintojen tarkistamiseksi testaajille on annettava joitain tietoja. Muuten he eivät tiedä mitä ohjelmiston on tarkoitus tehdä. Mutta käytettävyyden testaamiseksi tämän on oltava minimaalista - vain tehtävään tai vaatimuksiin perustuvia, kuten "x" (tuote) ostaminen ja "y" maksaminen (luottokorttitietojen käyttäminen). Testaajille on asetettava velvollisuus tallentaa havaintoja, onnistumisia ja epäonnistumisia.

UAT-edut

Hyvän UAT: n tärkein etu on, että se pitää jatkuvat ylläpitokustannukset mahdollisimman alhaisina. Se on halvempaa korjata toiminnallisuus- ja käytettävyysongelmat aikaisin. Vian korjaaminen on paljon vaikeampaa, kun sen ympärillä on enemmän koodia regressiotestiin tai jos alkuperäinen kehittäjä ei ole käytettävissä.

Useissa vaiheissa ja erityyppisillä testiyleisöillä suoritettu UAT tarjoaa optimaaliset mahdollisuudet tunnistaa ja korjata rikkoutuneet ominaisuudet / käytettävyysongelmat testauksen alkuvaiheissa. UAT-tavoitteiden pitäminen tehtävä- ja vaatimustasolla antaa testaajille tarkkailla ja huomata paljon enemmän ja jopa yrittää askelta kehittäjien tarjoaman laajuuden ulkopuolella.

UAT-syklien palautetta voidaan käyttää myöhempiin kehityskertauksiin, mikä lisää ohjelmistojen tukevuutta ja käytettävyyttä. Hyvin ajoitettu, jopa beetatestausvaiheet voivat täydentää markkinointi- ja myyntitoimintaa tarjoamalla referenssejä ja tapaustutkimuksen palautetta.