Saturs
- Demo un mirsti!
- Ieejiet lietotāju kurpēs
- Īsa UAT vēsture
- UAT stāsta, cik sistēma ir izmantojama
- Kas var veikt UAT?
- Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
- Panākumi un neveiksmes plūst
- UAT priekšrocības
Avots: Lightcome / iStockphoto
Izņemšana:
Tiklīdz programmatūra tiek pārbaudīta vienības, integrācijas un sistēmas testēšanā, vajadzība pēc pieņemšanas testēšanas var šķist lieka. Kāpēc lietotāju pieņemšanas pārbaude (UAT) joprojām ir svarīga? Šeit labi uzziniet par UAT priekšrocībām un to, kāpēc tas ir unikāls.
Demo un mirsti!
Vai jūs kādreiz esat piegādājis klienta prezentāciju vai apmācību, un kaut kas sabrūk līdz pusei? Vai arī jūs kādreiz esat kādam devis instrukcijas un sapratu, ka esat kaut ko palaidis garām, vai arī tas nedarbojās gluži tā, kā jūs cerējāt? Katrā no šiem gadījumiem jūs izvēlaties gala lietotāja perspektīvu un strādājat ar programmatūru šajā personā. Iespējams, ka jūs izdarījāt kaut ko savādāk, jo domājāt kā lietotājs, nevis izstrādātājs.
Ieejiet lietotāju kurpēs
Lietotāju pieņemšanas testēšanas (UAT) unikālais leņķis ir programmatūras kā gala lietotāja pārbaude. Programmatūra ir veidota, lai lietotājiem sniegtu taustāmus rezultātus. Piemēram, e-komercijas vietnes ļauj klientiem iegādāties produktus. Kad klients veic pasūtījumu, e-komercijas vietņu programmatūra paziņo veikala administratoram, lai izvēlēto preci varētu izvilkt un iesaiņot nosūtīšanai. Var būt dažādi programmatūras lietotāju veidi, tāpēc šis testēšanas posms ļauj attīstības komandai pārbaudīt, vai gala lietotāji sasniedz gaidītos programmatūras rezultātus.
Īsa UAT vēsture
Pirms interneta parādīšanās lielākā daļa programmatūras tika ieviesta zināmai lietotāju auditorijai. Ja uzņēmums klientam izstrādāja programmatūru, norīkotajam vadītājam bija tiesības pārbaudīt, vai programmatūra atbilst līguma noteikumiem. Tas bija domāts, lai attēlotu punktu, kurā programmatūra bija “piemērota mērķim”, kas tika panākts, izvēloties gala lietotāju pārstāvjus, lai veiktu testēšanu un sniegtu ziņojumu ar rezultātiem. Tā kā lietotāji bija zināma, slēgta grupa, katrs varēja tikt apmācīts programmatūras lietošanā, parasti veicot ļoti detalizētus pārbaudes soļus. Dienas moto bija tāds, ka vairāk detaļu bija labāk.
Tā kā arvien vairāk programmatūras tika izstrādāta klientiem tīmeklī, gala lietotāju auditorija kļuva atvērtāka. Visus iespējamos galalietotājus vairs nebija iespējams identificēt un apmācīt, tāpēc programmatūras projektēšanā bija jāiekļauj daudz lielāks uzsvars uz lietojamību un tai bija jābūt viegli saprotamai - pat ar minimālu sniegto informāciju. Tātad UAT bija jāmaina, lai izpildītu šīs prasības.
UAT stāsta, cik sistēma ir izmantojama
Tātad, UAT mums ne tikai norāda programmatūras daļas funkcionalitāti, bet arī norāda, cik tā ir izmantojama. Lielāko UAT daļu vislabāk veic personas, kas saprot mērķa gala lietotāju, kurš programmatūru pieredzēs ar nelielām iepriekšējām zināšanām un var sniegt patiesu norādi par programmatūras lietošanas vienkāršību un to, kas ir jāuzlabo.
Kas var veikt UAT?
Kad izstrādātāji testē programmatūru, viņi atceras informāciju par sistēmas rakstīšanu. Šīs zināšanas var ietekmēt testēšanu, un izstrādātāji var veikt dažādas darbības nekā galalietotāji, piemēram, ātrāk veikt darbības vai noraidīt sīku informāciju, kas galapatērētājiem varētu šķist mulsinoša. Tādējādi izstrādātāji nav labākie UAT kandidāti. Kas tad ir?
Daudzas organizācijas nodarbina īpašas testēšanas komandas, kas nav iesaistītas tehniskajā projektēšanā un izstrādē. Mazākas organizācijas vai nu piešķir testēšanu personālam, kas nav saistīts ar attīstību, piemēram, tiem, kuri veic administratīvos pienākumus, vai arī izmanto ārēja uzņēmuma pakalpojumus. Dažas organizācijas izmanto tā dēvēto “priekštelpu pārbaudi”, kur tās burtiski pieaicina darbiniekus, kuri nav aktīvi iesaistīti projektā, un lūdz viņus izmēģināt sistēmu no tiešo lietotāju viedokļa. Piemērs varētu būt produkta pasūtīšana tiešsaistē.
Pēc iekšējās testēšanas var notikt izmēģinājuma vai beta testēšanas stadijas, kurās programmatūra tiek padarīta pieejama nelielām “reālu” lietotāju grupām, kuras tiek uzaicinātas izmantot produktu bez maksas vai ar ievērojamu atlaidi, pretī saņemot detalizētu informāciju par lietošanu.
Bez kļūdām, bez stresa - jūsu soli pa solim, kā izveidot programmatūru, kas maina dzīvi, neiznīcinot savu dzīvi
Jūs nevarat uzlabot savas programmēšanas prasmes, kad nevienam nerūp programmatūras kvalitāte.
Progresīvie UAT posmi ar daudzveidīgu auditoriju palielina pārliecību par programmatūras lietojamību. Apvienojumā ar iteratīvās attīstības fāzēm var veikt vairākus UAT ciklus, lai pārbaudītu jaunas funkcijas, tiklīdz tās tiek piegādātas, vienlaikus pārbaudot iepriekšējās funkcijas.
Labiem UAT pārbaudītājiem ir interese redzēt, kas notiek, ja viņi ved dažādus maršrutus uz noteiktu mērķi. Galu galā visi programmatūras pieejai pieiet dažādos veidos, tāpēc, ja daudzas iespējas var aptvert neliela cilvēku grupa, programmatūras pārliecība par darbības režīmu ir augstāka.
Panākumi un neveiksmes plūst
UAT procesiem jāpārbauda, vai katrs programmatūras lietotāja tips iegūst taustāmus rezultātus, kas nepieciešami gan veiksmes, gan neveiksmes plūsmām.
Veiksmes veiksmē galalietotājs aiziet no gaidītā rezultāta, piemēram, pasūtot produktu. Neveiksmju gadījumā programmatūra atbalsta galalietotāju, izmantojot kaut kāda veida kļūdas scenārijus, piemēram, ja klients sniedz nederīgu kredītkartes maksājuma informāciju.
Lai pārbaudītu funkcionalitāti, testētājiem ir jāsniedz zināma informācija. Pretējā gadījumā viņi nezina, kas programmatūrai ir paredzēts. Bet, lai pārbaudītu lietojamību, tam jābūt minimālam - pamatots tikai uz uzdevumiem vai prasībām, piemēram, “x” (produkts) pirkšana un “y” samaksa (izmantojot kredītkartes informāciju). Pārbaudītājiem jāuzliek pienākums reģistrēt novērojumus, panākumus un neveiksmes.
UAT priekšrocības
Galvenais laba UAT ieguvums ir tas, ka tas uztur iespējami zemas uzturēšanas izmaksas. Lētāk ir savlaicīgi novērst funkcionalitātes un lietojamības problēmas. Daudz grūtāk novērst kļūdu, ja ap to ir vairāk koda regresijas pārbaudei vai ja sākotnējais izstrādātājs nav pieejams.
UAT, kas tiek veikts vairākos posmos un ar dažāda veida testa auditorijām, nodrošina optimālas iespējas identificēt un novērst sabojātos parametrus / lietojamības problēmas sākotnējās testēšanas fāzēs. UAT mērķu uzturēšana uzdevumu un prasību līmenī ļauj testētājiem novērot un pamanīt daudz vairāk un pat mēģināt rīkoties ārpus izstrādātāja norādītās darbības jomas.
Atsauksmes no UAT cikliem var izmantot turpmākajās attīstības iterācijās, palielinot programmatūras noturību un lietojamību. Labi ieplānots, pat beta testa fāzes var papildināt mārketinga un pārdošanas aktivitātes, nodrošinot atsauces un gadījumu izpētes atsauksmes.