¿Cómo lidiar con la mentalidad de "Automatización es fácil"?

El título lo dice todo. Algunos empleados de nuestra empresa creen que las pruebas automatizadas son "fáciles" y que "debería llevar un día" escribir conjuntos de pruebas COM y UI. ¿Qué se puede hacer para contrarrestar esto?

Nota: no estoy preguntando sobre cómo promover la automatización. Ese no es el problema. Las pruebas y procesos automatizados se promueven y solicitan todo el tiempo aquí. El problema es que algunas personas no entienden que la automatización no es "fácil" ni "rápida".

La próxima vez que reciba una solicitud, intente dividir la mayor parte del proceso de automatización en fragmentos de tiempo. Creo que cuando se dan cuenta de que lleva 5 minutos por campo de texto o presionar un botón, comienzan a darse cuenta de cuánto tiempo lleva.

Por ejemplo, tal vez por qué lleva tanto tiempo es que comienzan a introducir interdependencia entre los campos: por ejemplo, solo les permite continuar si se completa, pero no si esto no es así, excepto cuando ...

Trate de educarlos sobre POR QUÉ lleva tanto tiempo, pero no tanto como perderlos a través del proceso de "aprendizaje".

En mis roles me he encontrado con muchas personas "x es fácil", especialmente en proyectos de desarrollo. En mi opinión, hay tres razones para esto:

1) Realmente no entienden de qué están hablando, pero les gusta mucho sonar como lo hacen.

2) Han leído un par de libros y piensan que saben de lo que están hablando

3) Por último, la gente supone que porque una computadora está haciendo las pruebas rápidamente, porque las computadoras son rápidas.

La única forma segura de combatir esto es involucrar a los usuarios de manera regular, las estrategias de comunicación para los proyectos son clave, sin duda, explicar los entresijos de las pruebas automatizadas a los usuarios no técnicos será inútil, pero haciéndolos conscientes de los procesos involucrados puede ser beneficioso Puede hacerlo a través de documentación, talleres o simplemente un chat amigable la próxima vez que pase.

Incluso he visto un BA soltero que es el más ruidoso de estas personas "x es fácil" y simplemente los invito a pasar un día en el departamento, con el pensamiento de que o bien se irán entendiendo más sobre lo que haces O lo harán simplemente salgo pensando "Dios, realmente no sé de qué estoy hablando, creo que estaba equivocado".

El software es el negocio de automatizar cosas.

Escribimos software para facilitarnos las tareas aburridas, repetitivas y laboriosas. Escribimos software para automatizar la realización de informes, la recopilación de datos, la comunicación con otros, etc. Escribir pruebas automatizadas es realmente solo escribir software para asegurarnos de que nuestro otro software funcione de la manera que esperamos.

Si sus compañeros de trabajo entienden que escribir software es difícil y lleva tiempo, debería ser bastante fácil mostrarles que escribir más software debería ser difícil y tomar tiempo. Sería bueno obtener todos los beneficios de la automatización de forma gratuita, pero, como siempre, tenemos que poner el trabajo por adelantado para obtener los beneficios más adelante.

Si no entienden eso, debe trabajar para enseñarles eso o pulir su currículum.

La mayoría de los empleados pasan su tiempo en la parte "frontal" (cliente-jefe-parte interesada) de la empresa o en la "parte posterior" (donde se realiza el trabajo "real"). Estas dos funciones son diferentes, casi opuestas. (Y muy pocas personas han trabajado en ambos). Como resultado, a menudo hay malentendidos entre los dos grupos.

La mejor manera de educar, por ejemplo, a las personas "de frente", es hacer que una o algunas de ellas pasen un día en la "parte de atrás". Si completaran "Un día en la vida de ...", tendrían una idea más realista de lo que se puede hacer en un día y por qué lleva más tiempo y esfuerzo ejecutar pruebas automatizadas. Del mismo modo, las personas "de vuelta" podrían beneficiarse de uno o dos días en el "frente".

En "Cómo ser rico", John Paul Getty (un magnate de su tiempo) abogó por ese "entrenamiento cruzado". En su opinión, un vendedor que pasara un tiempo en la línea de ensamblaje donde se fabricaba el producto haría un trabajo de venta mucho mejor, y del mismo modo un ingeniero que pasara un día con los clientes haría un mejor trabajo de "depuración".

El problema es que algunas personas no entienden que la automatización no es "fácil" ni "rápida".

No estoy de acuerdo con tu premisa aquí.

Soy un gran defensor de las pruebas automatizadas, sin importar si se trata de pruebas unitarias, pruebas de integración o pruebas de IU. Hay muchas herramientas excelentes disponibles para implementar pruebas automatizadas.

Comparemos las pruebas automatizadas con las pruebas manuales basadas en el siguiente ejemplo:

En una aplicación web, pruebe la funcionalidad "Cambiar contraseña" de un usuario existente utilizando un navegador.

Prueba manual :

• Inicie la aplicación web
• Abrir el navegador
• Maldición, hay un error. ¿Por qué? ¡Oh, olvidé iniciar la base de datos!
• Ok, apaga la aplicación web
• Inicia la base de datos
• Inicie la aplicación web
• Actualizar el navegador
• Hmm, ¿cuál era la contraseña de nuestro usuario de prueba nuevamente?
• Echando un vistazo a la base de datos
• ¡Oh, la tabla de usuarios está vacía! Tengo que crear un nuevo usuario.
• Registre un nuevo usuario en la aplicación web: ingresando nombre de usuario, contraseña, dirección de correo electrónico
• ¿Por qué no puedo iniciar sesión con mi nuevo usuario? ¡Necesito hacer clic en el enlace de confirmación en el correo electrónico!
• Bueno, le he dado al usuario un correo electrónico como "test@example.com". Vayamos a la base de datos y configuremos la columna "activa" en "Sí".
• Iniciar sesión. ¡Esta vez funciona!
• Hmm, ¿qué quería probar de nuevo ...?

¿Fácil? Realmente no. Hay muchas trampas posibles en el proceso.

¿Rápido? No. El trabajo manual lleva tiempo.

Ahora, intentemos escribir una prueba automatizada :

• Necesitamos encontrar herramientas para nuestro lenguaje de programación para iniciar automáticamente la base de datos y el servidor web. La investigación e implementación lleva tiempo.
• La base de datos debe estar limpia cuando comience la prueba. Crear los guiones lleva tiempo.
• Necesitamos escribir la prueba. Como necesitamos un usuario, también debemos registrar uno nuevo para nuestra prueba. Requiere tiempo.
• Finalmente, podemos escribir lo que queremos probar: cambiar la contraseña del usuario. Con nuestra herramienta de prueba de navegador, esto se hace bastante rápido en comparación con las tareas anteriores.

¿Fácil? ¡No! Necesitábamos investigar las herramientas, implementarlas, corregir algunos errores en nuestras pruebas.

¿Rápido? ¡No! Lleva incluso más tiempo que hacer una prueba manual.

Pero, hay una gran diferencia aquí: para futuras pruebas, solo necesita escribir la prueba en sí , el último punto en la lista, que se hizo comparable rápidamente. No es necesario realizar todas las investigaciones y guiones de inicio para realizar más pruebas.

Y después de haber escrito el examen, puede comenzarlo fácilmente. En unos pocos segundos (o tal vez minutos, si el inicio de la base de datos y la aplicación web tarda mucho), verá si la rutina "Cambiar contraseña" funciona o no. Si hay un error, corríjalo y vuelva a ejecutar la prueba; verá de inmediato si el error está solucionado. Rápido y fácil .

Escribir pruebas automatizadas no es fácil ni rápido en primer lugar, pero ejecutarlas sí lo es.

Y este es el punto donde vuelve el tiempo invertido.

Las pruebas en general no son fáciles, y tampoco deberían serlo. Si Boeing o Mercedes no probaran sus productos tan rigurosamente como lo hacen, entonces estarían en bancarrota debido a demandas judiciales o cerrarían sus negocios por vender artículos de tan baja calidad. ¿Conducirías un automóvil a 70 millas por hora sabiendo que el volante puede o no romperse?

Es muy difícil sugerir formas de lidiar con la mentalidad sin comprender quiénes son esas personas o sus razones. La mayoría de los gerentes y directores piensan en los costos y son juzgados por lo que se produce. El uso de este criterio hace que sea muy difícil para ellos justificar pasar tiempo en las pruebas. Si este es su caso, deberá encontrar formas de presentar esta tarea como beneficiosa a largo plazo, lo cual, por supuesto, lo es.

El hecho de que el software no sea tangible no significa que podamos escapar sin pensar en las implicaciones de que los sistemas que construimos no funcionan. Apuesto a que Amazon tiene pruebas automatizadas y apuesto a que hay personas que conocen muy bien las implicaciones de costo de la falla de sus sitios web / servicios.

2 +2 = 4 es uno de los códigos más simples que todos entienden; Y puedes ver cómo se entiende fácilmente. Pero esto no significa que sea una ecuación "fácil". El nivel de abstracción que se necesita para alcanzar la ecuación simple es bastante complejo. Lo mismo sucede con el software y las metodologías de prueba de software. El nivel de abstracción que requiere un fragmento de código requiere mucho trabajo.

Es cierto que una buena práctica lleva a reutilizar clases y objetos, pero igualmente, para alcanzar este estado es necesario invertir tiempo y esfuerzo .

Hay dos lados en esta pregunta.

Por su parte, parece pensar que está haciendo un buen trabajo y que el grupo "La automatización es fácil" no sabe de qué están hablando.

Por su parte, por lo que dices, ven que las pruebas automatizadas toman (en su opinión) mucho tiempo para producir.

Desde esta distancia, con lo poco que tenemos que seguir, no sabemos quién tiene "razón", o si alguien tiene "razón".

Cómo lidiar con la automatización es una mentalidad fácil

Háblales. Pida honestamente sus ideas sobre cómo se puede hacer mejor. Involúcralos y participa Es la única forma de averiguar si realmente tienen algo positivo que ofrecer. Tal vez tienen algunas contribuciones valiosas para hacer, y puede lograr ganar / ganar.

Si no tienen una idea real de cómo funciona la programación y las pruebas automatizadas, o ideas realistas sobre cómo mejorar la productividad, entonces, habiéndolos involucrado positivamente, puede mostrar cómo se hace y dónde pasa el tiempo. Sea humilde y positivo, agradeciéndoles sus aportes / ideas. Piense en lo que han dicho: tal vez sus sugerencias desencadenen una forma diferente de pensar para usted. Si es así, deles su opinión. Al ser humilde y positivo, también puede hacer que gane / gane.

Antes de hablar con ellos, piense en cómo construye, ejecuta y administra sus pruebas. ¿Qué marco (s) estás usando? ¿Hay otros que podrían ser mejores? ¿Tiene un estándar "estándar" que adapte? ¿Podría la construcción de las pruebas ser más automatizada? ¿Qué te detiene?