Lectura

QA: Pruebas para asegurar la calidad del producto software

MARTES, 30 DE DICIEMBRE DE 2014

Las pruebas de calidad sobre una aplicación informática se pueden dividir siguiendo diversos
criterios, y uno de ellos es según la accesibilidad que se tenga sobre los elementos del sistema a
evaluar. Es allí donde entran en juego dos conceptos muy conocidos por los profesionales de
seguridad informática: caja blanca y caja negra... incluso la caja gris como punto intermedio entre
ellas.

Fuente: http://www.softwaretestingnet.com/2009/10/black-box-and-white-box-testing.html

Pruebas de caja blanca

Cuando nos referimos a pruebas de caja blanca hablamos de pruebas que están fuertemente ligadas
al código fuente. Para realizar la batería de test en primer lugar habremos inspeccionado el código
fuente y analizado todos los posibles flujos de ejecución de la aplicación, cerciorándonos en cada
caso de que los resultados obtenidos sean los esperados.

Es por esto que se dice que estas pruebas están fuertemente ligadas en una implementación en
concreto, ya que si ésta se modifica, por regla general las pruebas tendrán que ser modificadas y/o
rediseñadas.

Fuente: http://www.calidadysoftware.com/testing/pruebas_unitarias1.php

1
Como puede apreciarse en la imagen de arriba, los "testers" tendremos la posibilidad de observar
el funcionamiento de los diversos componentes (óvalos) y probarlos adecuadamente, además de
poder verificar las dependencias, interfaces y flujos de comunicación existentes entre ellos (flechas).

Llegado a este punto suele surgir una pregunta... ¿Quién debería encargarse de hacer las
pruebas? Lo más recomendable sería que sea la persona del equipo que mejor conozca el lenguaje
de programación en el que se haya desarrollado el proyecto, además que debería estar
familiarizado con las herramientas de depuración y pruebas útiles para ese entorno.

En la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de
pruebas, como por ejemplo, las soluciones incluidas en el paquete "Mercury Interactive Software
Test Tools" u otras como las bibliotecas de JUnit, NUnit para C#, CPPUnit, etc.

Esto deja en claro que dependiendo del lenguaje que se esté utilizando se pueden conseguir
herramientas nativas o adaptadas a dicho lenguaje y además estas herramientas facilitan en gran
medida el desarrollo de pruebas, la elaboración de casos de prueba, seguimiento de errores, etc.,
de forma que se pueda llevar un proceso lo más ordenado y completo posible.

 ¿A qué niveles se aplica?

Son diferentes los criterios que se toman al respecto, ya que en realidad se puede aplicar a cualquier
nivel (unidad, integración o sistema)... Sin embargo, comúnmente se suele aplicar modularmente a
unidades funcionales con el objetivo de inspeccionar y verificar el comportamiento de cada uno de
los elementos antes de empezar su integración dentro de un producto software como tal. Una vez
que se tienen probados todos los elementos por separado, se pasa a realizar una prueba más
general después de haber pasado una fase de integración, donde se comprueban los flujos
existentes entre las diferentes unidades funcionales. Este criterio vuelve a ser válido si se tratan de
sistemas completos donde se busca en código abierto comprobar la comunicación entre todos los
subsistemas que componen un proyecto.

 ¿Cómo se aplicaría esto a un escenario real?

Si quisiéramos brindar un caso práctico sobre el uso de pruebas de caja blanca, podríamos pensar
en un sistema de revisión de código como Gerrit (sistema de integración continua).

2
 Ciclo de control de desarrollo de software con caja blanca

Si tenemos un ciclo de desarrollo donde los programadores van incluyendo cambios sobre un
proyecto base, tarde o temprano surgirá la necesidad de que exista de por medio una persona que
evalúe la calidad y validez del código que se está subiendo al repositorio principal. No está de más
recordar que esta persona tendrá acceso al código fuente que va a auditar en cada momento.

En la figura anterior, hemos enmarcado en azul la acción que realizaría un tester para realizar una
inspección de código tras recibir una nueva actualización por parte de los desarrolladores. En este
caso, si el evaluador considera que el código es correcto y funcional aceptará el cambio y este pasará
a ser incluido como parte del proyecto final (en un repositorio centralizado). En caso contrario se
pedirá una rectificación o "patch set" para que el cambio que se pretendía introducir sea válido tras
la corrección (no se puede dar por válido un cambio tras una rectificación sin antes volver a analizar
el código fuente del cambio).

Otro entorno donde comúnmente se utilizan las pruebas de caja blanca es en las auditorías de
seguridad de una aplicación web, donde el cliente proporciona el código fuente de su aplicación
con el fin de que encuentre el mayor número de fallos. En estos casos lo primero que se hace es
comprobar el uso de buenas prácticas de seguridad incluidas en diversas guías de seguridad y
manuales especializados, ejecución de herramientas automatizadas para el escaneo de
vulnerabilidades... Tras esto también se realiza un procedimiento manual para verificar la validación
de campos de entrada, control de usuarios, controlar la ejecución de código externo, filtraciones de
información interna a través de metadatos o comentarios en el código fuente (con especial atención
a cuando se hace uso de código de terceros), etc.

3
Pruebas de caja negra

Su definición es un poco más sencilla, ya que conociendo una función específica para la que fue
diseñado el producto, se pueden diseñar pruebas que demuestren que esa función está bien
realizada solamente a través de su interfaz software, panel de ejecución, etc. Es decir, de la función
que desempeña la aplicación, actuando sobre ella como una caja negra, proporcionando unas
entradas y estudiando las salidas para ver si concuerdan con las esperadas.

 ¿Cómo se aplicaría esto a un escenario real?

Tal y como se mencionó en la anterior entrada, las fábricas de pruebas son empresas especializadas
en confeccionar conjuntos de test con el fin de evaluar la calidad de la aplicación que está probando.
En la mayoría de los casos estas empresas solamente tienen acceso al producto final, por lo que
inspeccionan todo desde afuera. Es muy interesante este punto de vista, ya que además de
centrarse especialmente en el ámbito funcional se tiende a buscar indicios de mal funcionamiento
a nivel de caja blanca, es decir, mala práctica a la hora del diseño. Por ejemplo inspeccionar el
comportamiento "responsive", evaluar la salida tras determinadas entradas en campos de
formularios o parámetros de la aplicación (algo muy utilizado en el entorno de seguridad
informática, sobre todo en el sector profesional en el hacking ético), etc.

Pruebas de caja gris

Algunos analistas consideran que solamente existen los dos tipos de cajas previamente
mencionados, pero algunos pocos consideramos la posibilidad de incluir en la clasificación un tercer
tipo de caja que, en resumen, será una mezcla de los dos anteriores como si de una situación
intermedia se tratara. En este caso utilizaremos los casos de prueba generados para los test de
caja blanca, pero en un escenario de un testing de caja negra, es decir, vamos a realizar pruebas
sobre elementos que a priori podrían tener problemas por la forma en la que se ha realizado la fase
de integración, la complejidad de los métodos o patrones de diseño elegidos, implementación de
código de terceros, etc. Y tras lo cual vamos a analizar los resultados obtenidos.

En la próxima oportunidad entraremos de lleno en las pruebas unitarias, que son consideradas un
punto clave a la hora de desarrollar. Se trata de pruebas que se realizan paralelamente al desarrollo
y son creadas por los propios programadores como parte de un buen proceso de desarrollo de
aplicaciones informáticas.