¿Deben los probadores automatizar su trabajo?

9

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?

testing automation

— Jader Dias
fuente

Simplemente comience a llamarlos "desarrolladores en prueba" y la ambigüedad se resuelve.

— Edward Strange

@Crazy ¿Pero no es más costoso tener 2 equipos de desarrolladores?

— Jader Dias

55

¿Más caro que qué? ¿Vender un producto mal probado? ¿Cuello de botella en el proceso de desarrollo porque los desarrolladores están escribiendo pruebas en lugar de producto?

— Edward Strange

12

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.

— James Love
fuente

¿Pero no podrían simplemente pedirles a los desarrolladores que escriban ese caso de prueba?

— Jader Dias

1

Por las razones que dije anteriormente, los desarrolladores sabrían mucho más acerca de la implementación interna y abordarían el software de manera diferente a la que proviene del exterior.

— James Love

No puedo ver cómo la implementación de un caso de prueba podría diferir de una persona a otra.

— Jader Dias

55

@Jader, desea que diferentes personas escriban las pruebas automatizadas que escribieron el código original. De lo contrario, las pruebas estarán sesgadas para funcionar con el código tal como fue escrito.

— Marcie

3

Durante las últimas semanas, tuve un desarrollador que me ayudó a escribir accesorios para su código. Es un muy buen desarrollador, pero definitivamente pierde algunos matices de cobertura para su código solo porque no piensa en la cobertura en profundidad de forma regular. Si los desarrolladores ayudan con las pruebas, haga que un probador revise su trabajo.

— Ethel Evans

11

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.

— CaffGeek
fuente

Pero, ¿por qué deberían hacerlo y no solo los desarrolladores?

— Jader Dias

@JaderDias, como se ha mencionado, los evaluadores no deberían tener prejuicios preconcebidos sobre el código que intentan probar

— CaffGeek

3

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.

— Taylor Price
fuente

¿Tienes curiosidad por tu última oración? ¿No crees que los desarrolladores pueden contribuir a las pruebas funcionales? ¿Qué sucede si los evaluadores describen la estructura de la prueba e identifican los casos de prueba y los desarrolladores solo ayudan con la implementación?

— Miss Cellanie

1

Creo que me estoy imaginando probadores que son desarrolladores por derecho propio y pueden escribir sus propias pruebas. Su trabajo consistiría en recorrer los requisitos y hablar con el usuario para identificar los casos de prueba y luego escribir los casos. Esto deja a los desarrolladores lógicos libres de estar cerca de la lógica a medida que la escriben. También deja a los evaluadores lo suficientemente alejados de "poseer" la lógica de que pueden intentar romperlo con objetividad y sin remordimiento.

— Taylor Price

2

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.

— Ethel Evans
fuente

0

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.

— glenatron
fuente

Visual Studio 2010 (Premium o Ultimate, no recuerdo cuál) tiene algo que registra las acciones de la pantalla para automatizar las pruebas de IU. Vi una demostración de esto por Andrew Woodward MVP cuando hacía un show de UI Testing SharePoint, cosas increíblemente.

— James Love

Grabar y reproducir correctamente tiene una reputación bastante pobre. Tiende a ser bastante frágil y difícil de mantener. Sí, como un rápido y sucio "Tengo que ejecutar esto en 4 centros de datos diferentes, no quiero guardarlo para uso futuro", está bien, pero es horrible de mantener porque terminas con toneladas de repetición. Un pequeño elemento cambia, y de repente tienes que actualizar 100 pruebas. Doloroso. Tampoco reemplaza de ninguna manera la prueba manual, que tiende a diseñarse asumiendo que un humano notará todas esas otras cosas que no verificó explícitamente.

— testerab

Lo que sería bastante dulce sería algo que podría llevar las cosas a un nivel ligeramente más bajo que mover el puntero y hacer clic con el mouse, para que realmente registres en qué botón se hizo clic en lugar de dónde ocurrió el clic. Eso haría que este tipo de pruebas sea más resistente y práctico. Cuando necesite ejecutar cada script en, por ejemplo, nueve versiones diferentes de Windows, es una pesadilla tener que hacerlo manualmente en todas ellas.

— glenatron

Identificar el botón por id en lugar de ubicación es perfectamente posible con algunas herramientas. Lamentablemente, grabar y reproducir scripts hechos de esa manera TODAVÍA es horrible de mantener, no resuelve el problema de la repetición. No creo que haya que alejarse de la necesidad de diseñar su automatización de prueba con cuidado, si realmente desea mantener algún script o crear más de una docena de ellos. ¿Has pensado en usar algo basado en palabras clave como Robot Framework junto con Auto-It?

— testerab

0

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

— testerab
fuente