Com provar la teva aplicació abans del llançament: pla pràctic

Per provar la teva aplicació abans del llançament, fes una llista dels pocs recorreguts que un usuari ha de poder completar, executa cadascun com un usuari nou en un ordinador i en un mòbil, i després prova les maneres en què pot sortir malament: dades buides, entrada incorrecta, un segon compte, una connexió lenta. Prova amb més cura qualsevol cosa que impliqui diners o dades privades, i repeteix els recorreguts principals a la URL en directe després de publicar. Acaba observant algú que no ha vist mai l'aplicació mentre intenta utilitzar-la.

No necessites un equip de QA ni un marc de proves per fer-ho. Necessites una llista, una o dues hores i la disciplina de repassar-la de veritat.

Pas 1: Escriu els recorreguts que importen

Un recorregut és una tasca de principi a fi que un usuari ve a fer. La majoria d'aplicacions en tenen entre tres i sis que realment importen. Per a una aplicació de reserves:

Registrar-se i confirmar el compte
Trobar una classe i reservar-la
Cancel·lar una reserva
Pagar un abonament de classes
Personal: veure les reserves d'avui

Si has escrit històries d'usuari, els seus criteris d'acceptació ja són els teus casos de prova. Si no, escriu una línia per recorregut amb el que significa «èxit».

Ordena'ls per prioritat. Els recorreguts que generen diners o que tots els usuaris fan (el registre, l'inici de sessió, l'acció principal) es proven primer i amb més profunditat.

Pas 2: Prova el camí ideal com un usuari nou

El «camí ideal» és el recorregut que va exactament com estava previst. Prova'l tal com l'experimentaria un desconegut:

Fes servir una finestra de navegació privada, així no estàs connectat i no tens dades guardades.
Fes servir un compte nou amb un correu real que puguis comprovar.
Comença des de la pàgina d'inici o un enllaç, no des d'una pàgina que tinguis marcada mentre construïes.

Els usuaris nous no tenen dades. Molts errors només apareixen quan una llista és buida, un perfil no té foto o encara no s'ha comprat res. El teu propi compte, ple de dades de prova, els amaga.

Pas 3: Intenta trencar-la

Ara repeteix cada recorregut i fes deliberadament el que no toca.

Prova això	Què estàs comprovant
Enviar formularis buits, o amb només espais	Els camps obligatoris s'apliquen, amb un missatge clar
Text molt llarg, emoji, noms amb accents	El disseny aguanta i les dades es desen bé
Formats incorrectes: lletres en un camp de telèfon, una data passada	Validació tant a la pàgina com al servidor
Fer doble clic al botó d'enviar	No es dupliquen comandes ni reserves
Botó enrere del navegador a mig flux	Cap estat trencat ni dades perdudes
Refrescar a cada pàgina	Les dades persisteixen; cap pàgina en blanc ni 404
Tancar sessió i després prémer enrere	Les pàgines privades no es mostren
Dues pestanyes editant el mateix	L'últim desat no esborra el primer en silenci

Val la pena destacar el refresc: si l'aplicació funciona quan fas clic però un refresc en una pàgina més profunda mostra un 404, consulta com solucionar errors 404 després de desplegar.

Pas 4: Prova els permisos amb dos comptes

Aquesta és la prova més important per a qualsevol aplicació amb comptes, i la que més sovint s'omet.

Crea dos usuaris normals, A i B, i (si l'aplicació els té) un administrador.

Com a A, crea un registre. Inicia sessió com a B. Pot veure'l, editar-lo o esborrar-lo? No hauria de, tret que sigui així pel disseny.
Com a A, copia la URL d'un dels teus registres. Inicia sessió com a B i obre aquesta URL directament.
Com a usuari normal, obre les pàgines d'administració escrivint-ne les URL.
Tanca la sessió del tot i prova les mateixes URL.

Si trobes un problema aquí, no llancis fins que estigui arreglat. La comprovació s'ha de fer al servidor, no només amagant un botó. La nostra llista de verificació de seguretat per a aplicacions creades amb IA va més a fons.

Pas 5: Prova en dispositius reals

Obre l'aplicació en un telèfon de veritat, no només en una finestra estreta del navegador.

Pots tocar cada botó sense fer zoom?
El teclat tapa el camp que estàs escrivint?
Les taules i el contingut ample es desplacen o s'ajusten, en lloc d'empènyer la pàgina de costat?
El text es llegeix sense fer pinça?

Prova com a mínim un iPhone (Safari) i un telèfon Android (Chrome) si els pots deixar. Safari en particular té les seves pròpies peculiaritats amb les dates, el vídeo i els elements de posició fixa.

Pas 6: Prova els diners i el correu de principi a fi

Qualsevol cosa que cobri targetes o enviï correus necessita una execució completa.

Pagaments. Fes servir el mode de prova del teu proveïdor de pagaments i els números de targeta de prova. Comprova un pagament reeixit, una targeta rebutjada i un pagament cancel·lat. Confirma que la comanda o la subscripció apareix a la teva aplicació després del pagament, no només al tauler del proveïdor. Si la teva aplicació depèn de webhooks (missatges que el proveïdor de pagaments envia al teu servidor), comprova que arriben a l'aplicació publicada, no només en desenvolupament. Després, abans del llançament, passa a les claus reals i fes una petita compra real que tornis a reemborsar.

Correus. Registra't amb adreces reals en dos o tres proveïdors diferents. Comprova que els correus arriben, que no van a spam i que cada enllaç que contenen apunta al domini en directe, no a una adreça de vista prèvia.

Pas 7: Comprova la velocitat i els errors

Obre les eines de desenvolupador del navegador (clic dret → Inspeccionar) i mira la pestanya Consola a cada pàgina principal. Els errors en vermell val la pena arreglar-los encara que res no sembli trencat.
Carrega el lloc en un telèfon amb dades mòbils, no amb Wi-Fi. Si la primera pantalla triga diversos segons, mira primer la mida de les imatges.
Executa una auditoria gratuïta com Lighthouse a les eines de desenvolupador de Chrome per tenir una lectura ràpida del rendiment i de l'accessibilitat.

Pas 8: Prova l'aplicació publicada, no només la vista prèvia

Una vista prèvia i una aplicació publicada no són el mateix entorn. Abans d'explicar a ningú el llançament, repeteix els recorreguts principals a la URL en directe:

Estan totes les variables d'entorn i els secrets configurats per a l'aplicació publicada?
Fa servir la base de dades correcta, amb les dades que esperes?
Les redireccions d'inici de sessió i els enllaços de correu fan servir el domini en directe?
Un refresc en una pàgina profunda es carrega bé?

Pas 9: Observa algú altre fent-la servir

Dona a una o dues persones un objectiu («reserva una classe de ioga per dissabte»), no instruccions. Observa, no ajudis, i anota on dubten. És la manera més ràpida de trobar textos confusos i botons amagats. Per a una versió més gran d'això, consulta com fer una prova beta.

Quan trobin un error, anota'l com cal, amb els passos, el resultat esperat i el resultat real. La nostra guia sobre com escriure un bon informe d'error mostra el format.

Fer servir la IA per ajudar-te a provar

Si construeixes amb IA, pots demanar-li que t'ajudi a planificar i executar les proves:

Llista els recorreguts principals d'usuari d'aquesta aplicació i, per a cadascun, els casos límit més probables que es trenquin: estats buits, entrada no vàlida, permisos i refresc. Posa-ho en una llista de verificació que pugui repassar.

Inicia sessió com a dos usuaris de prova diferents i comprova si l'usuari B pot veure o modificar alguna cosa que l'usuari A ha creat, inclosa l'obertura directa de les URL dels registres d'A. Informa del que trobis abans de corregir res.

Considera l'informe de proves de la IA com una primera passada. Repassa tu mateix els recorreguts de diners i de permisos.

Proves a Mythex

A Mythex, l'ordre /test executa App Testing: l'agent controla un navegador sobre la teva vista prèvia en directe, fa clic a les pàgines, captura captures de pantalla i informa dels fluxos trencats al xat. Funciona millor amb un recorregut concret, com «prova el registre i la reserva d'una classe». Arregla el que trobi amb /fix o amb un missatge normal, i després torna a executar /test. App Testing fa servir la vista prèvia, així que comprova tu mateix els recorreguts principals a la URL publicada després de publicar. Consulta App Testing a la documentació, i la nostra guia sobre com depurar una aplicació creada amb IA per quan alguna cosa falla.

Errors habituals

Provar només com a tu mateix. El teu compte d'administrador amb moltes dades amaga els errors d'estat buit i de permisos.
Provar només en un ordinador. A molts llocs la majoria de visitants arriben des d'un mòbil.
Saltar-se el segon compte. Les dades que es filtren entre usuaris són l'error més greu amb què pot llançar-se una aplicació.
Confiar en la vista prèvia. L'aplicació en directe té una configuració diferent; prova-la també.
Arreglar errors sense tornar a provar el que hi ha al voltant. Un canvi en un formulari pot trencar un altre que comparteix codi.

Llista de verificació abans del llançament

Recorreguts principals llistats i ordenats per prioritat
Cada recorregut supera la prova com a usuari nou en una finestra privada
Entrada buida, incorrecta, llarga i duplicada gestionada
El refresc funciona a cada pàgina
Els usuaris no poden veure ni modificar les dades dels altres, ni tan sols per URL
Les pàgines d'administració estan bloquejades per als usuaris normals i per als visitants que no han iniciat sessió
Funciona en un iPhone real i en un telèfon Android
Pagaments provats: èxit, rebuig, cancel·lació, i l'aplicació s'actualitza després
Els correus arriben, eviten el spam i enllacen al domini en directe
Cap error en vermell a la consola de les pàgines principals
Recorreguts principals repetits a la URL publicada
Almenys una persona externa l'ha provat mentre tu observaves

Preguntes

Quantes proves necessita una aplicació petita abans del llançament?

Prou per estar segur que els recorreguts principals funcionen per a un usuari nou en un mòbil i en un ordinador, que els usuaris no poden veure les dades dels altres i que tot el que implica diners funciona de principi a fi. Per a la majoria d'aplicacions petites, això són unes quantes hores concentrades, no setmanes.

Cal tenir proves automatitzades per a un MVP?

No necessàriament. Les proves manuals dels recorreguts essencials detecten la majoria d'errors que bloquejarien el llançament. Les proves automatitzades comencen a valer la pena quan canvies l'aplicació sovint i vols saber ràpidament que no has trencat res que abans funcionava.

He de provar la vista prèvia o l'aplicació en directe?

Totes dues. Prova a fons la vista prèvia i després repeteix els recorreguts principals a l'aplicació publicada, perquè les variables d'entorn que falten, una base de dades diferent o la configuració de les rutes poden fer que la versió en directe es comporti de manera diferent.

Qui més hauria de provar la meva aplicació a part de mi?

Com a mínim una persona que no l'hagi vist mai. Dona-li un objectiu, no instruccions, i observa sense ajudar. Els constructors eviten inconscientment els camins que es trenquen.