¿Deben los probadores automatizar su trabajo?

Estamos tratando de configurar nuestro proceso de prueba. Nos preguntamos si nuestros evaluadores deberían desarrollar pruebas de regresión automatizadas, o si los desarrolladores deberían hacerlo.

¿Y qué hay de otros tipos de pruebas automatizadas? ¿Deberían los probadores desarrollarlos?

Digo que los probadores deberían desarrollar las pruebas automatizadas: tienen el enfoque del "par de ojos externos" del código y detectarán (¿o debería ser solo 'puede'?) Detectar errores en los que no haya pensado, y mucho menos manejar .

Además, su comprensión de los requisitos funcionales puede ser de mayor nivel que la comprensión de los desarrolladores, por lo que se encuentra entre el conocimiento incondicional de bajo nivel del programador, pero no tan alto como el de BA.

Si puedes automatizarlo, automatízalo.

Deje a los evaluadores libres para encontrar las cosas que no puede automatizar. Y cuando encuentren un nuevo error, si puede automatizarse y agregarse a las pruebas automatizadas, agréguelo.

En mi opinión, los desarrolladores y evaluadores son responsables de los diferentes tipos de pruebas.

El desarrollador, mientras escribe la lógica, también debe escribir pruebas de unidad e integración. Esto permitirá al desarrollador asegurarse de que lo que han escrito hasta ahora funciona según lo previsto. Además, estas pruebas seguirán existiendo para que el desarrollador las ejecute cuando realicen cambios futuros. Una vez que se completa la lógica, el desarrollador puede estar seguro de que lo que está escrito funciona a medida que comprende las especificaciones y puede pasar al probador.

El probador a partir de este punto debe ser responsable de escribir pruebas de todo el sistema que aseguren que la lógica de negocios funcione según lo previsto.

Dado que los desarrolladores a menudo están demasiado unidos al código, los probadores deberían poder ayudar a limpiar las pruebas de los desarrolladores, pero no al revés.

En mi experiencia, la forma en que un probador configura y ejecuta un caso de prueba automáticamente difiere de la forma en que lo hace un desarrollador. Los evaluadores pensarán más sobre cómo obtener la mayor cantidad de información del caso de prueba, cómo ejecutar pruebas rápidamente, cómo mantener las pruebas mantenibles, y así sucesivamente. Lo que es más importante, los evaluadores verán matices de cobertura de prueba que los desarrolladores perderán.

Si los recursos de desarrollo de prueba son bajos, los desarrolladores pueden ayudar, pero un probador debe revisar su trabajo cuidadosamente. Los desarrolladores deben trabajar en accesorios y herramientas de prueba antes de escribir casos de prueba reales, y los desarrolladores nunca deben escribir casos de prueba para su propio código. Hacer que los desarrolladores ayuden con las pruebas tiene ventajas: expone a los desarrolladores a otras partes del producto, y las pruebas pueden ayudarlos a convertirse en mejores desarrolladores. Sin embargo, así como el trabajo de un desarrollador junior nunca pasaría sin una revisión de código, el trabajo de control de calidad de un desarrollador debe obtener una revisión de control de calidad de alguien con más experiencia en pruebas.

Editado para agregar: soy una SDET con 5 años de experiencia. Trabajo con grandes desarrolladores con más de 10 años de experiencia cada uno, y últimamente he estado trabajando con ellos para superar un cuello de botella en las pruebas.

Una cosa que realmente me gustaría poder ver son herramientas de automatización sólidas para los probadores que les permitirán registrar efectivamente su progreso a través de un script de prueba y luego permitir que ese script se ejecute automáticamente en el futuro. Especialmente si esto también facilita que el mismo script se ejecute en diferentes versiones del sistema operativo sin que el probador tenga que pasar por todos ellos a mano.

Desafortunadamente, ciertamente para el producto en el que trabajo, ninguna de las herramientas en el mercado hace el trabajo. Pero vale la pena tener esto en cuenta y ver lo que está disponible en el mercado en caso de que haya algo que funcione para lo que está haciendo.

Una distinción crítica que es realmente importante aquí es la siguiente: ¿sus evaluadores simplemente están verificando o están probando ?

Esta publicación de blog de Michael Bolton lo explica mejor, pero en esencia: ¿buscan simplemente confirmar el comportamiento o buscan encontrar problemas con el sistema?

Creo que también es útil considerar los Cuadrantes de Pruebas Ágiles (Brian Marick los describió originalmente, pero los encontré en el libro "Pruebas Ágiles" de Lisa Crispin y Janet Gregory: incluso si no estás siguiendo una metodología de desarrollo Ágil, creo que La distinción entre las pruebas que critican el producto y las pruebas que respaldan al equipo, realmente vale la pena cuando se considera la automatización y se trata de desarrollar un plan para saber quién hace qué y por qué.

Por ejemplo, las comprobaciones de unidades escritas por los desarrolladores actúan como detectores de cambio, lo que le permite detectar regresiones temprano cuando se vuelven a ejecutar regularmente; estas son pruebas que respaldan al equipo. Las comprobaciones de regresión a nivel del sistema que están automatizadas para que puedan volver a ejecutarse regularmente y rápidamente también apoyan al equipo al detectar regresiones temprano y complementan las pruebas unitarias realizadas por los desarrolladores. Eso libera el tiempo de sus evaluadores para realizar pruebas que critican el producto, por ejemplo, pruebas exploratorias. O posiblemente aplicando algunas de las verificaciones automáticas para probar el producto.

La otra cosa que realmente me gusta de la presentación de Lisa Crispin que vinculé es que señala que la automatización también se puede usar para respaldar las pruebas manuales: crear datos de prueba, la automatización se usa para llevar un escenario al punto en el que desea centrarse hoy, para ejemplo.

Considerar estos dos artículos con suerte lo ayudará a analizar qué tipo de pruebas desea hacer, facilitará la selección de lo que podría ser adecuado para la automatización y descubrir qué partes de la automatización son más adecuadas para que las realicen los probadores, y cuáles por los desarrolladores