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

También practicamos SCRUM. Y al igual que usted, también incluimos las pruebas funcionales como parte de nuestra definición, como hemos hecho.

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

Una segunda cosa buena acerca de la revisión del código, es que le brinda otra vista sobre la funcionalidad real, y para asegurarse al 100% de que está en línea con lo que el cliente / cliente quería. Ha habido algunas ocasiones en las que alguien revisaba el código y la funcionalidad donde estaba la persona ... "Espera, esto no está bien ..." y resultó que la persona que implementó el código simplemente malentendido algo.

Dios mío, sí (intento 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 impresionante cuando nuestros usuarios finales detectan problemas con nuestras pruebas funcionales y los hacen sentir enormemente parte del proceso de desarrollo "¡¡También puedo leer el código !!"

¡Puedes hacer inspecciones de pares!

Las inspecciones de pares son:

Una revisión de documentos activamente & informalmente como parte de la autoría & Ciclo de producción de documentos.

Las razones por las que esto funciona bien con las pruebas son las siguientes:

1. Con frecuencia puede inspeccionar requisitos o documentos con más de un par de ojos.
2. Puede involucrar más que solo desarrolladores: pruebe BA con Test Lead, BA con PM, BA con Dev.
3. Puede establecer reuniones de nueva curación como parte de un proceso Agile: asegúrese de ser serio con los compromisos sólidos de los miembros del equipo.
4. Puede usar estas inspecciones de pares como parte de un ejercicio de comunicación y de comunicación con sus partes interesadas. ¡Que comience la conversación!

Revisamos las pruebas funcionales por pares, al menos de manera casual, y se recomienda encarecidamente a nuestra organización que todo el código sea revisado.

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

Tiene mucho sentido para mí. Cualquier código que escriba debe ser examinado 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 necesaria, a veces más importante que la revisión del código en sí, ya que a menudo se supone que puede reemplazarse con cualquier código que cumpla el mismo resultado de prueba automatizado.

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

Falta de este punto es una de las cosas que hace que estas metodologías parezcan descuidadas para los revisores externos.