menu_superior

Cómo aplicar el testing de aceptación

testing de aceptación

Recientemente he tenido la oportunidad de impartir una formación sobre pruebas de aceptación en un cliente que está cambiando su modelo de desarrollar software hacia un modelo de factoría. En principio el equipo tecnológico del cliente pasará de ocuparse del ciclo de vida completo a hacerlo sólo de la especificación de requisitos y de las pruebas de aceptación posteriores. Es un

caso muy obvio para aplicar pruebas de aceptación, y por eso necesitan la formación, pero no único, ya que las pruebas de aceptación son necesarias siempre que el desarrollo de software depende de un proveedor externo.

Aprovechando que con motivo del curso le he dado muchas vueltas a las pruebas de aceptación, me he decidido a escribir este post con el objetivo de señalar los aspectos más importantes a la hora de establecer un proceso de testing de aceptación:

  1. La aceptación de software depende de los requisitos. Estos requisitos deben ser precisos en cuanto a las características que debe reunir el producto que se adquiere, cuanto más precisos sean más probabilidades hay de las pruebas que diseñemos sean efectivas y que su superación implique el cumplimiento de las necesidades del usuario y/o del negocio.
  2. La aplicación de las pruebas de aceptación depende del contexto. Si el producto se divide en fases, es necesario planificar pruebas de aceptación parciales para cada fase, pruebas de regresión para asegurar que cada entrega no afecta a las partes ya aceptadas y pruebas de integración para asegurar que el software entregado funciona al completo de acuerdo con los requisitos del producto final.
  3. Cada ciclo, cada batería y cada caso de prueba, debe estar mapeado con los requisitos. Si no disponemos de una trazabilidad real end-to-end no podemos detallarle al proveedor qué parte de su software es la que bloquea la aceptación. Aún en el caso de que algunas de las pruebas que diseñemos no estén amparadas por ningún requisito, se puede especificar un requisito de “condiciones generales” para que haga de cobije este tipo de casos de prueba.
  4. El plan de pruebas se debe poner  a disposición del proveedor al principio. La idea es que por un lado el proveedor tenga una idea de qué pruebas le haremos al software que nos entregue y, por otro, el plan continúe madurando (haciéndose más detallado y más completo) hasta el mismo momento de la aceptación.
  5. Se pueden y se deben hacer pruebas exploratorias. Creo que es importante complementar las pruebas de aceptación con un pequeño ciclo exploratorio. El motivo es muy sencillo, al ser unas pruebas surgidas directamente de unos requisitos necesitamos que el testing exploratorio cubra la ejecución de casos de prueba que se queden en el tintero en el momento del diseño del plan de pruebas.
  6. El mecanismo de aceptación es claro para todos desde el principio. Esta es de esas recomendaciones que no se suelen tener en cuenta por que todos creen haber entendido el mecanismo de aceptación… hasta que llega el momento de aceptar una entrega que tiene defectos que no son bloqueantes y, pase lo que pase tanto proveedor como cliente tienen razones para sentirse traicionados por la otra parte. Para evitar este tipo de problemas hay que definir cómo se producirá la entrega, cuanto tiempo hay para hacer las pruebas, que plazo hay para resolver incidencias y reprobar, si existe o no un periodo de garantía y cual es el indicador (no es exactamente un SLA, pero este concepto puede valer para hacernos una idea) que permite considerar al producto como aceptable.
  7. Establece una relación de confianza con tu proveedor. Este es un punto importante que no parece tan obvio. Hay que tener en cuenta que a ni a proveedor ni a cliente les interesa que el proceso se lleve a cabo en un ambiente tenso por que ambos tienen mucho que perder: al cliente le interesa tener el software productivo lo antes posible y al proveedor que no haya rechazos para que su rentabilidad no disminuya… Es importante que ambos sean generosos y que no se utilice el contrato para rechazar software por pequeños defectos ni para retrasar el comienzo pidiendo detalles en los requisitos que no están disponible.
Como he escrito en ocasiones anteriores, la idea de estas recomendaciones no escapa del contexto de su aplicación. En cualquier caso me parece que son una buena base de la que partir a la hora de definir un proceso de aceptación de software basado en pruebas.
Comments are closed.