¿La programación extrema necesita herramientas de diagramación?

Question

He estado experimentando con algunos conceptos de XP, como la siguiente:

1. la programación en parejas
2. Prueba primera programación
3. entregas incrementales
4. Ruthless refactoración

Hasta aquí todo bien hasta que tuve un tocón importante:

¿Cómo puedo Firmar mis casos de prueba cuando todavía no hay ningún código. ¿De qué base debo diseñarlos? ¿De suposiciones simples? De los requisitos iniciales?

¿O es aquí donde encajan los diagramas UML y la "fase de análisis"?

Solo tuve que preguntar porque en algunos libros de XP que he leído, había poca o ninguna discusión sobre cualquier herramienta de diagramación (había una que sugirió que apareciera pseudocódigos y algún tipo de diagrama de flujo ... pero no me ayudó a escribir mis pruebas)

Answer 1

Los procesos ágiles a menudo están basados ​​en papel, pero esto hace algunas suposiciones básicas que podrían no ser ciertas en un entorno corporativo.

Incluso si su equipo está distribuido, puede usar bolígrafos y papel (con un escáner en color) o una pizarra (con una cámara digital barata). Capturar las imágenes de esta manera puede ser más ágil que tratar de usar herramientas de software más especializadas porque tiende a enfocarse en resolver el problema, en lugar de manejar la herramienta o retocar la presentación visual.

¿Cómo puedo diseñar mis casos de prueba cuando todavía no hay ningún código? ¿De qué base debo diseñarlos? ¿De suposiciones simples? De los requisitos iniciales?

Usted comienza desde la historia del usuario informado por los requisitos iniciales y las discusiones con el "cliente en el sitio" si tiene la suerte de tener uno.

La idea es que escriba la prueba antes del código, para que sepa cuándo ha terminado. Es posible que el código no se ejecute correctamente, o incluso compile, desde el momento en que comienza a escribir la prueba hasta el momento en que la prueba se ejecuta y pasa. Esto es similar al desarrollo tradicional de "prueba final", excepto que el momento en que se rompe el código tiende a ser más corto, y se garantiza que tendrá una prueba al final.

Cambia la manera en que se motiva el desarrollo a partir de "¿Qué código debo escribir a continuación?" a "¿Qué prueba debo escribir a continuación?". La segunda pregunta es más fácil de responder siempre que tengas una idea básica de qué es lo que quieres hacer.

Answer 2

¿Cómo puedo diseñar mis casos de prueba cuando todavía no hay ningún código? ¿A partir de qué base tengo que diseñarlos? Desde supuestos simples? De los requisitos iniciales ?

Para escribir una prueba no necesita ningún código. Usted conoce sus aportaciones y conoce sus resultados esperados. Entonces puede diseñar un caso de prueba para implementarlo.

No veo ninguna relación estrecha entre cosas UML y XP. UML es para el diseño del software y XP es el proceso que usted sigue para desarrollar ese software. Por lo tanto, aclare la pregunta si es posible.

Answer 3

Los casos de prueba provienen de los requisitos iniciales. Especifican lo que vas a construir, entonces, ¿de dónde vendrían las pruebas?

Una técnica que puede ser útil es tomar una función y dividirla en tres elementos: Given, When, Then. Dado es la información inicial, Cuando es la llamada al programa, Entonces es el resultado deseado. El punto es que cualquier requisito que no pueda analizar así puede no ser correcto, o al menos necesita más detalles.

El equipo de pruebas de Google es muy aficionado a este enfoque y ha blogueado extensamente al respecto. Find out more.

Answer 4

XP no tiene "fases de análisis".

No necesita utilizar una herramienta de diagramación con XP, aunque no hay nada que lo detenga si elige usar uno.

¿Qué desea modelar?

Parece que desea describir el dominio del problema (es decir, el modelado para el análisis) en lugar de documentar la implementación. XP no funciona como los métodos convencionales donde un especialista hace "análisis" y otro "codificación". En XP, es probable que el analista sea un desarrollador que trabaje con alguien del negocio que trabaje en conjunto para analizar las historias de los usuarios y estimarlas.

Usted normalmente no comienzan la documentación de casos de prueba - escribimos pruebas automatizadas en el código, ya sea en clave o en una especificación ejecutable como con JBehave o pepino. Se trata de un esfuerzo mayor que el diagrama, pero con un retorno de la inversión mucho mejor.