7-Estrategias básicas de test

8-Organización del test
      8.1-Organización general
      8.2-Test de desarrollo
      8.3-Test de módulo ( o test de unidad)
          8.3.1-Diseño de casos de test en el test de modulos
          8.3.2-Tests de integración
          8.3.3-Tests de integración incrementales vs no incrementales

     8.4-Tests de alto nivel
     8.5-Tests funcionales
     8.6-Tests de sistema
     8.7-Tests de aceptación

9-Técnicas de test de relectura de código, o técnicas "humanas"
     9.1-Técnica “Code Inspection”
     9.2-Técnica “Code WalkThorugh”
     9.3-Desk checking
     9.4-Peer rating

En los sistemas electrónicos y el software, el test es una de las fases más importantes, probablemente tanto como el propio desarrollo. Las empresas con más experiencia son conscientes de ello, y saben que un test adecuado tiene una implicación directa en la calidad del producto final, y al contrario de lo que puede parecer a simple vista, comporta a menudo un ahorro de dinero importante. Este ahorro se puede dar en variables fácilmente cuantificables, como el número de reparaciones, horas de asistencia técnica, sustitución de equipos, y en otras variables más difíciles de evaluar, como la satisfacción del cliente, la imagen del producto, o incluso la satisfacción de los propios trabajadores.

A pesar de su importancia, el test es poco tratado en las universidades en las que, con frecuencia, se trata de pasada. No obstante se ha escrito y discutido mucho sobre éste, y como a continuación ser verá, a pesar de disponer de técnicas y metodologías precisas, es un proceso bastante intuitivo. Este dossier se basa en uno de estos escritos, en concreto en el libro "The art of software testing" de Glenford J.Myers, que se considera como un clásico y referencia en la materia. También se basa en otra información recopilada de Internet y en la experiencia adquirida en los diferentes puestos de trabajo por los que he pasado.

Aunque los contextos en que se ejecuta el software y el firmware no son del todo iguales, lo que aquí se expone es aplicable a ambos. De hecho la diferencia software-firmware es cada vez más pequeña, ya que los entornos de los sistemas embedded son cada vez más complejos y más parecidos a los entornos de lo que entendemos por software. Por esto es cada vez más importante aplicar técnicas de test de software sobre el firmware. La parte que posiblemente queda un poco más alejada de éste texto es la relacionada con los drivers o controladores, los cuales se encuentran a medio camino entre el software y el hardware. Sobre estos se pueden aplicar algunas de las técnicas aquí expuestas, pero también se han de aplicar otras más propias del hardware o la electrónica.

Así, el objetivo de este documento es dar una visión general del test de software y de firmware, de como enfocarlo, y de algunas de las muchas técnicas que existen para llevarlo a término.

Antes de entrar en detalles sobre el test, es interesante hacer una aproximación general a este, y una buena forma de hacerlo es intentando definirlo. Normalmente el test se entiende como:

Aunque en el contexto general de un proyecto, el objetivo final del test es garantizar o verificar una cualidad ( ausencia de errores ), entender el test tal como se expresa en las definiciones anteriores generalmente lleva a un test infructuoso y sin éxito. Los mejores resultados se obtienen cuando se plantea de la siguiente forma:

Esto tiene implicaciones directas en el modo de trabajar del encargado del test y en la posición de la empresa respecto el test. Esto es así porque las personas tendemos a guiarnos por objetivos, y si partimos con la idea de demostrar que un software no presenta errores, probablemente lo acabemos consiguiendo sin muchas dificultades. Por otro lado si el test se realiza con la intención de encontrar errores seguramente se encuentren más. El tester es un cazador de errores, y como buen cazador, cuantos más y más grandes sean los errores que cace, mejor será este.

Esto no solo tiene implicaciones en el modo de trabajar del tester y en la posición de la empresa respecto a este, sino que también las tiene en el diseño de los casos de test. Es decir que los testers y los responsables del test han de ser conscientes y han de asimilar que las tareas de test son "tareas destructivas" ( con una intención final constructiva, está claro ). Es bajo esta condición cuando los tests dan mejores resultados. Por tanto un buen plan de test es aquél que maximiza las probabilidades de encontrar errores:

De esto se puede extraer que "Un test fracasa cuando no se encuentra ningun error" ya que:

Finalmente, la mejor forma de reforzar, o aproximarse a la afirmación de que "el producto satisface los criterios de calidad" es justificando que, a pesar de haberlo intentado, ha sido imposible demostrar que es falsa, más que limitarse a confirmarla.

Como se ha comentado, el test de software se encuentra muy ligado a factores psicológicos. Esto influye en diversos aspectos que se han de tener en cuenta a la hora de planificar, realizar, y analizar los tests. A continuación se listan algunas de estas consideraciones:

1 – La herramienta básica del test es el test plan. Éste documento ha de informar al tester de los pasos necesarios para cada prueba. Con la finalidad de evitar que el tester se deje llevar por el deseo de dar por válida la prueba, éste también debería incorporar el resultado esperado.

2-El desarrollador nunca ha de ser el responsable de las pruebas de su propio programa, ya que a menudo es difícil tomar un rol destructivo cuando se ha tenido un rol constructivo durante todo el desarrollo. Además, este puede estar presionado por fechas de entrega etc. Aunque deberá dedicar esfuerzos a conocer el funcionamiento del sistema, es mucho más conveniente que el test lo realice alguien ajeno al desarrollo. Lógicamente esto no aplica a las pruebas de desarrollo.

3-Una organización o empresa no debería ser la responsable de los tests finales de sus propios productos, ya que de forma similar a lo que sucede con el desarrollador, probablemente esta sea más reacia a demostrar que su producto no hace lo que supuestamente debería hacer. Teniendo en cuenta la inversión respecto el resultado, el test de un producto hecho por compañías independientes es mucho más rentable. A parte, saber que personas de otra compañía u organización revisaran su trabajo, hace que los desarrolladores vayan con más atención y cuidado durante el desarrollo.

4-Es importante revisar con atención los resultados de los tests, ya que con frecuencia, errores que se encuentran en tests posteriores, se habían pasado por alto en tests previos. Por esta razón, una vez el test ha finalizado, el responsable debería supervisar los resultados del tester, idependientemente de si se han encontrado muchos errores o no. Esto también evita arrastrar errores a lo largo de las diferentes etapas de vida del proyecto, lo que es muy frecuente que pase con los "pequeños errores".

5-Al plantear casos de test se ha de procurar que estos representen valores de entrada válidos y esperados, y también casos de test inválidos y no esperados que se puedan llegar a dar o no. Los casos correspondientes a valores inválidos e inesperados tienen una probabilidad de hallar errores mayores que los casos de test válidos y esperados.

6-Demostrar que el software no hace lo que debería hacer es la mitad del objetivo, la otra mitad es demostrar que hace lo que no debería hacer. Esto, se puede entender bien en el ejemplo del caso de una aplicación de facturación. Primero se trataría de demostrar que el software no hace los pagos tal como debería, mientras que el segundo punto consistiría en demostrar que hace pagos que no debería hacer.

7- Evitar hacer planes de test de usar y tirar, procurando que estos puedan ser reutilizables en el futuro, si es necesario. Esto evita tener que reinvertir tiempo en lo que ya se había hecho previamente, lo que puede ser vital p.ej al hacer tests de regresión. Una opción es mantener una base con los casos de test utilizados, clasificados según algún tipo de criterio que facilite su localización y reutilización. También es importante almacenar y mantener controlado un registro de los errores que se han ido encontrando y del estado de estos. Esto se puede hacer por escrito o preferiblemente mediante herramientas especializadas para el control de errores ( p.eh bugzilla ). Es importante acotar bien los errores, y aparte de tenerlos registrados, conocer bién la versión del software o firmware sobre el que se localizó, quien lo encontró, cuando etc.

8–La planificación de las fases de test se ha de hacer considerando que se van a encontrar errores, y nunca bajo la consideración de que no se encontraran.

9-La probabilidad de existencia de más errores en una parte del programa es proporcional al número de errores encontrados hasta el momento en esa parte. Por ello, estas partes deberían ser analizables con más detalle, incluso ser rehechas cuando el número de errores se considere preocupante.

10- Aunque la metodología es un factor clave, el test es un proceso extremadamente creativo y complicado, y a menudo más complejo que el propio desarrollo.

Regresar al índice de documentos