Una vez desplegado, el sistema es a menudo un servicio durante años o incluso décadas. Durante esta vez el sistema y su entorno operacional a menudo se corrigen, cambiado o extendida. Las pruebas que se ejecuta durante esta fase del ciclo de vida son llamadas 'pruebas de mantenimiento'.
Tenga en cuenta que las pruebas de mantenimiento son diferente de las pruebas de mantenimiento, que define lo fácil que es para mantener el sistema.
El proceso de desarrollo y prueba aplicables a los nuevos desarrollos no lo hace cambiar fundamentalmente con fines de mantenimiento. Los mismos pasos del proceso de prueba se aplicará y, dependiendo del tamaño y el riesgo de los cambios hechos, varios los niveles de las pruebas se llevan a cabo: una prueba de componentes, una prueba de integración, un sistema de prueba y una prueba de aceptación. Un proceso de prueba de mantenimiento por lo general comienza con la recepción de una solicitud de cambio o un plan de lanzamiento. El director de pruebas se utilizar esto como una base para producir un plan de pruebas. Tras la recepción de la nueva o modificada especificaciones, los casos de prueba correspondientes se especifican o adaptados. Tras la recepción del objeto de prueba, los nuevos y modificados ensayos y las pruebas de regresión se ejecutan.
Al término de la prueba, se conserva una vez más la testware.
La comparación de las pruebas de mantenimiento para probar una nueva aplicación no es más que una cuestión de una aproximación desde un ángulo diferente, que da lugar a una serie de cambios de énfasis. Hay varias áreas donde la mayoría de las diferencias ocurrir, por ejemplo con respecto a la base de pruebas. Una operación de "puesta a nivel» es con frecuencia se requiere cuando se mantienen sistemas. Las especificaciones están menudo 'perdido', y un conjunto de testware relativa a las especificaciones simplemente No existe. Bien puede ser posible llevar a cabo esta operación de puesta al día acción junto con la prueba de una nueva versión de mantenimiento, lo que puede reducir la costó. Si no es posible compilar las especificaciones de la cual los casos de prueba puede ser escrita, incluyendo los resultados esperados, una base de prueba alternativo, por ejemplo, una oráculo de pruebas, se debe buscar como solución de compromiso. Una búsqueda debe ser realizada para la documentación que es más cercano a las especificaciones y los cuales pueden ser gestionados por los desarrolladores, así como testers. En tales casos, es aconsejable capaz de atraer la atención del cliente a la calidad de la prueba inferior que puede ser alcanzado. Ser conscientes de los posibles problemas de "producción diaria '. En el peor de los casos no se sabe lo que se está probando, muchos casos de prueba son ejecutado en el mismo escenario y si se encuentra un incidente que a menudo es difícil de rastrear de nuevo a el defecto real, ya que no trazabilidad para probar diseños y / o requisitos existe. Tenga en cuenta que la reproducibilidad de las pruebas también es importante para las pruebas de mantenimiento.
Un aspecto que, en muchos casos, difiere un poco del desarrollo situación es la organización del ensayo. Nuevo desarrollo y su ensayo apropiado actividades se llevan a cabo por lo general como parte de un proyecto, mientras que las pruebas de mantenimiento normalmente se ejecutan como una actividad en la organización periódica. Como resultado, a menudo existe cierta falta de recursos y la flexibilidad, y el proceso de prueba puede experimentar una mayor competencia de otras actividades.
2.4.1 Análisis del impacto y pruebas de regresión
Por lo general, las pruebas de mantenimiento constarán de dos partes: • Pruebas de los cambios
• Pruebas de regresión para mostrar que el resto del sistema no se ha visto afectada por los trabajos de mantenimiento.
Además de las pruebas de lo que se ha cambiado, las pruebas de mantenimiento incluye extensas pruebas de regresión para las partes del sistema que no han sido cambiado. Una de las principales actividades e importante dentro de las pruebas de mantenimiento es análisis de impacto. Durante el análisis del impacto, junto con las partes interesadas, una decisión se hace sobre qué partes del sistema pueden verse afectados involuntariamente y por lo tanto necesitan pruebas de regresión cuidado. El análisis de riesgos ayudará a decidir dónde enfocar las pruebas de regresión es poco probable que el equipo tendrá tiempo repetir todas las pruebas existentes.
Si las especificaciones de prueba desde el desarrollo inicial del sistema son cuidado, uno puede ser capaz de volver a utilizarlos para las pruebas de regresión y de adaptarlos para cambios en el sistema. Esto puede ser tan simple como cambiar los esperados resultados de las pruebas existentes. A veces pueden necesitar ser construida pruebas adicionales. Extensión o mejora del sistema pueden significar nuevas áreas han sido especificado y las pruebas se elaborarán al igual que para el desarrollo. También es posible que las actualizaciones son necesarias para un conjunto de pruebas automatizadas, que a menudo se utiliza para apoyar las pruebas de regresión.
2.4.2 Los disparadores para las pruebas de mantenimiento
Como pruebas de mantenimiento indicado se realiza en un sistema operativo existente. Es desencadenada por las modificaciones, la migración, o la jubilación del sistema.
Las modificaciones incluyen cambios de mejora planificadas (por ejemplo, base liberada), correspondiente cambios correctivos y de emergencia, y los cambios en el medio ambiente, tal como estaba previsto del sistema operativo o de bases de datos, actualizaciones o parches para recién expuestas o descubrir vulnerabilidades del sistema operativo. Pruebas de mantenimiento para la migración (por ejemplo, de una plataforma a otra) debe incluir pruebas de funcionamiento del nuevo entorno, así como el software modificado. Pruebas de mantenimiento para el retiro de un sistema puede incluir pruebas de migración de datos o archivo, si Se requieren períodos de retención de datos a largo.
Puesto que las modificaciones son más a menudo la parte principal de mantenimiento pruebas la mayoría de las organizaciones, esto se discutirá en más detalle. Desde el punto de vista de la prueba, hay dos tipos de modificaciones. Hay modificaciones en cuales se podrán planificarse, y hay modificaciones correctivas ad-hoc, que no se puede planificar en absoluto. Mantenimiento correctivo Ad-hoc se lleva a cabo cuando la búsqueda de soluciones a los defectos no se puede retrasar. Procedimiento de prueba especial se requiere en ese momento.
Modificaciones previstas
Los siguientes tipos de modificación prevista se pueden identificar:
• Modificaciones perfectivas (adaptación del software a los deseos del usuario, por ejemplo, mediante el suministro de nuevas funciones o la mejora del rendimiento);
• Modificaciones de adaptación (adaptación de software a los cambios ambientales, tal como nuevo hardware, nuevos sistemas de software o una nueva legislación);
• Modificaciones previstas correctivas (corrección de defectos diferible).
El método de prueba estándar estructurado es casi totalmente aplicable a planificada modificaciones. En promedio, modificación prevista representa más del 90% de todos trabajos de mantenimiento en los sistemas. [Pol y van Veenendaal]