How to Conduct User Acceptance Testing: Process Stages, Deliverables, and End-User Testing Place in Quality Assurance

Reading time: 14 minuuttia

to Assur the technical quality of a product, to find bugs and logical mistakes in the software, it is essential to attribute to quality assurance activities. LAADUNVARMISTUSTESTAUS ei kuitenkaan kerro, onko lopputuote linjassa liiketoiminnan tavoitteiden kanssa ja pystyykö se suoriutumaan vaadituista tehtävistä reaalimaailman skenaarioissa. Joten sen varmistamiseksi, että kehitystiimi rakentaa oikean tuotteen todellisille loppukäyttäjille, käyttäjän hyväksymistestaus on elintärkeää.

mitä on käyttäjien hyväksymistestaus ja miten se eroaa laadunvarmistuksesta?

User Acceptance Testing (UAT) tarkistaa, onko tuote oikea loppukäyttäjille. Sillä on muita nimiä, esim.loppukäyttäjän testaus, operatiivinen, sovellus, beetatestaus tai validointi, mutta ne kuvaavat samaa asiaa. Laadunvarmistuksessa on tärkeää erottaa validointi ja todentaminen toisistaan.

todentamisella tarkoitetaan yleisiä LAADUNVARMISTUSMENETTELYJÄ, joilla pyritään testaamaan tuotteen teknisiä näkökohtia sen varmistamiseksi, että tuote todella toimii. Validointi (tai käyttäjän hyväksymistestaus) tehdään sen varmistamiseksi, että tuote vastaa liiketoiminnan vaatimuksia ja että loppukäyttäjä voi käyttää sitä.

validointi-ja todentamistoimet tuotetestauksen osalta

Validointitoimet voidaan jakaa kahteen testaustyyppiin.

Alfatestaus on hyväksymistestauksen alkuvaihe, jonka tyypillisesti suorittavat sisäiset testaajat varmistaakseen, että tuote toimii oikein ja täyttää liiketoiminnan vaatimukset.

Beta-testaus, toinen hyväksymistestaustyyppi, pyrkii täyttämään käyttäjän hyväksymiskriteerit. UAT: N voivat suorittaa

• olemassa olevan tuotteen todelliset käyttäjät,
• tuotteen aiemman version käyttäjät,
• tuotteen kehittämiseen osallistuvat sidosryhmät ja/tai
• yritysanalyytikot loppukäyttäjäasiantuntijoina.

näin kehitystiimi voi korjata suurimman osan käytettävyysongelmista, vioista ja odottamattomista ongelmista, jotka liittyvät toiminnallisuuteen, järjestelmän suunnitteluun, liiketoiminnan vaatimuksiin jne.

miksi itse asiassa tarvitset UAT: ta?

hyväksymistestauksen päätarkoitus on vahvistaa, että tuote vastaa käyttäjien tarpeita (määritelty tuotteen löytövaiheessa) ja on valmis lanseerattavaksi. Mukaan Origsoft kyselyn UAT käyttö, yli 75 prosenttia vastaajista sanoi tekevänsä useita syklejä loppukäyttäjien testaus 57 prosenttia väittäen huono laatu tuotteen syyksi.

joten tässä ovat tärkeimmät syyt, miksi UAT on tärkeä ja sen pitäisi olla osa kehitystäsi.

varmistetaan vastaavuus liiketoiminnan vaatimusten kanssa. Kuten olemme jo maininneet, UAT tehdään sen varmistamiseksi, että tuote toimii reaalimaailman olosuhteissa tarpeen ja antaa loppukäyttäjille mahdollisuuden ratkaista kohdennettuja ongelmia. Jos ohitat UAT, saatat menettää joitakin tärkeitä puutteita tai järjestelmän toimintahäiriöitä, jotka väistämättä aiheuttaa käyttäjän tyytymättömyyttä.

Säädä alkuperäisiä vaatimuksia. Joskus, kun loppukäyttäjät testata tuotetta, he voivat keksiä joitakin arvokkaita ajatuksia siitä, miten parantaa testattu ohjelmisto. Tällaisen palautteen saaminen antaa sinulle mahdollisuuden säätää vaatimuksiasi saadaksesi tuloksen, joka on hyödyllisempää asiakkaillesi.

vältä hävikkiä. Ensinnäkin on halvempaa korjata tuote kehityksen alkuvaiheessa, joten UAT: sta johtuvien vikojen löytäminen antaa kehitystiimillesi mahdollisuuden parantaa tuotetta paljon helpommin (tämä koskee kuitenkin lähinnä ketterää mallia. Lue lisää). Toiseksi, me kaikki tiedämme tarinoita tuotteiden epäonnistumisista huonon toimivuuden ja käytettävyyden vuoksi. UAT tarjoaa sinulle reaaliaikaista käyttäjäpalautetta ja vähentää huomattavasti epäonnistuneen Tuotelanseerauksen aiheuttamia tappioita.

UAT vaatii joka tapauksessa organisaatio-ja valmistelutyötä, jotta se olisi tehokas. Jos haluat varmistaa tuotteen voimassaolo, harkitse seuraavia vaiheita suorittaa käyttäjän hyväksymistestaus.

UAT: n avainvaiheet

analysoi tuotevaatimukset ja määrittele Keskeiset tuotevaatimukset

tuotevaatimusten analysointi on UAT: n suunnittelun ensimmäinen vaihe. Ensisijainen lähde syöttötietojen olisi ohjelmiston vaatimukset erittely, koska se sisältää koko liiketoiminnan ja toiminnalliset vaatimukset.

liiketoiminnan vaatimukset ovat organisaatiosi korkean tason tavoitteita, jotka viestivät liiketoiminnan tarpeista. Ne voivat kuulostaa ” asiakkaiden pitäisi pystyä käyttämään useita maksutapoja.”

toiminnalliset vaatimukset yhdistävät teknisen ratkaisun liiketoiminnan vaatimuksiin. Niin, toiminnallinen vaatimus kuulostaisi ” toteuttaa PayPal, Visa ja Mastercard, Payoneer maksu yhdyskäytävät.”

näiden vaatimusten yleiskatsaus kertoo tarkalleen, mitä kannattaa testata, toimivatko toteutetut ratkaisut käyttäjille ja ratkaisevatko ne liiketoiminnan ongelmat. Toiminnalliset vaatimukset voidaan muuntaa testitapauksiksi ottaen huomioon liiketoimintavaatimusten menestyskriteerit. Ja se auttaa sinua muodostamaan yleisen testausstrategian. Harkitse yrityksesi analyytikoiden, LAADUNVARMISTUSINSINÖÖRIEN tai tuotteiden omistajien osallistumista vaatimusanalyysiin.

loppusuunnitteluvaiheessa luodaan teknistä dokumentaatiota UAT-prosessia varten. Tässä dokumentoit testausstrategian, säännöt, testiskenaariot/ – tapaukset, standardit jne. Seuraavissa kohdissa kuvataan käyttäjän hyväksymistestauksessa käytettyä dokumentaatiota.

User acceptance testing deliverables

UAT test plan. UAT-testisuunnitelman luominen auttaa pitämään kaikki samojen tavoitteiden ja vision tasalla. Tärkein asiakirja, se sisältää kaikki tiedot siitä, mitä testataan, kuka, ja miten. Voit kattaa kaikki organisatoriset ja prosessuaaliset näkökohdat UAT, sinun täytyy yksityiskohtaisesti testausstrategia ja entry/exit kriteerit.

loppukäyttäjän testausstrategia. Strategiassa hahmotellaan testattava tuote, käyttäjän hyväksymistestauksen tarkoitus, testityypit ja tavoitteet. Testausstrategiasi tulisi kattaa sellaiset tiedot kuin

• Tuotekuvaus,
• testaustavoitteet,
• testauksen laajuus,
• standardit,
• testaustyypit,,
• testaajat/roolit
• prosessikuraattorit (esimiehet),
• arvioijat,
• raportointistandardit ja
• tulokset.

osallistumiskriteerit. Nämä ovat ehtoja, jotka osoittavat, että ohjelmisto on valmis testattavaksi. Kehitystiimi, laadunvarmistus, liiketoiminta-analyytikot ja sidosryhmät sijoittavat ne suunnittelun varhaisimpaan vaiheeseen.

poistumis-tai hyväksymiskriteerit. Nämä ovat ehtoja, jotka määräävät, että ohjelmisto on voimassa käyttäjille. Hyväksymiskriteerien sovittaminen olisi UAT: n viimeinen vaihe.

Testiskenaariot. Testiskenaariot ovat hypoteettisia tilanteita, joita käyttäjät voivat kohdata ollessaan vuorovaikutuksessa tuotteesi kanssa. Niiden tavoitteena on ohjata testaajat läpi mahdolliset järjestelmän käyttöongelmat.

periaatteessa testiskenaarion pitäisi välittää yksinkertainen käsitys siitä, mitä testataan. Esimerkki skenaariosta on ” tarkista ostoskorin toimivuus.”Jokaiseen käyttäjätilanteeseen liittyy yksi tai kaksi vaatimusta tai käyttäjätarinaa. Ne on kirjoitettu sen vahvistamiseksi, että järjestelmä on käyttökelpoinen, tarkistamalla päästä päähän-operaatiot todellisilla tiedoilla.

jos haluat kirjoittaa hyviä testiskenaarioita käyttäjien hyväksymistestausta varten, harkitse loppukäyttäjien ottamista mukaan hyväksyntään ja ota mukaan kaikki mahdolliset käyttötapaukset, sekä yleiset että Melko harvinaiset. Harkitse myös niiden kirjoittamista selkokielellä ja vältä monimutkaisia sanamuotoja tai liian teknisiä selityksiä.

Testitapausta. Testitapaus on joukko erityisiä toimia, jotka toteutetaan tietyn järjestelmän käyttäytymisen, ominaisuuden tai toiminnallisuuden testaamiseksi ja todentamiseksi. Testitapaukset ovat yksityiskohtaisempia yksiköitä, joiden on vastattava kaikkia testiskenaarioita. Useimmiten voit muuntaa käyttäjän tarinoita ja liiketoiminnan käyttö tapauksissa kirjoittaa tehokkaita testitapauksia. Esimerkkejä testitapauksista ovat:

1. Tarkista rekisteröimätön käyttäjä lisäämällä tuotteen ostoskoriin.
2. Tarkista ostoskorin suodatus.
3. Tarkista ”jatka ostoksia” – painike.

testitapaukset ovat tehokkaita, kun on ilmoitettu selkeä käyttötarkoitus, ja käyttäjä pystyy ymmärtämään, mitä sen täyttämiseksi pitäisi tehdä. Testitapauksen käyttöohje voi näyttää tältä:

1. Avaa sovellus.
2. lisää Mikä tahansa tuote ostoskoriin.
3. todennusta ei tarvita.
4. Jatka ostoskoriin.

voit myös sisällyttää testitapaukseen odotettuja tuloksia, jotta käyttäjä on tietoinen siitä, mitä tulee tapahtumaan:

1. tuote ilmestyy ostoskoriin.
2. järjestelmä pyytää lupaa rekisteröityneenä käyttäjänä.

raportointistandardit. Määrittele, miltä raportin pitäisi näyttää ja mitä tietoja loppukäyttäjän pitäisi antaa.

testausselosteet. Nämä keräävät dokumentoidut lähtötiedot, kun testi on suoritettu. Testistandardeista ja testausskenaariosta riippuen raportteihin voidaan sisällyttää erilaisia tietoja. Mutta tyypillisesti UAT, QA joukkueet vaativat vain kuittauksen testaaja. Kuittaus on vain vahvistus siitä, että testi on onnistunut ja se vastaa käyttäjän kriteerejä.

UAT: n päättyessä LAADUNVARMISTUSINSINÖÖRIT tai UAT: n johtaja voivat käyttää toimitettuja tuloksia arvokkaiden tietojen keräämiseen ja tulosten välittämiseen kehitystiimille.

perinteisesti laadunvarmistusinsinöörit vastaavat loppukäyttäjän palautteen käsittelystä. Testitulokset, vikailmoitukset ja fail/pass-tietueet toimitetaan kehittäjille, jotta varmistetaan jatkuva kommunikaatio tiimin eri osien välillä. Loppukäyttäjän palautteen perusteella QA-tiimi voi myös tarjota ohjelmistojen laatumittareita, joilla mitataan edistymistä UAT: n suhteen.

User acceptance testing templates

olemme maininneet muutamia tärkeitä dokumentteja, jotka on luotava oikeanlaista UAT-suunnittelua ja toteutusta varten. On olemassa erilaisia tapoja kirjoittaa niitä, mutta tässä on joitakin malleja, jotka voivat tulla kätevä.

• Testisuunnitelmapohjat: Coley Consultingin Test Plan template, sfsu template (downloadable link) tai iiba template (downloadable link)
• Test scenario template
• Test report template

valitse aika ja muoto loppukäyttäjän testaukselle

Hyväksymistestaus voidaan suorittaa projektin eri vaiheissa riippuen käyttämästäsi menetelmästä, mutta tyypillisesti se suoritetaan kehityssyklin lopussa ennen julkaisua. Koska ohjelmistokehityksen kaksi suosituinta projektinhallintamenetelmää ovat Waterfall ja Agile, tarkastelemme käyttäjien hyväksymistestausta näiden kahden mallin sisällä.

Vesiputousmallin Hyväksymistestaus

sukeltaaksemme syvemmälle yksityiskohtiin meidän on kerrattava nopeasti, mikä Vesiputousmalli on. Se on perinteinen projektinhallintamenetelmä, joka perustuu tuotteen vaiheittaiseen kehittämiseen.

vaiheet eivät leikkaa toisiaan, eli ei ole olemassa samanaikaista suunnittelua ja suunnittelutestausta, eikä kehitystä ja testausta. Koko prosessi on tiukasti dokumentoitu ja sen tarkoituksena on tuottaa täysin toimiva sovellus kehityksen lopussa ilman iteraatioita.

käyttäjän Hyväksymisvaihe Vesiputousmallissa

käyttäjän Hyväksymistestaus vesiputouksessa tapahtuu viimeisessä kehitysvaiheessa, juuri ennen lanseerausta.

se voidaan suorittaa vasta, kun järjestelmä katsotaan koodi-ja toimintovalmiiksi, kun seuraavat viitearvot on saavutettu.

• tuoteliiketoiminnan vaatimukset on täytetty.
• koodikanta on valmis.
• LAADUNVARMISTUSTOIMET (järjestelmä, integrointi, yksikkötestaus) on saatu päätökseen.
• KYSELYVAIHEESSA paljastuneet viat on korjattu.
• Pienet näköongelmat ovat hyväksyttävällä alueella.
• käyttäjän hyväksymä ympäristö(UAT-hallinta, testaustyökalut, testiskenaariot jne.) on luotu.

Vesiputousmallissa käyttäjän hyväksymistestaus on lopullinen kohta, joka osoittaa ohjelmiston valmiuden. Jos tuote täyttää käyttäjän hyväksymiskriteerit, se tarkoittaa, että tuote on valmis tuotantoon. UAT: n toiminta, siinä tapauksessa, on järjestelmän tarkistuksen, sen toimivuuden, käytettävyyden ja vikojen suorittamiseen. Ensisijaisena tavoitteena on kuitenkin varmistaa, että tuote vastaa alkuperäisiä vaatimuksia ja loppukäyttäjän tarpeita.

käyttäjän hyväksyntä ketterissä menetelmissä

ohjelmistokehityksen Ketterä malli ei ole yhtä suoraviivainen kuin Waterfall. Se perustuu jokaisen kehitysvaiheen iterointiin, kunnes tuote saavuttaa vaaditun laadun ja toiminnallisuuden. Kunkin vaiheen iteroinnit mahdollistavat erittäin joustavan kehityksen ja vaatimusten dynaamisen muutoksen, sillä Agile ei keskity paljoa dokumentaation luomiseen. Ja näin kehitystiimi voi nopeasti vastata asiakkaan muuttuviin vaatimuksiin.

käyttäjän hyväksymistestaus ketterässä mallissa

kuvassa näkyy Ketterä tuotekehityssykli iteraatioineen. Voit suorittaa käyttäjän hyväksymistestauksen projektin jokaisessa vaiheessa tuotteen voimassaolon varmistamiseksi. Tärkein ero UAT: n välillä vesiputouksessa ja ketterässä on se, että UAT toteutetaan useita kertoja (usein kunkin iteraation sisällä) ja sen tulokset voivat vaikuttaa alkuperäisiin vaatimuksiin, koska se antaa välitöntä palautetta siitä, mikä toimii parhaiten.

tarkistuspisteet loppukäyttäjien testauksen aloittamiseksi ketterässä projektissa ovat

• formed business requirements,
• UX / system documentation,
• Testimateriaali (Interaktiiviset mallikuvat, hifi-prototyypit, demot) ja
• käyttäjän hyväksymä ympäristö.

Agilessa UAT on olennainen osa yleistä testaustoimintaa, joten se voi ottaa erilaisia muotoja ja käyttää erilaisia työkaluja. Nämä voivat olla esimerkiksi toiminnallisia ja ei-toiminnallisia vaatimuksia koskevia testejä tai alkuvaiheen testejä suunnitteluvaiheessa tehtyjen oletusten validoimiseksi. Jokaisen iteraation lopussa hyväksymistestaus tuottaa suorituksia, joita käytetään vaatimusten, järjestelmäarkkitehtuurin, UX-tyylioppaiden jne.muokkaamiseen.

rekrytoi käyttäjiä ja muodosta UAT-tiimi

kuten aiemmin mainittiin, testaajat voidaan rekrytoida olemassa olevasta käyttäjäkunnasta. Projektin yksityiskohdista riippuen ne voivat olla aiheasiantuntijoita, tuotteen reaalimaailman käyttäjiä, sidosryhmiä, liiketoiminta-analyytikoita, tuotteen omistaja tai asiakas. Voit myös käyttää joukkoistamisalustoja testaajien etsimiseen tai freelance-käyttäjätestausasiantuntijan palkkaamiseen.

harkitse sosiaalisen median viestin tai jopa Aloitussivun luomista yleisön houkuttelemiseksi. Potentiaaliset testaajat eivät välttämättä ole tech savvy tai perehtynyt ohjelmistojen testausprosesseihin. Kuitenkin, ne, jotka jo ovat tai käyttävät tuotetta (tai ehkä samanlainen) ovat hyviä ehdokkaita UAT koska siinä tapauksessa voit välttää syvä onboarding ja laadunvarmistus joukkue osallistumista.

Ota käyttöön loppukäyttäjien testausvälineet ja laivalla olevat testaajat

tietenkin markkinoilla on erityisiä välineitä, jotka on suunniteltu loppukäyttäjien testaukseen. Suosituimmat työkalut tarjoavat testauksen hallintatoimintoja, kuten raportointia, tehtävien katsauksia ja testausasiakirjojen malleja. Tässä muutamia esimerkkejä ohjelmistoista, joita voidaan käyttää UAT: n toiminnan tukemiseen.

Usersnap on suosittu alusta, joka tarjoaa visuaalista palautetta testatuista ohjelmistoista ja verkkopohjaisista sovelluksista. Pohjimmiltaan, se on työkalu, jonka avulla käyttäjät voivat merkitä vikoja oikealle näytöllä, jättää kommentteja ja ehdotuksia, ja jakaa palautetta. Vastaavia instrumentteja on paljon, kuten Userback ja UserTesting.

FitNesse on avoimen lähdekoodin wiki-pohjainen viitekehys hyväksymistestien automatisointiin. Sen avulla kaikki sidosryhmät voivat helposti luoda, muokata ja suorittaa testejä ja luoda varhaisen palautteen. Käyttäjät syöttävät erityisesti muotoiltuja syötteitä tuottaakseen automaattisesti testejä, jotka järjestelmä suorittaa välittömästi. Sitten tuotos palautetaan ja korostetaan riippuen siitä, vastaako se odotettua tulosta vai ei. Tällä yhteistyöalustalla on lievä oppimiskäyrä ja se on suosittu ketterien joukkueiden keskuudessa.

Bugwolf on toinen UAT: n johtamisen väline. Testausympäristön ja vikailmoituksen lisäksi se tarjoaa pelillistämis-ja kilpailuominaisuuksia motivoimaan ja sitouttamaan käyttäjiä. Löydät myös hyödyllisiä sisäänrakennettuja maksuvaihtoehtoja, jos aiot suorittaa loppukäyttäjien testausta verkossa.

hyvin tunnetuilla projektinhallintatyökaluilla, kuten Jiralla tai Trellolla, on myös toiminnallisuus UAT: n johtamiseen.

Testing dashboard in SpiraTest

Create user acceptance environment and run training

to get the most out of end user testing, start with the training. Testaajat ja UAT johtaja ovat vastuussa siitä. Harkitse jäsentämistä koulutusprosessin sisällyttää seuraavat näkökohdat.

• tutustuttaa käyttäjät testausprosessiin ja sen tavoitteisiin.
• junan käyttäjät voivat käyttää työkaluja loppukäyttäjien testaukseen, jos aiot käyttää niitä.
• Toimittakaa niille raportointistandardit ja-ohjeet.
• varmista, että käyttäjät ymmärtävät testitapaukset oikein ja tarjoavat tarvittaessa tukea.
• anna niille pääsy testausympäristöön.

useimmiten loppukäyttäjän testaus voidaan tehdä käyttäjän puolella, eli laitteistoa ei tarvitse toimittaa testaajilleen. Koko prosessin voi tehdä myös verkossa. Monimutkaisemmat projektit tai luottamukselliset tiedot voivat vaatia oman käyttäjätestaajaryhmän keräämistä toimistossasi. On myös tärkeää nimittää johtaja, joka tarjoaa dokumentaatiota, työkaluja ja tukea.

suorita testit

kun testiskenaariot ja testitapaukset ovat selvillä, olet valmis lähtemään testeihin mukaan. Jotta voit tukea loppukäyttäjiäsi prosessin aikana ja saada vaaditut tulokset, Anna selkeä käsitys siitä, mitä toimia kukin testitapaus vaatii. Muista, että käyttäjät eivät ole ammattimaisia testaajia. Testin aikana, muista antaa todellista tai lähellä todellista tietoa käyttäjille, välttää näytteen sisältöä tai valenappuloita. Mikä tahansa väärinkäsitys voi saada heidät juuttumaan testitapaukseen.

toinen tärkeä näkökohta on se, että kehittäjät ovat valmiita korjaamaan kaiken, mikä menee pieleen. Testausympäristösi voi sammua tai voi olla virheitä, jotka estävät käyttäjiä testaamasta. Käyttäjien olisi voitava käyttää vaadittuja toimintoja jokaisessa testausvaiheessa, olipa kyseessä interaktiivinen suunnittelu tai toimiva sovellus, jotta he voivat suorittaa jokaisen testaussuunnitelmaan sisältyvän testitapauksen.

kerää tuotostiedot ja analysoi ne

UAT-toiminnan aikana saat testaajilta tonneittain dataa. KYSELYTIIMINNE täytyy analysoida se. Tiedot kerätään manuaalisesti toimitettavien käyttäjäraporttien tai tietyn työkalun avulla. Lisäksi voit tehdä haastatteluja erillisille käyttäjille saadaksesi lisätietoa heidän suorittamistaan testitapauksista ja siitä, mitä he ajattelevat niistä.

järjestelmän valmiuden arvioimiseksi on harkittava läpäistyjen/epäonnistuneiden/kiinteiden testien prosenttiosuuden mittaamista.

Test tracking dashboard in Panaya

on huomioitava myös muutama muu seikka:

järjestelmän vakaus. Vakaus voidaan määrittää UAT: n aikana havaittujen odottamattomien virheiden määrän perusteella.

testauksen kattavuus. Kattavuus mitataan kirjallisten testiskenaarioiden/ – tapausten määrällä ja niiden suhteella valmiisiin testeihin. Voit myös sovittaa UAT-testaustuloksesi käyttäjän reittikarttaan ymmärtääksesi, mikä osa toiminnallisuudesta jäi testaamatta.

järjestelmän käytettävyys. Tämä voidaan laskea läpäisemättömien testien määrällä, koska käyttäjä ei keksinyt keinoa tehdä sitä. Mutta yleinen UX testataan käytettävyystestauksessa, joka tehdään erillisenä toimintana.

sopimuksen / vaatimuksen noudattaminen. Vaatimusten noudattaminen tarkastetaan, kun kaikki loppukäyttäjätestit on tehty. Se varmistaa, että ohjelmistorakenne vastaa edelleen alkuperäisiä vaatimuksia / sopimuksen soveltamisalaa, vaikka käyttäjän hyväksynnän tuomat muutokset.

Korjaa viat, tee uusintatesti ja kirjaudu pois

UAT: n suorittamisen jälkeen kaikki viat on dokumentoitava asiaankuuluvin huomautuksin ja toimitettava kehitystiimille. Niiden on tehtävä muutoksia koodiin UAT: n paljastamien ongelmien ratkaisemiseksi.

kun olet korjannut viat, testaa ne uudelleen varmistaaksesi, että kaikki toimii oikein. Kun hyväksymiskriteerit ovat täyttyneet ja arvioijat hyväksyneet, lopullinen hyväksymispäätös tehdään tuotteen tuotanto-valmiudesta.

UAT: n tiimiroolit

kuten aiemmin mainitsimme, UAT: n testaus eroaa muista LAADUNVARMISTUSTOIMISTA, koska sitä eivät suorita vain tekniikan asiantuntijat; on myös tärkeää ottaa mukaan todelliset loppukäyttäjät tähän prosessiin. Myös QA-ammattilaisten ja liiketoiminta-analyytikoiden osallistuminen on välttämätöntä, samoin tiivis yhteistyö projektipäällikön ja kehitystiimin kanssa.

UAT-tiimin vastuut voivat vaihdella yrityksen ja projektin tarpeiden mukaan, mutta tässä esimerkki roolijaosta, jota voi harkita.

Business program manager. Tämä on henkilö, joka koordinoi ja valvoo koko projektin, yhdenmukaistaa sen liiketoiminnan tavoitteita. Ennen UAT-vaihetta ohjelmapäällikön tulisi luoda ohjelman toimitussuunnitelma ja liiketoimintavaatimusasiakirja testaustoimien tueksi. Hän vastaa myös testaussuunnitelman ja testistrategian tarkastamisesta ja hyväksymisestä.

UAT: n aikana ohjelmapäällikkö seuraa testitoiminnan toteutusta ja varmistaa valmistumisen aikataulussa ja budjetissa. Sen jälkeen hän käy läpi testiraportin ja päättää sen käyttöönotosta tuotantoon.

UAT test lead / manager. Testijohtajan vastuulla on suunnitella ja organisoida UAT tarkasti. Tämä edellyttää yleensä tiivistä yhteistyötä projektipäällikön kanssa.

testijohtaja kerää ja analysoi kaikki liiketoiminnalliset ja toiminnalliset vaatimukset, joita sitten käytetään tarvittavan dokumentaation kehittämiseen, eli testistrategia, testisuunnitelma, testiskenaariot jne. Lisäksi hän työskentelee valmisteluvaiheessa testitiimin kanssa, määrittää testiskenaarioita tiimin jäsenille ja järjestää koulutusta, jotta testaajat ymmärtävät UAT-menettelyn. Testijohtaja myös valmistelee ja hallinnoi tarvittavia resursseja ja lataa olennaisia testitietoja testityökaluihin.

Koko UAT: ssa johto koordinoi testitapausten toteutusta varmistaen, että kaikki testitulokset dokumentoidaan. Hän myös seuraa testauksen edistymistä, kerää mittareita ja luo/ylläpitää testiraporttia.

UAT: n testiryhmän jäseniä. Testiryhmän päätehtävä on suorittaa testit annetun aikataulun ja ohjeiden mukaisesti. Testaajien on luotava testilokit ja raportoitava vioista ja vaaratilanteista. Ne osallistuvat myös tyypillisesti uudelleenkokeisiin (tarvittaessa).

projektipäällikön, joka on vastuussa hankkeen onnistuneesta loppuun saattamisesta, on seurattava testaustoimia, annettava organisatorista tukea ja raportoitava edistymisestä. Hän toimisi myös välittäjänä testausryhmän, kehittäjien, asiakkaan ja muiden mahdollisten sidosryhmien välillä.

UAT: n tarkistuslista

Tiivistäen yllä esittämämme UAT: n ohjeet, olemme kehittäneet tarkistuslistan, joka auttaa sinua järjestämään testaustoimintasi ja olemaan tekemättä mitään tärkeää.

UAT-hankkeen käynnistäminen.

1. varmista kehitystiimisi kanssa, että kaikki tuotteen komponentit ovat valmiita testattavaksi. Dokumentoi kaikki kysymykset, joita ei voitu käsitellä ennen UAT: ta.
2. yksilöi keskeiset sidosryhmät.
3. valitse tiiminvetäjä, joka vastaa projektista, mukaan lukien paperityöt.
4. Keskustele ja sovi projektirakenteesta, UAT-tiimistä ja UAT-dokumentaatiosta.
5. on keskusteltava perusteellisesti testausmenettelyistä ja laadittava alustava UAT-suunnitelma.

Planning UAT.

1. luo UAT-tiimisi ja varmista, että sinulla on testaajia jokaiselta markkinasegmentiltä ja/tai jokaiselta sidosryhmältä. Varmista, että kaikki osallistumiseen liittyvät asiakirjat ovat täydellisiä ja allekirjoitettuja (salassapitosopimus, osallistumissopimus jne.).
2. ilmoita testistrategia ja aikataulu tiimille. Varmista, että jokainen jäsen ymmärtää roolit, menettelyt ja vastuut.
3. varmista, että kaikki liiketoiminnan vaatimukset otetaan talteen ja ilmoitetaan UAT-tiimille.
4. keskustellaan ja sovitaan maahantulo-ja maastapoistumisperusteista.
5. Laadi kaikki liiketoimintadokumentit: testaussuunnitelma, testiskenaariot, testitapaukset jne.
6. ilmoita järjestelmän liiketoiminnan tavoitteet ja hyväksymis – /poistumisperusteet.
7. sopivat raportointistandardeista.
8. suorita tarvittava koulutus järjestelmästä ja apuvälineistä. Varmista, että testaajat ymmärtävät raportoida tapauksista.
9. kootaan ja valmistellaan kaikki tarvittavat resurssit UAT: n toimintaan. Varaa tilaa tarvittaessa.
10. valmistella ja testata ympäristöä, testinhallintatyökaluja, laitteita, palvelimia, palautekanavia, ongelmien seurantaa, sisällön toimittamista jne.
11. varmista, että sinulla on kaikki kirjautumiset, että suojausyhteys on määritetty ja testitiedot ladattu.

UAT: n suorittaminen.

1. seuraa, miten menettelyt suoritetaan, ja varmista, että raportit toimitetaan ajoissa ja tarkasti.
2. luo ja ylläpitää testin yhteenvetoraporttia.

UAT: n jälkeinen toiminta.

1. analysoi lähtötiedot mittaamalla läpäisevien/epäonnistuneiden testien prosenttiosuus sekä luokittelemalla viat vakavuuden mukaan.
2. Määrittele asema hyväksymiskriteerien perusteella.
3. Laadi UAT: n loppuraportti ja esitä se sidosryhmille sekä arvioitu aika ja ponnistus, joka tarvitaan hyväksymiskriteerien ja julkaisusuositusten täyttämiseksi.

testausmenetelmät saattavat vaihdella yhtiöittäin. Tässä muutamia muita ladattavia UAT tarkistuslistoja, jotka saattavat sopia tarpeisiisi samoin: Checklist 1, Checklist 2.