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

miércoles, 3 de septiembre de 2014

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.

En las siguientes entregas se irán comentando más y mejor las pruebas a realizar y su importancia.

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

Jhonattan Fiestas
jhonattan.fiestas@11paths.com

3 comentarios:

  1. HAY LEGISLACION AL RESPECTO ES DECIR SOBRE LA OBLIGACION DE HACER PRUEBAS PARA ASEGURAR LA CALIDAD DEL SOFTWARE?

    ResponderEliminar