Dossier sobre el test de software ( y firmware)
Jordi Bartolomé 01-09-2007
 
4-Perfil del tester
Es importante escoger correctamente el perfil de las personas encargadas de diseñar y de llevar a término los tests. Con frecuencia se minusvalora el perfil de los implicados en los tests, y estos se encargan a personas que no tienen los conocimientos, experiencia o la actitud adecuada para realizarlos. En el peor de los casos, esto puede llevar a tests en los que no se detectan errores importantes, tests que se alargan más de lo normal, o en los que se pasa por alto probar partes críticas del producto. Por tanto, como en todas las tareas, se ha de analizar la aptitud de las personas escogidas para diseñar y realizar las pruebas, e incluso, valorar si pagar más por un tester con un determinado perfil puede acabar suponiendo un ahorro importante de dinero, ya que, como se comentaba al inicio, a menudo el coste de solucionar los errores aumenta de forma proporcional al tiempo que tardan en detectarse. Los errores hallados a tiempo por un buen tester pueden suponer un ahorro de dinero importante a medio-largo plazo. Algunos de los puntos a tener en cuenta a la hora de escoger el perfil de un tester son:

1-Conocimientos: se ha de valorar cuales son los conocimientos que ha de tener la persona que ha de realizar las pruebas. Es obvio que si se quiere hacer el test de integración de varias DLLs o librerías software, se deberá buscar a una persona con conocimientos avanzados de programación. En caso de querer testear la vulnerabilidad de un sistema de banca electrónica será necesario encontrar a alguien con experiencia en el hacking o seguridad informática. Por otro lado, si se desea realizar un test de usabilidad de una lavadora, será más productivo y rentable, buscar a personas con experiencia en las labores del hogar. Por tanto, el perfil del encargado de test y de los testers se ha de adecuar al tipo de pruebas y a la complejidad del producto. Un punto que nunca está de más, es que éste tenga conocimientos de calidad del software.

2-Actitud: en el test, la actitud es un punto bastante importante, y es recomendable que las personas encargadas de realizarlo sean personas pacientes, a la vez un poco inquietas, y con cierta motivación por encontrar "los errores ocultos". Tal como se dice al inicio del documento, los mejores resultados del test se obtienen cuando el tester toma un "rol destructivo", para ello este ha de estar motivado en demostrar que el producto presenta errores. Se podría entender al tester como un hacker que desea hallar vulnerabilidades en nuestro producto.

3- Experiencia: como en todo, la experiencia es un punto importante, y en el test, aún lo es mas. La experiencia en el test hará más fácil identificar los posibles errores o puntos débiles del producto, así como también, crear un entorno propicio para que se manifiesten. Precisamente es este último uno de los aspectos más dificiles del test: conseguir reproducir los errores. Tener localizado un error y ser capaz de reproducirlo reduce enormemente el tiempo necesario para solucionarlo.

Obviamente las empresas tienen recursos limitados y normalmente no pueden disponer de una o varias personas para cada tipo de prueba. Es aquí donde entra la habilidad del jefe de proyecto o responsable del test a la hora de escoger a los implicados en el test, en función de los recursos disponibles en la empresa.
 
5-Propuesta de test plan
Como se ha dicho, el test plan es la herramienta básica del test y ha de ser un documento lo más cómodo y fácil de entender posible con la finalidad de facilitar su seguimiento al tester. Un test muy denso o difícil de entender dificultará y alargará el trabajo de éste. En el caso de trabajar sobre equipos con los que el tester se pueda lesionar accidentalmente, o en los que un error de manipulación pueda tener consecuencias críticas, será importante avisar al tester e indicar en el Test Plan las medidas de seguridad que ha tomar para evitarlas. Si los resultados se guardan directamente en el mismo documento de test, este deberá facilitar el registro de otra información complementaria como es la versión del software o firmware, la fecha-hora del test, nombre del tester etc. No obstante, para el registro y seguimiento de los errores se recomienda alguna de las herramientas que existen para ello ( p.ej. bugzilla ). Atendiendo a lo visto hasta éste punto, se propone estructurar el test plan de la siguiente forma:

1-Introducción y objetivos del test: debe servir de introducción para situar al tester en el contexto del test. En éste punto se puede hacer énfasis en los puntos críticos y aspectos generales a los que se debe prestar más atención.

2-Material y condiciones necesarias para el test: en este apartado se han de especificar los recursos que el tester necesitará para realizar las diferentes pruebas, como también las condiciones o contexto en que estas han de tener lugar. También se debe indicar que documentación extra será necesaria para realizar el test.

3-Casos de test: los casos de test se han de agrupar según algún tipo de criterio como puede ser el objetivo, la funcionalidad etc. A parte de para de para ordenar el documento, esto permite distribuir el trabajo entre los diferentes testers en función de sus habilidades o su perfil. A continuación se muestra un par de ejemplos de casos de test:

“…
2.1 - Control de usuarios
Verificación del control de concurrencia en el acceso de más de un usuario a la web de IP-SYS:
a) Ir a la página de autentificación y entrar el nombre de usuario y contraseña correctos y validar repitiendo el proceso descrito en el anterior apartado.
b) Mantenerse en la página principal con el navegador abierto y abrir otra ventana de navegador.
c) En la nueva ventana de navegador ir a la página de autentificación del IP-SYS e introducir el nombre y contraseña de usuario correcta.
Comprobar que se muestra el mensaje de error indicando que ya existe otra sesión abierta y que hasta que esta no finalice no se va a poder acceder.
Fecha-Hora: Tester:
KO / OK: Observaciones:
 
2.2 - Caducidad de sesión
Verificación del correcto control del tiempo de duración de la sesión:
a) Ir a la página de autentificación, entrar el nombre de usuario y contraseña correctos y validar.
b) Mantenerse en la página principal durante 5 minutos.
Comprobar que pasados los 5 minutos la sesión ha caducado y se vuelve a mostrar la página de bienvenida.
Fecha-Hora: Tester:
KO / OK: Observaciones:

…"

4-Observaciones:en el caso de que los resultados se guarden en el mismo documento, puede ser interesante disponer de un campo de observaciones donde el tester pueda expresar otros aspectos que crea importantes y que no se hayan tenido en cuenta en el test plan.

Obviamente, esta es solo una propuesta y no tiene porque ser la mejor, por ello se puede modificar según se crea conveniente.

 
6-Planificación y control del test
Tal como se ha citado, el error más frecuente al planificar tests es no prever la aparición de errores, y eso se traduce en planificaciones que se acaban quedando cortas. Las planificaciones se han de realizar teniendo en cuenta los siguientes puntos:

1-Objetivos: se han de dejar claros los objetivos de cada test plan.

2-Criterios de finalización: se ha de establecer un criterio que permita dar por acabado un test plan.

3-Agenda: intentar fijar unas fechas realistas para las distintas subtareas, procurando que en el momento de comenzar el test, estén disponibles los recursos necesarios como el test plan, los módulos o aplicaciones a ser probados etc. evitando así los retrasos desde el inicio.

4-Herramientas y recursos: establecer cuales van a ser las herramientas necesarias para realizar el test, y en el caso de que deban crearse, planificando también el tiempo para su desarrollo.

5-Tiempo de las herramientas: en el caso de que se tengan que usar herramientas específicas para realizar el test, y estas se tengan que reservar, será importante establecer durante cuanto tiempo se han de reservar.

6-Responsabilidad: se ha de establecer un responsable para cada una de las tareas relacionadas con el test: escribir el test plan, ejecutar y validar los casos de test, reparar los errores encontrados. Esto asegurará la correcta ejecución y en caso contrario al responsabilidad de ello.

7-Proceso de integración: se ha de planificar como se unirán las piezas que componen el software ( top-down, bottom-up ) y por tanto que orden se seguirá en las pruebas de integración. Esto tiene implicaciones directas en las herramientas y recursos necesarios para realizar el test, sobre todo si previamente se han de desarrollar módulos drivers o módulos stub.

8-Tareas de seguimiento: es importante tener en cuenta que periódicamente se han de realizar tareas de seguimiento para supervisar la evolución del test, intentando localizar las partes que han presentado más errores de lo normal, verificando si se han cumplido ya los criterios de completitud, o si es necesario reajustar las planificaciones. Lógicamente el test se hace para encontrar errores, y si se encuentran se deberán solucionar. Es el responsable del proyecto quien ha de tomar la decisión de entregar un producto con los errores solucionados o no, analizando el coste de solucionar-los y el coste de las repercusiones de no hacerlo. Nunca considerando que los errores encontrados no se reproducirán fuera de las pruebas, dado que como dice una de las leyes de Murphy "Si existe la posibilidad de que algo falle, fallará".

9-Mecanismos de corrección: se ha de fijar también como se actuará cuando se detecten errores: se corregirán de forma paralela al test, se actualizará el programa testeado una vez corregidos, se corregirán todos a la vez al final del test...

10-Tests de regresión: establecer con que frecuencia o en que condiciones se deberán realizar los tests de regresión, una vez se hayan corregido los errores.

 
6.1-Recursos del test

A continuación se da un checklist del material que se suele utilizar durante las fases de test, con la intención de ayudar en su planificación. Conocer la disponibilidad de este material, permitirá avanzar o retrasar las pruebas, y así ajustar mejor las fechas:

1-Software o equipo a probar: se debe asegurar que en el momento de comenzar las pruebas se dispondrá del firmware o del código a testear. Para evitar confusiones, es importante tener controlado en todo momento la versión del código o compilación sobre la que se está trabajando.

3-Material de seguridad: en el caso de probarse un dispositivo con el que el tester pudiera lesionarse o en el que un bug o error de manipulación pudiera tener consecuencias críticas, se deberá garantizar que durante el test estén disponibles todas las herramientas o medidas de seguridad necesarias para evitarlo.

4-Manuales de uso: es muy probable que el tester no sepa como utilizar alguno de los equipos o elementos referenciados en el test plan, y por eso nunca está de más que este tenga a su alcance los manuales o guias rápidas de estos.

5-Test plan: como se ha comentado al inicio de este documento, el test plan es la herramienta básica del test y este deberá estar disponible en el momento de iniciar las pruebas.

6- Software de control de errores: los errores detectados durante las pruebas se han de ir registrando en el correspondiente sistema de gestión de errores ( p.ej Bugzilla ) con la finalidad de poder llevar el control de estos de forma fácil. Este software también deberá estar disponible y correctamente configurado en el momento de iniciarse las pruebas.

7-Herramientas de test: en algunas ocasiones las pruebas se realizan mediante workbenchs o programas que operan de forma automática sobre el firmware o el software. En caso de usarse algún tipo de programa de este estilo también deberán estar disponibles y correctamente configurados en el momento de iniciar las pruebas.

 
6.2-Criterios de "completitud"

Uno de los puntos más comprometidos para el responsable de un test es el momento en que se plantea si vale la pena continuar el test o si al contrario lo mejor es darlo por terminado ( aunque se desconozca la cantidad de errores que quedan por encontrar ). A menudo el dilema se soluciona con criterios económicos "no hay más dinero para continuar" o "acabamos, porque el producto se debe vender ya". Existen criterios más correctos y útiles para este propósito, aunque finalmente los tests finalizan en alguna de las siguientes circunstancias:

1-Se terminan cuando el tiempo programado se acaba. Este criterio es inútil puesto que, aunque se haya consumido el tiempo programado, este puede haber sido insuficiente, o puede haber sido suficiente pero el proceso de test puede haber sido de baja calidad.

2-Cuando se han ejecutado todos los casos de test sin haber encontrado errores. Este criterio también puede ser inútil, ya que quizás no se hayan detectado errores porque el test plan es incorrecto o inadecuado.

A continuación se exponen algunos criterios más correctos. Una primera aproximación sería tener en cuenta los criterios propios de la metodología de test utilizada, de forma que el test finalizaría cuando se hubieran revisado todos los casos de test establecidos por la metodología utilizada, siempre y cuando esta permita establecer un número máximo de casos de test. P.ej un test se podría dar por acabado cuando aplicando una metodología de caja blanca basada en el criterio de las condiciones, se hubiesen analizado todas las condiciones. De todas formas no existe una forma de garantizar que una metodología ha sido utilizada de forma correcta. Un segundo método más correcto sería dar por finalizado un test cuando se haya encontrado un número determinado de errores, que deberá haber sido definido antes de comenzar las pruebas. Esto presenta algunas dificultades:

- Como se puede estimar el número de errores que hay en un programa?
- Como se puede estimar el porcentaje de estos errores que se podrá llegar a encontrar?
- Y más difícil aún: que errores originados en fases concretas del diseño serán localizados en fases concretas del test ?

La mejor forma de predecir los errores es basándose en la experiencia adquirida en proyectos anteriores. Otra es hacer un ensayo previo sobre el programa con la finalidad de establecer un ratio de número de errores por módulo, o mejor aún, por lineas de código. No obstante se puede partir de un estándar de 4 a 8 errores por cada 100 lineas de código y ajustar-lo a medida que avanza el proyecto. Antes de empezar el test también se puede asumir que el 40% de los errores presentes en la aplicación seran debidos a errores lógicos y de programación y el 60% restante a errores de diseño. Los errores lógicos y de programación se encuentran en las siguientes proporciones: el 65% en el test de módulos, el 30% en el test funciona y el 3% en los tests de sistema. Los errores de diseño se encuentran en las siguientes proporciones: 0% en la fase de test de los módulos, el 60% en el test funcional, y el 35% en el test de sistema. Se puede ver que los porcentajes no suman el 100% y esto es debido a que se asume que hay un porcentaje de errores que nunca se llegará a encontrar. Si en el tiempo destinado al test no se ha encontrado el número de errores previsto, será necesario analizar si esto es debido a que realmente el producto tenía menos errores de lo normal, a si las previsiones del número de errores eran excesivas, o si en cambio los mecanismos de test utilizados eran inadecuados o incorrectos. La tercera forma de saber si un test se puede dar por completo o no, es sencilla, pero implica un alto grado de experiencia e intuición. Consiste en dibujar una gráfica con el número de errores encontrados por unidad de tiempo durante la evolución de este. Examinando el perfil de la gráfica se puede intentar determinar si se puede dar una fase por acabada o si al contrario es conveniente continuar:

Algunas dificultades de éste método son acertar la trayectoria que seguirá la gráfica, evaluar correctamente el tiempo invertido en el test ( con frecuencia los testers realizan otras tareas) etc.

Como se puede ver, el punto clave a la hora de decidir si continuar el test o no, es la difícil tarea de valorar el coste de continuar realizando el test y las repercusiones que puede tener no continuarlo. Después se ha de valorar si vale la pena seguir o no. Las estrategias descritas permiten ayudar a valorar el número de errores que quedan por hallar, pero obviamente, la experiencia es un punto importante. Pero sea como sea no se debe olvidar nunca que, la solución de los errores encontrados después de sacar un producto al mercado tiene un coste mayor que si se solucionan en la etapa de test.

 
7-Estrategias básicas de test

Es imposible e inviable encontrar todos los errores de un programa, es decir realizar tests exhaustivos, incluso en los programas más triviales. Por ello se ha de establecer alguna estrategia que permita simplificar el problema y afrontarlo de una forma viable. Se distinguen dos tipos básicos de estrategias en función del enfoque general que hacen del problema:

Estrategias de caja negra vs. estrategias de caja blanca

Las estrategias de caja negra ( o estrategias orientadas a la entrada / salida ) ven el producto a testear como una caja negra, sin entrar en detalles internos o de implementación, y tienen como finalidad encontrar aquellas circunstancias en que el producto no se comporta como debería. Es imposible hacer una prueba exhaustiva a las entradas y salidas y se ha de disponer de alguna metodología para establecer que entradas y que salidas se probaran. Utilizar las técnicas adecuadas para establecer los casos de test, incrementa la eficiencia de las pruebas. Las estrategias de caja blanca ( de caja de cristal, estructurales, de cobertura, o estrategias orientadas a la lógica interna). Extraen conclusiones a partir de la estructura y lógica interna de la aplicación sin entrar mucho en detalles relacionados con las especificaciones. Demostrar que el código no tiene errores, no garantiza que este haga lo que debería hacer. Incluso puede ser que el código no presente errores, pero no implemente ciertas funcionalidades que sí debería. De nuevo es imposible realizar una prueba exhaustiva de todos los caminos posibles a traves del código y por ello es necesario disponer de alguna metodología para organizar y garantizar que el código se recorre y verifica de forma inteligente y óptima. Aunque no se explicará con detalle, a continuación se citan algunas de las técnicas agrupadas dentro del las "estrategias de caja blanca" para que, si alguien lo necesita, pueda buscar información y profundizar más en estas:

- Cobertura lógica ( logic-coverage testing): sus objetivos son recorrer y validar el máximo de caminos lógicos dentro del código, sin dejar zonas sin revisar.

- Cobertura de código
- Cobertura de decisiones o ramas ( decisión coverage or branch coverage )
- Cobertura de condiciones
- Equivalencia de clases ( equivalence partitioning )
- Analisis dels valores límite ( boundary value análysis )
- Grafos de causa-efecto ( cause effect-graphing )
- Adivinar errores ( error guessing )
 
  Página anterior (pag 1/4)   Volver al índice   Página siguiente (pag 3/4)
Regresar al índice de documentos