¿Deberían los evaluadores aprobar las versiones o simplemente informar sobre las pruebas?

20

¿Tiene sentido otorgar autorización de aprobación a los evaluadores? Debería un equipo de prueba

Simplemente pruebe características, problemas, etc., y simplemente informe sobre una base de aprobado / reprobado, dejando que otros actúen sobre esos resultados, o
¿Tiene autoridad para retrasar las liberaciones basadas en esos resultados?

En otras palabras, ¿se debería exigir a los evaluadores que firmen las versiones? El equipo de prueba con el que estoy trabajando siente que sí, y estamos teniendo un problema con esto debido a la "alteración del alcance de la prueba": la negativa a aprobar lanzamientos a veces se basa en problemas explícitamente no abordados por el lanzamiento en cuestión.

testing release-management process

— Ernest Friedman-Hill
fuente

2

Por favor, reformule su pregunta para que no sea una encuesta. ¿Cuál es el problema que estás tratando de resolver?

— M. Dudley

55

"debería" depende en gran medida de la estructura organizativa de la empresa. Si se miden los errores encontrados en la producción, poder mantener una versión con errores es una herramienta esencial.

Excelente punto, @MichaelT. En mi organización, las pruebas son una función más que una descripción del trabajo, y la evaluación es más ad-hoc y nada cuantitativa. Las implementaciones exitosas alimentarían críticas positivas, pero los errores en la producción no serían negativos específicos, como tampoco lo haría para nadie más en el equipo.

— Ernest Friedman-Hill

55

Si tiene un problema con el que los evaluadores se niegan a aprobar las liberaciones en función de los problemas que no se planean abordar, entonces tiene un problema de comunicación (no saben que no se planea abordar los problemas) o un problema de las personas (se están volviendo importantes; si liberar es, en última instancia, una decisión comercial).

— Jan Hudec

27

En la mayoría de los lugares en los que he trabajado, las personas de control de calidad tienen algún tipo de paso de cierre de sesión, pero no tienen la autoridad final sobre si la liberación continúa o no. Su aprobación representa que completaron las pruebas esperadas por el plan de lanzamiento, no que el lanzamiento sea perfecto.

En última instancia, QA! = La empresa y la empresa deben decidir si están de acuerdo con implementar el código en el estado actual o si el beneficio supera la desventaja o lo que sea. A menudo, esto es realizado por clientes o partes interesadas inmediatamente antes de la implementación y, a menudo, se denomina Aceptación del usuario.

Si su control de calidad también es su grupo de aceptación de usuarios, existe la posibilidad de que tengan la autoridad para definir a su candidato de lanzamiento como inaceptable, pero si está obteniendo esto por cuestiones que están fuera del alcance de la corrección de errores / iteración / sprint / cambio solicite / lo que sea que invierta su tiempo, entonces el Gerente del Proyecto o las partes interesadas de la línea de negocios deben asistir a una reunión de Jesús con el equipo de control de calidad.

Está bien informar sobre defectos preexistentes o resultados no deseados de nuevos requisitos, pero si está fuera del alcance y no es desastroso, generalmente no es aceptable etiquetarlo como un problema de bloqueo. Va en la cartera de pedidos para que el propietario del producto priorice como todo lo demás.

— Cuenta
fuente

¿Quién decide si invitará al cliente a realizar una prueba de aceptación en la compilación 1234 o si no es lo suficientemente bueno para las pruebas de aceptación?

— Bart van Ingen Schenau

3

@BartvanIngenSchenau: El propietario del producto / gerente de proyecto debe tener la última palabra al respecto. Porque incluso las pruebas de aceptación a menudo se abultarán si es necesario (¿desea la función X ahora aunque no podamos hacer que Y trabaje con ella, o desea esperar 2 meses más hasta que la arreglemos?) Y el propietario del producto está negociando eso.

— Jan Hudec

Además de lo que dijo Jan, en muchas metodologías habría un cronograma o cadencia aquí. algunas personas implementan a cada candidato que sobrevive a la prueba de humo inicial en UAT, algunas implementan automáticamente todo lo que se registra en la rama candidata, algunas todo lo que se registra en main. idealmente, ha estado mostrando el progreso de las partes interesadas a medida que avanza de alguna manera, por lo que no debería haber mucha sorpresa al final. en algunos de estos casos, terminas mostrando a las partes interesadas lo que la gente de QA te ha estado arrastrando a través de los carbones y simplemente dicen "a quién le importa" y se acabó.

— Bill

En SaaS moderno con implementación continua, el ciclo de implementación del código (servicio) puede ser independiente del ciclo de lanzamiento de la característica (negocio). Este ciclo de lanzamiento de funciones se puede implementar utilizando indicadores o conmutadores de funciones, por ejemplo, de alfa (interno) a beta (opcional) a disponibilidad general. Esa es una forma de involucrar una firma comercial formal más separada e independiente de la capacidad de implementación de un código o servicio en particular. Al contrario, la vinculación de las versiones de funciones con las implementaciones de servicios introduce el acoplamiento y el riesgo en el proceso que se puede evitar con la técnica de indicador de características.

— Será

@ no estoy en desacuerdo, pero alguien todavía está juzgando si esas características ocultas están lo suficientemente ocultas como para que otros usuarios que no sean el equipo beta lo noten en el despliegue inicial y, en última instancia, en cualquier lugar donde haya utilizado ese enfoque, se reproduce la secuencia más o menos lo mismo, pero con diferentes etiquetas en las partes móviles y el riesgo cambió un poco. Prefiero la situación que describe, pero el equipo de control de calidad que encuentra algo preexistente o el gerente de producto que decide proceder de todos modos es algo tan importante en este modelo como en cualquier otro en mis experiencias.

— Bill

6

Alguien necesita esa autoridad . Ya sea un probador, el equipo de probadores, el líder del equipo de probadores o el líder de la organización de desarrollo es algo irrelevante. O quizás más exactamente, depende de la organización.

En última instancia, la opción de lanzar software es una función comercial. El negocio tiene que decidir si la calidad es adecuada. Podría decirse que el director de aseguramiento de la calidad debe tomar esa decisión o transmitir esa decisión a la unidad de negocios apropiada. Todo depende del tamaño de la empresa, la importancia relativa de la calidad, etc.

Dicho todo esto, la información utilizada para tomar la decisión comienza con el probador . Ya sea que tengan el poder de detener una liberación o no, deben sentir la responsabilidad de informar a los tomadores de decisiones cuando vean algo que creen que debería causar un retraso en la liberación.

— Bryan Oakley
fuente

6

Otorgar ese derecho de aprobación (es decir, un derecho de veto) para las versiones a los probadores tiene tanto sentido como otorgar ese derecho a los desarrolladores: ninguno en absoluto.

Los probadores y desarrolladores son principalmente personas técnicas, por lo que es probable que tomen sus decisiones principalmente por razones técnicas. Pero, las preocupaciones que deben sopesarse al realizar un lanzamiento son preocupaciones técnicas y comerciales. Obviamente, el cliente no estará contento si entrega un producto lleno de errores, pero estará igualmente descontento si sigue posponiendo un lanzamiento porque todavía hay problemas abiertos en el producto.

Alguien necesita encontrar el equilibrio adecuado entre un buen producto y cumplir con el cronograma prometido al cliente. Para hacer eso, no debe involucrarse en el proyecto en un rol puramente técnico, sino más bien en un rol más orientado al negocio / administración, como gerente de proyecto o propietario del producto, y tomar su opinión de los probadores y los desarrolladores.

— Bart van Ingen Schenau
fuente

1

He votado en contra porque estoy básicamente en desacuerdo con varios puntos y suposiciones que está haciendo. No estoy de acuerdo con que el control de calidad no deba tener autoridad para vetar un lanzamiento porque muchos grupos de control de calidad también operan en un rol de aceptación del usuario. Además, no estoy de acuerdo con la suposición de que los evaluadores son personas técnicas. No siempre es el caso, no todos los grupos que lanzan software pueden permitirse un equipo de control de calidad completo, por lo que ese rol puede recaer en analistas de negocios que pueden no ser técnicos en absoluto.

— maple_shaft

1

Además del punto de maple_shaft, a menudo veo la última llamada de esta izquierda a quien tenga el rol de cliente a menos que haya algo terrible identificado. es, en última instancia, su entrega y es más probable que tengan el punto de vista correcto sobre el riesgo, suponiendo que les brinde información precisa.

— Bill

5

La decisión de 'liberar' o 'no liberar' es, al final del día, una decisión comercial, donde se debe realizar un análisis riguroso de riesgo / recompensa.

Es una locura para cualquier organización pedirle al equipo de prueba que asuma esta responsabilidad o que el equipo de prueba acepte esta responsabilidad.

El papel del equipo de prueba es proporcionar un análisis de la calidad del software, su disponibilidad para ser lanzado y cualquier riesgo identificado como una entrada a la decisión comercial de lanzar o no lanzar.

Como han señalado otros, _ alguien _ (y creo que es un individuo) necesita la autoridad para tomar la decisión de "liberar" o "no liberar". Esa misma persona puede haber delegado esa decisión en condiciones específicas (es decir, sin errores P1 o P2)

— Jordán
fuente

3

He trabajado con la misma situación de probadores que se esfuerzan demasiado e inventan formas cada vez más creativas de romper un sistema que, cuando se evalúa el riesgo, es increíblemente improbable que ocurra en la producción.

Si bien entiendo y felicito al equipo de prueba por no querer enviar una versión imperfecta, sí requiere una fuerte propiedad del producto para definir qué es un "riesgo aceptable".

En mi experiencia, al equipo de prueba se le debe otorgar un veto sobre la publicación de software, pero el propietario del producto debe anular este veto, pero solo después de una discusión con los evaluadores principales.

El software nunca será perfecto, si estás sufriendo un problema de prueba, nunca obtendrás nada lanzado hasta que haya un problema de producción importante (que no se probará correctamente) y se apresurará.

— Miguel
fuente

1

Ese es un problema real, pero no estoy seguro de si ese es necesariamente el problema del OP. Mi interpretación es que de alguna manera los evaluadores están interpretando nuevos requisitos que no se definieron originalmente.

— maple_shaft

2

Mi experiencia con los equipos de prueba me ha llevado a caer al otro lado de esto. Para mí, QA no debería tener la expectativa de poder bloquear un despliegue sin exponer su caso al resto del equipo o hacer que el propietario lo anule.

— Bill

1

Es cierto: probablemente no fui lo suficientemente explícito, los mismos problemas ocurren cuando los evaluadores plantean defectos, y cito, "en la esencia de la historia", lo que lleva a los mismos problemas: nunca se libera nada.

— Michael

En mi caso, es más la interpretación de @maple_shaft; no tanto por ser desviado para encontrar formas de romper el software, sino por informar de la falta de manejo de casos explícitamente no admitidos.

— Ernest Friedman-Hill

1

@ ErnestFriedman-Hill Parece que está describiendo requisitos negativos y estos son los que faltan en sus documentos de requisitos funcionales. Un requisito negativo es una declaración explícita sobre lo que NO hará un sistema , y puede ser tan aceptable como los requisitos regulares. Si estos se declaran, sus casos de prueba contra los requisitos negativos no son válidos.

— maple_shaft