¿Deberíamos tener un probador dedicado en el equipo o las pruebas son responsabilidad mutua del equipo de desarrollo?

Actualmente tenemos varios equipos Scrum con 3 a 6 desarrolladores y 1 probador dedicado en cada equipo.

¿Deberíamos tener un equipo de scrum como este O tener todos los desarrolladores y ellos pueden compartir la responsabilidad de las pruebas mutuamente?

¿Está relacionada esta opinión o es posible proporcionar una respuesta autorizada?

Respuestas (4)

En un equipo Scrum es mejor distinguir entre roles y capacidades .

Cada equipo de Scrum necesita una capacidad de prueba , pero no necesariamente necesita roles de probador.

Todo el equipo de Scrum asume la responsabilidad de la calidad. Esto significa más que solo probar, también significa:

  • Pruebas de regresión automatizadas
  • Mantener la calidad del código
  • Uso de integración continua
  • Prueba exploratoria

Hay habilidades indudables para ser un buen probador y algunos serán mejores que otros. Sin embargo, podemos buscar compartir este conocimiento con el equipo de Scrum mediante la tutoría y la capacitación. Es por eso que hablamos de tener perfiles de habilidades en forma de T en un equipo Scrum.

Buen artículo. Entonces, ¿sugiere tener un probador con un conocimiento profundo de varios métodos de prueba y otros desarrolladores para aprender de ellos o ayudarlos?
Una mezcla de ambos. Recuerde que habrá momentos en los que el evaluador no esté disponible (vacaciones, enfermedad), por lo que vale la pena transferir la mayor cantidad de conocimiento posible. Pero si su probador tiene talento para encontrar problemas, busque el equipo para apoyarlo cuando sea posible.

Si bien es importante compartir la responsabilidad de las pruebas en todo el equipo, los equipos ágiles aún necesitan evaluadores dedicados, especialmente ahora con enfoques más amplios en la automatización. No tener una persona dedicada y centrada únicamente en la calidad podría significar un desastre para su equipo.

Estoy de acuerdo en que la automatización debe ser el foco. Pero, ¿cuál podría ser el inconveniente de hacer que los desarrolladores también sean responsables de las pruebas de automatización?
La desventaja es que los está comprometiendo a mantener activos que no hacen nada para mejorar y hacer crecer el producto. La automatización es excelente, pero no agrega nada a la experiencia del cliente frontal. Hacer que los desarrolladores sean responsables de todos estos activos parece una exageración. Y nuevamente, la cobertura de código es algo complicado, especialmente cuando tiene el escenario de 'guardias que protegen a los guardias', y lo más probable es que vea una caída en la calidad de la prueba.
Lo que también significa una disminución en el ROI en su biblioteca de automatización, así como una disminución en la velocidad de desarrollo de funciones. Recuerde, los desarrolladores se preocupan principalmente por una cosa: desarrollar el producto introduciendo pequeños cambios en el código base con regularidad. Los ingenieros de pruebas se preocupan principalmente por tener pruebas declarativas que validen los límites o "bordes" de un componente de software. Por ejemplo, cuando se ejecuta una prueba automatizada, se ejecutan la mayoría de las líneas de código en un módulo de software. Dejar esto en manos de los desarrolladores para garantizar la cobertura (n # de escenarios), no es la mejor idea
Entendido. Esta idea surgió porque no tenemos personas de calidad para las pruebas, por lo que hacer pruebas de automatización se está volviendo difícil. Así que pensamos en esta idea.
Bueno, supongo que a nadie le gusta esta respuesta, pero es la dura verdad.
Tener una persona enfocada únicamente en la calidad implica que el resto del equipo no necesita molestarse (demasiado)... También abre la puerta al juego de culpas: "debiste haber..." que es todo malo en mi libro.
@Ray, la calidad general es una responsabilidad del equipo, comprar no tener una sola persona en el equipo enfocada en ella o administrar la deuda asociada con decisiones de ingeniería que tienen impactos a largo plazo es un error. ¿Tener un analista comercial implica que nadie más debe preocuparse por las implicaciones o impactos comerciales para un usuario? ¿Tener un diseñador de interfaz de usuario significa que nadie tiene que proporcionar información o comentarios sobre el formato o la usabilidad de una página web o flujo de trabajo de la aplicación? Por supuesto no.
¿ No tener un Business Analyst significa que a nadie le importa la implicación en el negocio? Por supuesto no. Siempre que exista la cobertura necesaria de inquietudes, no es necesario que se llene ningún puesto específico especializado y titulado.
La eficacia de las pruebas se basa en ver las cosas de manera objetiva, sin prejuicios. Es mucho mejor tener un equipo dedicado que se centre en encontrar defectos en lugar de un desarrollador centrado en probar que el SW funciona.

La metodología ágil considera el proceso de desarrollo como un "proceso colaborativo", por lo que cada rol debe participar en el proceso de desarrollo.

Los probadores miran el producto de una manera diferente a como lo ven los desarrolladores: en general, los probadores intentan que el producto de software falle . Por el contrario, los desarrolladores tratan de hacer pasar el producto de software . Esta diferencia en la metodología de pensamiento aumenta la posibilidad de descubrir errores temprano.

Compartir miembros de prueba dedicados desde el principio de la vida del producto les da una buena comprensión de los aspectos comerciales y técnicos del producto.

La única solución es contratar a un gerente de proyecto manco. De esa manera no puede decir "por otro lado..."

Obviamente, tener "desarrolladores" que también sean "probadores" genera un conflicto de intereses.

Por otro lado, supongamos que un gran lanzamiento ya ha terminado de codificarse. Los "desarrolladores" no tienen trabajo y los "testers" están sobrecargados. Entonces, ¿deberían los desarrolladores jugar al solitario en sus computadoras hasta que los probadores hayan terminado?

Así que simplemente no hay una solución absoluta al dilema.

No hay conflicto de intereses en un equipo saludable. Todo el equipo es responsable de la calidad. Eso no impide tener un experto en calidad en el equipo, pero sí. Si tiene un equipo saludable de profesionales, todos querrán entregar un producto de calidad.
"Conflicto de intereses" podría ser la forma incorrecta de expresarlo. Pero es difícil probar tu propio código ya que lo ves de cierta manera. La gente en general es reacia a admitir sus errores (lo que no es saludable para un buen equipo). Solucionamos el problema primero haciendo que un desarrollador diferente hiciera una revisión del código, luego también un desarrollador diferente probaría esa sección en lugar del que escribió el código.
Ahora esas son todas las cosas con las que puedo estar de acuerdo. Un equipo en el que estaba obtuvo excelentes resultados en las pruebas de caja blanca. El revisor por pares también fue responsable de extraer el cambio propuesto y probarlo. ¿Les dio una perspectiva única sobre "cómo puedo romper esto"?
¿Deberíamos tener un probador dedicado en el equipo o las pruebas son responsabilidad mutua del equipo de desarrollo?
RespuestasAquíPolítica de privacidad1y, 0v