Contenido
Pruebas de componentes
También llamadas pruebas unitarias, se ejecutan en la primera etapa donde los desarrolladores ya cuentan con los componentes del sistema desarrollados. Regularmente cada desarrollador prueba que sus componentes funcionen de acuerdo a lo esperado. Los componentes pueden ser dependiendo del lenguaje que se esté usando: módulos, unidades y clases en el caso de programación orientada a objetos.
Para estas pruebas regularmente se usan herramientas de depuración donde el programador va revisando línea a línea el comportamiento del código, al momento de detectar algún defecto procede a analizarlo y a resolverlo.
Las pruebas de componentes son las primeras pruebas a las que se somete el software.
Pruebas de integración
Se ejecutan una vez concluidas las pruebas de componentes se ejecutan pruebas teniendo todos o la mayor parte de componente integrados, para verificar que todos operen correctamente de manera conjunta. Se valida el software a través de varias interfaces y casos de uso tomando en cuenta que la salida de un componente es la entrada de otro.
En sistemas de tamaño medio a grande, estas pruebas regularmente son ejecutadas por los especialistas en pruebas con apoyo de los desarrolladores, requieren de una entidad que juegue el papel de mediador entre los diversos grupos que participan en estas pruebas.
A diferencia de las pruebas unitarias, las pruebas de integración, requieren una mejor estructura y organización, requiere al menos de un plan de pruebas.
Pruebas de sistema
Sirven para validar que todas las funciones y componentes del sistema colaboran correctamente. Estas pruebas se ejecutan una vez concluidas las pruebas de componentes y las de integración, a diferencia de estas 2 pruebas, las pruebas de sistemas se realizan desde el punto de vista del usuario y validan en su totalidad los requerimientos del usuario especificados e incluso aquellos no especificados u olvidados que afectan el funcionamiento del sistema.
Según Bourne, al inicio de las pruebas de sistema sólo se han completado la mitad de los trabajos de control de calidad y pruebas, en especial cuando se habla de un sistema cliente-servidor. Esto da evidencia de la necesidad de estas pruebas.
Pruebas de aceptación
Antes de la liberación del software en el ambiente productivo es altamente recomendable que el usuario final valide el producto. El objetivo de estas pruebas es validar que el proveedor entendió y desarrolló lo que el usuario solicitó.
Existen 4 tipos de pruebas de aceptación:
- Pruebas de aceptación de contrato: El cliente prueba junto con el proveedor del sistema y con ello se decide si el sistema está listo para su liberación a producción o si requiere alguna modificación o corrección. Los criterios de aceptación sólo son los incluidos en el contrato de desarrollo. Estas pruebas se deben de ejecutar en el ambiente real (productivo).
- Pruebas de aceptación de usuario: Se recomienda cuando el usuario es diferente al cliente. El cliente suele organizar esta prueba y seleccionar los escenarios de uso típico. Se toma en cuenta el punto crítico del usuario.
- Pruebas de aceptación operativa: Busca la aceptación del sistema por parte de los administradores que le darán soporte. Se pueden validar la generación y restauración de copias de seguridad, recuperación de desastres, gestión de usuarios y controles de seguridad.
- Pruebas de campo (también llamadas pruebas alfa o beta): Es una prueba de campo controlada usada especialmente cuando existen diferentes entornos de usuarios incluso algunos de ellos inexplorados previamente. Se recomienda cuando el sistema está pensado para el mercado en general.