QA: Pruebas para asegurar la calidad del producto software (III)

martes, 30 de diciembre de 2014

Tal y como se había comentado con anterioridad, 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

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).

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.

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.


Jhonattan Fiestas
jhonattan.fiestas@11paths.com


4 comentarios:

  1. Esta serie de entradas es altamente ilustrativa, pero hay una parte dentro de las pruebas de calidad software, que suele ser bastante "aburrida" y que casi siempre echo en falta.

    Lo que serían las pruebas estáticas (no sólo análisis estático, caja blanca), por ejemplo, para comprobar que la documentación (APIs, descripción de interfaces, manuales de instalación, administración, uso, etc.) está actualizada y acorde con lo que el software hace.

    Cosa que uno se encuentra comúnmente en los proyectos: falta de documentación, documentación no actualizada, interfaces no documentados, etc.

    En resumen, esto sólo es un comentario para añadir a esta gran serie.

    ResponderEliminar
    Respuestas
    1. concuerdo plenamente con el comentario anterior...la documentacion es esencial y siempre está incompleta, debe ser parte del test de evaluación y punto MAYOR de NO CONFORMIDAD, en una auditoria.

      Eliminar
    2. hola, algunas herramientas que recomienden para el soporte de pruebas estáticas?

      Eliminar
  2. Muy interesante y bien estructurado el articulo sobre los tres tipos de pruebas de software

    ResponderEliminar