A pesar del hecho de que las tecnologías de pruebas unitarias han existido durante 30 años (Kent Beck escribió el artículo "Pruebas simples de Smalltalk: con patrones" en 1989), no todos los programadores poseen esta tecnología y no todas las compañías hacen que las pruebas automáticas sean parte de su cultura corporativa. . Incluso a pesar de las ventajas obvias de las pruebas automáticas, la resistencia conductual sigue siendo bastante fuerte. Quien haya intentado implementar pruebas automatizadas sabe que siempre hay alguna razón por la cual esto no se pudo hacer.
Desde mi experiencia personal en la implementación de métodos de programación confiables en mi empresa, en las empresas que consulté, comunicándome en conferencias y también de fuentes disponibles públicamente, he formulado objeciones y resistencias típicas que impiden la implementación de una cultura de pruebas automáticas.
Agrupe todas las objeciones en una pirámide de programación confiable, que incluye cuatro niveles:
- La cultura profesional (el nivel más alto, la base de una programación confiable) es un conjunto de normas, reglas no escritas, creencias de los empleados que lo guían en su trabajo. Por ejemplo: "Enviar código descubierto por pruebas al repositorio es malo", "Es una pena silenciar los errores encontrados en el código".
- La administración es los procedimientos, políticas, reglas adoptadas por la organización, así como la voluntad (decisión) de los líderes. Por ejemplo: “Cada función de aplicación desarrollada debe pasar un código de revisión. ¡Sin excepciones!
- Los métodos son enfoques científicos, métodos para resolver un problema particular. Por ejemplo: "Si la función de la aplicación es difícil de probar, debe aumentar la capacidad de prueba de la aplicación aplicando la plantilla de Inyección de dependencias".
- Las tecnologías (el nivel más bajo) son lenguajes de programación, bibliotecas, marcos, herramientas. Por ejemplo, JUnit, Selenium, XCTest, etc.
¿Por qué es necesaria tal división? Porque el problema de un nivel se resuelve con métodos del mismo nivel o con métodos de un nivel superior. Por ejemplo, si no es habitual que una organización escriba pruebas automáticas (el problema de la cultura profesional), entonces este problema no puede resolverse describiendo el proceso comercial de prueba en detalle (nivel "gestión") o instalando un marco moderno (nivel "tecnología"). Le garantizo que en una semana nadie redactará pruebas, a pesar del proceso comercial aprobado.
Objeciones culturales
“Mis programas no se rompen. No veo la necesidad de realizar pruebas ".
Escuché esta declaración de principiantes o programadores demasiado confiados.
Por supuesto, una vez que una función escrita no puede romperse por sí sola. Pero aquí es importante entender que con el tiempo, el programa puede requerir soporte, la introducción de nuevas funciones o adiciones a las funciones existentes. La complejidad de los programas (el número de clases y las dependencias entre ellos) es bastante grande y, finalmente, después de realizar otra función nueva o mejorar una existente, un error ocurrirá tarde o temprano. Una prueba automática detectaría tal regresión.
Además, a menudo tal objeción puede ser escuchada por programadores novatos que no tienen un concepto de prueba. Por ejemplo, solo los bloqueos se consideran un desglose, no errores funcionales.
En una de las entrevistas que realicé, tuvo lugar el siguiente diálogo:
- ¿Tienes las habilidades de prueba automática?
- No, escribí programas simples, no había nada que romper.
- ¿Cuál es tu motivación para cambiar de trabajo?
- Quiero escribir aplicaciones complejas.
Sé muy bien cómo termina esto. Se confía en que el programador desarrollará un programa más complejo, pero no conoce los métodos de prueba automática, no puede probar la aplicación cualitativamente y no puede hacer frente a la escala del proyecto, lo que provocará la interrupción del proyecto, el desbordamiento del costo y la pérdida de reputación. Porque personalmente gestioné proyectos, donde no pude hacer frente a la escala del proyecto y fracasé precisamente por la falta de pruebas automáticas.
Renuencia a asumir la responsabilidad de la calidad del código, de las pruebas.
Las pruebas automatizadas son la única fuente de información operativa y objetiva sobre la verdadera calidad de un producto de software. En otras palabras, el programador siempre tiene un supervisor a sus espaldas, que puede informar a la gerencia en cualquier momento sobre qué tan bien el programador hace su trabajo. Las pruebas automatizadas le permiten vincular la productividad del trabajo no con tickets cerrados en Jira, sino con la verdadera calidad del producto de software. Y aquí ya debe pensar en cómo escribir de manera confiable para que cada próximo cambio en el código no rompa las funciones existentes. Para que cada nueva función funcione no solo en el script, cuando todo está bien, sino que también procesa correctamente los errores.
La responsabilidad es el compromiso voluntario para garantizar un resultado positivo del trabajo. El empleado acepta esta obligación en virtud de su carácter y educación. Desafortunadamente, debido a la crisis cultural y profesional, no todos los programadores están listos para asumir tales obligaciones.
"Escribe ahora mismo sin errores"
Las personas que no están muy familiarizadas con el funcionamiento del desarrollo de software pueden tener una actitud negativa hacia los desarrolladores que mencionan algún tipo de error.
- Cubramos la aplicación con pruebas automáticas.
- por qué?
- Para asegurarse de que todo funciona correctamente y no hay errores.
- ¿Escribes con errores? ¿Tienes bajas calificaciones? Escribe de inmediato sin errores.
"Sí, pero todos cometen errores ..."
- ¡Pero la compañía XYZ le dijo a un amigo que tienen los mejores programadores que escriben sin errores!
Por lo tanto, el desarrollo de pruebas es difícil de "vender" a clientes que no son expertos en tecnología. Como resultado, la administración se ve obligada a desarrollar un proyecto sin pruebas automáticas, lo que conduce a problemas bien conocidos.
Objeciones de la gerencia
“Con las pruebas, escribir un programa es el doble de largo. No cumpliremos los plazos ".
A primera vista, esta tesis parece justa. Es realmente necesario pasar tiempo del programador escribiendo pruebas. Pero los programadores y la administración no tienen en cuenta que el tiempo total de desarrollo del producto incluye no solo la programación, sino también la depuración y el soporte, así como el enorme costo de las pruebas de regresión manual después de hacer correcciones.
Las pruebas automatizadas tienen varias funciones:
- Comprobando
1.1. Las pruebas verifican que el objeto de prueba funciona correctamente.
1.2. Las pruebas verifican la calidad del trabajo del programador: si la tarea está resuelta, si hay algún efecto secundario en forma de regresión. - Diagnóstico Las pruebas de diagnóstico pueden reducir significativamente el tiempo de búsqueda de un defecto. Las pruebas le permiten determinar la ubicación del error con precisión para la clase y el método, y en ocasiones precisa para la línea de código.
- Automatización Las pruebas le permiten ingresar rápida y fácilmente el objeto de prueba en el estado deseado para la depuración.
- Documentando
4.1. Las pruebas de aceptación registran los requisitos del cliente para el producto que se está desarrollando.
4.2. Las pruebas muestran ejemplos del uso del componente desarrollado, reduciendo así el tiempo que otro programador dedica al estudio del trabajo del sistema.
En una de las organizaciones que consulté, el gerente se resistió a introducir una cultura de pruebas automáticas:
- Pero después de todo, ¡escribir pruebas por mucho tiempo! ¡No cumpliremos los plazos!
- ¿Tiene errores que ha estado buscando y corrigiendo durante mucho tiempo?
- Sí, hay algunos.
- ¿Cuál es el caso más difícil?
- Buscamos un error durante 80 horas.
- 80 horas son dos semanas de trabajo del programador. Si incluso pasó una semana entera probando la automatización, ¡le ahorraría meses diagnosticando y depurando su aplicación!
Nuestra organización tiene el postulado: "¡Con las pruebas, escribir un programa es el doble de rápido!" y este postulado no se discute. Solo se discute el coeficiente 2, a veces hay 3 y 4. Y algunos proyectos simplemente no pueden completarse sin pruebas automáticas competentes (ver el proyecto abrumado).
"Ya tenemos un departamento de pruebas manuales, déjenlos probar".
A primera vista, la separación de especializaciones en pruebas y programación parece lógica.
Pero veamos las desventajas de las pruebas manuales:
- Es muy caro
- Toma mucho tiempo Por ejemplo: el script de prueba para el probador de aplicaciones móviles "Cine en línea" hace 40 horas. ¡Y esto es solo para una plataforma! Si necesita probar la aplicación en iPhone, iPad, Apple TV, Android, Fire TV, entonces necesita pasar 40 × 6 = 240 horas de tiempo de trabajo, esto es un mes y medio, lo cual es inaceptable para ciclos cortos de desarrollo.
- Las pruebas manuales están sujetas a errores humanos comunes: no dan un resultado objetivo y verdadero.
Además, algunos tipos de pruebas no pueden realizarse dentro de un tiempo razonable, porque la cantidad de combinaciones de formatos y varios scripts de prueba es muy grande. Por ejemplo:
- Función para importar archivos CSV.
- Analizadores para documentos de texto.
- Instrumentos financieros
Método Nivel de objeciones
Ignorancia de los métodos de prueba automáticos.
Debido a la crisis en la educación, no hay disciplinas de pruebas automáticas en ninguna parte de las universidades. Hay muy pocos cursos de este tipo en las escuelas comerciales de TI. Y los cursos existentes son superficiales y de baja calidad. Por lo tanto, a menudo encuentro un estupor entre los programadores: no saben cómo probar aplicaciones no triviales (más difícil que 2 + 2 = 4).
De hecho, la ciencia de las pruebas es bastante extensa. Por ejemplo, no todos los programadores responderán de inmediato a las preguntas: a) ¿qué es la comprobabilidad? b) ¿Qué es la controlabilidad y la observabilidad? c) ¿qué patrones de diseño mejoran la capacidad de prueba de la aplicación? Y así sucesivamente.
Los programadores no saben lo que escriben, cómo se ve, qué funciones e interfaces serán.
Es muy difícil probar lo que no está claro como se ve. En otras palabras, sin los requisitos predefinidos para la aplicación, el programador no puede entender lo que se espera de él.
La peculiaridad de algunos proyectos es que se desarrollan utilizando la tecnología de Producto Mínimo Viable, que en otras palabras se puede describir de la siguiente manera: "Hagamos al menos algo por el tiempo mínimo y el presupuesto mínimo", y el cliente o la administración consideran al programador como analista, diseñador, arquitecto, programador y probador en una botella. Con este enfoque, se excluye la etapa formal de diseño de un sistema de software: la definición de lógica de negocios, dominio, interfaces de componentes, así como su organización interna de su relación entre ellos. No hay una arquitectura formalizada, ni interfaces, ni procesos comerciales prescritos; no está claro qué probar, a través de qué interfaces y cuál es el resultado esperado.
Código inapropiado
La capacidad de prueba es una propiedad del proyecto que dice con qué facilidad se puede probar. La idoneidad de la prueba está determinada por otras dos propiedades: controlabilidad y observabilidad. Capacidad de administración: una propiedad que determina cuán fácil es ingresar una aplicación en el estado deseado para la prueba (cumplir con las condiciones previas). Observabilidad: con qué facilidad es posible considerar el estado después de la prueba, compárelo con el esperado.
Por ejemplo, la autenticación de dos factores usando SMS es muy difícil de probar automáticamente, porque la función de recibir SMS está fuera del alcance del entorno de prueba automatizado. Tal sistema no es adecuado.
Frente a un sistema inadecuado, el programador se da por vencido y evita probar dicho sistema.
Preparación de datos de prueba.
Una de las resistencias obvias es la preparación de datos y estándares de prueba. Por ejemplo: el estado inicial de la base de datos en la que se realiza la prueba. La preparación de los datos de la prueba puede llevar mucho tiempo y trabajo de rutina, por lo que este trabajo se considera ingrato y poco interesante entre los programadores.
Solución:
- desarrollo de valores de referencia y ejemplos en la etapa de desarrollo de las pruebas de aceptación: también ayudarán a resolver conflictos con el cliente en la etapa de aceptación del trabajo;
- desarrollo de valores de referencia en la etapa de diseño del sistema. Por ejemplo, las solicitudes y respuestas HTTP estándar ayudarán a integrar más fácilmente al cliente y al servidor;
- Desarrollo de procedimientos especiales para el ensamblaje de bases de datos, en los cuales el estado requerido de la base de datos se crea automáticamente y no manualmente
- uso de la plantilla Object Mother [Fowler, Schuh, Peter y Stephanie Punke. "Facilitando la creación de objetos de prueba en XP". Universo XP. 2003], que ayuda a asignar e inicializar fácilmente objetos en el estado requerido.
Servicio de pruebas.
Durante el desarrollo de un proyecto, los requisitos para el mismo (aclaración, cambio) pueden cambiar. O puede ocurrir una refactorización interna, lo que conducirá a un cambio en las interfaces de clase. Con el cambio en los requisitos, los criterios de aceptación de una función particular también cambiarán, y con ellos las pruebas. En algún momento, el programador puede negarse a realizar las pruebas, es decir, mantenerlas actualizadas.
Solución:
- utilizando la plantilla de "adaptador" para desacoplar la lógica de la prueba de la interfaz que está probando;
- uso de pruebas de alto nivel (pepinillo, pepino, dado cuando entonces);
- ver solución a la resistencia "preparación de datos de prueba".
Conclusión
No hay duda de que el software debe ser confiable: superar las expectativas del cliente. Las pruebas automatizadas no son el único, sino un componente importante en el desarrollo de software confiable.
Formulé objeciones y obstáculos típicos para la implementación de las pruebas automáticas, que personalmente encontré en mi organización, así como en aquellas organizaciones que consulté.
El artículo describe solo problemas y apenas toca formas de resolverlos. En general, la estrategia para resolver estos problemas me parece así:
- Formación y promoción de una nueva cultura de diseño de TI, que es la fiabilidad, el orgullo y la responsabilidad personal por el resultado.
- Desarrollo de nuevos estándares altos para pruebas de código.
- Desarrollo e implementación de cursos de capacitación.
- La introducción de la motivación en la carrera de programadores y gerentes, vinculada a la calidad de los productos de software que se están desarrollando, así como a las habilidades de las pruebas automáticas.
Lo más importante que logré entender es que los problemas están en diferentes niveles: tecnológico, metodológico, gerencial y cultural. Y deben abordarse en los niveles apropiados. Es muy difícil implementar pruebas automatizadas si el programador no está capacitado en métodos de diseño adecuados para las pruebas o si la administración no admite una cultura de programación confiable en la organización.
Le agradeceré ejemplos de su práctica de cuán fácil o difícil fue implementar pruebas automatizadas en su organización. ¿Qué problemas enfrentaste? ¿Cómo los resolviste?