testing - realizar - tecnicas de pruebas de software
En desarrollo ágil, ¿quién debería escribir casos de prueba? (16)
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 por parte de los desarrolladores que piensan que es una pérdida de tiempo o simplemente no les gusta hacerlo.
La razón por la que no me gusta que mi gente de QA lo haga 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 es posible que no sepan los detalles técnicos que se necesitan.
Pero del mismo modo, la parte negativa de los desarrolladores que realizan los casos de prueba es que pueden omitir las cosas que creen que se romperán. (incluso inconscientemente tal vez)
Como director 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 sucursal antes de que se fusionen con el tronco. (Caja negra)
De la experiencia pasada, tuvimos mucha suerte definiendo pruebas en diferentes niveles para probar cosas ligeramente diferentes:
1er nivel: a nivel de código / clase, los desarrolladores deben escribir pruebas de unidades atómicas. El objetivo es probar las clases y métodos individuales tanto como sea posible. Estas pruebas deberían ser ejecutadas por los desarrolladores a medida que codifican, presumiblemente antes de archivar el código en el control de fuente, y por un servidor de integración continua (automatizado) si se está utilizando uno.
Segundo nivel: en el nivel de integración de componentes, nuevamente los desarrolladores crean pruebas unitarias, pero eso prueba la integración entre componentes. El objetivo 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 una está en uso.
Tercer nivel: a nivel de aplicación, haga que el equipo de control de calidad ejecute sus pruebas del sistema. Estos casos de prueba se deben basar 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, según lo documentado 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 quiere el cliente y cómo se espera que utilicen la aplicación.
Creo 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 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 de la unidad también fallaba durante el proceso de compilación / integración, en caso de que alguien olvidara ejecutar sus pruebas y cometiera un error de código en el archivo fuente.
Mi sugerencia sería que alguien 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 grupo de ojos puede detectar algo que inicialmente no fue capturado. Los casos de prueba iniciales pueden ser realizados por cualquier desarrollador, analista o administrador, no un probador.
QA no debe escribir los casos de prueba ya que pueden ser situaciones donde el resultado esperado no ha sido definido y en este punto, puede ser difícil tener a alguien como árbitro entre QA y desarrollo si cada lado cree que su interpretación es la correcta. Es algo que he visto muchas veces y desearía que no sucediera tan a menudo.
Sueldo mis pruebas en pruebas de "desarrollador" y pruebas de "cliente", 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 que no sean desarrolladores escriben para garantizar que el comportamiento coincida con la especificación. Los desarrolladores nunca deben escribir las pruebas de accepatancia 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 cierto.
Las pruebas de aceptación deben ser impulsadas por la especificación y, si están escritas por el desarrollador, serán impulsadas por el código y, por lo tanto, por el comportamiento actual, no por el comportamiento deseado.
Creo que el Project Manager o Business Analyst debería escribir esos casos de prueba.
Luego, deben entregárselos a la persona de QA para que se encargue y pruebe.
De esta forma, se asegura de que no falten espacios entre la especificación y lo que realmente se probó y se entregó.
El desarrollador definitivamente no debe hacerlo, ya que estarán probando 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 deba a un malentendido en la especificación, o una característica o ruta a través del código que no haya sido pensada e implementada correctamente.
Si considera que no tiene suficiente tiempo para esto, contrate a alguien más o promueva a alguien para este puesto, ya que es la clave para entregar un producto excelente.
Experimentamos con un emparejamiento del desarrollador con una persona de QA con muy buenos resultados. Por lo general, ''se respetaban unos a otros'' y, como el desarrollador tenía pruebas unitarias para manejar el código, ya tenía bastante conocimiento de los cambios. La persona de QA no fue, pero vino desde el lado de la caja negra. Ambos fueron responsables de la integridad. Parte del proceso de revisión en curso ayudó a detectar deficiencias en las pruebas unitarias y, por lo tanto, no había demasiados incidentes de los que sabía que alguien había evitado deliberadamente 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 el hecho de que esos jugadores de diferentes áreas interactúen ayudó a evitar la mentalidad de ''tirarlo a la pared'' que a menudo sucede.
De todos modos, espero que de alguna manera sea útil para ti.
La razón por la que no me gusta que mi gente de QA lo haga 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 es posible que no sepan los detalles técnicos que se necesitan.
Sí, necesitas tener más confianza en tu departamento de control de calidad o en uno mejor. Quiero decir, imagina que dijiste "No me gusta que mis desarrolladores desarrollen software. No me gusta la idea de que creen su propio trabajo".
Como desarrollador, sé que existen riesgos 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 van a escribir pruebas que demuestren que su código hace lo que creen que hace. No muchos van a escribir pruebas que se apliquen al caso real de negocios en cuestión.
Las pruebas son una habilidad, y es de esperar que su departamento de control de calidad, o al menos, los líderes en ese departamento, estén bien versados en esa habilidad.
"desarrolladores que piensan que es una pérdida de tiempo, o que simplemente no les gusta hacerlo". Luego, recompénsales por ello. ¿Qué ingeniería social es necesaria para que creen casos de prueba?
¿Puede QA revisar el código y probar casos y pronunciar "Cobertura insuficiente - Necesita más casos". Si es así, entonces el programador que tiene cobertura "suficiente" de inmediato será el Big Kahuna.
Entonces, mi pregunta es: una vez que se realiza la tarea, ¿quién debe definir el objetivo de los casos de prueba "suficientes" para esta tarea? Una vez que sepa "suficiente", puede hacer que los programadores se responsabilicen de completar "lo suficiente" y de que el control de calidad sea responsable de garantizar que se realicen pruebas "suficientes".
¿Demasiado difícil definir "suficiente"? Interesante. Probablemente esta sea la causa raíz del conflicto con los programadores en primer lugar. Podrían sentir que es una pérdida de tiempo porque ya hicieron "suficiente" y ahora alguien dice que no es "suficiente".
Seleccione (no solo elija al azar) 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 sobre los detalles técnicos: creo que todos los miembros de un equipo ágil deberían tener acceso de lectura al código y a la documentación disponible. La mayoría de los probadores que conozco pueden leer (y escribir) códigos, por lo que es posible que encuentren útiles las pruebas unitarias, posiblemente incluso las extiendan. Asegúrese de que los diseñadores de prueba obtengan respuestas útiles de los desarrolladores, si necesitan saber algo.
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!
El equipo.
Si un defecto llega a un cliente, es culpa del equipo , por lo tanto, el equipo debe escribir casos de prueba para garantizar que los defectos no lleguen al cliente.
El Project Manager (PM) debe entender el dominio mejor que nadie en el equipo. El conocimiento de su 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 las expectativas sobre entradas inválidas. Necesitan proporcionar al menos el caso de la prueba de "camino feliz".
El desarrollador conocerá el código. Usted 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 las pruebas de caja blanca. Esa es la ventaja de 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 pasar cuando ...?" - cada uno de estos es un caso de prueba. Si la respuesta es compleja "Si a continuación, x , pero si b , a 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, es por eso que tienen probadores.
El canon ágil es que debe tener (al menos) dos capas de pruebas: pruebas de desarrollador y pruebas de clientes.
Las pruebas de desarrollador son escritas por las mismas personas que escriben el código de producción, preferiblemente usando desarrollo impulsado por prueba . 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 del cliente son especificadas por el cliente o el proxy del cliente. Son, de hecho, la especificación del sistema, y deben escribirse de forma que sean ejecutables (totalmente automatizados) y comprensibles para los empresarios. A menudo, los equipos encuentran formas para que el cliente incluso los escriba , con la ayuda de la gente de QA. Esto debería suceder mientras (o incluso antes) se desarrolla la funcionalidad.
Idealmente, las únicas tareas para QA hacer justo antes de la fusión, es presionar un botón para ejecutar todas las pruebas automatizadas, y hacer algunas pruebas exploratorias adicionales (= sin guión). 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 nada.
Un caso de prueba comienza primero en la tarjeta de la historia.
El propósito de las pruebas es conducir los defectos hacia la izquierda (anteriormente en el proceso de desarrollo del software cuando son más baratos y más rápidos de solucionar).
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 cumplió el propósito de una tarjeta de historia.
Los criterios de aceptación de la tarjeta de historia determinarán qué pruebas de unidades automatizadas deben codificar los desarrolladores al igual que lo hacen con el Desarrollo impulsado por prueba. También impulsará la prueba funcional automatizada implementada por los probadores autoamted (y quizás con el soporte del desarrollador si usa herramientas como FIT).
Igualmente importante es que los criterios de aceptación impulsarán las pruebas de rendimiento automáticas y se pueden usar 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 y / o los usuarios. Siga este proceso y es probable que lo suelte con cero defectos.
Raramente he oído hablar o he visto a Project Managers escribir 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. ¿Debo entender los préstamos subprime, las tasas de interés y demás? Tal vez en un nivel superficial, pero los verdaderos expertos necesitaban asegurarse de que esas cosas funcionaran. Mi trabajo era mantener al equipo saludable, 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 debería 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 es revisar los casos de uso mientras construye casos de prueba, y el analista revisa los casos de prueba una vez 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 entiende los requisitos y los casos de prueba se deben mapear según los requisitos. Los desarrolladores no deberían ser las personas que escriben los casos de prueba para evaluar su código. QA puede escribir pasos de prueba detallados por requerimiento. Pero la persona que escribe el requisito debe dictar lo que debe probarse. 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 alcance de la prueba, y QA escribe los planes de prueba granulares.
Necesitamos evolucionar a partir de "así es como se ha hecho o se debe hacer mentalidad", está fallando y fallando continuamente. La mejor manera de resolver el problema de escritura del plan de prueba / casos es que los casos de prueba se deben escribir en el documento de requisitos en cascada o en la historia del usuario en forma ágil cuando se escriben dichas preguntas / historias de usuario. De esta forma, no hay duda de qué es necesario probar y los equipos de QA y UAT pueden ejecutar el caso (s) de prueba y el tiempo de enfoque en las pruebas reales y la resolución de defectos.