Disseny i realització de proves de programari

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Disseny i realització de proves de programari.

1. Propòsit de les proves

Propòsit principal de les proves dins del cicle de vida del desenvolupament: verificar que el programari compleix els requisits especificats i detectar defectes abans que arribin a producció, proporcionant informació objectiva sobre la qualitat del producte per donar suport a la presa de decisions.

Tres matisos que es pregunten:

• Les proves no demostren l'absència de defectes: només en demostren la presència (Dijkstra). L'exhaustivitat és impossible.
• Les proves no milloren la qualitat per si soles: la revelen. La qualitat es construeix, no es prova.
• Serveixen també per reduir el risc i per donar confiança per desplegar.

Els set principis de les proves (ISTQB, International Software Testing Qualifications Board):

1. Les proves mostren la presència de defectes, no la seva absència.
2. Les proves exhaustives són impossibles.
3. Provar aviat (early testing), també anomenat desplaçament a l'esquerra (shift-left), estalvia temps i diners: el cost de corregir un defecte creix com més tard es detecta, i provar des de l'inici —revisar l'especificació, escriure proves abans o durant la implementació— surt més barat que provar només al final.
4. Agrupació de defectes: un nombre reduït de mòduls conté la majoria dels defectes (Pareto).
5. Paradoxa del pesticida: repetir sempre les mateixes proves deixa de trobar defectes nous; cal revisar-les i ampliar-les.
6. Les proves depenen del context.
7. La falàcia de l'absència d'errors: un sistema sense defectes coneguts pot ser igualment inservible si no cobreix les necessitats de l'usuari.

Verificació vs validació: verificació = estem construint el producte correctament? (compleix l'especificació); validació = estem construint el producte correcte? (satisfà la necessitat real).

Error → defecte → fallida: una persona comet un error, que introdueix un defecte al codi, que en executar-se pot provocar una fallida del sistema.

2. Nivells de prova

Proves d'acceptació d'usuari (UAT — User Acceptance Testing): les executen els usuaris finals o els representants del negoci en un entorn semblant al de producció, amb dades i escenaris reals, per validar que el sistema satisfà les seves necessitats i que estan disposats a acceptar-lo. No busquen defectes tècnics: busquen adequació a l'ús. Variants: prova alfa (a les instal·lacions del desenvolupador), prova beta (a l'entorn de l'usuari), prova d'acceptació operativa (còpies, recuperació, manteniment), prova d'acceptació contractual i normativa.

Estratègies d'integració: big bang, descendent (top-down) amb stubs, ascendent (bottom-up) amb controladors (drivers), sandvitx i incremental contínua (CI).

Dobles de prova: dummy, stub, spy, mock i fake.

3. Tipus de prova

3.1 Funcionals

Verifiquen què fa el sistema: proves de requisits, de casos d'ús, de regles de negoci, de fluxos i de dades.

3.2 No funcionals

Verifiquen com de bé ho fa:

• Rendiment: càrrega, estrès, resistència (soak), pic (spike), escalabilitat i volum → tema 21. Un informe de prova de càrrega (per exemple, l'informe agregat de JMeter) es llegeix comparant mitjana i mediana —si són properes, el rendiment és estable; si la mediana queda molt per sota de la mitjana, uns quants temps molt alts la distorsionen— i mirant la desviació estàndard: com més baixa, més consistent és el servei sota càrrega.
• Seguretat: anàlisi estàtica (SAST, Static Application Security Testing), dinàmica (DAST, Dynamic Application Security Testing), anàlisi de composició (SCA, Software Composition Analysis), proves de penetració (pen test) i anàlisi de vulnerabilitats.
• Usabilitat i accessibilitat (WCAG (Web Content Accessibility Guidelines) 2.1 AA, obligatòria al sector públic pel RD (Reial Decret) 1112/2018): eines automàtiques (axe, WAVE, Lighthouse) i proves amb usuaris i amb productes de suport (lectors de pantalla).
• Compatibilitat: navegadors, dispositius, sistemes operatius, resolucions.
• Fiabilitat, recuperació i tolerància a fallides.
• Portabilitat, mantenibilitat i instal·lació.
• Internacionalització i localització.

3.3 Proves de canvis

Totes es fan al voltant d'un canvi, i el tribunal les contraposa per la pregunta a la qual responen: la confirmació respon s'ha arreglat allò?, la regressió he trencat res? i la de fum arrenca, si més no?.

• Proves de confirmació (retest): tornar a executar la prova que va fallar, un cop corregit el defecte, per comprovar que la correcció funciona. Miren el defecte corregit, no la resta del sistema.
• Proves de regressió: s'executen per assegurar que els canvis o correccions introduïts al codi no han provocat errors nous en funcionalitats que ja funcionaven correctament. Aquesta és la definició literal que es pregunta, i la correcta és sempre «regressió».
• Són les candidates naturals a l'automatització, perquè es repeteixen a cada canvi.
• Regressió completa vs selecció de regressió basada en l'anàlisi d'impacte.
• Una prova de fum (smoke test) és una bateria mínima i ràpida de les funcions crítiques, feta abans de provar de debò, que verifica que el sistema arrenca i que va el que és essencial; serveix per decidir si val la pena continuar provant. És l'exemple típic de criteri d'entrada: no busca defectes, comprova que la versió és provable.
• La prova de sanitat (sanity test) és una comprovació ràpida i focalitzada d'una àrea concreta després d'un canvi menor, a mig camí entre la de fum i la regressió completa.

4. Tècniques de disseny de casos de prova

La diferència que es pregunta: la caixa blanca dissenya els casos analitzant el funcionament intern del codi —camins, condicions, complexitat—; la caixa negra, a partir de l'especificació externa, sense conèixer el codi. No es distingeixen per la fase en què s'apliquen —totes dues serveixen a qualsevol fase—, i la distractora habitual inverteix les dues definicions.

4.1 Caixa negra (basades en l'especificació)

La caixa negra dissenya els casos a partir de l'especificació i del comportament esperat, sense mirar com està escrit el codi per dins. Serveix a qualsevol nivell de prova i no cal accés al codi font.

• Particions d'equivalència: dividir el domini d'entrada en classes que es comporten igual i provar-ne un representant de cadascuna. Estalvia proves redundants.
• Anàlisi de valors límit: provar els extrems de cada partició i els seus veïns immediats. És on es concentren els defectes. La diferència amb l'anterior és quin representant es tria: la partició en tria un qualsevol; els valors límit trien justament els de la vora —les dues es fan servir juntes, i el tribunal les contraposa.
• Taules de decisió: combinacions de condicions i accions.
• Transició d'estats: per a sistemes amb estats i esdeveniments.
• Casos d'ús i parells (pairwise) per reduir l'explosió combinatòria.

4.2 Caixa blanca (basades en l'estructura)

La caixa blanca dissenya els casos a partir de l'estructura interna del codi i en mesura la cobertura assolida; exigeix accés al codi font i és sobretot de nivell unitari. La contraposició amb la caixa negra és especificació contra codi, no «usuari contra tècnic».

• Cobertura de sentències, de decisions/branques, de condicions, de condicions múltiples i MC/DC (obligatòria en programari crític).
• Cobertura de camins i complexitat ciclomàtica com a fita del nombre de camins.

4.3 Basades en l'experiència

Predicció d'errors (error guessing), proves exploratòries i proves basades en llistes de verificació.

5. Automatització

Piràmide de proves (Mike Cohn): molts casos unitaris a la base, menys d'integració/servei al mig i molt pocs d'extrem a extrem (E2E) al cim. Les d'a dalt són lentes, fràgils i cares; les de baix, ràpides i barates.

Antipatró del con de gelat: la piràmide invertida —molts E2E i poques unitàries— que produeix una bateria lenta, inestable i inútil.

Proves inestables (flaky): passen o fallen sense canvis al codi. Destrueixen la confiança a la bateria: cal aïllar-les i corregir-les immediatament, no reexecutar-les fins que passin.

Eines: JUnit, pytest, NUnit, Jest (unitàries); Testcontainers, WireMock, Pact (integració i contractes); Selenium, Cypress, Playwright (E2E web); Appium, Espresso, XCUITest (mòbil); REST (REpresentational State Transfer) Assured, Postman/Newman, Karate (API, Application Programming Interface); JMeter, k6, Gatling (rendiment); OWASP (Open Worldwide Application Security Project) ZAP (Zed Attack Proxy), Burp (seguretat); SonarQube (estàtica).

Integració al pipeline: unitàries i estàtiques a cada commit; integració i contractes a cada fusió; E2E i rendiment abans del pas a preproducció → tema 41.

5.1 Desenvolupament guiat per proves (TDD)

TDD (Test-Driven Development, desenvolupament guiat per proves): tècnica en què s'escriu la prova d'un requisit abans que el codi que l'implementa. Cicle roig → verd → refactor, que es repeteix per a cada requisit:

1. Roig: triar un requisit i escriure'n una prova, que ha de fallar perquè encara no hi ha implementació.
2. Verd: escriure la implementació mínima que fa passar la prova, sense preocupar-se encara del disseny.
3. Refactor: millorar l'estructura del codi (eliminar duplicació, aclarir noms) mantenint totes les proves en verd.

El primer pas del cicle és sempre escriure la prova, no el codi: és la inversió respecte al desenvolupament tradicional i el que distingeix el TDD d'«escriure proves després».

6. Gestió i entorns

Pla de proves (IEEE 829 / ISO/IEC (International Electrotechnical Commission) 29119): abast, estratègia, nivells i tipus, criteris d'entrada i de sortida, entorns, dades, riscos, recursos, calendari i entregables.

• Criteris d'entrada: quan es pot començar a provar (codi desplegat, prova de fum superada).
• Criteris de sortida: quan es pot deixar de provar (cobertura assolida, cap defecte crític obert, casos executats).

Gestió de defectes: registre amb passos per reproduir, resultat esperat i obtingut, entorn, gravetat (impacte tècnic) i prioritat (urgència de negoci) —no són el mateix—, i el seu cicle de vida (obert → assignat → resolt → verificat → tancat / rebutjat / duplicat / ajornat).

Entorns: desenvolupament, integració, QA (Quality Assurance, assegurament de la qualitat)/proves, preproducció (com més semblant a producció, millor) i producció.

Dades de prova: aquest és un punt crític al sector públic. No es poden fer servir dades personals reals en entorns de prova sense una base de licitud i garanties: el principi de limitació de la finalitat del RGPD, art. 5 ho impedeix. Solucions: generació sintètica, anonimització o pseudonimització robusta, i subconjunts mínims. Si excepcionalment s'usen dades reals, cal la mateixa protecció que a producció.

6.1 El procés de prova i els seus productes

Provar no és només executar: és una seqüència d'activitats que acompanya tot el projecte. Planificació → seguiment i control → anàlisi (què s'ha de provar) → disseny (com es provarà) → implementació (preparar el material i l'entorn) → execució → tancament (informe, lliçons apreses i arxiu del material). No són estrictament seqüencials: en un context àgil s'encavalquen i es repeteixen a cada iteració.

Els productes de treball tenen noms que es confonen:

• Condició de prova: allò que s'ha de comprovar —un requisit, una regla de negoci, un risc—. Diu què.
• Cas de prova: entrades, precondicions i resultat esperat que exerciten una condició. Diu amb quines dades i què ha de passar.
• Procediment de prova: la seqüència ordenada de casos i els passos per executar-los.
• Informe de proves: què s'ha executat, què ha passat i quins defectes queden oberts. És el que sosté la decisió de desplegar.

L'estratègia de proves és el criteri general amb què s'aborda tot això, i es tria segons el context: analítica (es prioritza pel risc o pels requisits), metòdica (una llista de verificació estàndard, sempre la mateixa), conforme a la norma o al procés, i reactiva (es dissenya mentre s'executa, com a les proves exploratòries).

7. Al sector públic

• Les proves d'accessibilitat són obligatòries i s'han de documentar a la declaració d'accessibilitat (RD 1112/2018).
• Les proves de seguretat formen part dels requisits de l'ENS, que exigeix anàlisi de vulnerabilitats i, segons la categoria, proves de penetració abans del pas a producció.
• La validació i proves del servei d'ITIL (Information Technology Infrastructure Library) v3 és el procés que dona la confiança que l'entrega lliurarà el valor esperat → tema 19. Els seus quatre subprocessos són definició de models de prova, adquisició de components per a la versió, proves de la versió i proves d'acceptació del servei.
• L'acceptació formal del contracte (LCSP) és el moment jurídic en què es verifiquen els criteris; els plecs han de definir-los de manera mesurable (cobertura mínima, absència de vulnerabilitats crítiques, compliment WCAG).
• Les UAT les han de fer les unitats usuàries municipals, no el proveïdor.

Claus d'examen

• La definició literal de regressió cau així: «els canvis o correccions al codi no han provocat errors nous en funcionalitats que ja funcionaven». Encara que el redactat variï, si parla de repetir una prova després d'un canvi per comprovar que no s'ha trencat res, és regressió (TS-TIC 2023 específic, p. 65; TS-TIC 2025 específic, p. 52).
• El cicle TDD comença en roig: es tria un requisit i s'escriu la prova abans que el codi. La confusió és posar «escriure la implementació» com a primer pas (TS-TIC 2025 pràctica, s3-p23).
• Davant d'una eina lliure per a proves de validació d'usuari, la resposta és una eina d'automatització de navegador (Selenium), no una de build (Maven) ni d'anàlisi estàtica (SonarQube) (TS-TIC 2023 pràctica, s4-p11).
• Per interpretar un informe de prova de càrrega, compara mitjana i mediana: si són pràcticament iguals, el rendiment és estable des de l'inici, no inestable (TS-TIC 2021 pràctica, s4-p16).
• Els subprocessos de «Validació i proves del servei» d'ITIL v3 parlen d'adquisició de components, no d'adquisició de recursos de màquina, que és la distractora habitual (TS-TIC 2018 específic, p. 87).

Per recordar

• Les proves mostren la presència de defectes, no l'absència; les exhaustives són impossibles; provar aviat (shift-left); paradoxa del pesticida.
• TDD: cicle roig → verd → refactor. Es comença escrivint la prova, no el codi.
• Verificació = construir bé el producte; validació = construir el producte correcte.
• Nivells: unitàries → integració → sistema → acceptació.
• Les tres proves posteriors a un canvi, per la pregunta que responen: confirmació = s'ha arreglat allò?; regressió = he trencat res? —és la candidata principal a l'automatització—; fum = arrenca, si més no?.
• Condició de prova = què s'ha de comprovar; cas de prova = amb quines dades i quin és el resultat esperat.
• UAT = les fan els usuaris finals, en entorn i dades realistes, per validar l'adequació a l'ús.
• Valors límit: on es concentren els defectes.
• Piràmide de proves: moltes unitàries, poques E2E. El con de gelat és l'antipatró.
• Gravetat ≠ prioritat.
• No es poden usar dades personals reals en proves sense base de licitud i garanties: sintètiques o anonimitzades.