- Introducción.
- Fundamentos teóricos.
- Descripción del proceso de pruebas de aceptación.
- Un ejemplo práctico.
- Propuesta de automatización del proceso.
- Valor Práctico
- Conclusiones
- Referencias
- Anexo
El desarrollo de software con la calidad requerida es hoy un reto de nuestra universidad. Cuando se construye software a la medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide y verifique todos 1os requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo del sistema.
El presente trabajo resume las experiencias de las pruebas de aceptación con el cliente realizadas en Venezuela a los productos software "Registro y Notaria" e "Identidad", siendo el objetivo del mismo definir y describir el proceso a seguir para realizar las pruebas de aceptación con el cliente, el flujo de comunicación entre el equipo de desarrollo y el grupo de calidad, así como toda la documentación empleada y generada en este proceso.
Palabras clave: Pruebas, aceptación, calidad.
Abstract
One of the current challenges of our university is the development of software with high quality. For developing software with the requirement needed for the client, it is necessary to do tests in order to check the client’s acceptation. It is done by the final user instead of the Head of the System of Development.
This work is motivated from the experience in working with test of acceptation done in Venezuela to the software: "Registro y Notaria" and "Identidad". Our aim is to define and to describe the steps needed for doing the mentioned test of acceptation, the communication flow between the team of developing and the quality group, as well as the documentation used and generated in this process.
Keywords: Test, accept, quality.
1. Introducción.
La calidad no es algo que se pueda agregar al software después de desarrollado si no se hizo todo el desarrollo con la "calidad" en mente. Muchas veces parece que el software de calidad es aquél que brinda lo que se necesita con adecuada velocidad de procesamiento. En realidad, es mucho más que eso. Tiene que ver con la corrección, pero también con usabilidad, costo, consistencia, confiabilidad, compatibilidad, utilidad, eficiencia y cumplimiento de los estándares. Todos estos aspectos de la calidad pueden ser sometidos a pruebas que determinen la calidad. Incluso la documentación para el usuario debe ser probada.
La calidad tiene un costo asociado y las pruebas como proceso para controlar la calidad consume tiempo, personal y otros recursos, como en todo proyecto de cualquier índole, siempre se debe tratar que las fallas sean mínimas y al menor costo posible. La fase de pruebas añade valor al producto que se maneja: todos los programa tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo principal de la fase de pruebas es encontrar la mayor cantidad de errores y defectos.
Es virtualmente imposible que un desarrollador de software pueda prever como utilizara el usuario realmente el programa. Se pueden malinterpretar las instrucciones de uso, se pueden utilizar habitualmente extrañas combinaciones de datos, y una salida que puede parecer clara para el responsable de las pruebas y puede ser ininteligible para el usuario, hay errores que sólo el cliente puede detectar: "El cliente siempre tiene razón".
El cliente es quien impone los requisitos quien mejor que él para dar fe de su satisfacción además no debemos dejar de la mano la existencia de la calidad percibida que por cruel que nos parezca determina en como nuestro software será aceptado.
Página siguiente |