QA: Pruebas para asegurar la calidad del producto software

Las aplicaciones (en general cualquier mecanismo diseñado e implementado por un humano) son propensas a tener fallos. A veces, pueden contribuir al fracaso de cualquier proyecto de software, e impactar de forma negativa en toda una empresa. No parece "justo" que la imagen de toda una compañía se degrade por errores que pueden ser subsanados, y a los que el código es tan "propenso" en general. Los tiempos de desarrollo, los entornos de programación, las diferencias entre versiones... todo influye para que, incluso con la máxima dedicación, puedan darse fallos que empañen la imagen y a veces la reputación, de una organización. Surge por tanto la necesidad de asegurar en lo posible, la calidad del producto.

Pruebas de software

Principalmente se debe verificar que se cumplan con las especificaciones planteadas desde un inicio por el analista o el propio cliente, y/o eliminar los posibles errores que se hayan cometido en cualquier etapa del desarrollo. Hace años (y todavía en entornos pequeños), estas pruebas se realizaban de manera relativamente informal, como podría ser la generación de informes que pasaban entre departamentos. Pero hoy es, en muchos aspectos, una de las etapas críticas dentro del ciclo de vida del software. Existen, de hecho, diferentes metodologías para llevar a cabo las pruebas de calidad de manera óptima, y que tienen en cuenta la complejidad de trabajar con diferentes lenguajes de programación, sistemas operativos, arquitecturas hardware, etc. Debido a esto último, el proceso de testing debe basarse en metodologías o métricas generales que revisen los aspectos fundamentales del sistema, desde el seguimiento de errores, automatización de pruebas unitarias, etc.

Las pruebas de software son las investigaciones empíricas y técnicas cuyo fin es proporcionar información objetiva e independiente sobre la calidad del producto. Esta actividad forma parte del proceso de control de calidad global. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software y dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento del proceso de desarrollo.

Para conseguirlo, en realidad no existen las "mejores prácticas" como tal, debido a que cada práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en otra, por lo que las actividades de testeo, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar deben ser seleccionados y utilizados de la manera más eficiente según contexto del proyecto.

¿Por qué es necesario hacer pruebas?

La labor de desarrollar software en una empresa (ya sea como producto o herramienta interna) trae consigo la necesidad de asegurar que el trabajo realizado se acerca (en lo posible) a la perfección en cuanto calidad y desarrollo seguro. Evidentemente, esto redunda en la satisfacción del equipo que logra los objetivos como por parte del cliente que obtiene el mayor beneficio de un producto finalizado.

Además, como toda buena inversión, ahorra tiempo a largo plazo. Si trasladamos por ejemplo los conceptos al entorno móvil, para asegurar el correcto funcionamiento de las aplicaciones en cada tipo de terminal y sistema operativo, el equipo de pruebas debe realizar diversos test a diferentes niveles (como veremos en siguientes entregas). Excepto Google Play, las grandes compañías de distribución de apps (AppsStore y Microsoft Marketplace) suelen someter a diversas pruebas las apps candidatas, para comprobar que se encuentran dentro de unos umbrales mínimos de calidad. Este proceso puede ser de varios días antes de recibir el visto bueno o el rechazo, con lo que el proceso debería volver a comenzarse. Esta es una de las razones por las que someter cualquier aplicación a una buena batería de pruebas de forma interna.

¿Cuándo y cómo empezar el proceso de testing?

Siguiendo el proceso de desarrollo software, tras la realización del análisis, diseño y en algún punto del desarrollo de la aplicación debe iniciarse la etapa de pruebas. Para esto es necesario un ambiente aislado del de desarrollo y el de producción, es decir, debería simularse la ejecución de la aplicación en un entorno idéntico a donde se va a ejecutar. Esto incluye la mayor muestra posible de sistemas "estándar" de usuario, en el caso de que se trate de una aplicación destinada al público en general, donde es imposible simular todos los escenarios.

Un aspecto importante para todas las empresas debe ser el tener un buen equipo de testers que cuenten con las herramientas necesarias para realizar las labores de pruebas de una manera eficiente, o bien un conjunto reducido de testers experimentados que lleven la búsqueda de fallos con la metodología con la que están habituados trabajar y en el menor tiempo posible.

Otra práctica habitual (más informal pero bastante difundida) es distribuir una versión beta y que los propios usuarios sean los que encuentren los fallos y los reporten. Aunque esto conlleva desventajas, como la complejidad para que los usuarios reporten de manera adecuada el fallo (descripción del entorno, pruebas de concepto...) o simplemente a la pérdida de profesionalidad de todo el proceso en sí. Además, los betatesters, pueden pasar por alto test importantes como "pruebas de estrés", "test unitarios"..., que detectan fallos a nivel modular.

Una recomendación importante es que los desarrolladores de una aplicación no pueden ser a su vez testers de esa aplicación. Ser juez y parte hace que se pierda objetividad debido a la presunción de que su desarrollo es totalmente fiable, a la consideración de que determinados elementos no son relevantes a verificar, etc. Por ello es necesario que el equipo de testeo se encuentre totalmente desligado del equipo de programación. En este sentido, surge también una alternativa bastante interesante que es la realización de testeo cruzado entre equipos de trabajo, es decir, un equipo de desarrollo se encarga de realizar las pruebas sobre el software creado por otro equipo y viceversa. Aunque según disponibilidad de personal, siempre será mejor un equipo especializado en realizar estas labores.

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.


Fuente: http://blog.elevenpaths.com/2014/09/qa-pruebas-para-asegurar-la-calidad-del.html