La prueba de componente también llamada prueba unitaria es por definición la prueba que se lleva a cabo luego de haber construido el componente.
Como los desarrollos son hechos en diferentes lenguajes, puede llegar a haber diferencias de conceptos y por tal, tendremos que por componentes podemos tener a una: prueba de módulo, prueba de clase ó prueba de unidad, y en estos casos en los que el desarrollador interviene «probando», estaremos en presencia de las «pruebas del desarrollador».
Este último párrafo define un punto de partida sobre el que podemos discutir y generar un debate muy rico, y es tan simple como que las pruebas no son de ninguna manera una actividad exclusiva de los «probadores», muy por el contrario se extiende al área de desarrollo. Obviamente que nosotros ponemos otra energía, otro conocimiento, otra perspectiva, y otras prácticas, pero hay que dejar muy en claro que los desarrolladores deben necesariamente realizar cierto tipo de pruebas con el objeto de mejorar la calidad del código que se construya.
Para toda prueba de componente hay que tener en cuenta: (a) las bases de la prueba, es decir: los requisitos del componente, su diseño detallado y su código; (b) los objetos de prueba más típicos, es decir: los componentes, ó clases, ó unidades, ó módulos, más programas y/o conversión de datos y/o migración de programas; y finalmente (c) los módulos de la/s base/s de datos.
Para comenzar a entender de qué hablamos, debemos tener muy en claro cuál es el alcance que debemos perseguir con este tipo de prueba.
En principio, hay que saber que: (a) sólo se prueban componentes individuales, (b) cada componente es probado en forma independiente, y (c) los casos de prueba podrán ser obtenidos a partir de ciertos artefactos. Abordemos, de manera sencilla cada uno de estos puntos.
Hay que considerar el aspecto individual, ya que un componente podría estar compuesto por un conjunto de unidades pequeñas y por ende, en estos casos habrá que tomar y someter a la/s prueba/s cada una de ellas. No obstante, a veces suele ocurrir que no se puedan probar de manera individual estas partes por diversas razones, en estos casos habrá que trabajar de otra manera que en un rato veremos.
Una vez que podemos y no tenemos ningún inconveniente en probar en forma independiente al componente, el objetivo será identificar fallos como producto de defectos internos que presente el componente, sin olvidarse que puede llegar a ocurrir que encontremos defectos cruzados entre los componentes que estemos tratando y que por ende, es decir por definición primaria, quedaría fuera del alcance de estas pruebas ya que son de componentes.
En cuanto a los casos de prueba que se puedan escribir para ejecutarlos, debemos tomarnos de ciertos artefactos como pueden ser: las especificaciones del componente, el diseño de software y/o el modelo de datos. Cada uno de ellos aportará lo necesario para permitir escribir un caso de prueba básico que seguramente podremos mejorar si investigamos más, pero que de por sí, nos ayudará a probar una condición particular que presente el componente a probar.
Pasemos ahora al tema Pruebas Funcionales y Pruebas No funcionales, ya que mucho se habla del tema y es necesario aclarar este punto.
Los componentes también merecen recibir una prueba funcional y no funcional, ya que forma parte del proceso de calidad de software.
El componente como tal, presenta una funcionalidad que deberá ser probada a través de un caso de prueba para verificar y validar si las funciones se realizan correctamente y/o si se cumplen todas las especificaciones. Por otra parte, los defectos que normalmente pueden encontrarse, tienen su origen cuando se están procesando los datos en el entorno de sus valores límites y/o en funciones ausentes.
En esta misma línea, no hay que olvidarse de tener en cuenta las pruebas de robustez, en las que se comprueban la resistencia a datos de entrada inválidos. En este caso, son pruebas negativas las que se hacen, ya que se comprueban datos de entrada que no son válidos. Si el software aceptara alguno de estos datos (no válidos) puede estar provocando en algún momento fallos durante procesamiento de datos (con datos que no son correctos) y/o fallos de sistema (los denominados, system crash).
En cuanto a las pruebas del tipo no funcional, se podrían considerar pruebas de rendimiento, pruebas de stress, pruebas de fiabilidad, entre otras.
También no debemos olvidarnos que para las pruebas de componentes, se pueden considerar los denominados «arneses para pruebas».
Básicamente podemos interpretarlo como un artefacto que nos ayudará a ejecutar una prueba sobre un componente que requiere de datos entrantes y/o salientes, y/o de un componente que aún no se ha construído ó que no es parte del objetivo a ser probado. En estos casos es que se utilizan: (a) drivers (controladores) y stubs (reemplazan o simulan componentes). Si hasta ahora no se visualiza bien, debemos darnos cuenta que estos dos artefactos se programan, razón por lo cual será necesario contar con el código fuente y hasta incluso puede ser necesario utilizar herramientas especiales.
Bien, para ir terminando con este tema, el desarrollador deberá seguir una metodología para realizar sus pruebas, y obviamente estarán enfocadas al desarrollo.
Los casos de prueba estarán relacionados con la funcionalidad, estructura y variables del componente, y sus pruebas las deberán realizar con una cierta frecuencia, utilizando depuradores y marcos de trabajo para sus pruebas unitarias (unit test framework), accediendo directamente a las variables afectadas.
Pero sin lugar a dudas, las técnicas de caja blanca son los que deberán aplicarse sobre el código fuente del componente. En este sentido recordemos que tenemos que manejar y entender la siguiente clasificación:
- técnicas de pruebas dinámicas
- técnicas de pruebas estáticas
Respecto a las técnicas de pruebas dinámicas, tenemos:
- Pruebas de sentencia y cobertura.
- Pruebas de decisión y cobertura.
- Pruebas de condición y cobertura.
- Pruebas de cobertura de camino.
como principales, aunque podemos agregar a:
- SYLSC, secuencia lineal y salto de código
- basadas en el flujo de datos
Respecto a las técnicas de pruebas estáticas, tenemos:
- Revisiones / Revisiones guiadas (walkthroughs)
- Análisis del flujo de control
- Análisis del flujo de datos
- Métricas compilador/analizador
En próximos artículos que estaré publicando, profundizaré un poco en cada una de estas técnicas que tan importantes son y que además, son puntos que toman en el exámen para certificar como ISTQB Foundation Level, razón por lo cual hay que entender y practicar mucho, máxime si no tenemos experiencia como desarrolladores.
También tengo pensado mostrar algunas herramientas que nos permiten conducir este tipo de técnicas.
Ok, espero que les haya resultado útil este material.
Abzo
Gustavo
