Proyecto a punto de finalizar.Es hora de comenzar a probar.¿Qué métodos son viables hacia el final del ciclo de desarrollo?

Question

Supongamos que uno se une a un proyecto cerca del final de su ciclo de desarrollo.El proyecto se ha transmitido a muchos equipos y, en general, ha sido un juego libre para todos, sin que se hayan realizado pruebas de ningún tipo durante todo el tiempo.Los otros miembros de este equipo no tienen conocimientos de pruebas (¡qué vergüenza!) y las pruebas unitarias de cada método parecen inviables en este momento.

¿Cuál sería la estrategia recomendada para probar un producto en este momento, además de las pruebas de usabilidad?¿Es este normalmente el punto en el que estás atascado con el trabajo manual de salida esperada/salida real de apuntar y hacer clic?

Answer 1

Me suelen adoptar un enfoque de abajo hacia arriba de la prueba, pero creo que en este caso quiere ir de arriba hacia abajo. Prueba de los componentes más grandes se puede envolver unidad de pruebas y ver cómo fallan. Esos fracasos se deben apuntar hacia lo subcomponentes necesitan pruebas de su propia cuenta. Vas a tener un conjunto de pruebas bastante irregular cuando se hace esto, pero es un comienzo.

Answer 2

Si usted tiene el presupuesto para ello, conseguir una suite de automatización de pruebas. HP / Mercury Quick Test es el líder en este espacio, pero es muy caro. La idea es que registre los casos de prueba como macros por la conducción de su interfaz gráfica de usuario a través de casos de uso. A llenar las entradas en un formulario (web, .net, columpio, casi cualquier tipo de interfaz gráfica de usuario), el motor aprende los nombres de los elementos de formulario. A continuación, puede comprobar la salida esperada de la GUI y en el PP. A continuación, se puede conectar en una tabla u hoja de cálculo de varias entradas de prueba, incluyendo los casos no válidos donde debería fallar y ejecutar a través de cientos de escenarios, si quieres. Después de las pruebas se registran, también puede editar los scripts generados a personalizarlos. Se construye un informe aseado para usted en el final que muestra exactamente lo que falló.

Hay también algunos de automatización GUI suites baratos y libres de prueba que hacen más o menos lo mismo pero con menos funciones. En general, el más caro de la suite, la customizition menos manual es necesario. Echa un vistazo a esta lista: http://www.testingfaqs.org/t-gui.html

Answer 3

Creo que aquí es donde entraría en juego una buena prueba de Garantía de Calidad.Escriba casos de prueba antiguos y entréguelos a varias personas del equipo para que los prueben.

Answer 4

¿Cuál sería la estrategia recomendada para probar un producto en este momento, además de las pruebas de usabilidad?

Recomendaría la inspección del código por parte de alguien que conozca (o que pueda desarrollar) la especificación funcional del producto.

Una forma extrema y purista sería decir que, debido a que "ha sido una batalla general sin pruebas de ningún tipo", no se puede confiar en nada de eso:ni las pruebas existentes, ni el código, ni los desarrolladores, ni el proceso de desarrollo, ni la gestión, nada sobre el proyecto.Además, las pruebas no añaden calidad al software (la calidad debe estar incorporada, ser parte del proceso de desarrollo).La única manera de tener un producto de calidad es fabricar un producto de calidad;Este producto no tenía calidad en su construcción y por lo tanto es necesario reconstruirlo:

• Trate el código fuente existente como un prototipo o documentación desechable.
• Cree un nuevo producto pieza por pieza, incorporando opcionalmente fragmentos adecuados (si los hay) del código fuente antiguo.

Pero realizar una inspección del código (y corregir los defectos encontrados mediante la inspección del código) podría ser más rápido.Eso sería además de las pruebas funcionales.

Si desea o no no sólo probarlo sino también dedicar tiempo adicional a desarrollar pruebas automatizadas depende de si desea mantener el software (es decir, en el futuro, cambiarlo de cualquier manera y luego volver a probarlo). él).

También necesitarás:

• Cualquiera:
  • Conocimiento de la especificación funcional (y especificación no funcional)
  • Desarrolladores y/o personas de control de calidad con alguna pista
• O:
  • Un producto pequeño y sencillo.
  • Usuarios finales pacientes y comprensivos
  • Soporte técnico continuo después de la entrega del producto.

Answer 5

Una técnica que incorporo en mi práctica de desarrollo al entrar en un proyecto en este momento en el ciclo de vida es añadir pruebas de unidad que se presentan defectos (por los usuarios finales o de control de calidad). Usted no recibirá la cobertura de código completo de la base de código existente, pero al menos de esta manera el desarrollo futuro puede ser manejado y documentado por las pruebas. También de esta manera usted debe estar seguro de que sus pruebas fallan antes de trabajar en la implementación. Si se escribe la prueba y no falla, la prueba es defectuoso.

Además, a medida que agrega nueva funcionalidad al sistema, comenzar con los ensayos de modo que al menos esos subsistemas se ponen a prueba. A medida que los nuevos sistemas interactúan con existente, trate de añadir pruebas en torno a las viejas capas límite y su forma de trabajo en el transcurso del tiempo. Si bien estos no serán pruebas unitarias, estas pruebas de integración son mejor que nada.

Refactoring es otro objetivo prioritario para la prueba. Refactorización sin pruebas es como caminar en la cuerda floja sin red. Es posible llegar al otro lado con éxito, pero es el riesgo vale la pena la recompensa?