Si se implementa una nueva función y hay un error, ¿debería el QA rechazar esa función o aceptarla y presentar un nuevo error?

7

En el trabajo, usamos un rastreador de errores llamado Pivotal Tracker (www.pivotaltracker.com) que permite a los ingenieros archivar características y errores. Si se entrega una característica o corrección de errores, el trabajo de QA es aceptarla o rechazarla en consecuencia.

Si un ingeniero implementa una nueva función que tiene un error, ¿debería QA aceptar esa función y presentar el error por separado, o debería QA rechazar esa función e informar el error en un comentario?

Ventaja potencial de rechazar la característica: Mejores posibilidades de que los ingenieros noten y solucionen el error antes de liberar el código

Posible ventaja de presentar un error por separado: Permite a los ingenieros evaluar mejor cuántos errores ha habido (si eso es realmente útil)

    
pregunta DormoTheNord 27.03.2011 - 09:57

5 respuestas

13

No hay una respuesta dura y rápida; depende de su organización.

Una cosa a considerar es que si el control de calidad encuentra muchos errores en la nueva función, sería mejor hacer un seguimiento de cada uno de ellos por separado, así que tenderé a presentar informes de errores individuales.

Si el error es tan grave que no hay forma de que la función pueda usarse como se esperaba (por ejemplo, falta el elemento del menú para iniciar la función), puede tener más sentido rechazar la función directamente. Alcanzó la etapa de prueba de cordura.

No olvide que si busca un informe de error, el control de calidad necesita un número de versión significativo para poder presentar el error. No es un error en la versión 1.0 ni un error en la versión 2.0, tiene que ser contra un construcción / carga provisional particular, o similar.

Obviamente, el control de calidad también debe tener el poder de rechazar que toda la compilación se envíe a los clientes, simplemente medir que "solo hay un error en esa nueva característica" no es suficiente.

    
respondido por el Oddthinking 27.03.2011 - 10:03
2

Un pequeño manual como respuesta:

1. Permitir característica, no archivar error

¡No hagas esto! Incluso si la característica está permitida en la producción con errores, los problemas deben registrarse (puede que nunca se solucione, pero esta es otra historia).

2. Permitir característica, error de archivo

Use esto cuando el problema sea menor o tenga una solución razonable y no tenga un gran impacto. Se informa del error y, con suerte, se solucionará en el futuro. Ejemplo de errores aquí: la ventana mueve 1 px a la derecha después de que 10 minimiza, los comentarios se ignoran en el archivo de salida, errores menores de la interfaz de usuario.

3.No permitir características, error de archivo

No permita que la función salga del entorno de desarrollo cuando el error que se encontró es crítico / afecta a muchas personas (como mencionó anteriormente, falta un elemento del menú y no se puede usar la nueva función, o datos) pérdida). Sin embargo, abrir un error para un problema de este tipo podría ser complicado porque el error generalmente es visible para todas las personas en la organización, pero tiene sentido solo para un grupo pequeño. Podría crear ruido.

4. No permitir características, no presentar errores

Los mismos tipos de error que en 3 se aplican aquí. La única diferencia es que no se crea ningún error, sino que se informa al grupo de desarrolladores al respecto. Eventualmente, podría ser registrado en otro lugar (en una pizarra)

    
respondido por el Victor Hurdugaci 28.03.2011 - 23:43
1

Una tercera opción es rechazar la nueva característica y presentar un error. Si tiene un departamento de control de calidad separado que es el responsable de la calidad, no deben aceptar códigos rotos. OMI, "rechazar" siempre debe ser la primera opción. Si posteriormente presenta un error o no depende de usted.

Esto puede ser impopular con el desarrollo (e incluso con los gerentes de producto), pero eso es algo bueno. Si algo es doloroso, hazlo a menudo. Esto hará que las personas encuentren una solución al problema. Es decir, si cada vez que envían un código de error, vuelve con un "rechazo", se cansarán de eso y trabajarán más duro para encontrar los defectos en su propio código.

    
respondido por el Bryan Oakley 28.03.2011 - 18:58
0

No estoy familiarizado con Pivotal Tracker, así que no estoy seguro de lo que puede hacer.

Donde trabajo, usamos FogBugz para el seguimiento de errores, y en un caso como este marcaríamos la función "Esperando reparaciones" y abriríamos casos separados para cada uno de los errores encontrados. Esto resuelve ambos problemas: permite que cada error se rastree de forma individual (y deberían serlo, en una función compleja), y también le permite saber claramente si la función está lista para ser enviada o no.

    
respondido por el Avi 27.03.2011 - 10:07
0

Depende de la severidad del error.

Como regla general, se debe aceptar una función si pasa la prueba de aceptación. Si ese error se encontró allí, la función normalmente se rechaza.

Independientemente de si esa característica fue rechazada o no, el error se debe presentar por separado. Los ingenieros definitivamente notarán una característica fallida, pero si el error se menciona solo en los comentarios, será más difícil rastrearlo.

    
respondido por el Nikita Barsukov 29.03.2011 - 09:20

Lea otras preguntas en las etiquetas