- 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 |