domingo, agosto 31, 2014

Software funcionando sobre....¿pruebas exhaustivas e intensivas?

Siempre me he mantenido en algo que aprendí de tantas conversaciones con mis amigos y compañeros haciendo software, y de la experiencia:

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y NO AL CONTRARIO

igual se podría leer en el contexto organizacional

LA CALIDAD 
Y/O PROCESOS DEBEN TRABAJAR PARA LA ORGANIZACIÓN Y NO AL CONTRARIO 


En Agile damos prioridad a software funcionando, pero es necesario hacer pruebas, ¿cuántas?¿cuáles?, la repuesta es: todas y cada una que le permitan entregar un software funcional y de valor, de modo que usted no pierda la tranquilidad y el sueño luego de terminar su jornada laboral, léase entonces:

  • pruebas par
  • pruebas unitarias
  • pruebas funcionales
  • pruebas de integración
  • pruebas de seguridad
  • pruebas de compatibilidad
  • pruebas de adaptabilidad 
  • pruebas de instalabilidad..
  • pruebas de stress
  • etc
  • etc
  • etc
Pero cuantas y cuales..vuelvo y lo repito  LAS NECESARIAS ni una más, ni una menos.

A que se refiere esto, por ejemplo dentro de las prácticas ágiles se encuentran:
  •  TDD : Test driven development - desarrollo dirigido por las pruebas
  • ATDD: Aceptance test driven development - desarrollo dirigido por las pruebas de aceptación
Y hablamos de cobertura (cuantas pruebas aseguran nuestro código).

Sobre lo que quiero llamar la atención es:
  • NO ES NECESARIO cubrir todo el código con pruebas unitarias (ejemplos los POJO, DTO, o VO no lo requieren), solo objetos que tengan lógica de negocio (es mi humilde recomendación, ahora si a tu equipo esto le agrega valor, lo acepto y difiero respetuosamente).
  • Ni es estratégico  volcarse a una cobertura de 100% de pruebas sobre el código.

Nuestro objetivo es proveer software funcional, las pruebas nos ayudan a hacer software funcional pero como tal:
  • Las pruebas no son un entregable que agregue valor al cliente, me explico, si hacemos pruebas o no al cliente no le interesa, a el solo le interesa que funcione y no falle..
  • Las pruebas codificadas se convierten en una pieza de código más para mantener
    • incluir en el servidor de integración continua
    • hacerle refactor
    • corregir,
    • adaptar,
    • etc
Por lo tanto,  hagamos las pruebas suficientes para estar tranquilos y que nos aseguren ENTREGAR SOFTWARE DE CALIDAD.


LA CALIDAD NO ES NEGOCIABLE...

Pero 

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y el no software para cumplir con tdd del 100%, atdd del 100%, etc, etc.



Saludos ágiles
Jorge Abad

2 comentarios:

  1. Jorge, la calidad no es negociable simplemente porque no tiene valor o su valor tiende a infinito.

    Es lo que muchos no han terminado de entender. Yo particularmente desconfío de quienes lo hacen porque pienso que son capaces de vender su alma al mejor postor.

    ¿O acaso negociarías la calidad de los frenos de tu automóvil cuando conduces con toda tu familia a bordo?

    Salud@s.

    ResponderBorrar
  2. De acuerdo con que la calidad no es negociable, pero difiero con que a los clientes no les importa, por suerte ya se está cambiando la conciencia de muchos, y cada vez serán más los que pidan un porcentaje decente de cobertura de código con pruebas automatizadas y además pagan por tener esa cobertura.... Yo diría que lo estamos logrando: vamos por buen camino en cambiar la industria del software. Saludos!

    ResponderBorrar