¿Compartiendo casos de prueba de desarrollo (integración de unidad y desarrollo) con el equipo de QA (prueba)?

8

El equipo de prueba (el llamado equipo de control de calidad en algunas organizaciones) insiste en que el equipo de desarrollo debe compartir sus casos de prueba (del equipo de desarrollo) con ellos. Sus argumentos son que los casos de prueba de desarrollo son el punto de partida para la prueba de control de calidad.

Como miembro del equipo de desarrollo, no entiendo la solicitud. En mi opinión, el probador debe probar la solución según los requisitos. No sé si el equipo de prueba debe compartirse con el documento de diseño detallado (diseño de bajo nivel). Sin embargo, les estamos compartiendo el diseño detallado.

He leído algunas publicaciones aquí que dicen que el equipo de control de calidad debe compartir sus casos de prueba con el equipo de desarrollo para obtener una mejor solución y un mejor rendimiento. Pero, nada del equipo de desarrollo comparte sus casos de prueba con el equipo de prueba de control de calidad.

Parece que mi equipo de control de calidad está muy contento si comparto mi unidad de desarrollo y los casos de prueba de integración y los resultados de la prueba.

— Sudhi Sukumaran
fuente

66

El control de calidad no necesita documentación de diseño detallada. Se supone que deben probar los requisitos , no el diseño .

Una ventaja de compartir esta información es que el equipo de control de calidad puede determinar si están interpretando los requisitos de la misma manera que el equipo de desarrollo. ¿O prefiere proporcionar alguna otra documentación o revisarla en una reunión?

— JeffO

2

Stack Exchange no es un foro ...

— Peter Mortensen

44

@JeffO en realidad, esa es una buena razón para no compartir los casos de prueba de desarrollo, sino que requiere crearlos directamente a partir de los requisitos. Un beneficio importante de la función de prueba por separado son los supuestos desafiantes realizados durante el desarrollo al tener "nuevos ojos" en los requisitos. Si algunas pruebas de control de calidad fallan porque están interpelando los requisitos de manera diferente al equipo de desarrollo, excelente, esa es información muy importante que se habría perdido si comenzaran leyendo la interpretación "obvia" hecha por el equipo de desarrollo.

— Peteris

19

Cuando su equipo de desarrollo y su equipo de control de calidad no hablan entre sí, existe un cierto riesgo de que algunas pruebas se realicen innecesariamente dos veces y otras se olviden. El peor de los casos es cuando su equipo de desarrollo ha implementado algunas buenas pruebas de integración automática, que se ejecutan en unos minutos u horas, y su personal de control de calidad prueba las mismas cosas manualmente, pasando días o semanas para esa tarea. Otro mal escenario es cuando ambos grupos piensan que el otro grupo es responsable de algún tipo de pruebas, por lo que se omiten esas pruebas.

Por lo tanto, suponiendo que ambos grupos trabajen en equipo y no uno contra el otro, tiene sentido informarse mutuamente en detalle qué pruebas realiza cada grupo y dejar que los dos grupos coordinen sus actividades.

— Doc Brown
fuente

3

En mi experiencia, la forma más confiable de informarse mutuamente en detalle era a través de la cobertura de prueba . No importa si QA o dev olvidan algo, el análisis de cobertura generalmente mostrará lo que salió mal. El único inconveniente es que es tentador confiar demasiado en él y apagar el cerebro "¡Tenemos el 100%, somos perfectos!" sí claro

— mosquito

la cobertura del código no significa que el código funcione. Los programas exitosos son más que solo lógica de código: también hay datos involucrados. Agregue factores ambientales (por ejemplo, funciona bien en XP, no en Win7) e interacción (por ejemplo, habilito el módulo del producto y ya no puedo iniciar sesión). La cobertura del código es la miopía centrada en el desarrollador.

— gbjbaanb

@gnat: el análisis de cobertura puede ser un indicador útil para encontrar algunas partes no probadas en su programa que, de lo contrario, pueden olvidarse, estoy de acuerdo. Pero, por supuesto, para desarrollar un buen conjunto de pruebas, la cobertura por sí sola no es suficiente y tampoco le evita hacer las mismas cosas innecesariamente dos veces. ¿Y si es la herramienta adecuada para comunicar cosas entre el equipo de control de calidad y el equipo de desarrollo? Esto depende mucho de cómo funcionan esos dos equipos.

— Doc Brown

1

@gbjbaanb estoy de acuerdo con la miopía, he visto con demasiada frecuencia que la gente cae en la ilusión de "cubierto = probado", eso es bastante dañino. Lo único útil ( muy útil para ser precisos) que he visto en el análisis de cobertura es "brechas", que muestran lo que no está cubierto. Más allá de eso, simplemente deja de ser útil, no puede decir si mágicamente código de cubierta se prueba correctamente o no

— mosquito

1

@DocBrown Yo diría que es la herramienta adecuada para controlar posibles lagunas en la comunicación ... :) no es de ninguna manera un reemplazo para la discusión, el trabajo en equipo y la transferencia de conocimiento

— mosquito

16

El equipo de prueba (el llamado equipo de control de calidad en alguna organización) insiste en que el equipo de desarrollo debe compartir sus casos de prueba (del equipo de desarrollo) con ellos.

Claro, el control de calidad debe tener una comprensión general de lo que está cubierto por las pruebas de unidad / integración y lo que no.

Sus argumentos son que los casos de prueba Dev son el punto de partida para la prueba de control de calidad.

... incluso si su razonamiento es defectuoso. El mantra # 1 de una persona de QA es no confiar en los desarrolladores . "¡No te preocupes por eso! ¡Lo revisé a fondo!" es el primer paso hacia un problema de producción gigante.

Como dice Doc Brown, no es bueno pasar mucho tiempo de control de calidad en algo que está bien cubierto por las pruebas automáticas. Pero es insensato no perder tiempo en algo que está bien cubierto por las pruebas automatizadas. Y es un desperdicio pasar un montón de tiempo documentando sus pruebas unitarias en detalle cuando el control de calidad realmente no debería confiar en ellas de todos modos (y debido a que ese nivel de documentación impulsa a sus desarrolladores a hacer pruebas unitarias menos / malas).

— Telastyn
fuente

Estoy totalmente de acuerdo con lo que escribió, las principales reglas de aseguramiento de la calidad son, por supuesto, "verificar todo" y "dos pares de ojos son mejores que uno".

— Doc Brown

4

En una arquitectura de software moderna, la intención es que las pruebas no solo prueben el código sino que lo hagan de una manera que documente su funcionalidad.

Esta documentación de lo que hace el código (además de lo que se pretende hacer en las especificaciones) es útil para que los QA'ers comprendan mejor la intención del código y también si cumple con los requisitos. También es información útil cuando los QA'ers escriben casos de prueba y les ayudará a tener una idea de lo que, en teoría, ya se está probando. Algunas de las áreas bajo prueba podrían beneficiarse de casos adicionales y otras podrían estar expuestas por no tener pruebas.

Los detalles reales de esta exposición dependerán en gran medida de la composición de la organización y, en particular, de la profundidad técnica de los evaluadores (por ejemplo, leer el código fuente).

Para ser un tanto contraria ... A menudo me gusta ignorar las pruebas de desarrollador y presentar mis 'propias' pruebas (soy miembro de un gran equipo de QE). He descubierto que ignorar las pruebas de desarrollador ayuda a evitar la mentalidad de mirar el problema / problema / característica solo desde el punto de vista de los desarrolladores.

El lema de MY QE es: QE debería agregar valor al probar el producto. ¡"combinar y ejecutar pruebas unitarias" por sí solo es un control de calidad insuficiente!

— Michael Durrant
fuente

3

Mi primera reacción a esta pregunta es "depende".

Depende de lo que quiera decir con "casos de prueba del equipo de desarrollo".

Si solo tiene pruebas unitarias ( prueba de caja blanca ); El equipo de control de calidad (prueba de integración y sistema) no pudo aprovechar sus casos de prueba. Las pruebas unitarias solo están ahí para verificar su unidad, que únicamente no cumple un requisito (en su mayoría). Las pruebas de caja blanca no deberían ser el camino para la integración o las pruebas del sistema.
Si tiene pruebas de comportamiento; El equipo de control de calidad puede usarlos para derivar algunos escenarios de integración.
Si está utilizando TDD ; Según la definición, las pruebas son documentos ejecutables de los requisitos, la arquitectura y el diseño de la aplicación. El equipo de control de calidad definitivamente necesitaría estos casos de prueba.
Algunos métodos de diseño de pruebas, como las pruebas de recuadro gris, requieren información de diseño detallada para poder aislar o simular sujetos de prueba como componentes o subsistemas (prueba de integración). Por lo tanto, compartir el diseño detallado con el equipo de control de calidad también es necesario.
Los hombres de prueba del sistema nunca se molestan con un diseño detallado. Se centran en escenarios de usuario. Por lo tanto, las pruebas de desarrollo (caja blanca) no serán de ninguna utilidad para ellos.

Mi humilde recomendación para su caso es una evaluación de enfoques ágiles como tener probadores (QA) dentro del equipo de desarrollo y pruebas de diseño (características, integración, sistema) juntas por adelantado.

— Kaan
fuente

1

No hay ninguna razón por la que no deba compartir lo que ha probado con el equipo de control de calidad, sin embargo, deberían estar duplicando las pruebas suyas que consideran importantes para verificar adecuadamente la aplicación.

1) Son responsables de probar el código / aplicación / lo que sea. Al duplicar sus pruebas cuando corresponda, verifican que su prueba se realizó correctamente.

2) Como desarrollador, usted es responsable de la unidad que prueba su código (generalmente, sin embargo, algunas organizaciones también han comenzado a hacer que los desarrolladores prueben su código). Este es un enfoque diferente, y generalmente se enfoca más en cubrir los puntos de decisión en un método.

3) Como mencionó, es importante que su equipo de prueba comparta sus casos de prueba con usted para ayudarlo a pensar en casos que posiblemente no haya considerado originalmente.

4) Alguien mencionó que es responsabilidad del equipo de prueba probar los requisitos, y si bien esto es cierto, el diseño detallado también es bastante útil. Al tener el diseño, el equipo de prueba no solo puede asegurarse de que está cubriendo los requisitos, sino que también los ayuda a comprender algunas de las decisiones de diseño y los ayudará a crear mejores casos de prueba.

— Ficertyn
fuente