Mejora del proceso de prueba (TPI) utilizando el modelo PDCA

¿Qué es la mejora del proceso de pruebas?

Mejora del proceso de prueba Se trata de la práctica de medir el rendimiento de un proceso de pruebas, identificar sus puntos débiles y aplicar cambios controlados para que el siguiente proyecto ofrezca mayor calidad a menor coste y en menos tiempo. Considera las pruebas como un proceso medible y optimizable, en lugar de una actividad que se repite de la misma manera en cada lanzamiento.

Imagina el GuruEl proyecto del Banco 99 acaba de finalizar. La junta directiva valora tu trabajo y el cliente está satisfecho. Aun así, tu jefe todavía tiene algunas preguntas para ti.

Los gerentes a menudo describen pruebas de software como un proceso problemático e incontrolable. Mirando hacia atrás GuruEn el proyecto del Banco 99, ¿se enfrentó a alguno de los siguientes problemas?

Estos son problemas comunes en casi cualquier proyecto de pruebas. Muchas organizaciones se dan cuenta de que mejorar el proceso de pruebas es la única forma duradera de resolverlos, ya que aprender de los errores del pasado es lo que evita que se repitan en el siguiente ciclo de lanzamiento.

¿Por qué probar la mejora del proceso?

El siguiente escenario muestra por qué la mejora del proceso de pruebas es importante. GuruEl proyecto 99 Bank está terminado, la calidad de las pruebas fue excelente y recibimos buenos comentarios del cliente.

¿Cuál es la lección aprendida de este escenario? Es simplemente “Siempre intenta hacerlo mejor”Incluso cuando crees que has hecho un buen trabajo, siempre hay otros que lo hacen mejor, porque han encontrado mejores ideas y mejores soluciones que las tuyas.

Cada empresa quiere que el proyecto se complete con el más alto calidad, en el más bajo costo, y en el más corto tiempo de entrega. La mejora del proceso de pruebas es lo que ayuda a un equipo de pruebas a avanzar hacia los tres objetivos al mismo tiempo.

¿Cómo implementar la mejora del proceso de pruebas?

Para implementar la mejora del proceso de pruebas en el GuruProyecto 99 Bank, el gerente de pruebas puede seguir el PDCA El ciclo PDCA (Planificar-Hacer-Verificar-Actuar) es un método de gestión de cuatro pasos utilizado en los negocios para el control y la mejora continua de un proceso. Cada iteración del ciclo constituye un ciclo de mejora, y el resultado de la acción se convierte en el insumo del siguiente plan.

Paso 1) Planificar

La fase de planificación es donde se diseña la mejora. Está dividida en tres pasos más pequeños.

Paso 1.1) Identificar el problema

La primera actividad de un proceso de mejora de pruebas es identificar los problemas que ocurrieron en el proyecto actual. Los problemas en este proyecto pueden volver a ocurrir en otro proyecto. Resolver problemas y encontrar soluciones para evitarlos en el futuro es el objetivo principal de Test Improvement.

Ahora volvamos al proyecto. Guru¿Encuentras algún problema o sugerencia de mejora en la página web de 99 Bank? Selecciona a continuación.

Paso 1.2) Determinar el objetivo

Comprenda el problema y las dificultades que surgieron en el proyecto. Así podrá determinar los puntos de mejora y las fases de prueba que requieren atención prioritaria.

Suponga que ha identificado que la fase de ejecución de la prueba tomó demasiado mucho más tiempo y costo de finalización. ¿Se podrían agilizar y abaratar las pruebas? Esta pregunta se convierte en el objetivo del ciclo. Un objetivo útil se expresa como una cifra y una fecha límite, por ejemplo, «reducir el esfuerzo de ejecución de las pruebas de regresión en un 30 % antes del próximo lanzamiento».

Paso 1.3) Definir las acciones de mejora

En función del objetivo acordado, se determinan las acciones de mejora. Estas acciones deben ser graduales e implementarse poco a poco, ya que no es realista cambiarlo todo de inmediato.

Por ejemplo, para que las pruebas sean más rápidas y económicas, se pueden considerar las siguientes acciones.

En el ejemplo anterior, las opciones A y B hacen que las pruebas sean más rápidas y económicas. La opción C las haría más rápidas, pero también más caras, ya que un tester con más experiencia cobra un salario más alto. Esta disyuntiva es precisamente la razón por la que cada acción candidata debe evaluarse en función del objetivo, no de la intuición.

Paso 2) Hacer

Ya has definido los puntos de mejora. Ahora es el momento de elaborar un plan para implementarlos. Este plan debe responder a las siguientes preguntas.

• ¿Qué mejoras deben implementarse y en qué orden?
• ¿Cuándo debe estar terminado el plan?
• ¿Qué pasos deben completarse para lograr el plan?
• ¿Quién es el responsable de cada paso y cómo se confirmará su finalización?

Realizar acciones de mejora

Una vez establecido el plan, debe implementarse. Las actividades de mejora pueden perturbar el trabajo de prueba que ya está en marcha, por lo que un gerente de pruebas debe prestar atención. Whatsapp a ellos para poder evitar lo no deseado Consecuencias.

Considere el siguiente escenario. En el GuruProyecto 99 Bank, para que las pruebas sean más rápidas y económicas, decidiste utilizar pruebas de automatización En lugar de un gran bloque de pruebas de regresión manuales. Tras la aplicación de la medida, la productividad aumentó significativamente.

Paso 3) Verificar

En el paso de Verificación, usted realiza tres acciones.

• Evalúa el eficiencia de las acciones de mejora de las pruebas
• Medir como eficaz la solución fue
• Analizar si podría ser mejorada promover

El objetivo de esta fase es confirmar que las acciones de mejora se implementaron con éxito y evaluar si se ha alcanzado realmente el objetivo establecido en el Plan.

La mejor manera de realizar esa evaluación es con métricaLas métricas son esenciales para una gestión organizacional exitosa. El gerente de pruebas recopila datos y los utiliza para medir parámetros como la productividad, la calidad y el costo.

Por ejemplo, antes de que se aplicara la automatización al proyecto, la productividad de las pruebas era 10 casos de prueba por hora-hombreDespués de aplicar la automatización, la productividad se midió en 20 casos de prueba por hora-hombre.

Pero junto con esa ganancia surgió un problema indeseado.

En este caso, aplicando la automatización aumentado la productividad de las pruebas, pero la calidad de las pruebas disminuidoPor lo tanto, una medida de mejora puede causar graves problemas. Consecuencias en otro lugar. En tal escenario, la herramienta de prueba debe seleccionarse con mucho más cuidado, y el conjunto automatizado debe revisarse con el mismo rigor que el código de producción. Una evaluación estructurada de las herramientas candidatas, como la descrita en el Selenium tutoriales, impide que una herramienta se adopte simplemente porque es popular.

Consideremos el mismo escenario nuevamente. El GuruEl costo del proyecto 99 había invadir porque los miembros del equipo también se tomaron mucho tiempo para ejecutar los casos de prueba. Al utilizar la herramienta de prueba automatizada, guardó el 30 por ciento del costo del proyecto. Eso es una buena mejora, pero tu jefe espera más.

Por lo tanto, siempre hay que buscar soluciones más novedosas que mejoren aún más el proceso de pruebas. En este caso, otras opciones pueden ahorrar costes adicionales del proyecto.

• Gestiona tus recursos humanos de forma eficaz, de modo que los evaluadores cualificados se utilicen donde aporten mayor valor.
• Negocie mejores condiciones comerciales con sus proveedores de herramientas y personal.
• Retirar los casos de prueba duplicados o de bajo valor en lugar de automatizarlos.

Paso 4) Actuar

Cuando las acciones de mejora se hayan implementado con éxito y se haya alcanzado el objetivo, el responsable de pruebas deberá completar el ciclo con las siguientes actividades.

• Revisar las actividades de mejora y actuar en función de las lecciones aprendidas
• Estandarizar el punto de mejora dentro del proceso de gestión de pruebas
• Actualizar los documentos de política, las plantillas de planes de prueba y los documentos de procesos estándar
• Determinar cuándo y dónde se aplicarán estos cambios en el próximo proyecto

Si no se alcanzó el objetivo, el ciclo no se detiene. El objetivo no alcanzado se traslada a una nueva fase de planificación junto con toda la información que la fase de verificación reveló sobre las razones del bajo rendimiento de la acción.

Comparación entre TPI NEXT, TMMi y CMMI

El ciclo PDCA es el motor de la mejora, pero un modelo de referencia indica cómo debería ser un estado "mejor". Se suelen utilizar tres modelos, que a menudo se confunden entre sí.

TPI NEXT Es un modelo de referencia específico para pruebas, publicado por Sogeti. Evalúa 16 áreas clave, organizadas en tres grupos, según cuatro niveles de madurez: Inicial, Controlado, Eficiente y Optimizado. Dado que la evaluación se realiza área por área, un equipo puede ser Eficiente en un área y estar Controlado en otra.

TMMi, mantenido por TMMi FoundationEs un modelo de madurez de pruebas por etapas con cinco niveles: Inicial, Gestionado, Definido, Medido y Optimización. Una organización alcanza un nivel solo después de cumplir con las áreas de proceso de ese nivel.

CMMI No se trata de un modelo de pruebas. Abarca toda la organización de desarrollo y su representación por etapas cuenta con cinco niveles de madurez: Inicial, Gestionado, Definido, Gestionado Cuantitativamente y Optimizado. TMMi se diseñó para complementar CMMI, no para reemplazarlo.

Métricas que demuestran la mejora del proceso de pruebas

La fase de verificación se desmorona sin datos numéricos. Basta con un conjunto de métricas pequeño y estable recopilado antes y después de cada ciclo, y deben utilizarse las mismas definiciones en ambos lados de la comparación.

• Productividad en la ejecución de pruebas — Casos de prueba ejecutados por hora-hombre
• Porcentaje de detección de defectos (DDP) — Defectos detectados en las pruebas como porcentaje del total de defectos detectados, incluidos los notificados después del lanzamiento.
• Coste por caso de prueba ejecutado — Coste total del esfuerzo de prueba dividido por los casos de prueba ejecutados
• Cobertura de requisitos — requisitos con al menos uno vinculado caso de prueba
• Tiempo de respuesta para la corrección de defectos — edad promedio de un defecto en el ciclo de vida del defecto

Usando el GuruSegún las cifras de 99 Bank, donde se encontraron 180 defectos en las pruebas y 20 fueron reportados por el cliente después del lanzamiento, el cálculo es sencillo.

# Defect Detection Percentage and improvement deltas
def ddp(found_in_test, found_after_release):
    return found_in_test / (found_in_test + found_after_release) * 100

def delta(before, after):
    return (after - before) / before * 100

print("Defect Detection Percentage: %.1f%%" % ddp(180, 20))
print("Productivity gain: %.1f%%" % delta(10, 20))
print("Test cost change: %.1f%%" % delta(50000, 35000))

Salida:

Defect Detection Percentage: 90.0%
Productivity gain: 100.0%
Test cost change: -30.0%

Un DDP del 90 % significa que uno de cada diez defectos aún llegó al cliente, por lo que no se alcanzó el objetivo de calidad por completo, a pesar de que la productividad se duplicó y los costos disminuyeron un 30 %. Esta perspectiva limitada es lo que impide que un equipo cante victoria demasiado pronto.

Errores comunes en la mejora del proceso de pruebas

La mayoría de los programas de mejora fracasan por razones organizativas más que técnicas. Los siguientes errores son la causa de la mayoría de las iniciativas abandonadas.

• Mejorar sin un punto de partida. Si nadie midió el proceso antes del cambio, nadie puede demostrar que el cambio fue útil. Registre la línea base durante la planificación, no después.
• Se busca alcanzar un nivel de madurez en lugar de impulsar un negocio. Un certificado que no reduce los costos, los defectos ni los plazos de entrega es un gasto, no una mejora.
• Cambiar demasiadas cosas a la vez. Cuando cinco acciones llegan en la misma versión, no se puede producir una regresión. traca cualquiera de ellos.
• Automatizar un proceso defectuoso. La automatización multiplica cualquier proceso al que se aplique, incluidos los diseños de pruebas deficientes y los criterios de entrada poco claros.
• omitirping la fase de actuación. Una mejora que nunca se incluye en la política de pruebas y la ciclo de vida de las pruebas de software Los documentos mueren con el equipo del proyecto que los creó.
• Excluyendo a los evaluadores. Las personas que no fueron consultadas sobre un cambio siempre encuentran la manera de sortearlo.

Para profundizar en estas ideas, revise las fases de la ciclo de vida de las pruebas de software, aprieta tu caso de prueba diseñar, formalizar el proceso de gestión de defectos, evaluar dónde pruebas de automatización ofrece un retorno real y vea cómo una herramienta como HP ALM Puede almacenar las métricas de las que depende su fase de verificación.

Preguntas Frecuentes