Jordi Bartolomé 01-09-2007
Pag 2/3
Per tant, com en totes les tasques, s'ha d'analitzar quant d'aptes son les persones escollides per a dissenyar i realitzar les proves, i inclús, valorar si pagar més per un tester amb un determinat perfil pot acabar suposant un estalvi de diners, ja que, com es comentava al inici, sovint el cost de solucionar els errors augmenta de forma proporcional al temps que triguen en detectar-se. Els errors trobats a temps per un bon tester poden suposar un estalvi de diners important a mig - llarg plaç.Alguns dels punts a tenir en compte a l’hora d’escollir el perfil d’un tester son:
1-Coneixements: s’ha de valorar quins son els coneixements que ha de tenir la persona que ha de fer les proves. És obvi que si es vol fer un test d'integració de varies DLLs o llibreries software, es cercarà a una persona amb coneixements avançats de programació. En cas de voler testejar la vulnerabilitat d'un sistema de banca electrònica serà necessari trobar algú amb molta experiència en hacking o seguretat informàtica. D'altra banda, si es vol fer un test d'usabilitat d'una rentadora de roba, serà més productiu cercar persones amb experiència en tasques de la llar. Per tant, el perfil de l’encarregat del test i dels testers s’ha d’adequar al tipus de proves i a la complexitat del producte. Un punt que mai està de més, és que aquest tingui coneixements de qualitat del software. |
|
2-Actitud: en el test, l’actitud és un tema força important i és recomanable que les persones encarregades de dur-lo a terme siguin persones pacients, a l’hora una mica inquietes i amb certa motivació per trobar els errors ocults. Tal com es diu al inici del document els millors resultats del test s’obtenen quan el tester pren un “rol destructiu”, per això aquest ha d’estar motivat en demostrar que el producte presenta errors. Es podria entendre al tester com un hacker que pretén trobar vulnerabilitats en el producte. |
|
|
|
- Experiencia: com en tot, l’experiència és un punt important, i en el test, on la intuïció te molt a dir, encara ho és més. L’experiència en el test farà mes fàcil identificar els possibles errors o punts febles del producte, així com també, de crear l’entorn propici per que es manifestin. Precisament és aquest últim un dels més difícils del test: aconseguir reproduir els errors. Tenir localitzat un error i poder-lo reproduir redueix exponencialment el temps necessari per solventar-lo. |
Òbviament les empreses tenen recursos limitats i normalment no poden disposar d’una o varies persones per cada tipus de prova. És aquí on entra l’habilitat del cap de projecte o encarregat del test a l’hora d’escollir als implicats en el test en funció dels recursos disponibles a l’empresa.
En cas de que es treballi sobre equips amb els que el tester es pugui lesionar accidentalment, o en els que un error de manipulació pugui tenir conseqüències crítiques, serà important avisar al tester i indicar al Test Plan les mesures de seguretat que ha de prendre per evitar-ho.Si els resultats es guarden directament en el mateix document de test, aquest ha de facilitar l’enregistrament d’altra informació complementaria com és la versió del software o firmware, data del test, nom del tester etc. No obstant, per l’enregistrament dels errors es recomana la utilització d’alguna de les moltes eines de gestió d’errors que existeixen ( p.ex Bugzilla ).Atenent al vist fins aquest punt, es proposa estructurar el test plan de la següent forma:
1-Introducció i objectius del test: ha de servir d’introducció per situar al tester en el context del test. En aquest punt es pot fer èmfasi en els punts crítics i aspectes generals als que s’ha de prendre mes atenció. |
||||||||||||||||||||||||
2-Material i condicions necessàries pel test: en aquest apartat s’han d’especificar els recursos que el tester necessitarà per fer les diferents proves com també les condicions o context en que aquestes han de tenir lloc. També s’ha d’indicar quina documentació extra serà necessària pel test. |
||||||||||||||||||||||||
3-Casos de test: els casos de test s’han d’agrupar segons objectius, funcionalitats etc. A part de per ordenar el document, això permet distribuir la feina entre diferents testers en funció de les seves habilitats o perfil. A continuació es mostren un parell d’exemples de casos de test: |
||||||||||||||||||||||||
|
||||||||||||||||||||||||
4-Observacions: en cas de que els resultats es guardin en el mateix document pot ser interessant disposar d’un camp d’observacions on el tester pugui expressar altres aspectes que cregui importants que tot i no considerar-se específicament en el test plan sigui interessants conèixer. Obviament, aquesta es un només una proposta i no té perquè ser la millor, per lo que es pot modificar segons es cregui convenient. |
Tal com s’ha esmentat l’error més freqüent al planificar tests es no preveure la aparició d’errors, i això es tradueix en planificacions que s’acaben quedant curtes. Les planificacions s’han de fer tenint en compte el següents punts:
1-Objectius: s’han de deixar clar els objectius de cada test plan. |
2-Criteri de finalització: s’ha d’establir un criteri que permeti donar per acabat un pla de test. |
3-Agenda: intentar fixar unes dates realistes per les diferents subtasques, procurant que en el moment de començar el test, estiguin disponibles els recursos necessaris, com el test plan, els mòduls o aplicacions a ser provats etc. evitant aixi retrassos des de el bon principi. |
4-Eines i recursos: establir quines eines seran necessaries per desenvolupar el test, planificant també el temps pel seu desenvolupament en cas de que aquestes s’hagin de fer. |
5-Temps de les eines: en cas de que s’hagin d’usar eines especifiques per fer el test i aquestes s’hagin de reservar, és important establir quant de temps seràn encessaries. |
6-Responsabilitat: s’ha d’establir un responsable per cada una de les tasques relacionades amb el test: escriure el test plan, executar el casos de test, reparar els errors trobats. Això n’assegura la correcta execució i en cas contrari la responsabilitat. |
7-Procés d’integració: s’ha de planificar com s’uniran les peces que composen el software ( top-down, bottom-up), i per tant quin ordre es seguirà en les proves d’integració. Això te implicació directa en les eines i recursos necessaris per fer el test, sobre tot si prèviament s’han de desenvolupar mòduls drivers, o mòduls stub. |
8-Tasques de seguiment: és important tenir en compte que periòdicament s’han de realitzar tasques de seguiment per tal de supervisar l’evolució del test, intentant localitzar les parts que han presentat més errors de lo normal, verificar si s’han complert ja els criteris de completitud, o si és necessari reajustar les planificacions. Lògicament el test es fa per tal de trobar els errors, i si se n’han trobat s’hauran de solucionar. És el responsable del projecte qui ha de prendre al decisió d’entregar un producte amb els errors solucionats o no, analitzant-ne el cost i les repercussions que poden tenir. Mai considerant que els errors trobats no es reproduiran fora de les proves, donat a que com diu una de les lleis de Murphy “Si existeix la possibilitat de que algo falli, fallarà” |
9-Mecanismes de correcció: s’ha de fixar també com s’actuarà quan es detectin errors: es corregiran de forma paral•lela al test, s’actualitzarà el programa testejat un cop corregits, es corregiran tots junts al final del test... |
10-Tests de regressió: establir amb quina freqüència o en quines condicions s’hauran de realitzar tests de regressió, un cop s’hagin corregit errors. |
A continuació es dona un checklist del material que es sol utilitzar durant les fases de test, amb la intenció d’ajudar en la seva planificació. Conèixer la disponibilitat d’aquest material, permetrà avançar o retrassar les diferents proves, i així ajustar millor les dates:
1-Software o equip a provar: òbviament s’ha d’assegurar que en el moment de començar les proves es disposarà del firmware o del software a provar. Per evitar confusions, és important tenir controlat en tot moment la versió del codi o compilació sobre la que s’està treballant. |
2-Material complementari: sovint el firmware o software a provar requereix de material complementari per a funcionar. P.ex en el cas de voler testejar un software de comunicacions telefòniques, a part de l’ordinador, probablement també necessitarem el mòdem, cables de connexió, drivers etc. |
3-Material de seguretat: en cas de provar-se un firmware o software amb els que el tester pugui lesionar-se o en el que un bug o error de manipulació pugui tenir conseqüències crítiques, s’haurà de garantitzar que durant el test estiguin disponibles totes les eines o mesures de seguretat necessàries. |
4-Manuals d’utilització: és molt probable que el tester no sàpiga utilitzar algun dels elements o equips referenciats en el test plan, i per això mai està de més que aquest tingui a l’abast els manuals o guies ràpides d’aquests. |
| 5-Test plan: com s’ha esmentat al inci d’aquest document, és la eina bàsica del test i aquest haurà de ser disponible en el moment de començar les proves |
6- Software de control d’errors: els errors detectats durant les proves s’han d’anar enregistrant al corresponent sistema de gestió d’errors ( p.ex Bugzilla ) per tal poder portar el control d’aquests. Aquest software també haurà d’estar disponible i correctament configurat en el moment d’iniciar-se les proves. |
7-Eines de test : en algunes ocasions les proves es realitzen mitjançant workbenchs o programes que operen de forma automàtica sobre el firmware o software. En cas d’usar-se aquest tipus de programa també hauran d’estar disponibles i correctament configurats en el moment de començar. |
Un dels punts més compromesos pel responsable d’un test és el moment en que es planteja si val la pena continuar el test o si al contrari lo millor és donar-lo per finalitzat ( tot i desconèixer la quantitat d’errors que resten per trobar ) .Sovint el dilema es soluciona amb criteris econòmics: “ no hi ha més diners per continuar” o “acabem, per que el producte s’ha de vendre ja”. Existeixen criteris més correctes i útils per a aquest propòsit, tot i que freqüentment els testos finalitzen en les següents circumstancies:
1-S’acaben quan el temps programat s’esgota. Aquest criteri és inútil ja que tot i haver consumit el temps programat, aquest potser ha estat insuficient, o pot haver estat suficient però el procés de test haver sigut de baixa qualitat. |
2-Quan s’han executat tot els casos de test sense haver detectat errors. Aquest també pot ser inútil, ja que potser no s’han detectat errors perquè el test plan és incorrecte o inadequat. |
A continuació s’exposen alguns criteris més encertats. Una primera aproximació sería tenir en compte els criteris de la metodologia de test utilitzada, de tal forma que el test finalitzaria quan s’haguessin complert tots els casos establerts per la metodologia utilitzada, sempre i quan la metodologia permeti establir un nombre de casos màxim. P.ex un test es podria donar per acabat, quan s’usessin tècniques de caixa blanca basades en el criteri de les condicions i aquestes s’haguessin analitzat totes. De forma similar al cas anterior no hi ha una forma de garantir que una metodologia ha estat utilitzada de forma correcta.
Un segon mètode més correcte és donar per complert un test quan s’hagi trobat un determinat nombre d’errors que haurà d’haver estat definit abans de començar. Això presenta algunes dificultats:
| - Com podem estimar el nombre d’errors que hi ha a un programa ? |
| - Com podem estimar el percentatge d’aquests errors que es podran arribar a trobar ? |
| - I més difícil encara, quins errors originats en fases concretes del disseny seran localitzades a fases concertes del test ? |
La millor forma de predir els errors és basant-se en l’experiència adquirida en projectes anteriors. Una altra és fer un assaig previ sobre el programa per tal d’establir un ratio de nombre d’errors per mòdul, o millor per línees de codi. No obstant és pot partir d’un estàndard de 4 a 8 errors per 100 línees de codi i ajustar-lo a mesura que avança el projecte. Abans de començar el test també es pot assumir que el 40% dels errors presents a l’aplicació seran deguts a errors lògics i de programació i el 60% restant a errors de disseny. Els errors lògics i de programació es troben en les següents proporcions: el 65% en test de mòduls, el 30% en el test funcional i el 3% en els tests de sistema. Els errors de disseny es troben en les següents proporcions: el 0% en la fase de test de mòduls, el 60% en el test funcional i el 35% en el test de sistema. Es pot veure que els percentatges no donen el 100% degut a que s’assumeix que hi ha un percentatge d’errors que mai s’arriben a trobar.
Si en el temps estimat pel test no s’ha trobat el nombre d’errors previstos cal avaluar si això a estat degut a que realment el producte tenia menys errors de lo normal, si les previsions sobre el nombre d’errors eren excessives, o si en canvi els mecanismes de test utilitzats eren inadecuats o incorrectes.
La tercera forma de saber si el test es pot donar per complert o no, és senzilla, però implica un alt grau d’experiència i intuició. Consisteix en dibuixar en una gràfica el nombre de errors trobats per unitat de temps durant l’evolució d’aquest. Examinant el perfil de la gràfica es pot intentar determinar si es pot donar una fase per acabada o si al contrari és convenient continuar.
 |
Algunes dificultats d’aquest mètode son encertar la trajectòria que seguirà la gràfica, avaluar correctament el temps ivertit en el test ( sovint els testers fan altres tasques ) etc.
 |
Com es pot veure, el punt clau a l’hora de decidir si continuar el test o no, és la dificil tasca de valorar el cost de continuar fent el test i valorar les repercussions que pot tenir no continuar-lo. Després s’ha d’avaluar si val la pena seguir o no. Les estratègies descrites pretenen ajudar a valorar el nombre d'errors que resten per trobar, però òbviament, l’experiència és un grau molt important. Però sigui com sigui no s'ha d'oblidar mai, que la solució dels errors trobats després de treure al mercat un producte té un cost molt major que si es solucionen en l’etapa de test.
Es impossible i inviable trobar tots els errors d’un programa, és a dir fer testos exhaustius, inclús en els programes més trivials. Per això s’ha d’establir alguna estratègia que permeti simplificar el problema i afrontar d’una forma viable. Es distingeixen dos tipus bàsics d’estratègies en funció de l’enfoc general que en fan del problema:
 |
Estratègies de caixa negra vs. estrategies de caixa blanca |
Les estratègies de caixa negra ( o estratègies orientades a la entrada / sortida ). Veuen el producte a testejar com una caixa negra, sense entrar en detalls interns o d’implementació, i tenen com a finalitat trobar aquelles circumstancies en que el producte no es comporta com hauria. És impossible fer una proba exhaustiva a les entrades i sortides i s’ha de disposar d’alguna metodologia per tal de establir quines entrades i quines sortides es provaran. Fer servir les tècniques adequades per establir els casos de test, incrementa la eficiència de la fase de test.Les estratègies de caixa blanca (de caixa de vidre, estructurals, de cobertura, o estratègies orientades a la lògica interna) Extreuen conclusions a partir de la estructura i lògica interna de l’aplicació sense entrar gaire en l’especificació. Demostrar que el codi no te errors, no garantitza que faci el que hauria de fer. Inclús pot ser que el codi no presenti errors, pero no implementi certes funcionalitats que sí hi haurien de ser. Un altre cop és impossible fer una proba exhaustiva de tots els camins possibles a traves del codi i per això és necessari disposar d’alguna metodologia per organitzar i garantitzar que el codi es recorregut i verificat de forma intel•ligent i el mes optima possible.
Tot i que no s’explicaran, a continuació es citen algunes tècniques agrupades dins les estratègies de caixa blanca, per tal de que si algú ho necessita pugui cercar informació o aprofundir mes en aquestes:
| - Cobertura lògica ( logic-coverage testing): el seu objectius és recórrer i verificar el màxim de camins lògics dins del codi, sense deixar zones sense revisar |
| - Cobertura de codi |
| - Cobertura de decisions o branques ( decisión coverage or branch coverage ) |
| - Cobertura de condicions |
| - Equivalència de classes ( equivalence partitioning ) |
| - Anàlisis dels valors límits ( boundary value análysis ) |
| - Grafs de causa-efecte ( cause effect-graphing ) |
| - Endevinar errors ( error guessing ) |
 |
Pàgina anterior (pag 1/3) | Tornar a l'índex | Tornar a Tolaemon | Pàgina següent (pag 3/3) |  |