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