Roki Tex: TE between the Developing and the Developed Countries

Resumen Resumen de las actividades

varianzas aprobaciones

evaluación integral Resumen de Resultados

5.3.3 Prueba de control

Los proyectos no siempre se desarrollan según lo previsto. De hecho, toda obra humana más complicado que un día de campo familiar es probable que varíe de plan. Los riesgos se vuelven ocurrencias. necesidades de los interesados evolucionan. El mundo que nos rodea cambia. Cuando planes y la realidad divergen, debemos actuar para llevar el proyecto de nuevo bajo control.

En algunos casos, los resultados de prueba en sí son detrás de la divergencia; para ejemplo, supongamos que la calidad de los elementos de las pruebas resulta inaceptablemente mala y retrasa el Progreso de la prueba. En otros casos, la prueba se ve afectada por eventos de afuera; para ejemplo, las pruebas pueden ser retrasada cuando los elementos de prueba llegan tarde o la prueba medio ambiente no está disponible. Control de prueba se trata de orientar las acciones correctivas para tratar de lograr el mejor resultado posible para el proyecto.

Las acciones correctivas específicas dependen, por supuesto, de lo que estamos tratando de controlar. Considere los siguientes ejemplos hipotéticos:

• Una parte del software bajo prueba será entregado tarde, después de la prueba prevista fecha de inicio. Las condiciones del mercado dictan que no podemos cambiar la fecha de liberación. Prueba de control podría implicar modificar las prioridades de las pruebas por lo que comencemos las pruebas en contra de lo que está disponible ahora.

• Por razones de coste, pruebas de rendimiento se ejecuta normalmente en las noches de la semana fuera del horario de la producción de ambiente. Debido a la alta demanda imprevista de sus productos, la compañía ha adoptado temporalmente un turno de tarde que mantiene el entorno de producción en uso 18 horas al día, cinco días a la semana. Prueba de control podría implicar la reprogramación pruebas de rendimiento para el fin de semana.

Aunque estos ejemplos muestran las acciones de control que afectan las pruebas, el equipo del proyecto también podría tener que tomar otras acciones que afectan a los demás en el proyecto. Por ejemplo, supongamos que la fecha de terminación de la prueba está en riesgo debido a un elevado número de reparaciones de defectos que hacen fallar la prueba de confirmación en el entorno de prueba. En este caso, el control de prueba podría implicar que los programadores requieren hacer las correcciones para volver a probar a fondo las correcciones antes de registrarse en el código repositorio para su inclusión en una compilación de prueba.

5.4 GESTIÓN DE LA CONFIGURACIÓN

1 resumen cómo soportes de gestión de configuración pruebas. (K2)

En esta breve sección, vamos a ver cómo la gestión de configuración se refiere a las pruebas y apoya. Usted se encontrará con el glosario términos de gestión de configuración y control de versiones.

Gestión de la configuración es un tema que a menudo confunde a los nuevos practicantes, pero, si alguna vez tiene la mala suerte de trabajar como tester en un proyecto donde se manipula esta actividad crítica mal, Nunca se le olvide lo importante que es. En pocas palabras, la gestión de la configuración es, en parte, sobre determinar claramente los elementos que componen el software o sistema. Estos elementos incluyen código fuente, scripts de prueba, el software de terceros, hardware, datos, desarrollo y documentación de prueba. gestión de la configuración también trata de asegurar que estos elementos se utilizan cuidadosamente, a fondo y con atención a lo largo de todo el proyecto y ciclo de vida del producto.

Gestión de la configuración tiene una serie de importantes implicaciones para la prueba. Por un lado, permite a los testers gestionar sus testware y resultados de pruebas utilizando la misma configuración de mecanismos de gestión, como si fueran tan valioso como el código fuente y la documentación para el sistema en sí.

Por otro lado, la gestión de la configuración apoya la construcción del proceso, que es esencial para la entrega de una liberación de prueba en el entorno de prueba. El simple envío de archivos Zip por correo electrónico no será suficiente, porque hay demasiadas oportunidades para este tipo de archivos a contaminarse con contenidos no deseados o para albergar sobrante Las versiones anteriores de elementos. Sobre todo, en las últimas fases de

la prueba, es fundamental contar con una manera sólida y fiable de entrega de elementos de prueba que funcionan y son la versión correcta.

Por último, pero no menos importante, la administración de configuración nos permite mapear lo que se está probando a los archivos y componentes subyacentes que lo componen. Esto es absolutamente crítico. Por ejemplo, cuando nos informa defectos, tenemos que informar sobre ellos contra algo, lo que la versión controló. Si no está claro lo que encontramos en el defecto, los programadores tendrán un tiempo muy difícil de encontrar el defecto para fijarlo. Para el tipo de informes de prueba se discutió anteriormente para tener cualquier sentido, hay que ser capaz de rastrear los resultados de la prueba de nuevo a lo que probamos exactamente.

Idealmente, cuando se los somete a una prueba organizada, bajo control de versiones de liberación de un repositorio de código fuente gestionados cambio, es acompañado por un elemento de transmisión de prueba, informes o notas.

[IEEE 829] proporciona una guía útil para lo que sucede en tal informe. Notas de la versión no son siempre tan formal y no siempre contienen toda la información que se muestra. Mientras que nuestra descripción fue breve, gestión de la configuración es un tema que es tan compleja como la gestión de medio ambiente. Así que, planificación avanzada es fundamental para hacer este trabajo. Durante la planificación del proyecto y tal vez como parte de su propio plan de pruebas hay que asegurarse de los procedimientos y herramientas de administración de configuraciones seleccionado. A medida que avanza el proyecto, el proceso de configuración debe implementar mecanismos e interfaces claves en el

resto del proceso de desarrollo, esto debe ser documentado. Prueba en tiempo de ejecución, esto permitirá que usted y el resto del equipo del proyecto tengan sorpresas desagradables, como las pruebas del software equivocado, construyendo instalable inadecuados y comunicando defectos irreproducibles contra versiones de código que no existen más que en la prueba ambiente.

LA PLANTILLA IEEE 829 STANDARD: TEST DE ELEMENTOS DE INFORME