Avaluació del projecte

Procés de desenvolupament

És una mena de procés en què incorporem i verifiquem característiques diàriament, tot construint una base sòlida que ens permet assolir eventualment els requisits generals.

Quan es prepara un projecte s’elaboren una sèrie de requisits, és a dir, característiques que ha de complir una aplicació interactiva i que s’acorden amb el client o l’equip. Si aquests requisits estan ben formulats, és a dir, es redacten en forma de proposicions ben formades i no de manera vaga o genèrica, una vegada arribats al final del projecte, aquests es podran verificar, és a dir, es podrà fer un test que determini si el requisit s’ha assolit o no.

A una escala diferent, quan treballem en un projecte, també establim objectius diaris o setmanals que inclouen també requisits, i d’igual manera que hem de poder verificar que els requisits generals del projecte s’han assolit quan aquest acabi, també hem de poder verificar que els objectius/requisits diaris o setmanals efectivament s’han portat a terme.

Característica o 'feature'

Una característica o feature és quelcom que té valor per a l’usuari i que aquest desencadena mitjançant algun tipus d’acció, per exemple poder obtenir un mapa que li indiqui la gasolinera més propera.

En el cas del desenvolupament d’una aplicació interactiva, la regla més important que hem de mantenir és que l’única verificació completament vàlida és aquella que fem en el dispositiu final i en les mateixes circumstàncies que es trobarà l’usuari i que, si és possible, estigui feta per una persona diferent del desenvolupador. Qualsevol altra forma de verificació ens donarà un grau de seguretat més o menys gran, però mai complet.

La verificació es pot fer en l’àmbit individual, d’equip, o de forma sistemàtica i organitzada per professionals especialitzats en un procés anomenat verificació o testeig, i la mesura de la qualitat d’una aplicació interactiva està directament determinada per la duresa i l’exigència del procés de verificació i validació a què ha estat sotmesa. Entendre això marca la diferència entre un equip de desenvolupament amateur i un de professional.

El fet d’haver de verificar les característiques o requisits en el dispositiu final, junt amb les molt diverses circumstàncies que ens podem trobar a una aplicació interactiva fa que el procés de verificació o testeig sigui costós tant en termes de temps com de recursos humans i materials.

Proves internes

Al marge del procés de verificació, durant el desenvolupament d’un projecte es fan una sèrie de proves que, si bé no constitueixen un procés de verificació o testeig sistemàtic, sí que permeten que, en començar-lo, el projecte ja sigui relativament sòlid i funcional. Bàsicament, hi ha quatre tipus de proves: individual, sobre un component o sistema concret, d’equip i de projecte.

La prova individual és aquella que fem en l’àmbit personal, abans d’incorporar al projecte una nova característica en què hem estat treballant (vegeu la figura). En aquesta circumstància hem d’entendre que el fet d’haver completat les tasques necessàries per a implementar una característica no implica que aquesta funcioni realment, de manera que abans d’incorporar-la al projecte, per exemple incorporant-la al repositori, hem de fer una prova o test individual. Caldrà tenir en compte que:

  • Lògicament, aquest no pot ser un test complet, ja que durant el dia a dia del desenvolupament d’un projecte no disposem d’una quantitat suficient de temps, i possiblement no puguem tenir accés al dispositiu final, per exemple una tablet, de manera que hem de fer aquesta prova sobre un nombre limitat de casos i al dispositiu que tinguem més a mà, a l’ordinador amb què estem fent el desenvolupament o a un simulador.
  • En el cas que no sigui una característica el que estem incorporant sinó un contingut, per exemple un gràfic o un clip d’àudio que en principi no hauria de generar cap error, cal igualment fer una prova d’integració, és a dir, incorporar el recurs als arxius de l’aplicació interactiva i verificar, idealment al dispositiu final, que es veu o sona correctament.
Figura Prova individual

En el cas dels programadors, es poden fer proves sobre un component o sistema concret. Com a mínim, hauria de contenir una trucada a cadascun dels seus mètodes i, si és possible, algun tipus de prova automatitzada (vegeu la figura).

Figura Prova de component

La prova d’equip és necessària perquè un equip de desenvolupament pot estar format per moltes persones que incorporen característiques i continguts contínuament, i es pot donar la circumstància que una característica que funcionava bé en la prova individual falli perquè una altra persona ha incorporat una característica que hi interfereix d’alguna manera (vegeu la figura).

Figura Prova d’equip
  • Aquest problema es pot prevenir organitzant el desenvolupament en àrees i sistemes amb límits ben definits, de manera que tinguin el mínim grau d’interdependència entre ells. Aquest repartiment de responsabilitats en l’àmbit d’equip correspon als caps de producció i en l’àrea tècnica, a un programador amb coneixements d’arquitectura de software.
  • Per tal de detectar aquests possibles problemes, cal fer una prova col·lectiva de l’aplicació amb una certa periodicitat, per exemple setmanalment. D’aquesta manera s’assegura que les característiques i continguts incorporats pels membres de l’equip no tan sols funcionen correctament individualment sinó també quan treballen en conjunt. Com que aquesta prova es fa amb una freqüència molt menor, moltes vegades es pot fer sobre el dispositiu final i en aquestes circumstàncies té un grau molt alt de confiança.

Finalment, tenim la prova de projecte, ja que cada cert temps, amb motiu d’una fita important dintre de la planificació del projecte, per petició d’un client, o bé perquè s’apropa la data anunciada de publicació, pot caldre presentar l’aplicació. En aquestes circumstàncies, serà necessari que l’aplicació estigui moderada o completament lliure d’errors, de manera que cal fer un esforç específic per detectar i solucionar els detalls que poden quedar pendents. Dit d’una altra manera, és un moment en què està justificat fer un procés de verificació.

En termes de disseny de software, interdependència fa referència al mínim d’acoblament possible.

Exemple de prova de càrrega sobre un component

Donar una càrrega de treball molt alta a un sistema de l’aplicació o a un component, per exemple una aplicació que mostri un mapa, fent-li representar una quantitat molt alta d’icones per veure si així i tot el component continua funcionant. El raonament que hi ha darrere d’aquesta prova és que si el sistema o component suporta una càrrega de treball molt superior a la que haurà de suportar realment, podem tenir una confiança bastant gran que suportarà una càrrega de treball normal.

El procés de verificació (o 'testeig')

En desenvolupaments de projectes, és habitual utilitzar la terminologia anglesa test, testing i tester; en català hauríem de dir ‘verificar, verificació i verificador’, però potser serà més habitual trobar expressions com ‘testejar’, ‘testeig’ o ‘tester’.

El procés de verificació (o testeig) és la comprovació i validació, sistemàtica i controlada, que les característiques i/o requisits d’una aplicació s’han assolit i funcionen correctament (vegeu la figura).

Figura Prova de projecte amb procés de verificació o ‘testeig’

La dificultat més gran la trobarem a l’hora de validar que l’aplicació funciona correctament, ja que en el cas d’una aplicació interactiva, per verificar que una característica funciona correctament hauríem de comprovar-la en totes les circumstàncies possibles, cosa que sovint no podem fer donada la gran quantitat d’estats en què pot trobar-se un sistema informàtic i la gran diversitat d’accions que pot fer l’usuari en un moment donat.

Per aquest motiu, parlarem del concepte de comportament típic i posarem com a objectiu no assegurar una experiència lliure d’errors en tots els casos, sinó assegurar que amb un grau de confiança molt alta qualsevol usuari que faci un ús raonable de l’aplicació no trobarà cap error.

Com que és un procés col·lectiu que té una extensió en el temps i implica diferents persones, des del punt de vista de la producció caldrà definir rols, organitzar el treball en àrees i crear unes dinàmiques de treball que ens permetin assegurar que en finalitzar el procés haurem verificat totes les àrees i totes les característiques del projecte.

Per a aquest procés, podem ajudar-nos d’eines específiques per a la gestió del procés de verificació, en aquest cas bases de dades i llistes de bugs que ens ajudaran a mantenir organitzada la informació que anirem generant.

Els rols: el verificador, l'encarregat i el supervisor

En un procés de verificació es donen principalment tres rols diferents, el rol de verificador (tester), que detecta els bugs, el rol d’encarregat, és a dir, la persona que s’encarrega de solucionar el bug i el rol de supervisor, que valida que el procés es desenvolupa correctament i pot prendre decisions en casos especials que excedeixen les responsabilitats del tester i l’encarregat (vegeu la figura).

Figura Rols al procés de verificació

El 'bug'

El terme bug fa referència a que un dels primers errors detectats a un ordinador va ser causat per la presència d’un tipus d’insecte (en anglès, bug) entre els circuits de l’ordinador Mark II, el 1946.

El 'tester' o verificador

El tester o ‘verificador’ és la persona encarregada de detectar bugs, és a dir, funcionaments erronis a l’aplicació interactiva, bé perquè no es compleix algun requisit, bé perquè alguna característica o recurs no funciona o no es mostra correctament.

El fet que el tester hagi de verificar que els requisits i característiques es compleixen impliquen que ha de conèixer quins són aquests requisits. Per exemple, en el cas d’una aplicació que mostri diferents àrees d’un parc, el tester ha de conèixer quantes àrees haurien de visualitzar-se per poder detectar que en falta una.

D’altra banda, com que el concepte de “funcionar bé” o “veure’s bé” té un component subjectiu, el tester ha de tenir algun tipus de guia que li indiqui quins comportaments de l’aplicació són acceptables i quins no.

El verificador no hauria de verificar mai àrees i característiques del projecte a l’atzar, sinó concentrar-se en una àrea concreta o verificar una característica en particular cada vegada. Això implica la presència d’un pla de verificació que especifiqui en cada moment quin tester té assignada una àrea o una característica; garantint així que l’esforç de verificació s’aplica amb la intensitat apropiada a cada àrea o característica, i no en queda cap sense provar.

Temps de càrrega

Cada tester pot tenir una impressió diferent de si un procés de càrrega de recursos és o no massa llarg, però si definim a un document que el temps de càrrega no hauria de ser mai superior a, per exemple, deu segons, estem donant una mesura objectiva de quan un procés de càrrega és massa llarg.

Tant la comunicació dels requisits de l’aplicació o joc als testers, com proveir-los de les guies d’estil que han de seguir (a vegades, són les mateixes empreses propietàries d’una plataforma les que les elaboren), així com l’organització del pla de verificació, són responsabilitat del supervisor.

L'encarregat

L’encarregat és la persona encarregada d’arreglar un bug. En principi, ha de ser un membre de l’equip de desenvolupament amb els coneixements necessaris per arreglar-lo, tot i que pot succeir que un bug, al qual inicialment se li assigna a un membre de l’equip, acabi reassignat a un altre, ja sigui perquè aquesta persona considera que l’altre membre té uns coneixements més adequats, o bé perquè el bug s’ha categoritzat incorrectament, és a dir, s’ha estimat que era responsabilitat d’un departament o rol dins de l’equip de desenvolupament al qual no pertany.

Les responsabilitats de l’encarregat són quatre, en aquest ordre (vegeu la figura):

  1. Reproduir el bug, és a dir, ser capaç pels seus propis mitjans de provocar la situació d’error de la qual l’està informant el tester.
  2. Analitzar quines són les causes de l’error, és a dir, entendre perquè està succeint.
  3. Aplicar el canvi mínim que faci que l’error no es doni.
  4. Comprovar que l’error ja no es produeix.
Figura Resolució d’un bug

Una vegada aplicat el canvi, encara que pot tenir una certa seguretat en haver arreglat el bug, no és responsabilitat seva verificar-lo, ja que això sempre correspon a la persona que ho ha detectat; en aquest cas, el tester.

Una altra raó per la qual els canvis que fa l’encarregat sempre han de ser mínims, és perquè no provoquin més bugs; és a dir, no s’ha d’aprofitar que s’arregla un bug per introduir noves característiques a l’aplicació interactiva.

El supervisor

El supervisor és una persona amb un cert rang dins el projecte que supervisa l’activitat dels verificadors i els encarregats, i pot prendre accions en aquelles situacions que sobrepassin l’àmbit de responsabilitat d’aquests. Si es dona una d’aquestes situacions, ha de consultar els administradors del projecte i l’equip de desenvolupament per determinar l’acció que cal fer. Fora d’aquestes situacions, només ha d’observar.

Una responsabilitat del supervisor és conèixer bé els requeriments i estàndards de qualitat que ha de complir el projecte per tal de comunicar-los als testers, i també l’extensió del projecte i les àrees que comprèn, per tal d’elaborar un pla de verificació que els abasti completament.

Elaboració d'un pla de verificació

Una vegada arribats a un punt suficientment avançat del projecte, on ja tenim una certa seguretat que tant les característiques de l’aplicació interactiva com els continguts i nombre de pantalles que inclou no patiran grans alteracions, podem començar amb un procés de verificació sistemàtica que parteixi d’un pla de verificació (vegeu la figura). Abans d’aquest punt, l’equip de desenvolupament ha d’haver fet les corresponents proves internes, i també pot continuar amb elles en paral·lel mentre es duu a terme el pla.

Figura Pla de verificació

Trobareu una explicació sobre els tipus de requisits que es poden definir a un projecte al punt “El nivell de projecte”, de l’apartat “Planificació i realització del projectes” d’aquesta unitat.

Per fer aquest pla, haurem de fer una llista de les característiques, àrees i aspectes que volem verificar (vegeu la figura), així com establir els requisits de qualitat que han de complir. Aquests requisits han de ser formals i objectius, per tal d’eliminar qualsevol tipus d’ambigüitat a l’hora de definir si un comportament detectat és erroni o no. Finalment, haurem d’establir unes dates i assignar-les a diferents grups de verificadors per tal que puguin començar a treballar.

Figura Aspectes i àrees

Àrees, característiques i aspectes

En el curs de la seva activitat, l’usuari d’una aplicació interactiva passa per una sèrie d’àrees, és a dir zones diferenciades on pot romandre un cert temps i fer una sèrie d’accions (vegeu la figura). Una forma d’organitzar el pla de verificació és fer una llista d’aquestes àrees i assignar-les a verificadors diferents per tal que cap zona de l’aplicació interactiva quedi sense ser verificada.

Dintre d’una àrea l’usuari pot fer tota una sèrie d’accions, i és responsabilitat del tester provar-les totes, i també totes les combinacions d’accions, per exemple obrir el menú d’opcions abans i després d’examinar un objecte.

D’altra banda, les característiques són requisits que ha de complir l’aplicació, i és responsabilitat de la verificació comprovar que aquestes característiques no només estan presents sinó que funcionen en qualsevol circumstància.

Característiques d'una aplicació per a un museu

En el cas d’una aplicació que presenti els objectes d’un museu, aquestes podrien ser:

  • Escoltar una audiodescripció de cada objecte.
  • Poder canviar d’idioma en qualsevol moment.
  • Poder girar l’objecte.

Observem com la dificultat és assegurar que aquestes característiques funcionen en qualsevol circumstància. Per exemple, si tenim una característica de “canviar idioma en qualsevol moment”, això implicarà haver de comprovar-la a totes les pantalles, en tots els menús que pot fer servir l’usuari; i en combinació amb la resta d’accions que pot fer. Canviar d’idioma abans d’examinar un objecte, després de sortir del menú d’opcions i així successivament.

Quan parlem d’aspectes volem dir elements que són transversals al projecte, és a dir, que sempre hi són presents però que normalment l’usuari no observa de forma separada, cosa que sí que s’ha de fer durant el procés de verificació per assegurar que compleixen els requisits de qualitat. Podem pensar-hi com a diferents sistemes que funcionen a la vegada i resulten en l’aplicació interactiva. Exemples d’aquests aspectes poden ser:

  • Gràfics
  • Música, efectes de so i veu
  • Interacció
  • Textos/idiomes

Quan es verifica un aspecte concret de l’aplicació interactiva, el tester ha de fer com si la resta d’aspectes no existissin, per exemple, si està comprovant els efectes de so, tota la seva atenció ha d’estar enfocada a comprovar si s’inicien en el moment precís i amb un volum adequat, i a provar diferents combinacions per tal de verificar que tampoc no interfereixen entre si.

Exemple de combinacions d'elements

Els aspectes o característiques i les àrees es poden combinar, de manera que si hem de verificar, per exemple, l’aspecte gràfic, podem dividir aquesta tasca per àrees, i fer tests separats per exemple per cada pantalla de l’aplicació. Un altre avantatge de fer-ho així és que així els bugs que es trobin seran molt més fàcils de localitzar per l’equip de desenvolupament, ja que inclouran l’àrea on es produeixen.

Estratègies de verificació

Idealment, voldríem que després d’un procés de verificació una aplicació interactiva estigués lliure d’errors, però això en general és impossible, no només per la gran quantitat d’accions que pot fer l’usuari, sinó per la gran quantitat de combinacions d’accions i circumstàncies diferents en què poden fer aquestes accions.

Si fem els càlculs, veurem que cadascun d’aquests elements multiplica els casos que cal comprovar, de manera que molt ràpidament la xifra de possibilitats sobrepassa els recursos materials i humans de qualsevol equip.

Això fa que sigui necessari establir estratègies de verificació que ens permetin assegurar un funcionament correcte en un ampli ventall de casos amb uns recursos humans i materials limitats; les estratègies de verificació comprenen els següents tipus de test: exhaustiu, repetitiu o estocàstic, de límits, de saturació i d’accions imprevistes.

De fet, des de fa temps sabem que no és possible decidir de forma automàtica aspectes aparentment senzills, com per exemple saber si un programa informàtic, una vegada iniciat, s’aturarà en algun moment.

Test exhaustiu

Si el nombre de casos que hem de verificar és suficientment petit, podem plantejar un test que els inclogui tots. Sempre que puguem és la forma preferible de fer-ho.

Per plantejar un test exhaustiu hem de fer una llista d’elements com ara accions, circumstàncies i àrees que volem que inclogui, i fer l’expansió de totes les combinacions possibles d’aquests elements en forma de taula, incloent-hi un espai per indicar si el test l’hem fet o no (vegeu la figura).

Figura Test exhaustiu

Test repetitiu o estocàstic

Com hem dit moltes vegades, és impossible provar tots els casos possibles en què es pot trobar una aplicació interactiva, però podem obtenir una confiança estadística en què hem detectat una bona proporció d’errors si verifiquem repetidament una mateixa característica o aspecte, sempre que fem cada prova tan aleatòriament com sigui possible, és a dir, fent variacions a l’atzar.

Si procedim així, en cada test on no trobem cap error, la probabilitat que quedi algun error per detectar disminueix, ja que, assumint un comportament estadísticament normal del sistema, cada vegada és més improbable que si queda algun error aquest no s’hagi produït i, tot i que no podem assegurar que no existeixi, sí que podem dir amb una certa confiança que l’aplicació bé està lliure d’errors o, si en té, és molt improbable que es produeixin (vegeu la figura).

Figura Test repetitiu o estocàstic

Un problema que trobem aquí és que les persones no som bones per generar comportaments aleatoris i quasi sempre seguim algun patró més o menys conscientment. Això fa que perquè un test aleatori generi una bona confiança estadística, s’hagi de fer automàticament o bé el facin persones diferents per tal d’evitar que les proves sempre segueixin el mateix patró.

Test de límits

Aquest test és molt adequat quan tenim una magnitud contínua, és a dir, una propietat que pot tenir molts valors reals diferents o bé una magnitud discreta, és a dir, que es pot representar com un nombre sencer, però amb un rang molt ampli, o sigui, que el valor mínim i el màxim que pot tenir estan tan separats que no es pot plantejar un test cas per cas. Consisteix a fer una prova amb el valor mínim, una altra amb el valor màxim i un altre amb un valor mitjà o típic (vegeu la figura).

Figura Test de límits

L’assumpció que estem fent en aquest cas és que si l’aplicació interactiva funciona bé amb el valor mitjà i amb els valors mínims i màxims, també funcionarà correctament amb els valors intermedis, cosa que en general podem assumir que serà així. Dit d’una altra manera, normalment els errors als programes es produeixen quan alguna propietat pren els valors extrems, tot i que cal també comprovar el valor central, encara que sigui menys probable.

Exemple de test de límits: provar el volum de so de l'aplicació

Un exemple de test de límits seria provar el volum de so de l’aplicació. Si aquest pot anar de 0 a 100, normalment podem assumir que si provem amb volum 0, amb volum 100 i amb un valor intermedi i el so funciona correctament, no cal verificar els cent nivells de volum possibles.

Test de saturació

Aquest test consisteix a intentar saturar alguns dels sistemes o característiques del joc a força d’acumular instàncies d’un cert tipus d’element i comprovar si l’aplicació continua funcionant correctament.

En cert sentit el test de saturació és un test de límits, però quan aquests no són explícits sinó que corresponen a propietats de l’aplicació que no són accessibles directament, de manera que el tester ha de trobar una forma indirecta de portar-les al màxim.

Exemple de test de saturació

Per exemple, en un sistema de finestres que permeti obrir múltiples documents simultàniament, un tester podria començar a obrir tants documents com pugui, cercant el límit de capacitat del sistema.

Test d'accions imprevistes

Aquesta tècnica de verificació podríem dir que és fer el contrari del que faria un usuari normal de l’aplicació, i és molt característica d’un tester experimentat. Consisteix a fer accions que tot i que són possibles, en un ús normal de l’aplicació són molt improbables, per exemple obrir un menú i tancar-lo immediatament, o obrir el menú d’opcions just quan s’acaba de canviar l’idioma de l’aplicació.

Amb aquest tipus de tests s’està comprovant que els programadors gestionen correctament els esdeveniments i els canvis d’estat de l’aplicació i que no confien que l’usuari els donarà un marge de temps entre una acció i una altra, i que a més han tingut en compte tots els casos possibles.

Els 'bugs'

Com a resultat de l’activitat dels testers, es detectaran bugs, que són errors de l’aplicació o situacions en què el seu comportament no sigui l’esperat. Els bugs també poden provenir del fet que algun element de l’aplicació no compleixi amb els requisits de qualitat que s’hagin establert i en general de qualsevol aspecte que sobti el tester i que cregui necessari comunicar a l’equip de desenvolupament.

Cada vegada que es detecta un bug s’ha de fer un informe que especifiqui molt clarament on i en quines circumstàncies es produeix, sense suggerir cap tipus de solució, ja que això correspon a la persona que ho ha d’arreglar (vegeu la figura). Aquest informe pot incloure materials que puguin ajudar a caracteritzar-lo, per exemple captures de pantalles o vídeos i, en el cas de les aplicacions multidispositiu, quin és el model de dispositiu en què s’està fent la prova. Un altre element important és la versió de l’aplicació, per tal d’evitar situacions on un bug sembla que torna a produir-se però perquè el tester està fent servir una versió antiga de l’aplicació.

Figura Llista de ‘bugs’

Una vegada omplert d’informe d’un error, aquest es classifica i es prioritza segons la seva gravetat per tal que el pugui atendre l’equip de desenvolupament i s’integra a una llista o base de dades de bugs, compartida entre l’equip de desenvolupament i el de verificació.

La llista o base de bugs conté els reports de tots els que eventualment s’hagin detectat, classificats per àrees i categories, avaluats i prioritzats, per tal de poder atendre’ls en funció de la seva severitat.

S’engega en aquest moment un procés en què el bug pot passar per diversos estats i ser assignat a diferents persones i departaments fins que se soluciona, en el que es pot anomenar cicle de vida del bug. Aquest cicle de vida es pot veure com una mena de dinàmica en què el bug passa de l’equip de desenvolupament al de verificació, fins que o bé se soluciona o bé es pren alguna decisió per part dels administradors que el dona per tancat.

En funció de l’escala del projecte, aquesta llista pot incloure’s en un simple full de càlcul o base de dades o bé podem fer servir un sistema específic per gestió de bugs d’entre els que existeixen al mercat. El nombre de bugs que pugui incloure aquesta llista depèn de la duresa dels tests a què s’hagi sotmès l’aplicació, però per exemple en el cas d’un projecte petit, de tres a cinc persones i uns pocs mesos de durada, típicament pot arribar a uns pocs milers.

Dins de la llista de bugs, tindrem diferents propietats que recullen tota la informació associada a cada bug. Aquestes propietats poden variar segons el sistema que fem servir, però finalment proveeixen una informació semblant. Les més importants són: identificador, títol, descripció, àrea, categoria, reproductibilitat, passos per reproduir-lo, severitat, prioritat, estat, arxius adjunts, comentaris, versió de l’aplicació i dispositiu.

Identificador

L’identificador és un codi únic per a cada bug. Pot ser un número o una combinació de números i lletres però sempre ha d’identificar un únic bug. Una altra raó que justifica la necessitat d’identificar-los és que un mateix bug pot ser detectat diverses vegades, i és important poder distingir quin és l’original i quins els duplicats.

Importància de la identificació

Insistim en aquest punt perquè els bugs poden ser molt nombrosos i és molt fàcil que es perdi la referència si els identifiquem per la seva descripció, per exemple “problema amb el menú d’opcions”.

Títol

El títol és una frase curta que informa de l’efecte que s’està observant.

És molt important que sempre que parlem d’un bug en el context d’un procés de verificació ens hi referim per l’efecte observat; és a dir, els bugs sempre s’han de descriure des del punt de vista del que percep un usuari, no s’han de formular mai com una tasca, és a dir, com alguna cosa que cal fer, perquè fins que no es revisa el bug no se sap quina és la solució.

Exemple de com posar un títol correcte a un 'bug'

Per exemple, si detectem que a una aplicació interactiva per a un museu, de vegades volem girar un objecte arrossegant-lo amb el dit i no podem, encara que tinguem un cert coneixement del sistema d’entrada i sospitem que el problema pot ser que no està funcionant bé el codi que processa l’entrada tàctil, hem d’anotar “No es pot girar l’objecte” i no que “Cal revisar el codi que processa l’entrada tàctil”, ja que no tenim la seguretat que aquesta sigui la causa i, pitjor encara, si fem un canvi en aquest codi i cometem algun error, potser estarem introduint sense voler un nou bug i, a més, possiblement no solucionarem el bug anterior.

Descripció

La descripció ha de seguir sempre un mateix patró, on podem distingir diversos elements. Com el títol, no ha de contenir mai les nostres hipòtesis sobre la possible solució. Si tenim experiència en reportar bugs, podem fer servir només un camp de descripció a la base de bugs i incloure aquests elements com un petit text; si no, podem separar aquests elements en camps diferents per tal d’assegurar que no quedaran mai buits. Aquests elements són:

  • La circumstància, és a dir, en quin context (nivell o situació) es produeix el bug.
  • Les accions o passes que cal fer per reproduir el bug.
  • L’efecte observat.

Exemple de descripció d'un 'bug'

Un exemple de descripció d’un bug, amb tots els elements integrats, podria ser:


“En el menú principal, quan arrenquem l’aplicació per primer cop, si entrem al menú d’opcions i tornem a sortir al menú principal tres vegades i seleccionem l’opció de veure un objecte, aquest no es mostra”.

Les descripcions que fem dels diferents elements, han de ser clares i explícites; és a dir, hem d’evitar que la persona que ho llegeixi hagi de fer suposicions o interpretar el que escrivim, fins i tot si aquesta persona som nosaltres mateixos.

Àrea

La persona que arregla un bug normalment n’haurà d’arreglar molts més, així que hem de procurar que perdi la menor quantitat de temps possible en localitzar on s’està donant el problema. Per aquesta raó, hem d’incloure un camp àrea que permeti identificar ràpidament on s’està produint.

Una altra raó per introduir aquest camp és que d’aquesta manera la persona que arregla el bug pot aprofitar que està treballant en una àrea concreta per solucionar la resta de bugs que hi hagi en aquesta àrea, i així estalviar-se la feina que li pot suposar canviar de context.

D’altra banda, si dins d’un equip de desenvolupament cada persona ha treballat en àrees diferents, per exemple una persona s’ha encarregat del menú principal i una altra de la pantalla de presentació, classificar els bugs per àrees és una forma també de tenir una guia de com assignar-los.

Categoria

La categoria té a veure amb el sistema o departament al qual pertanyi el bug, per exemple “Programació” o “Gràfics”, i ens dona una primera indicació de com assignar-lo.

Com que inicialment només sabem què està passant però no quina és la solució, la classificació que posi un tester en aquest camp només serà una suposició, i serà la persona encarregada qui determinarà si el bug pertany realment a aquesta categoria i si s’hauria de canviar o reassignar.

També pot passar que un bug sigui complex i requereixi l’acció de diversos departaments o rols, fet que també provocarà que aquest es recategoritzi i es reassigni diverses vegades.

Exemple de 'bug' reclassificat

Per exemple, podem tenir un bug en què l’efecte observat sigui que una imatge no es mostri en una galeria. El tester pot classificar inicialment el bug amb categoria “Gràfics”, però quan el grafista l’examini pot determinar que el gràfic està present, de manera que la responsabilitat és del codi que gestiona la galeria i el bug s’ha de reclassificar amb la categoria “Programació”.

Reproductibilitat

La reproductibilitat és la facilitat que hi ha en reproduir un bug, és a dir, amb quina facilitat es pot provocar l’efecte negatiu observat.

Donada la naturalesa atzarosa d’alguns bugs, pot passar perfectament que, tot i situar-nos al punt concret on hauria de produir-se, i seguint escrupolosament les accions o passes que indica el tester, siguin necessàries moltes repeticions per tal d’observar l’efecte.

Els valors que pot prendre la reproductibilitat d’un bug són, doncs, una escala de dificultat, per exemple “fàcil”, “normal” i “difícil”. Típicament als bugs amb reproductibilitat més alta se’ls posa el sobrenom de Hard to repro.

Passos per reproduir-lo

Molt lligada a la reproductibilitat d’un bug, trobem els passos per reproduir-lo. Aquests són una llista ordenada d’accions que ha de fer l’usuari, en aquest cas l’encarregat, per poder observar l’efecte.

En cas que la reproductibilitat sigui molt fàcil, aquestes passes seran molt senzilles, i pràcticament només serà necessari fer l’acció indicada al lloc indicat o repetir-la pocs cops. En canvi, si un bug té una reproductibilitat més alta o és Hard to repro, normalment el tester haurà de treballar per elaborar aquesta llista de passes, ja que normalment és indicatiu que el procés que desencadena el bug és més complex del que inicialment s’havia considerat.

Exemple de llista de passes

Una llista de passes elaborada podria tenir aquest aspecte:

  1. Anar al menú de selecció d’objecte
  2. Girar el model del cotxe durant dos segons.
  3. Tornar al menú principal.
  4. Abans que el menú es mostri completament, prémer la tecla ‘ESC’
  5. L’aplicació es bloqueja.


Tot i que, inicialment, les passes podrien ser:

  1. Anar al menú de selecció d’objecte.
  2. Prémer la tecla ‘ESC’.
  3. L’aplicació es bloqueja.

Severitat

La severitat és una valoració de la importància d’un bug, és a dir, de si és més o menys greu des del punt de vista de l’experiència de l’usuari. Aquesta és una mesura subjectiva i correspon jutjar-la, en última instància, al supervisor o les persones que administrin l’empresa, però podem establir alguns criteris objectius.

Primer de tot, hi ha dos tipus de bugs que són els més greus de tots, els freezes i els crashes. Un freeze és una situació d’error que es dona quan l’aplicació interactiva es congela, de manera que a partir d’aquell moment no respon a cap acció de l’usuari, mentre que un crash és una finalització abrupta de l’aplicació, en què es tanca i retorna el control al sistema operatiu, normalment per un error de sistema.

Tant els crashes com els freezes són exemples de bugs bloquejadors, és a dir, que no deixen que l’usuari continuï fent servir l’aplicació interactiva, però no els únics, ja que un usuari pot anar a una pantalla i, per exemple, no tenir un botó per tornar a la pantalla anterior.

D’altra banda, tenim el concepte de ruta típica, és a dir, les accions o el recorregut que fa normalment un usuari de l’aplicació. En el cas d’una aplicació amb finestres, aquesta podria ser obrir un document, editar-lo, salvar els continguts i tancar l’aplicació, i en el cas d’una aplicació interactiva podria ser seleccionar un objecte, examinar-lo fent algunes rotacions, i escoltar l’audiodescripció.

Aquest camí pot estar dissenyat però també podem deixar llibertat als usuaris i observar el seu comportament, per exemple fent servir eines de tracking que registrin quines àrees visiten i quines accions fan.

En qualsevol cas, la ruta típica representa l’experiència de la majoria dels usuaris i per tant si un bug succeeix en algun punt d’aquesta ruta, serà molt més greu que si succeeix en una ruta secundària, és a dir un itinerari que per a l’aplicació és opcional.

El pitjor bug que podem tenir, és un de bloquejador a la ruta típica.

Deixant de una banda els bugs bloquejadors, la resta de bugs podríem dir que no impedeixen que l’usuari faci servir l’aplicació interactiva però sí que poden fer que la seva experiència d’ús sigui deficient, de manera que també hauríem d’adreçar-lo, tot i que això ja és una decisió particular de cada empresa.

Per a aquests bugs, podem fer servir un criteri de visibilitat, és a dir, un bug serà més greu com més noticiable sigui per a l’usuari. Per exemple en una aplicació narrativa serà més greu un bug que faci que la roba d’un personatge que ocupa una gran proporció de la pantalla canviï de color entre una vinyeta i una altra que ho faci petit arbre situat en el fons.

Un altre factor que podem considerar és la probabilitat que un usuari pateixi el bug, és a dir, com més improbable o difícil de reproduir sigui un bug, o més allunyat estigui de la ruta típica, podem considerar que la seva severitat també és menor. Així i tot, com que aquest valor ja el recollim a la reproductibilitat, és millor jutjar la severitat només per l’efecte per a l’usuari.

Una vegada definit el criteri amb què mesurarem la severitat hem de constituir una escala on en el punt més baix tindrem els bugs amb severitat “baixa” o minor, els bugs amb severitat “alta” o major i sovint també un valor especial per als bugs “bloquejadors” o block.

Prioritat

Els bugs no deixen de ser petites tasques pendents que també es poden prioritzar, és a dir, donar una indicació a l’equip de desenvolupament de quins són els que cal fixar com més aviat millor i els que poden esperar, encara que també puguin ser severs. Donar valor a aquest camp correspondrà normalment al supervisor i per valorar-lo haurà de tenir en compte aspectes com la reproductibilitat, la severitat del bug i si aquest està situat a la ruta típica o allunyada d’ella.

Els valors que podem donar a aquesta prioritat han de reflectir una escala creixent d’urgència, per exemple, “baixa”, “mitjana” i “alta”. Sovint també és útil tenir un valor de prioritat “màxima” o “crítica” per indicar que un bug s’ha de solucionar abans que tots els altres.

Estat

Trobareu exposats amb detall els possibles estats d’un bug al punt “Estats d’un bug”, d’aquest mateix apartat.

L’estat ens dona una indicació de la situació en què es troba un bug. Si un bug fos una tasca normal, aquest camp podria tenir valors com “pendent”, “en progrés” i “completat”, però els bugs tenen una dinàmica pròpia que fa que aquests estats siguin una mica més nombrosos.

En termes generals, però, podem dir que els estats d’un bug són diversos però es poden agrupar en “obert”, mentre el bug no s’hagi solucionat, i “tancat”, una vegada s’hagi solucionat.

Arxius adjunts

Els arxius adjunts són tots els documents que acompanyen l’informe del bug i que poden ajudar a localitzar-lo i reproduir-lo. Tenen força importància, especialment les captures de pantalla i els vídeos en el cas d’una aplicació interactiva, perquè permeten que l’encarregat observi exactament quines passes s’han donat sense cap tipus d’ambigüitat. És bona idea, doncs, gravar les sessions de verificació per poder produir després aquests clips.

Un altre detall important és incloure a la captura de pantalla o al vídeo el número de versió de l’aplicació, per tal que la persona encarregada sàpiga a quina versió es produïa.

Comentaris

Un bug pot tenir un camp de comentaris on es registrin els missatges que s’envien el tester i les persones encarregades que l’estiguin arreglant. Totes les conjectures que fem sobre l’origen del bug i que no s’han d’incloure mai a la descripció, sí que es poden incloure en aquest camp, ja que el que posem aquí s’interpreta que és una observació personal i no un fet comprovat. El comentari es deixa perquè la persona encarregada sàpiga a quina versió es produïa.

Versió de l'aplicació

És molt important incloure també, entre les propietats d’un bug, quin és el número de versió de l’aplicació en què s’ha detectat.

Exemple de 'bug' que no es pot reproduir

Pot passar que diferents bugs siguin causats per un problema comú, i un programador pot estar intentant arreglar un bug a la versió 2, però no pot reproduir-lo perquè el problema que el causava es va arreglar amb motiu d’un altre bug a la versió 1. En canvi, si veu que el bug que està intentant arreglar pertany a la versió 1, pot donar-lo per arreglat perquè sap que el problema ja no està present.

Dispositiu

De manera similar a la versió, i especialment important en el cas d’una aplicació multidispositiu, s’ha d’indicar també quin és el dispositiu en què es produeix el bug. Això és especialment important en bugs que tinguin una relació estreta amb el hardware, per exemple, un bug provocat perquè s’esgoti la memòria principal o un bug on un so en particular no funcioni perquè té un format que la targeta d’àudio no pot reproduir. Si no ho fem així, la persona que ho hagi d’arreglar no podrà reproduir mai el bug, ja que no comptarà amb el dispositiu apropiat.

Dinàmica de resolució d'un 'bug'

El procés de resolució d’un bug és una mica més complicat que el d’una tasca normal, i implica diferents rols com el de tester, encarregat i el supervisor. Consta d’una sèrie d’estats en què en cada moment la responsabilitat la té un rol concret, i ha de realitzar una sèrie d’accions abans que el bug passi a un altre estat. Això crea una dinàmica, especialment entre el tester i l’encarregat, que podríem assimilar a un joc en què el bug cada vegada està al terreny d’un de l’altre (vegeu la figura).

Figura Estats d’un ‘bug’

Aquest “joc” té un component psicològic força important, ja que el tester en el fons el que està indicant és que alguna cosa que ha fet l’equip de desenvolupament està malament. Això pot fer que l’encarregat es torni defensiu, li costi admetre que alguna cosa falla o directament negui que s’estigui produint un bug encara que el tester n’hi doni proves. Això fa que sigui extremadament important:

  1. Que l’encarregat i el tester siguin persones diferents.
  2. Que qui determini si un bug està resolt sigui sempre el tester que n’ha informat.

Estats d'un 'bug'

Durant el procés de resolució d’un bug, aquest passa per diferents estats o situacions; són els següents:

  • Obert. És l’estat inicial quan el tester introdueix el bug a la llista i vol dir que el que sigui que s’hagi detectat encara no s’ha solucionat. En aquesta situació algun membre de l’equip de desenvolupament s’assignarà com a encarregat del bug o serà el supervisor o el cap de l’equip de desenvolupament qui ho faci, segons la categoria i àrea d’aquest. Mentre un bug estigui a l’estat obert la responsabilitat és, doncs, de l’encarregat, i les passes que ha de fer són:
    1. Reproduir el bug.
    2. Trobar què l’està causant.
    3. Arreglar-lo.
    4. Comprovar que ja no succeeix.
  • Arreglat. “Arreglat” o fixed vol dir que la persona que té assignat el bug l’ha pogut reproduir, ha identificat una possible causa de l’error, ha aplicat els canvis necessaris i des de la seva perspectiva, afirma que està arreglat. En aquest punt el bug passa a ser responsabilitat del tester, que ha de verificar que efectivament el bug ja no es dona, independentment que ho afirmi la persona que ho ha arreglat.
  • Reobert. Si el tester determina que un bug que estava en estat “arreglat” o fixed no s’ha solucionat realment, és a dir, aconsegueix reproduir-lo a una nova versió de l’aplicació, li assignarà l’estat de reobert. Aquest estat té el mateix significat que l’estat obert, tot i que indica que el bug s’ha intentat solucionar. Cal dir que també pot passar que s’hagi solucionat parcialment, és a dir, que encara que continuï passant ara sigui més difícil de reproduir.
  • Tancat. Si el tester verifica que un bug en estat “arreglat” o fixed està solucionat, aquest passa a estat tancat i no cal que ni el tester ni l’encarregat facin cap acció addicional. El bug, però, roman a la llista per tal de no perdre’n la informació.
  • No puc reproduir. Podem dir que el curs típic d’un bug és “obert, arreglat i tancat”, possiblement amb cicles de “reobert arreglat” abans de “tancat”. Poden donar-se, però, altres situacions per les quals existeixen estats especials com “No puc reproduir” (Cannot Repro). Aquesta situació consisteix en que la persona encarregada d’un bug no pot reproduir-lo, és a dir, no pot observar l’efecte del qual s’ha informat, tot i posicionar-se al mateix punt dins l’aplicació i seguir les passes indicades pel tester. En aquesta situació i una vegada comprova que està fent servir la versió correcta de l’aplicació i un dispositiu on el bug s’hi hauria de produir, el bug ha de passar a estat de “No puc reproduir”. En aquest estat la responsabilitat passa a ser del tester, que ha de proveir passos addicionals que permetin determinar millor el procés que s’ha de seguir per reproduir el bug.
  • Nova informació. Quan el tester aporta informació addicional que permeti caracteritzar millor el bug, és a dir, informació que faciliti localitzar-lo i reproduir-lo, com per exemple, passes addicionals, posa el bug en estat “Nova informació” (New Info). En aquesta situació el bug torna a estar en una situació equivalent a l’estat “obert”, i passa a ser responsabilitat de la persona assignada per solucionar-lo, que ha de revisar la informació addicional aportada i tractar de reproduir altra vegada el bug.
  • “No un bug. Aquesta és una situació que pot generar conflicte en el costat del tester, ja que el desenvolupador li està comunicant que el que s’està informant no és un bug (‘Not A Bug’), sinó una característica de l’aplicació interactiva. En aquest punt, és molt important que el tester tingui una informació actualitzada dels requisits i normes de qualitat de l’aplicació per tal que se li pugui indicar quina és la característica que està confonent amb un bug. En cas de conflicte entre ambdues parts, correspon al supervisor donar el bug per tancat.

Exemple de 'Not A Bug' amb l'ús de les barres de desplaçament

Un exemple d’aquesta situació seria una aplicació d’un museu on es permeti que l’usuari examini textos fent servir unes barres de desplaçament, però si algun text és molt curt, aquestes barres no es mostren. Un tester podria pensar que en alguns dels textos curts aquestes barres haurien de sortir i informar-ne com a bug. En aquesta situació la persona encarregada canviarà l’estat del bug a “No un bug” (Not A Bug) tot indicant al tester la secció del document de disseny on es parla d’aquesta característica.

  • No s’arreglarà. Aquesta situació és diferent d’un “No un bug”, en el sentit que la persona encarregada reconeix que el comportament és un bug, però indica que aquest no s’arreglarà canviant l’estat a “No s’arreglarà” o Will Not Fix. Lògicament cal alguna raó especial per prendre aquesta decisió i normalment la responsabilitat d’aquesta situació recau en el supervisor. Tot i que cada situació és diferent, en general podem dir que en aquests casos s’aplica un criteri de practicitat, és a dir, es valora si donat el punt del desenvolupament en què s’està, solucionar aquest bug pot causar més problemes que avantatges.

Exemple d'absència d'un element a una aplicació

Per exemple, podem trobar un bug que diu, correctament, que falta un quadre a una aplicació que permet fer una visita virtual d’un museu, però si en aquell punt hem fet totes les proves necessàries per assegurar que l’aplicació funciona correctament a tots els dispositius sense esgotar la memòria i no tenim temps per repetir les proves, podem decidir que és massa arriscat incloure aquesta nova imatge, ja que augmentarà la quantitat de memòria requerida i pot provocar errors greus en alguns dispositius. En aquesta situació estarà justificat respondre al tester amb l’estat “No s’arreglarà” o Will Not Fix.

  • Duplicat. Aquesta situació es dona quan la persona assignada considera que el bug del qual s’està informant ja s’havia detectat abans. En aquestes circumstàncies, a més de posar el bug en l’estat “duplicat”, el desenvolupador ha d’indicar l’identificador del bug original. El tester hi pot estar d’acord o no, i en cas de conflicte serà el supervisor el que determinarà si el bug és un duplicat o no. A vegades la causa d’un bug duplicat pot ser que efectivament s’hagi detectat dues vegades el mateix problema, però també pot passar que l’encarregat jutgi que dos bugs tenen una causa comuna quan no la tenen. Per aquesta raó, si el tester no està convençut, ho farà saber a l’encarregat i, en cas de conflicte, es requerirà l’arbitratge del supervisor.

Suport al procés de verificació

El procés de verificació és molt costós en termes de temps i recursos, ja que requereix moltes hores de treball per part dels testers i, a més, disposar d’uns recursos materials i de software adequats. Hi ha una sèrie de mesures que es poden prendre, des del punt de vista de l’empresa o l’equip de desenvolupament, per tal de facilitar aquesta tasca; ens referim a: les proves internes, els modes de depuració o debug, les trampes, les dreceres, els tests automàtics, els informes d’error greu i els sistemes de gestió de bugs.

Proves internes

El procés de verificació no pot completar-se en un temps raonable si la quantitat de bugs és excessiva, ja que, tot i que la verificació té un paper de xarxa que assegura que qualsevol error present a l’aplicació interactiva amb temps suficient s’acabarà detectant, això no pot substituir que l’equip hagi incorporat les diferents característiques a l’aplicació amb una mínima seguretat que no contenen errors greus.

Dit d’una altra manera, no podem confiar que la verificació solucionarà tots els errors i treballar d’una forma descuidada, perquè llavors ens trobarem amb una quantitat de feina inabastable al final del projecte.

Modes de depuració o 'debug'

Des del departament de programació es pot facilitar la tasca de verificació tot incloent en l’aplicació interactiva un o més modes de depuració. Aquests modes serveixen per poder visualitzar informació addicional a l’aplicació que ens permeti identificar més de pressa quin element està causant un problema.

La seva importància no és tant des del punt de vista dels testers, ja que aquests no haurien de fer servir el mode de depuració, sinó que faciliten molt la tasca dels encarregats, ja que poden reproduir el bug i, amb aquesta informació addicional, formular millors hipòtesis del que pot estar passant.

Trampes

Una altra eina que accelera el procés de verificació són les “trampes” (cheats). Les trampes són combinacions de tecles o accions complicades que donen accés a característiques ocultes per a l’usuari i que permeten saltar-se les normes de l’aplicació interactiva.

Les trampes no són tan útils des del punt de vista dels testers com des del punt de vista dels encarregats, ja que permeten accedir més ràpidament a aquella àrea de l’aplicació on es produeix l’error. Per exemple, en una aplicació on hem d’escoltar una narració que dura molts minuts, podríem tenir una trampa que ens permeti saltar-la de manera que puguem arribar abans a la pantalla següent.

Dreceres

Les dreceres són potser l’única eina que té sentit que posem a disposició dels testers, ja que els permet saltar directament a una pantalla d’una aplicació interactiva, sense haver de passar per les anteriors.

Hem de dir, però, que en el moment en què es fa servir una drecera, automàticament està invalidant el test, ja que s’està fent la prova en un estat alterat de l’aplicació. Així i tot, si des de l’equip de desenvolupament podem tenir una seguretat molt forta que la part de l’aplicació que està ometent no té influència o té una influència limitada a la part que s’està verificant, podem incloure la drecera per tal que els testers puguin dedicar més temps a provar àrees que, d’altra manera, no podrien verificar a fons.

Així i tot, hem de ser conscients que l’única prova completament vàlida és aquella que fem des del començament, sense cap mena d’ajuda addicional.

Tests automàtics

Des de l’equip de desenvolupament també podem proveir de tests automàtics que permetin verificar una gran quantitat de casos, encara que no excloguin que també s’hagi de fer una verificació o testeig manual en la mesura que es pugui. Per exemple, en una aplicació on hi hagi diàlegs de veu amb subtítols, podem fer un test que verifiqui que totes les frases se subtitulen correctament mostrant-les una darrere l’altra en seqüència.

Aquests tests també poden ser estocàstics, per exemple, podem fer un test que generi milions de clics aleatoris a la pantalla per tal de comprovar que la interfície d’una aplicació interactiva no es bloqueja en cap cas.

Informes d'error greu

Trobareu més informació sobre els bugs greus al punt “Severitat”, d’aquest mateix apartat.

A vegades, podem trobar bugs que facin que l’aplicació finalitzi abruptament, per exemple perquè hagi esgotat la memòria principal disponible o hagi intentat fer un accés il·legal a una zona de memòria.

En aquests casos, normalment el sistema operatiu envia un avís a l’aplicació abans de tancar-la, de manera que si preparem un codi que guardi ràpidament a un fitxer algunes variables clau de l’aplicació, el tester podrà adjuntar-lo amb l’informe del bug i serà més fàcil fer-nos una idea de què pot haver passat. Aquests fitxers s’anomenen informes d’error greu (crash reports) i moltes vegades els genera el mateix sistema operatiu.

Sistemes de gestió de 'bugs'

La gestió dels bugs pot ser complicada perquè d’una banda són molt nombrosos i, de l’altra, cadascun d’ells passa per una sèrie d’estats que només uns usuaris amb uns rols concrets poden manipular. Això fa que fer aquesta gestió amb eines no específiques com un full de càlcul o una base de dades convencional sigui propens a fer que es produeixin malentesos entre l’equip de desenvolupament i els testers. Per adreçar això hi ha eines específiques que permeten gestionar aquesta informació.

Com que els bugs tenen unes característiques particulars, aquestes eines són diferents de les eines estàndard de gestió de tasques o es presenten com un mòdul diferent dins d’aquestes. Els seus serveis inclouen:

  • Registrar els diferents perfils i usuaris.
  • Definir les àrees i categories que distingim a l’aplicació.
  • Gestionar fitxers adjunts i comentaris als informes de bugs.
  • Generar avisos per correu electrònic o algun altre mitjà quan un bug canvia d’estat.

Aquests sistemes també permeten generar estadístiques i gràfics que ens serveixen per visualitzar quants bugs hi ha a la base de dades, de quin tipus són i com evoluciona la proporció de bugs que hem fixat.

Tancament del projecte

La verificació (o testeig) és un procediment que es porta a terme durant tota la vida d’un projecte, i és la part final de qualsevol cicle de desenvolupament iteratiu, al final del qual es produeix una nova versió.

Aquest procés de verificació inicialment no ha de ser gaire intens per tal de no bloquejar el desenvolupament de les característiques del projecte, però amb el temps i les successives versions ha de ser cada vegada més sever, fins a arribar a les últimes fases del projecte, on el procés de verificació ha de ser exhaustiu.

D’aquesta manera, en les fases finals el focus d’activitat ha de consistir només en verificar i corregir errors, primer poblant la base de bugs amb els resultats dels tests i després treballant per corregir-los, de manera que a cada cicle de verificació i correcció es redueixi progressivament el nombre de bugs pendents, fins a arribar a un punt on en quedin pocs o no siguin gaire greus, moment en què parlarem de la versió “Candidata a Publicació” o Release Candidate i es començarà a plantejar la publicació (vegeu la figura, part esquerra i mitjana).

Figura Evolució de la base de dades de ‘bugs’ i tancament del projecte

La publicació s’aprovarà quan tots els bugs estiguin corregits o les persones responsables i administradors de l’empresa considerin que els bugs pendents no són greus, moment en què es declara la versió “publicable”, Release o Gold i el desenvolupament del projecte es donarà per finalitzat o tancat.

El criteri mínim que hauríem de complir per publicar una aplicació interactiva és que sigui possible per a un usuari o jugador recórrer la ruta típica sense trobar bugs bloquejadors o errors greus.

Trobareu la definició de “ruta típica” al punt “Severitat” d’aquest mateix apartat.

Hi ha alguns factors que afavoreixen el tancament d’un projecte interactiu, en un temps raonable; parlem de la modularitat, la congelació de característiques i els continguts completats.

Modularitat

La modularitat és un aspecte principalment de programació, o més pròpiament d’enginyeria de software, però que té una influència molt forta en el procés de resolució de bugs, ja que si no s’ha tingut en compte pot fer que sigui molt difícil o directament impossible corregir tots els bugs d’un projecte.

Vol dir que l’aplicació interactiva ha d’estar composta per blocs independents amb responsabilitats ben definides i connectats entre si per interfícies que impedeixin que un mòdul accedeixi directament a les variables d’un altre (vegeu la figura).

Figura Modularitat

Si ho fem així, d’una banda podrem localitzar més fàcilment els bugs, ja que només haurem d’activar i desactivar blocs fins a trobar aquell que estigui donant problemes, i també tindrem la garantia que si el comportament que no funciona és responsabilitat d’un mòdul concret, la causa del bug estarà en aquell mòdul.

Aquest no és, però, l’aspecte més important, sinó també que quan corregim un bug el corregim en un punt concret d’un mòdul sense afectar la resta, de manera que tenim la garantia que a l’arreglar un bug no n’estem introduint un altre.

Tot connectat amb tot

Potser és més fàcil d’entendre si ho plantegem a la inversa, és a dir, què passa si tots els mòduls estan connectats entre si i accedeixen directament a totes les variables de la resta de mòduls? Que tot queda connectat amb tot, i un petit canvi a un variable de la interfície pot provocar que un procediment de so, que en principi no té res a veure, ja que és una àrea completament diferent, comenci a fallar. En aquestes circumstàncies qualsevol canvi que fem per arreglar un bug, pot provocar indirectament una pila de nous bugs, de manera que pot arribar a ser impossible reduir la mida de la base de bugs i que sigui una versió publicable.

Congelació de característiques i continguts completats

Dintre del procés de desenvolupament, cada característica o contingut de l’aplicació interactiva pateix una evolució en les successives etapes del desenvolupament, i forçosament les primeres versions d’una característica en concret, per exemple un menú d’opcions, contenen molts bugs. A més, cada vegada que introduïm una modificació a la característica, introduïm bugs addicionals.

Això fa que es necessitin un nombre mínim de versions perquè una característica es desenvolupi completament i a més, en algun punt, deixar d’introduir modificacions per tal de poder tancar-la, és a dir, concentrar-nos només en corregir els bugs que presenti.

Això, que és cert per a una característica aïllada, també ho és per a un projecte; de manera que en les últimes fases d’un projecte, i per tal de poder tancar-lo correctament, s’han de definir dues fites, relacionades amb les característiques i els continguts respectivament anomenades:

  • “Congelació de característiques” o Feature Freeze.
  • “Continguts completats” o Content Complete.

La primera marca el punt a partir del qual no s’han d’incorporar noves característiques al projecte, per exemple, un mode de control amb pantalla tàctil i, la segona, el punt on ja no afegirem més contingut, per exemple més recursos gràfics o sons.

Anar a la pàgina anterior:
Exercicis d'autoavaluació
Anar a la pàgina següent:
Activitats