Inicio
 > Informes e investigaciones > Blog de TEC > Aseguramiento de la calidad mediante pruebas de ...

Aseguramiento de la calidad mediante pruebas de aceptación

Escrito por: James Lyndsay
Publicado: julio 4 2006

Pruebas de aceptación

El software puede estar hecho por la gente que lo usa o se puede comprar a granel, y en el medio se encuentran los sistemas que se construyen con una esencia compartida, pero que se adaptan o se configuran de acuerdo a las necesidades de un comprador único. Generalmente, los grandes proyectos comerciales de tecnología de la información (TI) pertenecen a este grupo. El software se adapta especialmente para una empresa y sus diferencias le permiten proporcionar un valor estratégico, además de que es más maduro y rentable que el software que se crea desde cero.

Si la situación le parece conocida, entonces este artículo es para usted. Ya sabe que el costo que el sistema representa para su empresa rebasa las tarifas por licencias y los pagos que hace a su proveedor por las adaptaciones. En términos monetarios, el valor de un sistema que trabaja correctamente es mayor para usted que para su proveedor -al igual que el riesgo en caso de que fracase.

Al comprar software, usted tiene muy poca influencia directa en la calidad del trabajo de su proveedor. Es probable que él no cuente con los medios para predecir la forma en que el sistema se comportará una vez que se encuentre en su ambiente del negocio, ya que esto es algo que únicamente su empresa puede juzgar y evaluar con precisión. Las estrategias existentes de aseguramiento de la calidad, que se basan en la prevención de los problemas, pueden no ser adecuadas para su situación. Entonces ¿cómo sabe si el sistema será valioso? ¿Cómo sabrá que ha tomado las medidas necesarias para descubrir los riesgos?

Las pruebas de aceptación son el trabajo que usted realiza para examinar el producto que le ofrece su proveedor. Este trabajo se puede clasificar en tres áreas: evaluación del valor, evaluación del riesgo y soporte de estas evaluaciones, que puede obtener mediante la evaluación de las prácticas de trabajo de su proveedor.

1 Evaluación del valor

Una parte esencial de las pruebas de aceptación reside en demostrar que el sistema hace lo que debe hacer. Básicamente, implica una lista de expectativas que se compara con el software, empezando por la expectativa más importante hasta recorrer toda la lista.

No es difícil hacer de esta lista de expectativas una lista simple de funcionalidades. Sin embargo, el valor del sistema puede residir en la forma en que dichas funcionalidades trabajan en conjunto y los resultados que produzcan en la práctica. ¿Tiene capacidad de respuesta? ¿Es fácil de usar? ¿Qué cambios deberemos hacer a nuestro flujo de trabajo? ¿Podemos aprovechar todo lo que esperábamos? ¿Existen oportunidades que no habíamos contemplado?

El valor del sistema también dependerá de su confiabilidad, su seguridad y su flexibilidad. Sin ellas, el valor se desplomará, y, aunque su ausencia resulta evidente, su vulnerabilidad a las circunstancias no puede ser evaluada tomando en cuenta únicamente el valor.

2 Evaluación de los riesgos

Es probable que su empresa no cree el software, pero seguramente tratará con todos los problemas del sistema. El descubrimiento de los riesgos es complicado, ya que no puede predecir su alcance de forma confiable, ni puede decir que ha terminado simplemente por que completó una serie de tareas. Por el contrario, debe emitir un juicio con base en el tiempo (y con qué resultados) que ha pasado buscando problemas y el número de los mismos que ha encontrado.

Para sacar el mejor provecho de los recursos disponibles, debe tratar de ver el panorama y poder reunir los problemas que vayan surgiendo. Para sostener la eficacia de su búsqueda, debe reconocer los enfoques que producen pocos resultados y pasar a alternativas más viables.

Algunas estrategias se concentran principalmente en los problemas relacionados con el programa principal o los requisitos. Si está comprando software maduro para usar en varios sitios y tiene confianza en que ya se han detectado y solucionado dichos problemas, podrá concentrar sus esfuerzos en otra cosa. Buscar problemas inesperados que no surgirían en otras empresas puede resultar productivo, especialmente si busca los problemas relacionados con los cambios y la configuración que hacen que su versión del software sea única, así como los problemas en la forma en que el sistema interactúa con sus sistemas, procesos y equipos particulares.

3 Evaluación del trabajo de su proveedor

Su proveedor estará muy ocupado haciendo pruebas a medida que adapta y extiende su sistema para que cubra sus requisitos específicos. Las pruebas son una parte clave del desarrollo de software y pueden separarse en las negociaciones del presupuesto. Sin embargo, las pruebas por sí solas no producen ningún entregable que funcione, sino información sobre el producto y el proyecto que es de gran valor para el proveedor y el adquiriente.

Como adquiriente, usted debe esperar ver una parte de esta información y sacar algún valor particular del plan de pruebas (incluyendo los detalles del trabajo de las pruebas que se han terminado), así como la lista (que está en constante cambio) de los problemas que se conocen y que siguen sin resolverse. Usted, como pagador de las facturas, también puede estar involucrado en la estrategia general de pruebas, sobre todo si no participa directamente en las decisiones sobre calidad y puntualidad que se toman durante el desarrollo.

Los contratos y el periodo de aceptación

Es evidente que terminar este trabajo tomará tiempo. Cuanto más tiempo pase haciéndolo, mayor será el retraso entre la entrega del sistema y el punto en que pueda aportar algún valor a su empresa. Por otro lado, un sistema nuevo representará tanto riesgo como valor, así que habrá que hacer un sacrificio. Los problemas surgirán en las pruebas y hasta en el funcionamiento real del sistema. Por lo tanto, las preguntas acerca de quién deberá pagar el diagnóstico y la resolución de esos problemas debe tratarse en el contrato, presentando el concepto de "periodo de aceptación".

El elemento principal del contrato que nos interesa es el programa de pagos y, en especial, las decisiones que lo soportan. Se puede pagar una parte durante o antes de la entrega y retener el resto hasta que usted esté satisfecho con el trabajo del proveedor. Es evidente que hay espacio para las negociaciones, tanto en el contrato como en el punto de pago. Generalmente, la negociación gira en torno a la longitud y la flexibilidad del periodo y la forma en que el adquiriente evalúa la calidad del trabajo que realiza el proveedor.

Algunas veces, se llega a un acuerdo inmediato sobre las fechas de entrega y de pago. Si la fecha de entrega cambia, la fecha de pago debe cambiar en consecuencia para proteger el tiempo que usted necesita para evaluar el software que se le entrega. Este arreglo beneficia al proveedor, especialmente si el pago está relacionado con una fecha fija en que se utilizará el sistema en vivo, o si su empresa no tiene mucha experiencia en la evaluación de software.

Existen otros enfoques que pueden ser más específicos con respecto a la calidad del entregable, y que pueden incluir medidas como el número de problemas severos pendientes o el periodo que debe funcionar el entregable sin fallas. Si el software falla con demasiada frecuencia o si el proveedor tarda mucho tiempo en resolver los problemas, se pueden imponer algunas penalizaciones. Este enfoque puede resultar ventajoso para el adquiriente, aunque la imposición de costos de cambios en el desarrollo y los retrasos en los pagos al proveedor pueden ser motivo de una relación difícil. Cuando estos costos no dan al proveedor un incentivo comercial suficiente para reparar o completar el sistema, ambas partes salen perdiendo.

Usted puede incluir un periodo de "garantía" en su contrato. Generalmente, este periodo es mucho más corto que la garantía sobre artículos más importantes. Un periodo de garantía sobre una propiedad o un vehículo puede medirse en años, mientras que el mismo término aplicado al software se mide en meses o semanas, o no se mide. Existe un término más preciso -periodo de aceptación-que también refleja la verdad subyacente. Una vez que se vence este periodo de aceptación, el adquiriente debe asumir los costos relacionados con la resolución de los problemas.

Conclusión

La inversión que usted realice en un sistema nuevo no estará relacionada con el costo de las licencias ni el costo de implementación, sino con las oportunidades que traerá este sistema nuevo y los riesgos que implicará. En este artículo, describí los tres elementos clave de las pruebas de aceptación e hice énfasis en algunos asuntos que pueden negociarse.

 
comments powered by Disqus

Búsquedas recientes:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others