what is acceptance testing
Introducció a les proves d’acceptació (part I):
En aquesta sèrie de tutorials, aprendreu:
- Què és la prova d'acceptació
- Proves d'acceptació i pla de proves
- Informes d'estat i resum de les proves d'acceptació
- Què és la prova d'acceptació d'usuaris (UAT)
Ja heu acabat amb les proves de sistema? Estan solucionats la majoria dels vostres errors? Es verificen i es tanquen els errors? Què passa, doncs?
A continuació, apareix la prova d'acceptació, que és l'última fase del procés de prova de programari . Aquesta és la fase en què el client decideix GO / No-GO per al producte i s’ha de seguir obligatòriament abans de llançar el producte al mercat. Els esforços conjunts del desenvolupament i de l'equip de proves seran concedits pel client, ja sigui acceptant o rebutjant el producte desenvolupat.
Aquest tutorial únic sobre les proves d’acceptació us proporcionarà una visió completa del significat, els tipus, els usos i diversos altres factors que intervenen a la prova d’acceptació d’una manera senzilla i senzilla per a una millor comprensió.
Què aprendreu:
- Què és la prova d'acceptació?
- Per què proves d'acceptació?
- Tipus
- Qui fa les proves d'acceptació?
- Qualitats dels verificadors d’acceptació
- Ús
- Diferències entre la prova del sistema, la prova d’acceptació i la prova d’acceptació de l’usuari
- Proves d'acceptació
- Llit de proves d’acceptació
- Criteris d’entrada i sortida de AT
- Procés de proves d’acceptació
- Factors d’èxit d’aquesta prova
- Conclusió
- Lectura recomanada
Què és la prova d'acceptació?
Un cop el Procés de proves del sistema l’equip de proves l’ha completat i ha tancat la sessió, es lliura tot el producte / aplicació al client / pocs usuaris de clients / tots dos, per comprovar-ne l’acceptabilitat, és a dir, el producte / aplicació ha de ser impecable per complir amb els aspectes crítics i requisits empresarials importants. A més, els fluxos comercials d'extrem a extrem es verificen de manera similar a la de l'escenari en temps real.
L’entorn similar a la producció serà l’entorn de proves per acceptar les proves (normalment es denomina entorn de fase, preproducció, fallada, entorn UAT).
Això és un tècnica de proves de caixa negra on només es verifica la funcionalitat per garantir que el producte compleix els criteris d’acceptació especificats (no cal tenir coneixements de disseny / implementació).
Per què proves d'acceptació?
Tot i que la prova del sistema s’ha completat amb èxit, el client demana la prova d’acceptació. Les proves realitzades aquí són repetitives, ja que haurien estat tractades en les proves del sistema.
Llavors, per què els clients realitzen aquestes proves?
Això és perquè:
- Per guanyar confiança en el producte que surt al mercat.
- Per garantir que el producte funcioni de la manera que ho ha de fer.
- Per garantir que el producte coincideixi amb els estàndards del mercat actuals i sigui prou competitiu amb la resta de productes similars del mercat.
Tipus
Hi ha diversos tipus d’aquestes proves.
Poques d'elles es detallen a continuació:
# 1) Proves d’acceptació d’usuaris (UAT)
UAT és avaluar si el producte funciona correctament per a l’usuari i per a l’ús correcte. Els requisits específics que els usuaris finals solen utilitzar sovint es recullen principalment per a la prova. Això també es denomina proves d’usuari final.
El terme 'usuari' aquí significa els usuaris finals als quals està destinat el producte / aplicació i, per tant, les proves es realitzen des de la perspectiva dels usuaris finals i des del seu punt de vista.
=> També Llegiu: Què és la prova d'acceptació d'usuaris (UAT)?
# 2) Proves d'acceptació empresarial (MTD)
Es tracta d’avaluar si el producte compleix o no els objectius i els propòsits del negoci.
BAT se centra principalment en els beneficis empresarials (finances) que són força difícils a causa de les condicions canviants del mercat / tecnologies avançades, de manera que la implementació actual pot haver de patir canvis que resultin en pressupostos addicionals.
c ++ espereu uns segons
Fins i tot el producte que passa els requisits tècnics pot fallar en BAT per aquestes raons.
# 3) Proves d'acceptació del contracte (CAT)
Es tracta d’un contracte que especifica que un cop el producte es posa en funcionament, en un termini predeterminat, s’ha de realitzar la prova d’acceptació i ha de superar tots els casos d’ús d’acceptació.
El contracte signat aquí es denomina Acord de nivell de servei (SLA), que inclou les condicions en què el pagament només es farà si els serveis del producte estan en línia amb tots els requisits, cosa que significa que es compleix el contracte.
De vegades, aquest contracte es pot produir abans que el producte es publiqui. Sigui quina sigui la forma, un contracte hauria d’estar ben definit en termes de període de proves, àrees de prova, condicions de problemes en fases posteriors, pagaments, etc.
# 4) Normativa /ComplimentProves d'acceptació (RAT)
Es tracta d’avaluar si el producte infringeix les normes i regulacions definides pel govern del país on s’està publicant. Pot ser involuntari, però afectarà negativament el negoci.
Normalment, el producte / aplicació desenvolupat que es vol llançar a tot el món ha de ser sotmès a RAT, ja que diferents països / regions tenen diferents normes i regulacions definides pels seus òrgans de govern.
Si s’incompleix alguna de les normes i regulacions per a qualsevol país, aquest país o la regió específica d’aquest país no podran utilitzar el producte i es considerarà un fracàs. Els venedors del producte seran directament responsables si el producte s’allibera tot i que hi hagi una infracció.
# 5) Proves d’acceptació operativa (OAT)
Es tracta d’avaluar la preparació operativa del producte i és una prova no funcional. Inclou principalment proves de recuperació, compatibilitat, mantenibilitat, disponibilitat d’assistència tècnica, fiabilitat, fallada, localització, etc.
OAT assegura principalment l'estabilitat del producte abans de llançar-lo a la producció.
# 6) Prova d'alfa
Es tracta d’avaluar el producte en l’entorn de desenvolupament / proves per part d’un equip de verificadors especialitzats que normalment es diu testers alfa. Aquí, els suggeriments i suggeriments dels provadors ajuden a millorar l’ús del producte i també a corregir alguns errors.
Aquí, les proves es fan de manera controlada.
=> Llegiu també: Què és la prova alfa?
# 7) Prova beta / prova de camp
Es tracta d’avaluar el producte exposant-lo als usuaris finals reals, normalment anomenats beta testers / usuaris beta, al seu entorn. Es recullen comentaris continus dels usuaris i es resolen els problemes. A més, això ajuda a millorar / millorar el producte per proporcionar una experiència d'usuari rica.
Les proves es realitzen de manera incontrolada, cosa que significa que un usuari no té restriccions en la forma en què s’utilitza el producte.
=> Llegiu també: Què és la prova beta?
Tots aquests tipus tenen un objectiu comú:
- Assegureu-vos d’aconseguir / enriquir la confiança en el producte.
- Assegureu-vos que el producte estigui a punt per ser utilitzat pels usuaris reals.
Qui fa les proves d'acceptació?
Per al tipus Alpha, només els membres de l'organització (que van desenvolupar el producte) realitzen les proves. Aquests membres no formen part directa del projecte (gestors de projectes / leads, desenvolupadors, verificadors). Els equips de gestió, vendes i assistència solen realitzar les proves i aportar comentaris en conseqüència.
A part del tipus Alpha, tots els altres tipus d'acceptació solen ser realitzats per diferents grups d'interès. Igual que els clients, clients dels clients, verificadors especialitzats de l’organització (no sempre).
També és bo involucrar analistes de negocis i experiència en matèria mentre realitzeu aquesta prova en funció del seu tipus.
Qualitats dels verificadors d’acceptació
Els verificadors amb les qualitats següents es qualifiquen com a verificadors d’acceptació:
- Capacitat per pensar lògicament i analíticament.
- Bon coneixement del domini.
- Capaç d’estudiar els productes competitius del mercat i analitzar-los en el producte desenvolupat.
- Tenir percepció de l’usuari final mentre provem.
- Comprendre la necessitat empresarial de cada requisit i provar-ho en conseqüència.
Impacte dels problemes trobats durant aquesta prova
Qualsevol problema que es produeixi en la fase de prova d’acceptació s’ha de considerar com a prioritat alta i solucionar-lo immediatament. Això també requereix que es faci una anàlisi de la causa arrel en tots els problemes que es trobin.
L’equip de proves té un paper important a l’hora de proporcionar RCA per a problemes d’acceptació. Això també ajuda a determinar l'eficàcia de les proves.
A més, els problemes vàlids de la prova d’acceptació afectaran tant les proves com els esforços de l’equip de desenvolupament en termes d’impressions, valoracions, enquestes als clients, etc. De vegades, si es troba un desconeixement de l’equip de proves sobre les validacions, també conduirà a escalades.
Ús
Aquesta prova és útil des de diversos aspectes.
Alguns dels quals inclouen:
- Per esbrinar els problemes perduts durant la fase de proves funcionals.
- Què tan bé es desenvolupa el producte?
- Un producte és el que realment necessiten els clients.
- Els comentaris / enquestes van ajudar a millorar el rendiment del producte i l’experiència de l’usuari.
- Milloreu el procés seguit tenint RCA com a entrada.
- Minimitzar o eliminar els problemes derivats del producte de producció.
Diferències entre la prova del sistema, la prova d’acceptació i la prova d’acceptació de l’usuari
A continuació es detallen les diferències principals entre aquests 3 tipus de proves d’acceptació.
| Proves del sistema | Proves d'acceptació | Proves d’acceptació d’usuaris |
|---|---|---|
| Es realitzen proves positives i negatives | Normalment es realitzen proves positives | Només es realitzen proves positives |
| Es fan proves completes per verificar si el producte compleix tots els requisits especificats | Es realitzen proves per verificar si el producte compleix els requisits d’acceptació del client | Es realitzen proves per verificar si es compleixen els requisits dels usuaris finals per acceptar-los |
| Un producte es prova en conjunt concentrant-se només en necessitats funcionals i no funcionals | El producte es prova per a les necessitats empresarials: acceptabilitat de l’usuari, objectius comercials, normes i regulacions, operacions, etc. | El producte només es prova si l’acceptabilitat de l’usuari és correcta |
| L'equip de proves realitza proves de sistema | El client, els clients dels clients, el verificador (poques vegades), la gestió, les vendes i els equips d'assistència realitzen proves d'acceptació en funció del tipus de prova realitzada | El client, el client dels clients, els verificadors (poques vegades) realitza proves d’acceptació de l’usuari |
| Els casos de prova s’escriuen i s’executen | Les proves d’acceptació s’escriuen i s’executen | Les proves d’acceptació d’usuaris s’escriuen i s’executen |
| Pot ser funcional i no funcional | Normalment funcional, però no funcional en cas de RAT, OAT, etc. | Només funcional |
| Només s’utilitzen dades de prova per provar-les | Les dades en temps real / dades de producció s’utilitzen per provar | Les dades en temps real / dades de producció s’utilitzen per provar |
| Els problemes trobats es consideren errors i es solucionen en funció de la gravetat i la prioritat | Els problemes trobats marquen el producte com a fallada i es consideren solucionats immediatament | Els problemes trobats marquen el producte com a fallada i es considera que es solucionen immediatament |
| Manera controlada de proves | Es pot controlar o no segons el tipus de prova | Manera incontrolada de proves |
| Proves en entorn de desenvolupament | Proves sobre entorn de desenvolupament o entorn de preproducció o entorn de producció, segons el tipus | Les proves sempre es fan en entorns de preproducció |
| No hi ha suposicions, però si es pot comunicar alguna | No hi ha supòsits | No hi ha supòsits |
Proves d'acceptació
De manera similar als casos de proves de productes, tenim proves d’acceptació. Les proves d’acceptació es deriven dels criteris d’acceptació de les històries dels usuaris. Aquests solen ser els escenaris que s’escriuen a l’alt nivell detallant què ha de fer el producte en diferents condicions.
No dóna una imatge clara de com realitzar proves, com en casos de proves. Les proves d’acceptació les escriuen els provadors que comprenen completament el producte, generalment en matèria. Totes les proves escrites són revisades per un client i / o analistes de negocis.
Aquestes proves s’executen durant la prova d’acceptació. Juntament amb les proves d’acceptació, s’ha de preparar un document detallat sobre les configuracions a fer. Ha d'incloure detalls de cada minut amb captures de pantalla adequades, valors de configuració, condicions, etc.
Llit de proves d’acceptació
El banc de proves per a aquesta prova és similar a un banc de proves normal, però és diferent. La plataforma amb tot el maquinari, programari, productes operatius, configuració i configuració de xarxa, configuració i configuració de servidors, configuració i configuració de bases de dades, llicències, connectors, etc., s’ha de configurar de la mateixa manera. l’entorn de producció.
El banc de proves d’acceptació és una plataforma / entorn on s’executaran les proves d’acceptació dissenyades. Abans de lliurar l'entorn de prova d'acceptació al client, és una bona pràctica comprovar si hi ha problemes ambientals i estabilitat del producte.
Si no hi ha cap entorn separat configurat per a les proves d'acceptació, es pot utilitzar un entorn de proves regular per a aquest propòsit. Però aquí, serà desordenat ja que les dades de prova de les proves de sistema regulars i les dades en temps real de les proves d’acceptació es mantenen en un únic entorn.
El banc de proves d’acceptació sol establir-se al costat del client (és a dir, al laboratori) i tindrà accés restringit als equips de desenvolupament i proves.
com obrir un fitxer torrent
Els equips hauran d’accedir a aquest entorn mitjançant màquines virtuals o URL dissenyats específicament mitjançant credencials d’accés especials i se’n farà un seguiment. No s’ha d’afegir / modificar / suprimir res d’aquest entorn sense el permís del client i se’ls ha de notificar els canvis que s’hi fan.
Criteris d’entrada i sortida de AT
Igual que qualsevol altra fase del STLC, les proves d’acceptació tenen un conjunt de criteris d’entrada i sortida que s’han de definir bé al pla de proves d’acceptació (que es cobreix a la part posterior d’aquest tutorial).
Aquesta és la fase que comença just després de la prova del sistema i finalitza abans del llançament de la producció. Per tant, els criteris de sortida de les proves del sistema passen a formar part dels criteris d’entrada per a AT. De la mateixa manera, els criteris de sortida d'AT passen a formar part dels criteris d'entrada per al llançament de la producció.
Criteris d’entrada
A continuació es detallen les condicions que cal complir abans de començar:
- Els requisits empresarials han de ser clars i disponibles.
- La fase de proves del sistema i de regressió s'hauria de completar.
- Tots els errors crítics, majors i normals s’han de corregir i tancar (els errors menors acceptats principalment són errors cosmètics que no pertorben l’ús del producte).
- La llista de problemes coneguts s'hauria de preparar i compartir amb els grups d'interès.
- S’ha d’instal·lar un llit de proves d’acceptació i s’ha de fer un control d’alt nivell si no hi ha problemes ambientals.
- S'ha de tancar la fase de proves del sistema que permeti que el producte passi a la fase AT (normalment es fa mitjançant la comunicació per correu electrònic).
Criteris de sortida
Hi ha certes condicions que AT ha de complir per deixar que el producte es pugui llançar a la producció.
Són els següents:
- S'han d'executar proves d'acceptació i totes les proves han de passar.
- No queden defectes crítics / majors oberts. Tots els defectes s’han de corregir i verificar immediatament.
- AT hauria de ser subscrit per tots els grups d'interès inclosos Vés / No vés Decisió sobre el producte.
Procés de proves d’acceptació
En Model V , La fase AT és paral·lela a la fase de requisits.
El procés AT real es realitza com es mostra a continuació:
Anàlisi de requisits empresarials
Els requisits empresarials s’analitzen remetent tots els documents disponibles dins del projecte.
Alguns dels quals són:
- Especificacions dels requisits del sistema
- Document de requisits empresarials
- Casos d’ús
- Diagrames de flux de treball
- Matriu de dades dissenyada
Pla de prova d’acceptació del disseny
Hi ha determinats elements que s'han de documentar al pla de prova d'acceptació.
Vegem-ne alguns:
- Estratègia i enfocament de proves d'acceptació.
- Els criteris d’entrada i sortida haurien d’estar ben definits.
- L’abast de l’AT ha de ser ben esmentat i ha de cobrir només els requisits empresarials.
- L’enfocament del disseny de les proves d’acceptació s’ha de detallar perquè qualsevol persona que escrigui proves pugui entendre fàcilment la forma en què s’ha d’escriure.
- Establert el banc de proves, s’ha d’esmentar el calendari / calendari real de proves.
- Com que les diferents parts interessades realitzen les proves, cal esmentar els detalls sobre l’error de registre, ja que és possible que les parts interessades no siguin conscients del procediment seguit.
Dissenyar i revisar proves d'acceptació
Les proves d’acceptació s’han d’escriure a nivell d’escenari esmentant el que s’ha de fer (no detallat per incloure com fer-ho). S’han d’escriure només per a les àrees d’abast identificades per als requisits empresarials, i totes i cadascuna de les proves s’ha d’assignar al seu requisit de referència.
Cal revisar totes les proves d’acceptació per escrit per aconseguir una elevada cobertura dels requisits empresarials.
Això és per assegurar-se que no hi hagi cap altra prova a part de l'abast esmentat, de manera que les proves es trobin dins dels terminis programats.
Instal·lació del llit de proves d’acceptació
El banc de proves s’ha d’instal·lar de manera similar a l’entorn de producció. Es requereixen controls de molt alt nivell per confirmar l’estabilitat i l’ús del medi ambient. Compartiu les credencials per utilitzar l'entorn només amb una part interessada que realitzi aquesta prova.
Configuració de dades de prova d’acceptació
Les dades de producció s'han de preparar / omplir com a dades de prova als sistemes. A més, hi hauria d’haver un document detallat de manera que les dades s’hagin d’utilitzar per fer proves.
No disposeu de dades de prova com TestName1, TestCity1, etc., en lloc de fer-ho Albert, Mèxic, etc. Això proporciona una rica experiència de dades en temps real i les proves seran actualitzades.
Execució de la prova d’acceptació
Les proves d'acceptació dissenyades s'han d'executar a l'entorn en aquest pas. Idealment, totes les proves haurien de superar-se en el primer intent. No hi hauria d’haver errors funcionals derivats de la prova d’acceptació, si n’hi ha, i s’haurien de comunicar amb una alta prioritat per solucionar-los.
Una vegada més, els errors corregits s'han de verificar i tancar com a tasca d'alta prioritat. L'informe d'execució de la prova s'ha de compartir diàriament.
Els errors registrats en aquesta fase s’han de discutir en una reunió de triatge d’errors i s’han de sotmetre al procediment d’anàlisi de la causa arrel. Aquest és l’únic punt en què les proves d’acceptació avaluen si el producte compleix o no tots els requisits empresarials.
Decisió empresarial
En surt un Vés / No vés decisió del llançament del producte a Production. Vaja la decisió portarà el producte per endavant a ser llançat al mercat. No-Go la decisió marca el producte com a fracàs.
Pocs factors de la decisió de no accedir:
- Mala qualitat del producte.
- Hi ha massa errors funcionals oberts.
- Desviació dels requisits empresarials.
- No s’ajusta als estàndards del mercat i necessita millores per coincidir amb els estàndards del mercat actuals.
Factors d’èxit d’aquesta prova
Un cop planificada aquesta prova, prepareu una llista de comprovació que n'augmenti la taxa d'èxit. Hi ha alguns elements d'acció que s'han de seguir abans que comenci la prova d'acceptació.
Ells són:
- Teniu un abast ben definit i assegureu-vos que hi hagi una necessitat empresarial de l'abast identificat per a aquesta prova.
- Executeu proves d'acceptació en la fase de proves del sistema en si mateix almenys una vegada.
- Rendiment extens proves ad-hoc per a cadascun dels escenaris de prova d’acceptació.
Conclusió
En poques paraules, les proves d’acceptació ajuden a esbrinar l’eficiència dels equips de desenvolupament i proves.
Hi ha diverses eines per dur a terme aquesta activitat, però, normalment, es prefereix fer-la manualment, ja que hi ha una participació dels usuaris reals i dels diferents grups d'interès que no pertanyen a una formació tècnica, i pot ser que no sigui factible per a ells.
Que segueix?
Al nostre següent tutorial, passarem per sobre dels temes següents:
- Exemples de criteris de prova d’acceptació.
- Com escriure un pla de prova d’acceptació.
- Una plantilla adequada per escriure proves d’acceptació.
- Com escriure proves d’acceptació amb exemples.
- Identificació d’escenaris de prova d’acceptació.
- Informes de proves d’acceptació.
- Proves d'acceptació en desenvolupament àgil i basat en proves.
NEXT Tutorial núm. 2: pla de prova d’acceptació
Heu realitzat proves d'acceptació? Estarem encantats d'escoltar les vostres experiències !!
Lectura recomanada
- Proves alfa i proves beta (guia completa)
- Què és la prova d’acceptació d’usuaris (UAT): una guia completa
- Guia completa de proves de verificació de compilació (proves BVT)
- Proves funcionals contra proves no funcionals
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Tutorial de proves de magatzem de dades de proves ETL (una guia completa)
- Guia de proves de seguretat d'aplicacions web