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

jueves, 6 de noviembre de 2014

Para adentrarnos un poco más en las diferentes pruebas que tiene que (o debería) realizar un equipo de QA, vamos a clasificar las pruebas según determinados criterios y luego profundizaremos en su definición y características principales. La tarea de clasificar las distintas pruebas dependerá siempre de los diferentes enfoques que se pueden tener sobre el propósito del software desarrollado, así que vamos a presentar diferentes clasificaciones atendiendo a los criterios que se suelen tener en cuenta a la hora de realizar una evaluación de calidad.

Según la metodología utilizada para verificar y conocer a fondo el funcionamiento de la aplicación disponemos de dos casos:

  • Test basado en un guión de casos de prueba o comúnmente llamado Scripted Testing
  • Test basado en pruebas exploratorias también llamado Exploratory Testing
Según la accesibilidad que se tenga sobre los elementos del sistema a evaluar:
  • Pruebas de Caja Blanca
  • Pruebas de Caja Negra
  • Pruebas de Caja Gris
También podrían clasificarse según el nivel al que llega cada test, y en éste caso se hablaría de:
  • Pruebas unitarias
  • Pruebas de integración
  • Pruebas de sistema

Y por último y no menos importante, si la clasificación se basa en la ejecución del producto también existe la siguiente clasificación:

  • Pruebas funcionales: En estos casos se lanza la ejecución de la aplicación para evaluar las diferentes características del software. En estas pruebas se busca si la solución satisface las necesidades por la que fue creada, si es compatible entre versiones, si realiza el funcionamiento esperado para un grupo de personas, etc. Según las pruebas (más o menos ligeras), podríamos hablar de "pruebas de humo",  de regresión, pruebas de aceptación, de compatibilidad,  de uso a primer nivel o "Alpha testing", pruebas de uso en pre-producción o "Beta testing"..
  • Pruebas no funcionales: en este caso se tratan de pruebas totalmente complementarias a las anteriores, ya que no es necesario la evaluación del funcionamiento de la aplicación sino verificar diferentes aspectos de ella. En este conjunto entrarían pruebas de seguridad, de usabilidad, de rendimiento, de internacionalización y localización, pruebas de escalabilidad,  de mantenimiento, de instalación, de portabilidad...

Llegados a este punto vamos a ir definiendo uno a uno para que se puedan apreciar las similitudes y diferencias de cada tipo de test existente en la actualidad.



Scripted Testing

Cuando hablamos de un test basado en un guión de pruebas (Scripted Testing), nos referimos a un tipo de test cuyo enfoque puede ser entendido como "tradicional". En este escenario se realiza un proceso de creación de documentación relativo a las pruebas que se quieren realizar. El diseño de los casos de prueba se hace al inicio del proyecto, donde se tienen claramente definidos los aspectos que se desean alcanzar, y se van añadiendo casos de prueba en cada nueva fase de desarrollo, de forma que se utilizan los casos previamente definidos y se añaden otros nuevos según haya variado la aplicación con respecto a la fase anterior (nuevas características, soluciones a errores, optimización de recursos, etc.). Finalmente el guión de casos de prueba dará al tester los pasos a seguir para ejecutar la aplicación e interpretar los resultados obtenidos de las pruebas y completar un informe detallado que formará parte de la documentación para la siguiente fase.

Si hablamos del ciclo de vida de un Scripted Test, podemos definir dos fases si tomamos en cuenta una visión temporal del proyecto:
  • Diseño temprano de pruebas.
  • Ejecución de las pruebas (en muchos casos, muy posterior al diseño).
Sin embargo, tras esto se iniciaría un ciclo por cada fase de desarrollo del producto.
  • Refactorización del conjunto de casos de prueba.
  • Ejecución de las pruebas.
Una característica principal es que el Scripted Testing se adapta a contextos poco variables y a situaciones donde se tenga un control estricto sobre los diferentes aspectos del proceso. Nuevas variables que revisar y verificar, o cualquier cúmulo de cambios, harían el control sobre las pruebas de la aplicación se complicara considerablemente y en consecuencia supondría realizar muchos cambios en el guión de pruebas.

En la práctica, el equipo de QA elige un integrante al que llamaremos diseñador. Se encargará de crear los casos de prueba que debería dar como resultado un robusto conjunto. Otros integrantes (o solo uno, dependiendo del volumen de casos), realizarán la función de testers que serán los que busquen lo que el diseñador les diga bajo las condiciones de entorno que el diseñador les imponga.

Es importante que el diseñador no realice funciones de tester ya que su aportación a la búsqueda de errores sería prácticamente nula respecto a las pruebas que él mismo ha pasado por alto. O lo que es lo mismo: los demás pueden encontrar errores para los que el diseñador no ha generado casos de prueba.

Si pretendemos dar un ejemplo sobre esto, tendríamos que definir lo que es una Fábrica de Pruebas, puesto que en este entorno es el proyecto el que se adaptará al proceso de trabajo de la fábrica. En esta situación los proyectos se etiquetarán según sus características y se tratarán según la clasificación que les aplica. En este entorno existen plantillas con un conjunto de pruebas predefinidas y según el tipo de proyecto al que se le quiera aplicar, se aplica una plantilla u otra.

Para desarrollar estas plantillas se presta atención a aspectos generales como:
  • Los riesgos habituales en un determinado escenario.
  • Previsión de errores, así como su ubicación, su tipología, etc.
  • Posibilidad de aplicar la repetición de pruebas, que sería muy ventajoso.
  • Valorar el uso de scripts automatizados (programación de algoritmos de prueba)
Sobre esto, un aspecto que siempre debemos tener en cuenta es la capacidad de las personas a la hora de procesar información. Algunas personas pueden ver lo que otros no ven a simple vista, ya sea por falta de conocimientos o intereses. En contraposición, los ordenadores a su vez se centran únicamente en hacer lo que se les ha programado hacer, es decir, no posee suficiente inteligencia para descubrir errores que pueden estar en el mismo escenario en el que se está ejecutando, ya que solo observará lo que se ha diseñado que se observe.



Pruebas exploratorias

Las pruebas exploratorias o testing exploratorio es un estilo o enfoque a la hora de realizar una evaluación de calidad de un producto software en la que podríamos destacar su capacidad de retroalimentación. Donde aprender el funcionamiento de la aplicación, la labor de diseñar casos de prueba y ejecutarlas son etapas que van de forma conjunta durante casi toda la ejecución del test.

Si quisiéramos decirlo de otra manera, sería un estilo de testing donde se da especial prioridad a la libertad del tester de optimizar continuamente la calidad de su banco de pruebas y la responsabilidad asociada para mantenerlo y realimentarlo según vaya realizándose el diseño o la realización de pruebas. Es decir, no se espera a que se complete un ciclo de desarrollo para regenerar el conjunto de pruebas, sino que el número de pruebas irán incrementando en función de cómo se vaya explorando la aplicación. Cuanto más se use la aplicación más casos de uso se nos ocurrirán y de esta manera tendremos un guion más robusto y podremos realizar un informe mucho más completo que el que conseguiríamos con un Scripted Testing

Muchas personas que se dedican a las pruebas de calidad, consideran que el testing exploratorio tiene características comunes con la técnica de prueba de caja negra (hablaremos de ello más adelante), sin embargo, no queremos dar a entender el testing exploratorio como una técnica, sino más bien como una filosofía o enfoque donde la clave principal está en la responsabilidad y concentración del tester para gestionar tiempo y recursos en la búsqueda de mejorar constante y progresivamente su batería de pruebas sin necesidad de una nueva versión de la aplicación o características.

Y es que el objetivo principal que se persigue, es aprender cómo funciona realmente la aplicación y ser capaz de responder a preguntas sobre cómo se comporta en determinadas circunstancias. Es por esto que la calidad del testing exploratorio depende de las habilidades del tester para desarrollar los casos de prueba iniciales y generar nuevos a la hora de encontrar errores. El tester configura, opera, observa y evalúa el producto y su comportamiento, investigando de forma crítica el resultado y reportando la información de lo que parecen ser defectos (que amenazan el valor del producto) o problemas (que amenazan la continuidad y calidad de las pruebas).

En relación a la documentación, se puede decir que se puede ir desde registrar todas las pruebas realizadas, a documentar únicamente los defectos.

La tarea de documentar los errores no siempre depende del tester que los encuentre, ya que en situaciones comunes como las pruebas por parejas, dos personas crean los casos de pruebas y luego una los ejecuta y la otra documenta. Así se consigue un alto grado de rendimiento y concentración en la labor que se está realizando.

Las pruebas basadas en sesiones es un método específicamente diseñado para el testing exploratorio auditable y medible a gran escala. Es por esto que en algunas empresas, como complemento a la hora de realizar el testing exploratorio, hacen uso de herramientas, (capturas de pantalla o vídeo, por ejemplo), que se usan a modo de registro de la sesión.

Scripted Testing y Exploratory Testing

Combinación Scripted Testing y Exploratory Testing

En realidad, para realizar un test sobre aplicaciones no se tiene por qué optar a uno u otro enfoque. Una buena práctica de evaluación de calidad casi siempre es una combinación de testing exploratorio y testing basado en un guion de pruebas, aunque el equipo de QA siempre se va a tener tendencia hacia uno de los dos, dependiendo del tipo de proyecto, numero características e incremento de las mismas, etc.

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

Jhonattan Fiestas
jhonattan.fiestas@11paths.com

2 comentarios:

  1. No lei el articulo todavia pero hay algo q me llama la atencion en el titulo. Puede servir las pruebas para hacer aseguramiento de calidad?, no es mas bien Control de calidad ?

    ResponderEliminar
  2. Buenos días!
    El artículo habla de las prácticas que se deben realizar por un equipo de control de calidad para poder asegurar la calidad del producto final.

    Saludos!

    ResponderEliminar