testing - manifesto - Papel de los probadores en Agile?

agile methodology wiki (9)

1) Mientras un desarrollador está codificando una tarea, es imposible que un probador la pruebe (todavía no existe). ¿Cuál es el papel de un evaluador en este punto?

El probador aún puede crear planes de prueba y tener una lista de las pruebas que se crearán. También puede ser necesario que el probador reciba capacitación si el desarrollo implica algún software disponible, por ejemplo, si está haciendo un proyecto de CMS con Sitecore, entonces el probador debe saber algunas cosas sobre Sitecore. También puede haber alguna colaboración entre el probador, el desarrollador y el usuario final o BA para saber cuáles son los requisitos y las expectativas, de modo que no haya indicaciones que puedan aparecer en vagos requisitos.

2) ¿El probador ahora está involucrado en pruebas unitarias? ¿Esto se hace en paralelo a la prueba de caja negra?

No en nuestro caso. El verificador realiza más pruebas de integración / aceptación del usuario que las pruebas de unidad de bajo nivel. En nuestro caso, las pruebas unitarias vienen antes de cualquier prueba de control de calidad, ya que los desarrolladores que crean la funcionalidad crearán una capa de pruebas.

3) ¿Qué hace el verificador durante un sprint donde se han realizado principalmente cambios de infraestructura, que solo se pueden probar en pruebas unitarias?

¡Pruebas de regresión! Al hacer cambios en la infraestructura, ¿se rompió algo? ¿Cuán exhaustivo es el conjunto de pruebas que pueden ejecutar los desarrolladores en comparación con el control de calidad? Tuvimos esto en un sprint no hace mucho tiempo, donde la mayor parte del trabajo de sprint fue la reprografía de la plomería, por lo que no había mucho que probar, aparte de ver que las cosas que funcionaban antes todavía funcionaban después.

En nuestro caso, tenemos pruebas como un nivel más arriba de nuestro entorno de desarrollo, pero aún como un entorno de preproducción. La idea es permitir QA un sprint para validar el trabajo realizado y para detectar cualquier error crítico o de alta gravedad antes de una versión en etapas para la prueba final de aceptación del usuario, por lo que si los desarrolladores están trabajando en Sprint X entonces QA valida el sprint X-1 y la producción pueden tener sprint X-2 o versiones anteriores dependiendo de la UAT final y del calendario de despliegue, ya que no todos los sprints lo harán entrar en producción después de que QA dé la autorización para pasar a la puesta en escena. Hay ejercicios de emparejamiento que pueden suceder una vez que un desarrollador realiza una codificación inicial de una tarea para garantizar que tanto un probador como un usuario final firmen lo que se creó. Esta es nuestra tercera o cuarta versión de tratar de integrar el control de calidad en el proyecto, por lo que sigue siendo un trabajo en progreso que ya ha evolucionado varias veces.

Trabajo en un equipo que ha estado haciendo el método tradicional de desarrollo en cascada durante muchos años. Recientemente, nos han dicho que los proyectos futuros se moverán hacia una metodología ágil (particularmente Scrum). Sucede que mi proyecto será uno de los primeros, por lo que, en esencia, seremos conejillos de indias durante los próximos meses para resolver lo que se necesita para hacer la transición.

El proyecto en sí está en una etapa muy temprana y, por lo general, estaríamos a muchos meses de lanzar algo al equipo de pruebas, pero ahora vamos a trabajar directamente con ellos por adelantado. Como resultado, me preocupa el papel de los evaluadores en dicho proyecto en esta etapa. Tengo varias preguntas / inquietudes que espero que algunos desarrolladores ágiles con experiencia puedan responder:

Mientras un desarrollador está codificando una tarea, es imposible que un probador la pruebe (todavía no existe). ¿Cuál es el papel de un evaluador en este punto?
¿El probador ahora está involucrado en pruebas unitarias? ¿Esto se hace en paralelo a la prueba de caja negra?
¿Qué hace el verificador durante un sprint donde se han realizado principalmente cambios de infraestructura, que solo se pueden probar en pruebas unitarias?

¿Cómo funcionan los miembros tradicionales del equipo de prueba en su proyecto ágil?

Al igual que algunos otros encuestados han indicado, los probadores deberían participar desde el primer día. En Sprint cero, deben participar para garantizar que las historias que el propietario del producto está produciendo sean comprobables (por ejemplo, verificables una vez codificadas) y "aceptables" (es decir, cuando pasas por UAT). Una vez que el Product Backlog se rellena inicialmente, los Testers pueden trabajar en casos de prueba para las Historias programadas para el Sprint actual, y una vez que hay un producto para probar (Idealmente en algún lugar de su primer Sprint), entonces pueden comenzar las pruebas.

Si parece que nunca habrá nada para probar en algunos Sprints, tus historias están equivocadas. El objetivo de un Sprint, incluso uno temprano, es tener una pequeña porción del sistema eventual. Concéntrese en "asprin" (es decir, si desarrolla un sistema de prescripción de medicamentos, ¿cómo entrega funcionalidad comprobable en 2 a 4 semanas? Cree los que recete un asprin) y "balas trazadoras" (que, cuando se toman en combinación, tocan todo las partes riesgosas de la arquitectura). Se sorprenderá de lo que puede entregar para probarlo al principio. Si los probadores terminan con tiempo libre, hágalos emparejar el programa con los desarrolladores. Desarrollará relaciones y respeto mutuo.

Los beneficios de este enfoque son muchos, pero principalmente se prueba una buena parte de las personas internas -procesos de su desarrollo (traspaso de requerimientos, al desarrollo, a prueba, y también a la inversa) y secundariamente a todo el equipo (las tres disciplinas mencionadas ) ve los beneficios de una respuesta rápida como resultado de la producción de software ejecutable.

Parece imposible, pero lo he visto funcionar. Solo asegúrate de no morder un pedazo demasiado grande para empezar. Dejen que se relajen y se sorprenderán.

Buen post. Estuve en la misma situación hace 3 años y la transición de cascada a ágil fue difícil. Encontré muchos puntos dolorosos en la mudanza, pero una vez que los superé y mi papel cambió, me di cuenta de que esta forma de trabajar realmente se ajusta a las pruebas.

El mito común de que los evaluadores no son necesarios se disipa fácilmente.

1. Mientras un desarrollador está codificando una tarea, es imposible que un probador la pruebe (todavía no existe). ¿Cuál es el papel de un evaluador en este punto?

En mi experiencia, el probador podría estar trabajando con el cliente para afinar las historias en el sprint.

Por lo general, trabajan con los desarrolladores para ajustar el código que están entregando. es decir, asesoramiento sobre casos extremos, flujos, errores, etc.

A menudo pueden participar en el diseño de las pruebas que el codificador escribirá para realizar TDD.

Si el equipo ágil está bastante avanzado, el probador normalmente escribiría las pruebas ATDD (Desarrollo de prueba de aceptación). Estos podrían estar en una herramienta como Fitnesse o Robot Framework o podrían ser pruebas de ruby más avanzadas o incluso algún otro lenguaje de programación. O en algunos casos, la grabación y reproducción simples a menudo pueden ser beneficiosas para un pequeño número de pruebas.

Obviamente estarían escribiendo pruebas y planeando algunos escenarios o ideas de pruebas exploratorias.

Lo difícil de comprender a veces para el equipo es que la historia no tiene que estar completa para colocarla en la pila de prueba para la prueba. Por ejemplo, los codificadores podrían colocar una pantalla con la mitad de los campos planificados en ella. El probador podría probar esta mitad mientras que la otra mitad está siendo codificada y, por lo tanto, la retroalimentación con los primeros resultados de la prueba. Las pruebas no tienen que tener lugar en historias "terminadas".

2. ¿El probador ahora está involucrado en la prueba unitaria? ¿Esto se hace en paralelo a la prueba de caja negra?

Idealmente, los codificadores estarían haciendo TDD. Escribir la prueba y luego escribir el código para que la prueba pase. Y si los codificadores quieren un TDD realmente bueno, entonces se pondrían en contacto con el probador para pensar en las pruebas.

Si no se está haciendo TDD, los codificadores deberían escribir pruebas unitarias al mismo tiempo que la codificación. Probablemente no debería ser una idea después o después de la eliminación del software. El objetivo de las pruebas es probar que el software sea correcto para evitar perder el tiempo más adelante en la línea. Se trata de comentarios instantáneos.

3. ¿Qué hace el verificador durante un sprint donde se han realizado principalmente cambios de infraestructura, que solo se pueden probar en pruebas unitarias?

Idealmente, el probador estaría trabajando con el equipo y el cliente (que, por cierto, es parte del equipo) para definir las historias planificadas y construir una buena y detallada crítica de aceptación. Esto es invaluable y puede ahorrar mucho tiempo más adelante en la línea. El verificador también podría estar aprendiendo nuevas técnicas de automatización, planeando entornos de prueba, ayudando a documentar el resultado de la planificación.

Idealmente, cada historia en el sprint podría probarse de alguna manera, forma o forma. Esto no significa que debe ser por el equipo de prueba, pero debe ser comprobable. De modo que el probador podría estar trabajando con el resto del equipo para averiguar cómo asegurarse de que las historias se puedan probar.

Publiqué algunos consejos ágiles aquí: http://thesocialtester.posterous.com/

Espero que esto te ayude Rob ...

El método más natural para realizar pruebas en un entorno ágil es, en mi opinión, una prueba exploratoria http://en.wikipedia.org/wiki/Exploratory_testing . No suena palabras como

Según Cem Kaner & James Bach, las pruebas exploratorias son más una [mentalidad] o "... una forma de pensar acerca de las pruebas" que una metodología

prueba de par

suena familiar para los desarrolladores ágiles. Los probadores pueden participar mucho antes en el proceso que en las pruebas tradicionales.

En mi empresa, utilizamos y aprueba Agile. Nuestros miembros del equipo de control de calidad están involucrados en la creación de pruebas unitarias, manteniendo la infraestructura de pruebas de regresión y, al igual que en cascada, también prueban cada característica una vez completada.

Al hacer cambios de infraestructura, también participan para asegurarse de que la nueva infraestructura sea comprobable.

Entonces, desde mi experiencia limitada, trataré de responder sus puntos:

Si todavía no hay nada que probar, comience a configurar una infraestructura de regresión / prueba y asegúrese de que todo lo que se esté haciendo sea comprobable
Sí, él puede hacer ambas cosas
Mantiene la infraestructura de prueba y caza a quien rompe las pruebas

Idealmente, el QA y los evaluadores deberían estar involucrados, si no desde el primer día, y desde las primeras etapas de un proyecto de desarrollo de software, independientemente del proceso utilizado (cascada o ágil). El equipo de prueba necesitará:

Asegúrese de que los requisitos de proyecto o sprint sean claros, mensurables y comprobables. En un mundo ideal, cada requisito tendrá un criterio de ajuste escrito en esta etapa. Determine qué información debe registrarse automáticamente para solucionar cualquier defecto.
Prepare una estrategia de prueba específica del proyecto y determine qué pasos de QA se requerirán y en qué etapas del proyecto: integración, estrés, compatibilidad, penetración, conformidad, usabilidad, rendimiento, pruebas beta, etc. Determine los umbrales de defectos aceptables y elabore el sistema de clasificación para gravedad del defecto, especifique las pautas para el informe de defectos.
Especifique, organice y prepare el entorno de prueba: pruebe la infraestructura y los servicios simulados según sea necesario; obtener, desinfectar y preparar datos de prueba; escribir scripts para actualizar rápidamente el entorno de prueba cuando sea necesario; establecer procesos para el seguimiento, comunicación y resolución de defectos; prepararse para la contratación o reclutar usuarios para pruebas beta, de usabilidad o de aceptación.
Proporcione toda la información relevante para formar el cronograma del proyecto, la estructura de desglose del trabajo y el plan de recursos.
Escribir guiones de prueba.
Póngase al día con el dominio del problema, el sistema AS-IS y la solución propuesta.

Por lo general, esto no es una cuestión de si un equipo de prueba puede proporcionar algún aporte útil en el proyecto en una etapa temprana, ni si dicho aporte es beneficioso. Sin embargo, se trata de hasta qué punto una organización puede permitirse las actividades antes mencionadas. Siempre hay una compensación entre el tiempo disponible, el presupuesto y el recurso versus el nivel de calidad conocida del resultado final.

Mantener los probadores ocupados tiende a ser más fácil a medida que un proyecto madura (¡hay más para probar!), Pero los siguientes puntos también se aplican en las primeras etapas:

Los evaluadores pueden preparar sus planes de prueba, casos de prueba y pruebas automáticas para las historias de los usuarios antes (o mientras) de que se implementen. Esto ayuda al equipo a descubrir cualquier incoherencia o ambigüedad en las historias de los usuarios, incluso antes de que los desarrolladores escriban cualquier código.
En mi experiencia personal, los evaluadores no tienen ninguna participación en pruebas unitarias; solo prueban el código que pasa todas las pruebas de unidad, integración y aceptación automatizadas, todas escritas por los desarrolladores. Sin embargo, esta división puede ser diferente en otros lugares; por ejemplo, sus probadores podrían estar escribiendo pruebas de aceptación automatizadas. Las pruebas unitarias realmente deberían ser escritas por los desarrolladores, sin embargo, ya que están escritas en tándem con el código.
Su carga de trabajo variará entre sprints, pero las pruebas de regresión aún deben ejecutarse en estos cambios ...

También puede encontrar que hacer que los evaluadores pasen los primeros días de cada prueba de sprint, las tareas del sprint anterior pueden ayudar, sin embargo, creo que es mejor hacer que definan las cosas en las que los desarrolladores van a trabajar. escribiendo sus planes de prueba.

Solo algunos pensamientos, definitivamente incompletos:

Mientras el desarrollador está codificando una tarea, el verificador puede examinar las especificaciones (o las solicitudes del cliente, si no hay especificaciones formales) y escribir el plan de prueba. Esto puede incluir un marco conceptual para lo que debe probarse, pero también debe incluir la redacción formal de conjuntos de pruebas (sí, en el código) también. Esto puede ser todo un desafío para los equipos que se mueven hacia la agilidad, ya que muchos de los evaluadores son contratados sin habilidades de programación. (En muchos lugares, parece que es un requisito no poder codificar).
El probador puede participar en pruebas de unidades, o en un alcance ligeramente superior al probar componentes o bibliotecas que tienen una interfaz limpia.
Los evaluadores siempre deben ejecutar pruebas de regresión, pruebas de carga y cualquier otro tipo de prueba que se les ocurra, además de escribir suites de prueba para el próximo sprint. A menudo ocurre que los probadores trabajan un sprint antes del desarrollo (en la preparación de un entorno de prueba), así como también una carrera detrás del desarrollo (para probar lo que los desarrolladores acaban de producir).

Vi una buena talk sobre esto recientemente. Básicamente, este equipo comenzó haciendo un proceso de Scrum bastante estándar, luego hizo la transición a Kanban y Lean. Una de las cosas más importantes que hicieron fue erosionar gradualmente las distinciones entre probadores y desarrolladores. Los evaluadores participaron en la redacción de pruebas y códigos unitarios, los desarrolladores aportaron más pruebas de nivel superior al principio del desarrollo. Fue una curva de aprendizaje empinada para los evaluadores, pero valió la pena ya que el equipo fue construyendo en calidad desde el principio. En este momento, los evaluadores se llaman a sí mismos desarrolladores porque su trabajo está tan integrado en el proceso de escritura de código.