Nos encontramos con una aplicación donde las pruebas son una cadena consecutiva de pasos. como toda cadena, todo eslabón debe estar intacto, de lo contrario se pierde la naturaleza como tal de la cadena.
Probar cada paso representa una carga de trabajo considerable en horas/hombre. Entonces, surge la idea de distribuir el trabajo entre varios de los testers. Pero el problema no se resuelve, ya que “apriori” el tester B debe esperar (o duplicar trabajo) a que el tester A termine sus pruebas (entiéndase que A probará el eslabón de la cadena inmediatamente anterior al eslabón que B probará). Sólo un dato más: Hay que hacer un montaje (creación de datos de pruebas en las BBDD) previo al inicio de las pruebas.
Se me ocurren las siguientes opciones:
- Distribuir la tarea del montaje en la BBDD abarcando todas las casuísticas posibles
- Tester A puede comenzar sus pruebas del primer eslabón, entrando a consultar y distinguir pormenores
- Tester A debe dar el OK de un pre-testing de A finalizado y correcto (generación rápida y sin problemas en la estabilidad del eslabón primero)
- Tester B comienza las pruebas del siguiente eslabón considerando que el o los eslabones anteriores son para él como una “black box”.
- Tester B debe identificar posibles problemas cuya causa sean de montaje o de output de los procesos ejecutados en la caja negra.
- Tester A debe identificar posibles complicaciones y nuevas consideraciones de pruebas a transmitir al tester B.
- Tester X debe considerar toda la cadena como “black box”, con lo cual, lo que le importa es una entrada (montaje) y una salida (pantallas/reportes/documentos/etc.)
Alguna sugerencia o corrección?
Saludos,
Juan Carlos Peláez
Creo que es una buena idea. Solo un matiz, creo que la primera fase, a la que llamas “pre-testing”, sigue bloqueando la cadena. En esta fase deben definirse los test, ejecutarlos y asegurar que son estables para que no afecte al resto de la cadena de tests, por lo tanto es muy probable que los tester B, C , … , X queden a la espera del OK de A, ¿no?
Un saludo.
Que problema.
)
1. Seria posible trabajar en turnos o el fin de semana (lo siento soy medio indio
2.No es posible hacer un input ‘artificial’ entre las partes para que cada tester puede probar su parte al mismo tiempo?
Me parece que debes saber el output/input de cada eslabon?
Es mas greybox, pero indentificarias las problemas de las ultimas partes de la cadena antes.
Creo que no resuelve el total de horas/hombre usado, pero si la duracion. A final la duracion a veces vale mas.
Bueno, cualquiere suerte con tu problema. Por favor comparte las opciones probado finalmente.
Gracias por las aportaciones.
Cuando traté el tema de la “duplicación de trabajo” quizás hubiese podido explicarla mejor con el concepto de “pruebas incrementales acumulativas”.
Aclaro:
Eslabón 1 = funcionalidad a, funcionalidad b,
Eslabón 2 = funcionalidad a, funcionalidad b, funcionalidad c
Eslabón 3 = funcionalidad a, funcionalidad b, funcionalidad c….. funcionalidad X
Es decir, no se puede probar solamente el eslabón 3 sin tener que pasar por las funcionalidad (que no pruebas, pero si montajes y estabilidad) de los eslabones inmediatamente anterior.
Cómo lo estoy solucionando:
1. Los montajes para las pruebas son paralelos (varios recursos trabajando en ello
2. Los montajes se dividirán por características independientes (se deberán probar todas las funcionalidades, pero con aspectos diferenciadores)
Aún así, me queda la duda de que se puede mejorar.
2.