Content
- Demo i morir!
- Pas a les sabates dels usuaris
- Breu història de la UAT
- UAT t’explica com és d’ús el sistema
- Qui pot realitzar la UAT?
- Sense errors, sense estrès: la vostra guia pas a pas per crear programes que canvien la vida sense destruir la vida
- Fluxos d'èxit i fracàs
- Beneficis de la UAT
Font: Lightcome / iStockphoto
Emportar:
Una vegada que el programari es sotmet a proves d’unitat, integració i sistema, la necessitat de les proves d’acceptació pot semblar redundant. Per què continua essent important la prova d’acceptació dels usuaris (UAT)? Aquí, coneixeu els avantatges de la UAT i per què és únic.
Demo i morir!
Alguna vegada has lliurat una presentació o formació d’un client i alguna cosa es redueix a la meitat? O, alguna vegada heu donat a algú un seguit d’instruccions i us heu adonat que us heu perdut alguna cosa, o que no funcionava del tot com esperàveu? Durant cadascun d'aquests casos, adopteu la perspectiva de l'usuari final i treballeu amb el programari d'aquesta persona. El més probable és que hagueu fet una altra cosa perquè pensàveu com a usuari en lloc de desenvolupador.
Pas a les sabates dels usuaris
L’únic angle de prova d’acceptació dels usuaris (UAT) és provar el programari com a usuari final. El programari està creat per oferir resultats tangibles als usuaris. Per exemple, els llocs de comerç electrònic permeten als clients comprar productes. Quan un client realitza una comanda, el programari de llocs de comerç electrònic notifica a l’administrador de la botiga, de manera que l’article seleccionat es pot tirar i embalar per a la seva enviació. Hi pot haver diferents tipus d’usuaris de programari, de manera que aquesta fase de proves permet a l’equip de desenvolupament verificar si els usuaris finals aconsegueixen els resultats esperats del programari.
Breu història de la UAT
Abans de l’arribada d’internet, la majoria de programari es va desplegar per a un públic d’usuaris conegut. Si una empresa va desenvolupar programari per a un client, un gestor assignat tenia l’autoritat de verificar que el programari complia els termes del contracte. Es volia representar un punt en què el programari era "adequat per a propòsits", que es va aconseguir seleccionant representants d'usuaris finals per realitzar proves i proporcionar un informe amb resultats. Com que els usuaris eren un grup tancat i conegut, cadascun es podia formar en l'ús del programari, normalment mitjançant passos de prova molt detallats. El lema del dia era que més detalls era millor.
A mesura que es va desenvolupar cada vegada més programari per a clients a la xarxa, el públic final es va tornar més obert. Ja no era possible identificar i formar tots els usuaris finals probables, per la qual cosa el disseny del programari havia d'incloure un èmfasi molt més gran en la usabilitat i havia de ser fàcilment comprensible, fins i tot amb una informació mínima proporcionada. Per tant, la UAT va haver de canviar per complir aquests requisits.
UAT t’explica com és d’ús el sistema
Així doncs, UAT no només ens explica l’abast de la funcionalitat d’un programari, sinó que també ens indica quina utilitat es pot fer. La majoria de la UAT s’executa millor per persones que entenguin l’usuari final destinatari que experimentarà el programari amb pocs coneixements previs i pot donar una veritable indicació de la facilitat d’ús dels programes i què necessita millorar.
Qui pot realitzar la UAT?
Com a desenvolupadors de programari de prova, recorden detalls sobre com s'escriu un sistema. Aquest coneixement pot influir en les proves i els desenvolupadors poden fer diferents mesures que els usuaris finals, com ara realitzar passos amb més rapidesa o rebutjar detalls excel·lents que els usuaris finals poden trobar confusos. Per tant, els desenvolupadors no són els millors candidats a la UAT. Aleshores, qui és?
Moltes organitzacions utilitzen equips de prova específics que no participen en el disseny i desenvolupament tècnics. Les organitzacions més petites o bé destinen proves a personal sense desenvolupament, com aquells que realitzen funcions administratives, o bé utilitzen els serveis d’una empresa externa. Algunes organitzacions utilitzen el que es coneix com a "proves de passadís", on literalment recullen membres del personal que no participen activament en el projecte i els demanen que intentin el sistema des de la perspectiva dels usuaris finals. Un exemple seria demanar producte en línia.
Després de realitzar proves internes, es poden produir fases de prova pilot o beta, de manera que el programari es posa a disposició de petits grups d’usuaris “reals” que són convidats a utilitzar el producte de forma gratuïta o amb un descompte significatiu, a canvi de comentaris d’ús detallats.
Sense errors, sense estrès: la vostra guia pas a pas per crear programes que canvien la vida sense destruir la vida
No podeu millorar les vostres habilitats de programació quan ningú es preocupa per la qualitat del programari.
Les etapes progressives de la UAT amb diversos públics augmenten la confiança en la usabilitat del programari. Combinats amb fases de desenvolupament iteratiu, es poden realitzar múltiples cicles UAT per provar noves funcions a mesura que es presten, tot verificant les funcionalitats anteriors.
Els bons provadors de la UAT tenen curiositat en veure què passa si fan diferents rutes cap a un objectiu concret. Al cap i a la fi, tothom s’aproxima a l’ús del programari de maneres diferents, de manera que si un grup reduït de persones poden cobrir moltes possibilitats, la confiança del programari en mode operatiu és més alta.
Fluxos d'èxit i fracàs
Els processos UAT han de verificar que cada tipus d’usuari de programari obtingui els resultats tangibles necessaris tant per als fluxos d’èxit com de fallida.
En un flux d’èxit, un usuari final es queda amb un resultat esperat, com ara realitzar una comanda de producte. En un flux d’error, el programari admet l’usuari final mitjançant algun tipus d’escenari d’error, com per exemple quan un client proporciona informació de pagament de targeta de crèdit no vàlida.
Per verificar la funcionalitat, cal proporcionar informació als verificadors. En cas contrari, no saben el que hauria de fer el programari. Però per provar la usabilitat, aquesta ha de ser mínima, basada només en la tasca o en els requisits, com ara comprar "x" (producte) i pagar "y" (utilitzant els detalls de la targeta de crèdit). S’ha de posar l’únic on testers per registrar observacions, èxits i fracassos.
Beneficis de la UAT
Un avantatge clau de la bona UAT és que manté els costos de manteniment continuats el més baix possible. És més barat arreglar els problemes de funcionalitat i usabilitat més aviat. És molt més difícil arreglar un error quan hi hagi més codi al voltant de la prova de regressió o si el desenvolupador original no està disponible.
La UAT que es realitza en diverses etapes i amb diferents tipus de públic de prova proporciona oportunitats òptimes per identificar i reparar problemes trencats / usabilitat trencats en les primeres fases de la prova. Mantenir els objectius de la UAT al nivell de tasques i requisits permet als verificadors observar i notar molt més i fins i tot intentar passos fora de l’abast previst pels desenvolupadors.
La retroalimentació dels cicles de la UAT es pot incorporar a posteriors iteracions de desenvolupament, augmentant la robustesa i la usabilitat del programari. Ben aviat, fins i tot les fases de prova beta poden complementar les activitats de màrqueting i vendes, proporcionant referències i comentaris de l’estudi de cas.