banner

Capítulo 1: ¿Automatizar pruebas o no? Esa es la cuestión

(Free image by Alex Knight on Unsplash)


Para motivarte a responder de forma afirmativa/positiva la pregunta en el título de este capítulo, te invitamos a revisar un repositorio de post-mortems mantenido por Dan Luu en GitHub.

Esta lista de post-mortems recopila y describe las causas de fallas conocidas en diversos sistemas que usamos diariamente. La lista de fallas es variada e involucra aspectos diferentes al software (por ejemplo hardware), con lo cual se convierte en un material súper útil y revelador: no hay receta secreta para evitar problemas en sistemas de software. Sin embargo, lo que si podemos hacer es reducir la probabilidad de ocurrencia de esos problemas usando diferentes técnicas para prevención, detección, y manejo de fallos. Un grupo de esos técnicas son las pruebas, y en particular las pruebas (semi) automáticas.

Para usar pruebas (semi) automáticas, primero hay que entender que ¡ los sistemas de software modernos son complejos... ultra complejos... ultra mega complejos !, y como tal tienen comportamientos emergentes inesperados en sus componentes (hardware, software, usuarios, comunicaciones, etc.) que no se pueden predecir (ni contratando al indio amazónico). Una falla en la base de datos, una regla de negocio mal codificada con un "corner case" que el desarrollador nunca esperaba, un bloque try/catch vacío que tenía probabilidad muy baja de "agarrar" un error, una falla en una pieza de hardware, son eventos más comunes de los que uno cree. Súmale a eso los ambientes multi-dispositivo de hoy, la fragmentación inherente a dispositivos móviles, y los diferentes contextos en los que las personas usan aplicaciones hoy en día. Es imposible probar todas las posibles de combinaciones de ambientes, contextos, condiciones de ejecución, etc., de forma manual. También es imposible probar todas esas combinaciones automatizando pruebas en un tiempo factible. pero, sin lugar a duda, automatizando pruebas se pueden utilizar de forma más eficiente los recursos disponibles; hay tareas que una máquina (o varias en paralelo) puede hacer más rápido que un tester.

Al conjunto de todas las combinaciones de contexto, hardware, entradas, estados, etc. de una aplicación bajo pruebas se le conoce como espacio de pruebas.

Tip "motivador": Lamentamos decirlo, pero, NO hay forma de asegurar que una aplicación de software esté libre de errores. Los teóricos y practicantes de los métodos formales aseguran que las aplicaciones desarrolladas con este estilo pueden ser "verificadas" antes de ser desplegadas en producción, y esto es totalmente cierto; sin embargo, los métodos formales son usados en contextos y aplicaciones de misión crítica donde el costo de una falla es extremadamente alto a tal punto que un error puede afectar la vida o salud de los humanos. Por eso, los sistemas de software de misión crítica son desarrollado con métodos formales, con altos estándares de control de calidad, y con altos presupuestos para los procesos de pruebas; desafortunadamente, hasta en las mejores familias pasan los problemas, como en el caso de la nave observadora del clima en marte que falló en pleno atterizaje por problemas de conversión entre sistemas métricos .

El espacio de pruebas de una aplicación moderna es GIGANTEZCO, y la única forma de reducirlo, es haciendo pruebas de manera continua y eficiente. Para esto, en este primer capítulo hablaremos acerca de los conceptos básicos de pruebas y la necesidad de establecer una estrategia de pruebas como factor de éxito en los procesos de pruebas. El mensaje final aquí es, ¿por qué no hacer uso de técnicas que permitar hacer procesos de pruebas más eficientes? ¿que tal si no atrevernos a user pruebas (semi)automáticas?







results matching ""

    No results matching ""