Revisión por pares para pruebas al igual que revisiones de código

¿Alguien practica el proceso de "revisión de código" para las pruebas funcionales? Lo encontraste util? La forma en que mi empleador actual practica SCRUM incluye pruebas funcionales como parte de nuestro "debe haber hecho" cosas en cualquier sprint dado.

También practicamos SCRUM. Y al igual que usted, también incluimos pruebas funcionales como parte de nuestra definición tal como está hecha.

Desde mi experiencia, lo encuentro increíblemente útil. Hemos reducido significativamente la cantidad de errores en nuestro código simplemente forzando la prueba funcional.

Una segunda cosa interesante acerca de la revisión del código es que le da otra vista sobre la funcionalidad real y se asegura al 100% de que está en línea con lo que el cliente quería. Hubo algunas ocasiones en que alguien revisaba el código y la funcionalidad donde la persona fue ... "Espera, esto no está bien ..." y resultó que la persona que implementa el código simplemente no entendió algo.

Dios mío sí (trato de no usar improperios en SO; p). La revisión por pares de sus pruebas funcionales es básicamente una revisión por pares de sus requisitos y análisis, es increíblemente importante, y si usa un lenguaje BDD como pepino, ¡también puede involucrar a no programadores!

Es increíble cuando nuestros usuarios finales detectan problemas con nuestras pruebas funcionales y los hace sentir enormemente parte del proceso de desarrollo "¡¡También puedo leer el código !!"

Tiene mucho sentido para mi. Cualquier código que escriba debe ser revisado por otra persona, incluso si el código solo se usa internamente y nunca será ejecutado por el cliente.

Con las metodologías que ponen tanto peso en las pruebas, la revisión de las pruebas se vuelve mucho más importante, posiblemente requerida, a veces más importante que la revisión del código en sí, ya que a menudo se supone que puede reemplazarse por cualquier código que cumpla con el mismo código automatizado. Resultado de la prueba.

Revisar que las pruebas son correctas es un aspecto, que son lo suficientemente completas y precisas / representativas también es muy importante.

Perder este punto es una de las cosas que hace que estas metodologías se vean descuidadas para los revisores externos.

¡Puedes hacer inspecciones de pares!

Las inspecciones de pareja son:

Una revisión de documentos de manera activa e informal como parte del ciclo de creación y producción de documentos.

Las razones por las que esto funciona bien con las pruebas es que:

1. Con frecuencia puede inspeccionar requisitos o documentos con más de un par de ojos.
2. Puede involucrar a más que solo desarrolladores: pruebe BA con Test Lead, BA con PM, BA con Dev.
3. Puede establecer reuniones de curado como parte de un proceso ágil: asegúrese de tomarse en serio al respecto con compromisos sólidos de los miembros del equipo.
4. Puede utilizar estas inspecciones de pares como parte de un ejercicio de construcción de relaciones y ejercicio de comunicación con sus partes interesadas. ¡Comienza la conversación!

Revisamos las pruebas funcionales por pares, al menos casualmente, y se recomienda encarecidamente a nuestra organización que revise todo el código.

Recomendaría elegir a su revisor en función de sus objetivos para la revisión. Las pruebas codificadas pueden ser mejor revisadas por un desarrollador (principalmente para la calidad del código) y otro probador (principalmente para la cobertura de la prueba). Las pruebas sin código (utilizando un arnés, por ejemplo, pruebas basadas en datos) pueden ser mejor revisadas solo por otro probador. Las revisiones por pares también son una excelente manera de alentar a los evaluadores a aprender unos de otros.