Aquí esbozaremos algunas de las técnicas más comunes de prueba de software. Para listarlas, utilizaremos los criterios de clasificación más usuales, con lo que obtendremos una caracterización común en la literatura.
Conocimiento de la Composición interna del Componente
Se refiere al nivel de conocimiento de la estructura interna del sistema a probar que el tester requiere para realizar la prueba. Técnicas comunes son:
- Pruebas de caja negra (black-box testing, o “pruebas de funcionalidad”): centradas en verificar si el SUT satisface los requerimientos. Algunas técnicas de este tipo son la de clases de equivalencia y la de valores límite.
- Pruebas de caja blanca (white-box testing, o pruebas “de código/diseño/estructurales”): basándose en los requerimientos, en el diseño y en el código fuente, se revisa, entre otras cosas, si el SUT sigue los estándares especificados, si los algoritmos son adecuados, y si la arquitectura del programa y de la base de datos son apropiados. Algunas técnicas de este tipo son el análisis de algoritmos y la cobertura de sentencias, decisiones y condiciones.
Granularidad del Componente
Considera el tamaño de los elementos del SUT que se van probando; hablamos de:
- Pruebas de unidad: se prueba por separado cada “elemento mínimo de procesamiento”, concepto que define la organización, y que puede ser v.gr. un objeto, un componente, un módulo, una función, etc. Las técnicas que más debieran ser utilizadas son las de caja blanca. Típicamente, son realizadas por el equipo desarrollador.
- Pruebas de integración: se verifica la interacción entre unidades (en el sentido del punto anterior) con técnicas como pruebas de interacción y de mutación. Suelen ser ejecutadas por el equipo de prueba.
- Pruebas de sistema: se verifica el sistema como un todo, aplicando pruebas de caja negra utilizando perfiles de usuario, haciendo v.gr. pruebas de configuración, de ergonomía, de seguridad, de confiabilidad y de recuperación. Debieran ser ejecutadas por el equipo de prueba.
- Pruebas de aceptación: se verifica la satisfacción de requerimientos con técnicas como pruebas- α y pruebas-β
, descritas más abajo. Debieran ser llevadas a cabo por un equipo que incluya al cliente, al usuario y a los testers.
“Dirección de Avance” en la prueba
Para probar el SUT se diseñan casos de prueba; llamamos pruebas progresivas a la primera vez que éstos son aplicados. Esa primera fase detecta defectos que son corregidos por el equipo desarrollador, quizás considerando ciertas prioridades.
A la versión corregida debieran aplicársele nuevamente los casos de prueba, o al menos un subconjunto de ellos, porque puede ocurrir que no se hayan realizado todas las correcciones necesarias, o que las correcciones generen nuevas fallas.
A la repetición de la aplicación de un subconjunto de casos de prueba la llamamos pruebas regresivas. La elección del subconjunto es muy importante y debe realizarse bajo criterios bien definidos y en acuerdo con el responsable general del proyecto.
Aún cuando en principio se pudieran tener cuantos ciclos regresivos se quisiera, en realidad un número pequeño de ellos muestra tendencias que permiten tomar decisiones (como tener que rehacer un componente). Para aprovechar al máximo la inversión en las pruebas, en todo proyecto debiera ejecutarse al menos un ciclo de pruebas de regresión, que permitiera revisar los resultados de las correcciones realizadas.
Control sobre el Ambiente en el que se lleva a cabo la prueba
Se distinguen dos casos:
- Pruebas-α (α–testing), llevadas a cabo de manera controlada en un laboratorio de pruebas que trata de reproducir el ambiente en el que se ejecuta el SUT.
- Pruebas-β, realizadas al SUT en su ambiente real de ejecución.
Ejecución o no del SUT
Podemos hablar de dos grandes casos:
- Pruebas dinámicas, llevadas a cabo mediante la ejecución del SUT, introduciendo entradas y verificando si las salidas son correctas.
- Pruebas estáticas, que se realizan sin ejecutar el SUT; en ellas distinguimos:
- las Revisiones, en las cuales los testers y personas con otros roles revisan sistemáticamente el código del SUT, pero también otros documentos con elementos técnicos (como algoritmos, diseños o manuales) para detectar anomalías;
- el Análisis de Código, llevado a cabo mediante un proceso que incluye el análisis léxico, sintáctico y semántico del código (los 3 son partes de un compilador) para detectar rápidamente anomalías estructurales.
Otros Criterios
Otros aspectos que pueden generar categorizaciones son por ejemplo características internas al SUT como la plataforma para la cual se desarrolló (web, móvil, desktop); y externas, como el dominio de aplicación en el que opera (retail, aeroespacial, financiero). El primero puede requerir ciertas técnicas/herramientas de prueba (v.gr. para probar firmware); el segundo puede exigir cierta profundidad en la prueba que haga posible obtener ciertas certificaciones (v.gr. para equipos médicos en el sector salud).
Un aspecto más (y más de avanzada) es lo que podríamos llamar “Nivel de Abstracción” en las pruebas, en el que podríamos incluir el Model Based Testing e incluso los Métodos Formales.
La especificación de una Estrategia de Pruebas implica la selección de un subconjunto de algunas de las técnicas mencionadas arriba, y constituye una actividad central del proceso de prueba de software. Cuál(es) de estas técnicas se aplique(n) es una decisión crucial que depende de las características de cada proyecto.
Síguenos en :