Introducció al Testing i Conceptes Bàsics
Abans de començar a picar codi, hem d'entendre què busquem quan provem un programari.
Què és el Testing i la Qualitat del Programari (SQA)?
El Testing engloba totes aquelles accions empíriques (basades en l'experiència i l'execució) per assegurar la funcionalitat, validar i verificar el comportament del programari. L'objectiu és tenir una visió objectiva dels riscos abans de llançar un producte i prevenir els defectes.
Hem de diferenciar-ho del SQA (Software Quality Assurance), que és un concepte més ampli. El SQA inclou la millora dels processos de treball, auditories i normatives; el testing només n'és l'eina pràctica.
Testing Manual
Executat de forma tradicional per persones (testers) que naveguen per l'aplicació buscant errors.
Testing Automatitzat
Execució de scripts que proven la nostra aplicació sense intervenció humana. Estalvia temps, redueix errors humans i és clau en projectes complexos i en el Programari Lliure.
La Metodologia TDD (Test Driven Development)
El TDD és una filosofia de treball que capgira la manera tradicional de programar: s'escriuen els tests abans que el codi de l'aplicació. Això ens obliga a pensar com s'ha de comportar el programa abans de crear-lo.
El cicle de vida del TDD és estricte i es coneix com a Red-Green-Refactor:
RED (Vermell)
Es crea el test per a una nova funcionalitat. Si l'executem, el test fallarà (vermell) perquè el codi encara no existeix.
GREEN (Verd)
S'escriu el codi mínim i necessari perquè el test passi i es posi en verd. No busquem la perfecció, només que funcioni.
REFACTOR (Refacció)
Amb el test com a xarxa de seguretat, netegem, modularitzem i optimitzem el codi sense por a trencar res.
Enfocaments de Proves: Caixa Negra vs. Caixa Blanca
Depenent del coneixement que tinguem de les entranyes del sistema, aplicarem un enfocament o un altre:
Caixa Negra
No ens importa com està programat el codi internament. Simulem ser un usuari que introdueix unes entrades i espera un resultat concret (sortides).
Caixa Blanca (Estructural)
Som els programadors i coneixem el codi. L'objectiu és crear proves que passin per tots
els camins lògics possibles: if/else, bucles, tractaments d'errors. La
qualitat es mesura amb la Cobertura de Codi.
Tipus de Proves Funcionals
Aquestes proves asseguren que el sistema fa allò que les especificacions diuen que ha de fer:
Proves de Regressió
Asseguren que en afegir una funcionalitat nova, no hem trencat una funcionalitat vella que ja anava bé. Són les més crítiques.
Proves de Fum (Smoke Tests)
Proves rapidíssimes per descartar errors catastròfics. El nom ve de l'electrònica: "Si l'endollo, surt fum?". Exemple: comprovar si la base de dades connecta.
Proves de Sanitat (Sanity)
Semblants a les de regressió però enfocades en una àrea molt concreta de l'aplicació per validar-la ràpidament.
Proves Exploratòries
El tester actua com un "turista" navegant lliurement sense guió previ per trobar errors d'usabilitat o de lògica inesperats.
Proves de Mico (Monkey)
Provar opcions, fer clics i introduir textos de manera totalment aleatòria i ràpida fins a intentar "penjar" l'aplicació.
Tipus de Proves No Funcionals
Aquestes proves no miren què fa el sistema, sinó com ho fa (rendiment, infraestructura):
Càrrega i Estrès
Com respon el servidor si s'hi connecten 10.000 usuaris de cop? Què passa quan s'esgota la memòria RAM? Aquestes proves busquen els límits del sistema.
Estabilitat
Deixar el sistema funcionant durant dies de forma ininterrompuda per detectar si hi ha fuites de memòria o degradació del rendiment.
Usabilitat
Mesurar si la interfície és intuïtiva per a l'usuari final. No tot el que funciona tècnicament és fàcil d'usar.