¿Cómo encontrar errores relacionados con el negocio al principio de las prácticas de desarrollo de software?

Question

Estoy trabajando con un buen grupo de desarrolladores muy astutos en una de las instalaciones de mi cliente. Estamos codificando correctamente alrededor de NullPointerException y otras excepciones, por lo que no las tenemos. Pero cuando se trata de reglas comerciales tenemos algunos errores y encontramos problemas cuando ya están en producción. De acuerdo, tenemos un entorno de ritmo muy rápido y una implementación en la producción comandada por el equipo de administración, no por el desarrollo. Pero aprobamos "luz verde" con los equipos de control de calidad y calidad de datos.

¿Cuáles son las mejores prácticas para encontrar errores relacionados con el negocio al principio del proceso de desarrollo de software.

Answer 1

"¿Cuáles son las mejores prácticas para encontrar errores relacionados con el negocio al principio del proceso de desarrollo de software".

Varias cosas.

1. Casos de uso.

2. Pruebas generales basadas en los casos de uso.

3. Pruebas unitarias basadas en los casos de uso.

Lo importante es vincular el sistema, en su conjunto, con los actores reales, el valor comercial real. Es muy fácil enfocarse en problemas técnicos. Para evitar enfocarse estrechamente en problemas técnicos, tenga casos de uso y pruebe en contra de ellos.

Answer 2

He encontrado FitNesse ayuda en muchos casos similares - esencialmente, para simplificar en exceso, los usuarios especifican ejemplos importantes de "datos de entrada" y qué "resultados de salida" correspondientes esperan, y el marco de prueba comprueba que el la correspondencia es correcta Compruébelo, no resolverá todos los problemas de las reglas comerciales incorrectas, pero ayudará con muchos.

Answer 3

User Acceptance Testing se centra en este tipo de problemas.

Answer 4

Como un complemento a la respuesta de akf, me gustaría recomendar una guía completa, User Stories Applied.

Answer 5

Las historias de usuario/casos de uso deben ser lo suficientemente específicas para determinar la crítica de aceptación; Los criterios de aceptación deben incluir todas las reglas comerciales para evitar la situación que usted describe, y si sus Pruebas unitarias solo están probando capacidades técnicas, son insuficientes.

¿Puedes aprender de los incidentes que mencionas, por qué no estaban cubiertos en esos artefactos?

Además, en mi experiencia, este es el beneficio n. ° 1 de integración continua y "Entregar temprano y con frecuencia": no debe descubrir reglas comerciales no válidas más de un día o dos después de que la funcionalidad esté codificada.

Answer 6

Interacción cercana con alguien que conoce el negocio. Encuentro que los diagramas de flujo simples funcionan bien, estos pueden representar casos de uso en forma de diagrama que es más fácil de entender para el usuario.

También es importante tener una interacción temprana y frecuente con el usuario; determine todos los requisitos de datos en cada punto del caso de uso, de dónde provienen los datos, restricciones en los datos, etc. Los casos de uso que utilizan datos de muestra son útiles para detectar malentendidos aquí.

También ayuda tener un prototipo inicial.Powerpoint es bueno para esto, ya que no te tienta a comenzar a "codificar" en una fase temprana.

Answer 7

La mejor manera que conozco para detectar los problemas de negocios desde el principio es escuchar con atención y hacer muchas preguntas aclaratorias, por adelantado. "Quieres decir...?" y que hay con...?" puede ralentizar una reunión, pero puede sacar mucha información a la mesa rápidamente. Parece que las personas de QA y de calidad de datos necesitan estar en la sala durante estas conversaciones.

Pero si es la gente de control de calidad y la calidad de los datos del cliente que está firmando fuera en cosas que luego encontrar que no está bien, que tienen un problema, también, y como proveedor/contratista/consultor, no es un problema para que usted resuelva (más allá de señalarlo).

Answer 8

Si esas reglas comerciales se pueden expresar (sin demasiado esfuerzo) en el código, "Design by Contract" podría ser útil en su caso. Use aserciones para asegurarse de que cada parte del programa se rige por las reglas.

Answer 9

Sus tarjetas de historia debe tener

• criterios de aceptación

que impulsará la creación de

• prueba impulsado pruebas unitarias (escribir las pruebas unitarias primeros)
• automatizado pruebas funcionales
• fu ll prueba de regresión ejecutada al menos diariamente (si no en cada check-in)

Además, todas las pruebas de aceptación del usuario, diseñadas por la empresa, se deben capturar en sus pruebas funcionales automatizadas.

Si los desarrolladores utilizan

• par desarrollar
• prueba impulsado el desarrollo
• integración continua
• refactorización

entonces tales prácticas impulsarán defectos a cero o cerca de cero durante la UAT y en producción. Los defectos encontrados en UAT o producción serán la excepción. Si no sigue estas prácticas, gran parte de la velocidad de los equipos se perderá y pasará reparando defectos. Hemos encontrado que si un defecto encontrado en el desarrollo cuesta 1x, cuesta 2x corregir durante la prueba funcional, 3x para corregir durante UAT y 4x para reparar si se encuentra en producción. Como puede ver, el defecto de conducción a la izquierda (más temprano en el ciclo de vida del desarrollo) se paga por sí mismo.