| Automatització de proves | Podem realitzar les proves sempre de forma manual, sense usar l’automatització, però això pot arribar a ser molt costós en el llarg termini, especialment si participa un equip gran. Automatitzant les proves, podem cobrir tasques repetitives, comunes i reduir l’equip de proves o fer per exemple que participin per trobar més defectes mitjançant proves negatives (provar com “trencar” l’aplicació, enlloc de reproduir el que s’espera). Avantatges i desavantatges de l’automatització Els avantatges de l’automatització versus l’execució de proves manual són principalment: Eficàcia. |
| BDD (Behaviour Driven Development) | Amb BDD, les proves d’acceptació es descriuen a través de les històries d’usuari, a les quals s’afegeixen criteris d’acceptació. La característica principal de BDD és la utilització d’un llenguatge de domini com el Gherkin, que permet unir la part de negoci amb el codi de la prova. Amb aquesta tècnica, partint dels criteris d’acceptació, es descriuen les proves que verifiquen el comportament del codi des del punt de vista de l’equip de negoci. |
| Característica de qualitat de la solució |
El model de qualitat estableix com avaluar la qualitat d’una solució en diferents característiques: funcionalitat, interoperabilitat, fiabilitat, eficiència, usabilitat, seguretat i portabilitat. Aquestes característiques són a la seva vegada classificades en subcaracterístiques. Les característiques de qualitat estan relacionades amb els tipus de prova que les verifiquen o mesuren. Durant la planificació de les proves es determina quines característiques es provaran i quines no, i amb quin grau de profunditat. També es pot valorar la percepció de cada característica amb un qüestionari d’avaluació dirigit als usuaris i/o responsables. |
| Característica de qualitat dels lliurables |
Una característica de qualitat dels lliurables d’una solució, és un element de classificació per poder avaluar-lo i mesurar-lo. Als Sistemes d’Informació de la Generalitat s’usa una classificació de la qualitat dels lliurables en: |
| Característica de qualitat dels lliurables/procés |
Una característica de qualitat dels lliurables d’una solució, és un element de classificació per poder avaluar-lo i mesurar-lo. Als Sistemes d’Informació de la Generalitat s’usa una classificació de la qualitat dels lliurables en: |
| Cas d'ús | Un cas d’ús representa com usarà un tipus d’usuari (actor) el sistema a desenvolupar per fer una tasca. En la seva versió inicial inclourà el títol i una descripció textual. A mesura que s’avanci en l’anàlisi s’incorporaran els fluxos bàsics, els alternatius, … |
| Cas de prova |
Un cas de prova és un conjunt de valors d’entrada, precondicions d’execució, resultats esperats i postcondicions d’execució, que està desenvolupat amb un objectiu en particular o condició de prova, com per exemple, comprovar un camí específic d’execució o verificar que es compleix un requisit específic. |
| Criteris de qualificació | Conjunt de condicions i criteris per determinar que una solució o servei compleix amb les seves especificacions i està preparat pel seu ús en l’entorn destí. |
| Defecte |
Un defecte és qualsevol desviació negativa del funcionament respecte a l’acceptable, esperat o habitual. |
| Definició del Fet (DoD) |
En un projecte àgil caldrà definir l’artefacte que descriu els criteris de qualitat dels lliurables. Aquest element és la Definició de Fet o Definition of Done (DoD). |
| Definició del Preparat (DoR) |
Per tal de disposar d’un mecanisme transparent i compartit per tots els membres en d’un equip àgil, cal establir els criteris d’acceptació dels requisits. Les metodologies àgils estableixen els criteris de Definició de Preparat o Definition of Ready com l’acord entre l’equip i el product owner per a poder donar una història d’usuari com a ben definida i completa. Aquest artefacte, l’utilitza l’equip durant la planificació de l’sprint, per tal d’assegurar que tot el que entra en una iteració compleix els mínims acordats. |
| Estat d'un defecte |
Un defecte pot passar per diferents estats des de que es crea, perquè algú l’ha detectat, fins que es tanca. Els estats definits al model són: |
| Estat d'una prova |
Una prova pot estar en diferents estats, que a continuació es descriuen: |
| Estàndard |
Un estàndard és un acord documentat que conté especificacions vàlides per a ser utilitzades consistentment com a regles, directrius o definicions de característiques que assegurin que certs productes, sistemes, processos o serveis són adequats als seus propòsits. |
| Gherkin | Gherkin és el llenguatge utilitzat en la pràctica del Desenvolupament Guiat pel Comportament o BDD (Behavior Driven Development) que permet definir proves funcionals amb llenguatge natural, però a l’hora directament automatitzable amb l’ús d’eines específiques, com Cucumber o Concordion, entre d’altres. |
| Història d'usuari | Representació d’un requisit en metodologies de desenvolupament àgil |
| Hores ideals | Les hores ideals són el temps necessari per completar una tasca assumint que no hi haura cap interrupció o problema no previst. Si per exemple una persona sap que al dia treballa realment 6 hores, perquè la resta està de reunions, rebent trucades, etc., les hores ideals són 6h (el temps efectiu que realment farà una tasca). |
| Joc de proves |
Un joc de proves és un conjunt de casos de prova relacionats. |
| Manteniment perfectiu | Tipus de manteniment per realitzar de forma proactiva modificacions en el programari per millorar la seva qualitat, seguretat, el seu rendiment i la seva mantenibilitat. Inclou, entre d’altres: Actualització de la documentació Millora de l’eficiència, per exemple amb la reorganització de la base de dades per a que les dades puguin ser consultades més ràpidament Reestructuració del codi o de les dades (per millorar la seva mantenibilitat) |
| NAQ (Nivell d'assegurament de la qualitat) |
El Nivell d’assegurament de la qualitat o NAQ és un mecanisme per valorar la importància d’un sistema d’informació i el seu risc, i poder establir quina ha de ser l’extensió i profunditat de les mesures de qualitat a aplicar. |
| NGP |
El Nivell de Gestió del Projecte (NGP) és l’indicador que adequa l’esforç de gestió a la realitat de l’encàrrec, tenint en compte el nivell de qualitat de la solució (NAQ (Nivell d’assegurament de la qualitat)), la dimensió del projecte i altres criteris que poden influir. |
| Nivell de proves |
Un nivell de prova és un grup d’activitats de prova organitzades i gestionades de forma conjunta |
| Pla de proves |
Document que descriu l’abast, enfoc, recursos i planificació de les activitats de prova per un projecte/solució |
| Procediment de prova | Un procediment de prova especifica la seqüència d’accions per l’execució d’una prova. També es coneix com guió de prova o guió de prova manual. [Segons IEEE 829] |
| Prova de confirmació | Una prova de confirmació té com objectiu verificar que s’ha corregit un defecte o incidència concreta d’un element. |
| Proves d'acceptació | Les proves d’acceptació són les proves realitzades per usuaris o el client per determinar si el sistema és acceptat o no. No haurien de trobar-se defectes si s’han realitzat correctament les proves de qualificació/sistema. Pot haver un equip de qualitat que assisteixi i doni suport als usuaris en la realització de les proves d’acceptació, que ajudin als usuaris en cas de trobar-se amb alguna dificultat, o bé ajudant a registrar els resultats de les proves i els defectes que es puguin trobar. |
| Proves de fum | Les proves de fum avaluen la qualitat mínima de la solució abans de ser transferides a l’usuari final o abans d’iniciar la realització de proves exhaustives de qualificació/sistema. El seu objectiu és comprovar que els aspectes bàsics de la solució funcionen correctament i no s’interromp la seva operació (el login funciona, funciona correctament la connexió amb la base de dades, s’envia el correu electrònic a l’usuari en una operació, es presenten correctament les imatges, …). |
| Proves de qualificació |
Proves realitzades pel proveïdor de desenvolupament/manteniment i monitoritzades pel client (i el CTTI) per comprovar que la solució/servei està preparada per ser usada en el seu entorn destí. |
| Proves de regressió | Una prova de regressió té com objectiu verificar que un conjunt de funcions segueixen funcionant correctament, tot i no haver-se modificat. És important que en cada versió d’una aplicació s’executi un conjunt de proves de regressió. |
| Proves de rendiment |
Les proves de rendiment són proves no funcionals que tenen com objectiu validar l’eficiència de l’aplicació en temps de resposta i throughput. Dins les proves de rendiment, podem trobar diferents subtipus, segons el seu objectiu. |
| Script de prova | Un script de prova és el mateix que un procediment de prova, però l’associarem sempre a un procediment de prova automàtic, definit amb una eina |
| Severitat (d'un defecte) |
La severitat d’un defecte és l’impacte que produeix o podria produir en l’usuari (en cas que es posi en producció i es donin les condicions). En el model s’estableixen els següents graus de severitat: |
| TDD (Test Driven Development) | TDD o desenvolupament dirigit per proves és una pràctica de programació que consisteix a escriure primer les proves, després escriure el codi font mínim de l’aplicació necessari per a que passi la prova, i finalment, refactoritzar el codi de l’aplicació escrit. Aquestes etapes formen un cicle que es repeteix fins a completar una unitat de codi sencera. |
| Temps de resposta (d'interacció) | El temps de resposta o temps de resposta d’interacció és el temps mesurat (en segons per defecte), des de que l’usuari ha efectuat una acció (prémer enllaç, prémer botó, …) fins que es rep tot el contingut, tant el percebut per l’usuari, com els recursos interns necessaris per la càrrega completa del contingut (informació textual, imatges, fitxers de recursos com css i scripts, …) …). |
| Temps de resposta de transacció |
El temps de resposta de transacció mesura el temps total des de que l’usuari inicia una transacció de negoci fins la seva finalització, en la que l’usuari passa per diferents pantalles o interaccions. |
| Temps de resposta mig percentil |
Habitualment, quan es mesuren temps de resposta hi ha valors anomenats ‘fora de límits’ que han estat casuístiques especials i que influeixen en el temps mig de resposta i per tant desvirtuar les dades. Per aquest motiu és recomanable mesurar els temps de resposta de cada interacció en el seu percentil 90. |
| Think time |
El think time o temps d’espera és l’interval de temps en què un usuari de l’aplicació està ocupat en fer tasques localment, al seu ordinador (llegint la informació de la pantalla, emplenant els camps del formulari) fins al moment en què llança una petició al servidor (prement el botó d’enviament, un enllaç, …). |
| Throughput | Mesura la capacitat del procés dels volums de transaccions objectiu per unitat de temps. S’usa de forma comú per definir el volum desitjat mínim de transaccions que una aplicació ha de ser capaç de gestionar en un temps determinat. S’usa en les proves de rendiment. |
| Tipus de prova |
Ens referim a tipus de prova per identificar quina característica de qualitat d’un element vol verificar la prova. Per exemple, un prova de rendiment és un tipus de prova que verifica l’eficiència. |
| Usuaris concurrents |
Nombre d’usuaris connectats durant un temps específic que realitzen alguna operació amb l’aplicació. |
| Èpica | Una èpica és un concepte usat en metodologies àgils per referir-se a un requeriment a molt alt nivell, que es pot dividir en una sèrie de grups de funcionalitats relacionades |