Tarea: Determinar resultados de prueba
En esta tarea se describe cómo registrar de forma precisa los resultados de la prueba y qué tipo de seguimiento es necesario.
Objetivo

El objetivo de esta tarea es:

  • Realizar evaluaciones continuas del resumen de la calidad percibida del producto
  • Identificar y capturar los resultados detallados de la prueba
  • Proponer las acciones correctivas adecuadas para resolver anomalías en la calidad
Relaciones
RolesPrincipal: Adicional: Asistencia:
EntradasObligatoria: Opcional:
  • Ninguno
Externa:
  • Ninguno
Salidas
Pasos
Examinar todos los incidentes y anomalías de la prueba
Objetivo:  Investigar cada incidente y obtener información detallada de los problemas resultantes. 

En esta tarea, se analizan los registros de prueba para determinar los resultados de prueba significativos, teniendo en cuenta las diferencias entre los resultados esperados y los resultados reales de cada prueba. Identifique y analice uno a uno cada incidente y cada anomalía. Aprenda todo lo que pueda sobre cada aparición.

Busque los incidentes duplicados, los síntomas comunes y otras relaciones entre los incidentes. Estas condiciones proporcionan a menudo una pista importante sobre la causa raíz de un grupo de incidentes.

Crear y mantener solicitudes de cambio
Objetivo:  Especificar información de solicitud de cambio en una herramienta de seguimiento para la valoración, la gestión y la resolución. 

Las diferencias indican defectos potenciales en los elementos del destino de la prueba y se deben especificar en un sistema de seguimiento como incidentes o solicitudes de cambio, con una indicación de las acciones correctivas adecuadas que se deben realizar.

Subtemas:

Verificar los hechos de los incidentes Ir a la parte superior de la página

Verifique que estén disponibles datos de soporte precisos. Recopile los datos para adjuntarlos directamente a la solicitud de cambio, o haga referencia a dónde se pueden obtener los datos por separado.

Siempre que sea posible, compruebe que el problema sea reproducible. Los problemas reproducibles tienen una probabilidad mayor de recibir atención del desarrollador y que se solucionen; un problema que no se puede reproducir supone una frustración para el personal de desarrollo y malgasta recursos valiosos de programación en una búsqueda sin frutos. Aún así, se recomienda registrar estos incidentes, pero intente identificar los incidentes no reproducibles aparte de los reproducibles.

Aclarar los detalles de las solicitudes de cambio Ir a la parte superior de la página

Es importante que las solicitudes de cambio sean comprensibles, especialmente el titular. Asegúrese de que el titular sea claro y preciso, y que articule claramente el problema específico. Un titular breve es útil para las listas de defectos de resumen y el debate en las reuniones de estado CCB.

Es importante que la descripción detallada de la solicitud de cambio no sea ambigua y que se pueda interpretar fácilmente. Se recomienda registrar las solicitudes de cambio lo antes posible, pero dedique tiempo después a volver y mejorar y ampliar las descripciones antes de que lleguen a manos del personal de desarrollo.

Proporcione otras soluciones, tantas como resulte práctico. Esto permite reducir las ambigüedades restantes en la descripción y facilita la aclaración. También garantiza un aumento de la probabilidad de que la solución se aproxime a sus excepciones. Asimismo, demuestra que el equipo de prueba no sólo está preparado para encontrar los problemas, sino también para identificar las soluciones adecuadas.

Otros detalles a incluir son las capturas de imagen de pantalla, los archivos de datos de prueba, los scripts de prueba automática, la salida de los programas de utilidad de diagnóstico y otra información que puede resultar de utilidad a los desarrolladores para aislar y corregir la anomalía subyacente.

Indicar la gravedad del impacto relativo y la prioridad de las resoluciones Ir a la parte superior de la página

Proporcione una indicación de la gravedad del problema al personal de gestión y desarrollo. En los equipos más grandes, la prioridad de resolución real la determina el equipo de gestión, aunque puede dejar que las personas indiquen su prioridad de resolución preferida y la ajusten posteriormente según sea necesario. Como norma general, se recomienda asignar a las solicitudes de cambio una prioridad de resolución media por omisión, y aumentarla o disminuirla en cada caso según sea necesario.

Deberá diferenciar el impacto que tendrá la solicitud de cambio en el entorno de producción si no se ejecuta y el impacto que tendrá la solicitud de cambio en el esfuerzo de prueba si no se ejecuta. Es tan importante para el equipo de gestión saber cuándo afecta un defecto al esfuerzo de prueba, como para los usuarios ser conscientes de la gravedad.

A veces es difícil prever por qué necesita ambos atributos. Es posible que un incidente sea realmente grave, por ejemplo, una caída del sistema, pero que las acciones necesarias para reproducirlo sea muy poco probable que se produzcan. En este caso, el equipo puede indicar la gravedad como alta, pero indicar una prioridad de resolución muy baja.

Registrar las solicitudes de cambio adicionales por separado

A menudo, los incidentes ponen de manifiesto el dicho "Cuando el río suena, agua lleva"; cuando se identifica y se registra una solicitud de cambio, se identifican otros problemas que se deben solucionar. Evite la tentación de añadir simplemente estos resultados adicionales a la solicitud de cambio existente: si la información está directamente relacionada y ayuda a solucionar mejor el problema existente, es correcto. Pero si los otros problemas son diferentes, identificarlos en una CR existente puede hacer que no se accionen esos problemas, que no obtengan la prioridad correcta o que afecten a la velocidad con la que se solucionan otros problemas.

Analizar y evaluar el estado
Objetivo:  Calcular y proporcionar las medidas y los indicadores clave de la prueba. 

Subtemas:

Distribución de incidentes

Analice los incidentes basándose en dónde se distribuyen, por ejemplo, el área funcional, los riesgos de calidad, el verificador asignado y el desarrollador asignado.

Busque patrones en la distribución como, por ejemplo, áreas funcionales que aparentemente tengan un recuento de defectos por encima de la media. Asimismo, busque desarrolladores y verificadores que tengan una carga excesiva de trabajo y cuya calidad de trabajo esté disminuyendo

Cobertura de la ejecución de la prueba

Para evaluar la cobertura de la ejecución de la prueba, debe revisar los registros de prueba y determinar:

  • La proporción entre cuántas pruebas (scripts de prueba o guiones de prueba) se han realizado en este ciclo de prueba y el número total de pruebas de todos los elementos de prueba de destino previstos.
  • La proporción de guiones de prueba ejecutados satisfactoriamente.

El objetivo es garantizar que se han ejecutado de forma satisfactoria un número suficiente de pruebas destinadas a este ciclo de prueba. Si esto no es posible, o para aumentar los datos de ejecución, se pueden identificar uno o varios criterios de cobertura de prueba adicionales, basándose en:

  • La prioridad o el riesgo de calidad
  • La cobertura basada en la especificación (requisitos, etc.)
  • La prioridad o la necesidad empresarial
  • La cobertura basada en códigos

Consulte Concepto: Medidas clave de la prueba, Cobertura de la prueba basada en requisitos.

Registre y presente los resultados de la prueba en un informe de evaluación de prueba para este ciclo de prueba.

Estadísticas de solicitudes de cambio

Para analizar los defectos, debe revisar y analizar las medidas elegidas como parte de la estrategia de análisis de defectos. Las medidas de defectos que se utilizan con más frecuencia incluyen las siguientes medidas (a menudo expresadas en forma de gráfico):

  • Densidad de defectos - el número de defectos se muestra como una función de uno o dos atributos de defectos (por ejemplo, la distribución respecto al área funcional, o el riesgo de calidad comparado con el estado o la gravedad).
  • Tendencia de defectos - el recuento de defectos se muestra como una función en el tiempo.
  • Antigüedad de defectos - un informe especial de densidad de defectos en el que los recuentos de defectos se muestran como una función de la cantidad de tiempo que un defecto ha permanecido en un determinado estado (abierto, nuevo, esperando verificación, etc.)

Compare las medidas de este ciclo de prueba con los totales en ejecución de la iteración actual y los del análisis de iteraciones anteriores para entender mejor las tendencias emergentes en el tiempo.

Se recomienda presentar los resultados en un diagrama con los resultados de soporte de la solicitud.

Realizar una valoración de la experiencia de calidad actual
Objetivo:  Proporcionar información de retorno sobre la calidad actual experimentada y percibida en el producto de software. 

Formule un resumen de la experiencia de calidad actual, resaltando los aspectos buenos y malos de la calidad de los productos de software.

Realizar una valoración de los riesgos de calidad pendientes
Objetivo:  Proporcionar información de retorno sobre cuáles de las áreas de riesgo restantes proporcionan la máxima exposición potencial al proyecto. 

Identifique y explique aquellas áreas que no se hayan tratado todavía en términos de riesgos de calidad, e indique qué impacto y exposición suponen para el equipo.

Proporcione una indicación de qué prioridad considera que tiene cada riesgo de calidad pendiente, y utilice la prioridad para indicar el orden en el que se deben intentar solucionar estos problemas.

Realizar una valoración de la cobertura de la prueba
Objetivo:  Realizar una valoración de resumen del análisis de la cobertura de la prueba. 

Basándose en el trabajo del paso de cobertura de la ejecución de la prueba, proporcione una breve sentencia de resumen del estado y la información que representan los datos.

Esbozar el resumen de evaluación de la prueba
Objetivo:  Comunicar los resultados de la prueba a los interesados y realizar una valoración objetiva de la calidad y el estado de la prueba. 

Presente los resultados de la prueba de este ciclo de prueba en un resumen de evaluación de la prueba. Este paso consiste en desarrollar el borrador inicial del resumen. Se consigue ensamblando la información anterior que se ha recopilado en un informe de resumen legible. Dependiendo de los receptores interesados y del contexto del proyecto, el formato y el contenido real del resumen variará.

A menudo, es una buena idea distribuir el borrador inicial a un subconjunto de interesados para obtener información de retorno que puede incorporar antes de publicarla a un público más amplio.

Advertir a los interesados de los resultados clave
Objetivo:  Promover y hacer público el resumen de evaluación según corresponda. 

Utilizando los medios que sean necesarios, haga pública esta información. Se recomienda publicar estos datos en un sitio de proyecto centralizado, o presentarlos en reuniones convocadas regularmente para permitir recopilar información de retorno y determinar las próximas acciones.

Tenga en cuenta que hacer públicos los resúmenes de evaluación puede ser a veces una cuestión de sensibilidad política. Negocie con el gestor de desarrollo para presentar los resultados de forma que reflejen un resumen preciso y sincero de los resultados, respetando siempre el trabajo de los desarrolladores.

Evaluar y verificar los resultados
Objetivo:  Verificar que la tarea se ha realizado correctamente y que los productos de trabajo resultantes son aceptables. 

Ahora que ha terminado el trabajo, se recomienda verificar que el trabajo tenía el valor suficiente y que no sólo ha gastado una gran cantidad de papel. Debe evaluar si el trabajo tiene la calidad correcta y si es lo suficientemente completo para que resulte útil a aquellos miembros del equipo que vayan a utilizarlo posteriormente como entrada de su trabajo. Siempre que sea posible, utilice las listas de comprobación proporcionadas en RUP para verificar que la calidad y la completitud son lo "suficientemente buenas".

Fomente la participación en la revisión del trabajo interno de las personas que realizan tareas basadas en los resultados de su trabajo. Hágalo mientras todavía tenga tiempo para realizar acciones para solucionar sus problemas. También debe evaluar su trabajo en los productos de trabajo de entrada clave para asegurarse de que los ha representado de forma precisa y suficiente. Para ello, es muy útil hacer que el autor del producto de trabajo de entrada revise su trabajo.

Recuerde que RUP es un proceso de entrega iterativo y que en muchos casos los productos de trabajo evolucionan con el tiempo. Como tal, no siempre es necesario (y a veces es contraproducente) formar completamente un producto de trabajo que sólo se utilizará de forma parcial o que no se utilizará en absoluto en un trabajo inmediatamente posterior. Esto se debe a que existe una alta probabilidad de que la situación alrededor del producto de trabajo cambie (y que las suposiciones realizadas cuando se creó el producto de trabajo se demuestre que son incorrectas) antes de que se utilice el producto, lo que da como resultado un esfuerzo inútil y una revisión costosa. Asimismo, evite la trampa de invertir demasiados ciclos en la presentación en detrimento del valor del contenido. En entornos de proyecto en los que la presentación tenga importancia y un gran valor económico como entregable del proyecto, puede utilizar un recurso administrativo para ejecutar tareas de presentación.



Propiedades
Varias apariciones
Condicionado por sucesos
Continuo
Opcional
Planeado
Se puede repetir
Más información