En un desarrollo ágil, ¿quién debería escribir casos de prueba? [cerrado]

https://stackoverflow.com/questions/194790

10-07-2019
|

Pregunta

Nuestro equipo tiene un sistema de tareas donde publicamos pequeñas tareas incrementales asignadas a cada desarrollador.

Cada tarea se desarrolla en su propia rama, y ??luego cada rama se prueba antes de fusionarse con el tronco.

Mi pregunta es: una vez que se realiza la tarea, ¿quién debe definir los casos de prueba que se deben hacer en esta tarea?

Idealmente, creo que el desarrollador de la tarea es el más adecuado para el trabajo, pero he tenido mucha resistencia de los desarrolladores que piensan que es una pérdida de tiempo o que simplemente no les gusta hacerlo.

La razón por la que no me gusta que lo haga mi personal de control de calidad es porque no me gusta la idea de que creen su propio trabajo. Por ejemplo, pueden omitir cosas que son simplemente demasiado trabajo para probar, y pueden no conocer los detalles técnicos que se necesitan.

Pero del mismo modo, la parte negativa de los desarrolladores que hacen los casos de prueba es que pueden dejar de lado las cosas que creen que se romperán. (incluso inconscientemente tal vez)

Como gerente del proyecto, terminé escribiendo los casos de prueba para cada tarea, pero mi tiempo está sujeto a impuestos y quiero cambiar esto.

¿Sugerencias?

EDITAR: Por casos de prueba me refiero a la descripción de las tareas de control de calidad individuales que se deben realizar en la rama antes de que se fusionen con el tronco. (Cuadro negro)

Solución

El equipo.

Si un defecto llega a un cliente, es culpa del equipo, por lo tanto, el equipo debería ser escribir casos de prueba para asegurar que los defectos no lleguen al cliente.

El Project Manager (PM) debería entender el dominio mejor que nadie en el equipo. Su conocimiento del dominio es vital para tener casos de prueba que tengan sentido con respecto al dominio. Tendrán que proporcionar entradas de ejemplo y responder preguntas sobre expectativas sobre entradas no válidas. Deben proporcionar al menos el caso de prueba de 'camino feliz'.
El desarrollador (s) sabrá el código. Sugiere que el desarrollador puede ser el mejor para la tarea, pero que está buscando casos de prueba de caja negra. Cualquier prueba que se le ocurra a un desarrollador son pruebas de caja blanca. Esa es la ventaja de hacer que los desarrolladores creen casos de prueba: saben dónde están las costuras en el código.

Los buenos desarrolladores también vendrán al PM con preguntas "¿Qué debería suceder cuando ...?" - cada uno de estos es un caso de prueba. Si la respuesta es compleja " Si a entonces x , pero si b entonces y , excepto los jueves " - hay varios casos de prueba.
Los probadores (QA) saben cómo probar el software. Es probable que los probadores presenten casos de prueba en los que el PM y los desarrolladores no pensarían, por eso tiene probadores.

Otros consejos

Creo que el Project Manager o Business Analyst debería escribir esos casos de prueba.
Luego deben entregarlos a la persona de control de calidad para que se desarrolle y pruebe.

De esta forma, se asegura de que no falten espacios entre la especificación y lo que realmente se prueba y entrega.

Los desarrolladores definitivamente no deberían hacerlo, ya que probarán sus pruebas unitarias. Entonces es una pérdida de tiempo.

Además, estas pruebas encontrarán errores que el desarrollador nunca encontrará, ya que probablemente se deban a un malentendido en la especificación, o una característica o ruta a través del código que no se haya pensado e implementado correctamente.

Si descubre que no tiene suficiente tiempo para esto, contrate a otra persona o promueva a alguien para este puesto, ya que es clave para ofrecer un producto excelente.

Experimentamos con un emparejamiento del desarrollador con una persona de control de calidad con muy buenos resultados. En general, 'se mantuvieron honestos' y, dado que el desarrollador tenía pruebas unitarias para manejar el código, ya era bastante íntimo con los cambios. La persona de control de calidad no lo fue, pero llegó desde el lado de la caja negra. Ambos fueron responsables de la integridad. Parte del proceso de revisión en curso ayudó a detectar las deficiencias de las pruebas unitarias y, por lo tanto, no hubo demasiados incidentes que supiera de dónde alguien evitaba a propósito escribir la prueba X porque probablemente probaría que había un problema.

Me gusta la idea de emparejamiento en algunos casos y creo que funcionó bastante bien. Puede que no siempre funcione, pero tener a esos jugadores de diferentes áreas interactuando ayudó a evitar la mentalidad de "tirarlo por la pared" que a menudo sucede.

De todos modos, espero que sea de alguna manera útil para usted.

De la experiencia pasada, tuvimos bastante suerte definiendo pruebas en diferentes niveles para probar cosas ligeramente diferentes:

1er nivel: a nivel de código / clase, los desarrolladores deberían escribir pruebas de unidades atómicas. El propósito es probar clases y métodos individuales tanto como sea posible. Los desarrolladores deben ejecutar estas pruebas a medida que codifican, presumiblemente antes de archivar el código en el control de origen, y por un servidor de integración continua (automatizado) si se está utilizando uno.

2do nivel: en el nivel de integración de componentes, nuevamente haga que los desarrolladores creen pruebas unitarias, pero que prueben la integración entre componentes. El propósito no es probar clases y componentes individuales, sino probar cómo interactúan entre sí. Estas pruebas deben ser ejecutadas manualmente por un ingeniero de integración, o automatizadas por un servidor de integración continua, si hay una en uso.

3er nivel: a nivel de aplicación, haga que el equipo de control de calidad ejecute sus pruebas del sistema. Estos casos de prueba deben basarse en los supuestos comerciales o documentos de requisitos proporcionados por un gerente de producto. Básicamente, pruebe como si fuera un usuario final, haciendo las cosas que los usuarios finales deberían poder hacer, como se documenta en los requisitos. Estos casos de prueba deben ser escritos por el equipo de control de calidad y los gerentes de producto que (presumiblemente) saben lo que el cliente quiere y cómo se espera que usen la aplicación.

Siento que esto proporciona un nivel de cobertura bastante bueno. Por supuesto, los niveles 1 y 2 anteriores deberían ejecutarse idealmente antes de enviar una aplicación integrada al equipo de control de calidad. Por supuesto, puede adaptar esto a lo que se ajuste a su modelo de negocio, pero esto funcionó bastante bien en mi último trabajo. Nuestro servidor de integración continua enviaría un correo electrónico al equipo de desarrollo si una de las pruebas unitarias fallara también durante el proceso de compilación / integración, en caso de que alguien olvidara ejecutar sus pruebas y cometiera código roto en el archivo fuente.

" desarrolladores que piensan que es una pérdida de tiempo, o que simplemente no les gusta hacerlo " Entonces recompénselos por ello. ¿Qué ingeniería social es necesaria para que creen casos de prueba?

¿Puede el control de calidad revisar el código y probar casos y pronunciar "No hay suficiente cobertura? Necesita más casos". Si es así, entonces el programador que tiene "suficiente" La cobertura inmediata será el Big Kahuna.

Entonces, mi pregunta es: una vez que se realiza la tarea, ¿quién debe definir el objetivo de "suficiente"? casos de prueba para esta tarea? Una vez que sepa "suficiente", puede hacer que los programadores sean responsables de completar "suficiente". y QA responsable de asegurar que "suficiente" la prueba está hecha.

¿Demasiado difícil de definir "suficiente"? Interesante. Probablemente esta sea la causa raíz del conflicto con los programadores en primer lugar. Es posible que sientan que es una pérdida de tiempo porque ya hicieron "suficiente". y ahora alguien dice que no es "suficiente".

las personas de QA, junto con el "cliente", deberían definir los casos de prueba para cada tarea [realmente estamos mezclando terminología aquí], y el desarrollador debería escribirlos. primero!

La razón por la que no me gusta que lo haga mi personal de control de calidad es porque no me gusta la idea de que creen su propio trabajo. Por ejemplo, pueden omitir cosas que simplemente son demasiado trabajo para probar, y pueden no conocer los detalles técnicos que se necesitan.

Vaya, debes confiar más en tu departamento de control de calidad o en uno mejor. Quiero decir, imagina que habías dicho "No me gusta que mis desarrolladores desarrollen software". No me gusta la idea de que creen su propio trabajo. & Quot;

Como desarrollador, sé que existen riesgos involucrados al escribir mis propias pruebas. Eso no quiere decir que no haga eso (lo hago, especialmente si estoy haciendo TDD) pero no me hago ilusiones sobre la cobertura de las pruebas. Los desarrolladores escribirán pruebas que demuestren que su código hace lo que creen que hace. No muchos escribirán pruebas que se apliquen al caso comercial actual en cuestión.

Las pruebas son una habilidad y, con suerte, su departamento de control de calidad, o al menos, los líderes de ese departamento, están bien versados ??en esa habilidad.

Seleccione (no solo elija aleatoriamente) uno o dos evaluadores y permítales escribir los casos de prueba. Revisión. También podría ser útil si un desarrollador que trabaja con una tarea mira los casos de prueba para la tarea. Aliente a los evaluadores a sugerir mejoras y adiciones a los conjuntos de prueba; a veces las personas tienen miedo de arreglar lo que hizo el jefe. De esta manera, puede encontrar a alguien que sea bueno en el diseño de pruebas.

Informe a los evaluadores acerca de los detalles técnicos: creo que todos los miembros de un equipo ágil deberían tener acceso de lectura al código y cualquier documentación disponible. La mayoría de los probadores que conozco pueden leer (y escribir) código, por lo que pueden encontrar útiles las pruebas unitarias, posiblemente incluso extenderlas. Asegúrese de que los diseñadores de la prueba obtengan respuestas útiles de los desarrolladores, si necesitan saber algo.

Mi sugerencia sería que alguien más revise los casos de prueba antes de fusionar el código para garantizar la calidad. De acuerdo, esto puede significar que un desarrollador está pasando por alto el trabajo de otro desarrollador, pero ese segundo par de ojos puede detectar algo que inicialmente no se detectó. Los casos de prueba iniciales pueden ser realizados por cualquier desarrollador, analista o gerente, no por un probador.

El control de calidad no debe escribir los casos de prueba, ya que pueden ser situaciones en las que el resultado esperado no se ha definido y, en este punto, puede ser difícil contar con un árbitro entre el control de calidad y el desarrollo si cada parte cree que su interpretación es la el correcto. Es algo que he visto muchas veces y desearía que no sucediera tan a menudo como lo hace.

Divido mis pruebas libremente en "desarrollador" pruebas y "cliente" pruebas, la última de las cuales sería "pruebas de aceptación". Las primeras son las pruebas que los desarrolladores escriben para verificar que su código funciona correctamente. Las últimas son pruebas que alguien diferente que los desarrolladores escriben para asegurarse de que el comportamiento coincida con las especificaciones. Los desarrolladores deben nunca escribir las pruebas de aceptación porque su creación del software que están probando supone que hicieron lo correcto. Por lo tanto, sus pruebas de aceptación probablemente afirmarán lo que el desarrollador ya sabía que era verdad.

Las pruebas de aceptación deben ser conducidas por la especificación y si están escritas por el desarrollador, serán conducidas por el código y por lo tanto por el comportamiento actual, no el comportamiento deseado.

El Agile canon es que debe tener (al menos) dos capas de pruebas: pruebas de desarrollador y pruebas de clientes.

Las

pruebas de desarrollador están escritas por las mismas personas que escriben el código de producción, preferiblemente utilizando desarrollo impulsado por pruebas . Ayudan a crear un diseño bien desacoplado y aseguran que el código esté haciendo lo que los desarrolladores creen que está haciendo, incluso después de una refactorización.

Las

pruebas de clientes están especificadas por el cliente o el proxy del cliente. De hecho, son la especificación del sistema, y ??deben estar escritos de manera que sean ejecutables (totalmente automatizados) y comprensibles para la gente de negocios. Con frecuencia, los equipos encuentran formas para que el cliente incluso los escriba con la ayuda de personas de control de calidad. Esto debería suceder mientras, o incluso antes, se desarrolla la funcionalidad.

Idealmente, las únicas tareas que debe realizar el control de calidad justo antes de la fusión, es presionar un botón para ejecutar todas las pruebas automatizadas y realizar algunas pruebas exploratorias adicionales (= sin script). También querrá ejecutar esas pruebas nuevamente después de la fusión, para asegurarse de que la integración de los cambios no rompa algo.

Un caso de prueba comienza primero en la tarjeta de historia.

El propósito de las pruebas es conducir los defectos hacia la izquierda (anteriormente en el proceso de desarrollo de software cuando son más baratos y más rápidos de reparar).

Cada tarjeta de historia debe incluir criterios de aceptación. El propietario del producto se empareja con el analista de soluciones para definir los criterios de aceptación para cada historia. Este criterio se usa para determinar si se ha cumplido el propósito de una carta de historia.

Los criterios de aceptación de la tarjeta de historia determinarán qué pruebas unitarias automatizadas deben codificar los desarrolladores a medida que lo hacen Desarrollo impulsado por pruebas. También conducirá la prueba funcional automatizada implementada por los probadores automáticos (y tal vez con el soporte del desarrollador si usa herramientas como FIT).

Igual de importante, los criterios de aceptación impulsarán las pruebas de rendimiento automatizadas y pueden usarse al analizar el perfil de la aplicación por parte de los desarrolladores.

Finalmente, la prueba de aceptación del usuario estará determinada por los criterios de aceptación en las tarjetas de historia y debe ser diseñada por el socio comercial o los usuarios. Siga este proceso y probablemente saldrá con cero defectos.

Raramente he escuchado o visto que los Gerentes de Proyecto escriban casos de prueba, excepto en los equipos más pequeños. En cualquier aplicación de software grande y compleja debe tener un analista que realmente conozca la aplicación. Trabajé en una compañía hipotecaria como primer ministro. ¿Entendería los préstamos de alto riesgo, las tasas de interés y demás? Quizás a un nivel superficial, pero los verdaderos expertos necesitaban asegurarse de que esas cosas funcionaran. Mi trabajo consistía en mantener sano al equipo, proteger los principios ágiles y buscar nuevas oportunidades de trabajo para mi equipo.

El analista del sistema debe revisar todos los casos de prueba y su relación correcta con los casos de uso. Además, el analista debe realizar el UAT final, que también podría basarse en casos de prueba. Entonces, el analista y el tipo de calidad están haciendo una especie de revisión por pares.

La calidad está revisando los casos de uso mientras está construyendo casos de prueba, y el analista está revisando los casos de prueba después de que se escriben y mientras realiza UAT.

Por supuesto, BA es el experto en el dominio, no desde el punto de vista técnico. BA comprende los requisitos y los casos de prueba deben asignarse a los requisitos. Los desarrolladores no deben ser las personas que escriben los casos de prueba para probar contra su código. El control de calidad puede escribir pasos de prueba detallados por requisito. Pero la persona que escribe el requisito debe dictar lo que necesita ser probado. Quien realmente escribe los casos de prueba, no me importa demasiado, siempre y cuando los casos de prueba se remonten a los requisitos. Creo que tiene sentido que BA guíe la dirección o el alcance de las pruebas, y QA escribe los planes de pruebas granulares.

Necesitamos evolucionar a partir de la "mentalidad así es como se ha hecho o se debe hacer". está fallando y fallando continuamente. La mejor manera de resolver el problema de la redacción del plan de prueba / casos es que los casos de prueba deben escribirse en el documento de requisitos en cascada o en la historia del usuario en forma ágil a medida que se escriben esas solicitudes / historias de usuario. De esta manera, no hay duda de qué se debe probar y los equipos de control de calidad y UAT pueden ejecutar los casos de prueba y centrar el tiempo en las pruebas reales y la resolución de defectos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow