VIAJARA USTED EN EL AVIN QUE CONSTRUY?

Mtricas bsicas para reducir el riesgo de las decisiones de shipment

Primer Seminario Latinoamericano de Testing de Software Montevideo, agosto 27 de 2008

AGENDA

[1] [2] [3]

Introduccin Definiendo calidad Caso de estudio: Calculator+

[4]
[5] [6] [7]

Definiendo los criterios de entrada a testing

Definiendo los criterios de release Beta Evaluacin de las mtricas Conclusiones

[1] INTRODUCCIN
Un poco de contexto

Es bastante comn que las decisiones de shipping de los productos estn basadas en la confianza que tienen los testers y los desarrolladores en que el producto est listo. Lugo de probar el producto por un determinado periodo de tiempo, el equipo anuncia que el producto cumple o no con las condiciones para su liberacin al mercado. Muchas organizaciones hoy reconocen que tomar estas decisiones sobre la base de la percepcin son insuficientes. Diferentes aproximaciones a la solucin de este problema: Institucionalizar un sistema de gestin de calidad Auditar el proceso de construccin y pruebas del software Es posible definir mtricas especficas para soportar las decisiones de shipment. Como mnimo estas metricas deben ser definidas para la fase de pruebas.

[2] DEFINIENDO EL CONCEPTO DE CALIDAD

Prioridades para definir y evaluar el riesgo del shipping?

Para definir y evaluar los riesgos del shipment, primero debemos definir qu es para nosotros la calidad del producto. Una posiblidad es escoger nuestra mxima prioridad entre estas tres [grady1]: Minimizar el time to market (disminuir costos de ingeniera y schedule) Maximizar la satisfaccin del cliente (determinando caractersticas y trabajando con sus clientes) Minimizar la cantidad de defectos La prioridad escogida define el modelo , y las otras dos se optimizan dentro del contexto.

[grady1] Grady, Robert. Practical Software Metrics for Project Management and Process Improvement. Prentice Hall, Englewood Cliffs, NJ. 1992.

DEFINIENDO EL CONCEPTO DE CALIDAD [CONT]

REALITY-CHECK

Escenario: 3 semanas antes de la fecha acordada para el shipment, la cantidad de bugs es mayor de la esperada, y no se ha podido incluir la ltima funcionalidad. Cul ser la decisin? Si se decide entregar el producto en esas condiciones, Time to market ser la definicin de calidad. Si se decide incluir la funcionalidad, y entregar tan pronto se haya incluido, entonces la satisfaccin del cliente ser la prioridad mxima. Si se decide esperar hasta finalizar la correccin de defectos, minimizar defectos ser la definicin de calidad.
Por largo tiempo los grupos de SQA han tenido su foco en evitar defectos como definicin de calidad. En la realidad, no parece adecuado definir la calidad slo por el nivel de defectos de un producto. Diferentes definiciones de calidad del producto requieren diferentes mtricas..

[3] CASO DE ESTUDIO: CALCULATOR+

Contexto

El producto ha sido mejorado para optimizar la performance de las operaciones a travs de webservices.

Revisaremos las acciones y mtricas que ha ido tomando la compaa durante la evolucin del producto y su evaluacin del criterio de readiness to ship del producto.
PREMISAS Fase de testing: periodo en el cual los programadores han finalizado el desarrollo de todas las funcionalidades. Existe un hito llamado cdigo congelado, a partir del cual los programadores slo corrgien defectos y revisan correcciones, NO generan cdigo de nuevas funcionalidades ni cambios en las mismas. El equipo de testing ejecuta sus pruebas, identificando y reportando defectos, y actualizando los escenarios si es necesario.

CASO DE ESTUDIO: CALCULATOR+ [CONT]

Situacin actual del proyecto

Luego de alcanzar el hito cdigo congelado, y de finalizar la fase de testing, se liber una release Beta del producto. Los clientes manifestaron su descontento por los defectos detectados y por la pobre performance del producto en sus nuevas funcionalidades. El equipo de desarrollo trabaj muy duro en las ltimas 4 semanas, corrigiendo los defectos detectados y realizando cambios en el acceso a datos para mejorar la performance. Ahora, Calculator+ est ahora en el segundo beta release. Los clientes an continan sin estar muy convencidos de la estabilidad del producto.

CASO DE ESTUDIO: CALCULATOR+ [CONT]

DESICIONES DE LA ORGANIZACIN

A esta altura de la historia, estamos ante los siguientes riesgos: Comenzar una historia sin fin de corregir / testear / validar hasta quedar en una versin aceptada por el cliente.

An a pesar del esfuerzo de todos los actores por corregir defectos y mejorar el producto, no lograr la satisfaccin del cliente.
Desicin de la gerencia de producto

Evaluar el estado actual del producto, midiendo:

Ratio de defectos activos / resueltos Porcentaje de escenarios de pruebas exitosos

Cobertura del testing

CASO DE ESTUDIO: CALCULATOR+

ESTADO ACTUAL DEL PRODUCTO

[1] Ratio de defectos activos / resueltos Los testers detectan defectos ms rpido de lo que pueden corregir los programadores, un problema bastante comn durante los test de sistema. [2] Porcentaje de pruebas exitosas Es necesario planificar nuevos casos, pues se agregan funcionalidades. El conjunto actual de 100 tests de regresin cubren el 30% de las funcionalidades aprox. Un 50% de las funcionalidades an no han sido probadas.

[3] Con estas premisas, el equipo acuerda que la cobertura alcanzada es de un 60% aprox.

CASO DE ESTUDIO: CALCULATOR+

ANALIZANDO EL ESTADO ACTUAL

Cundo el equipo analiza estas mtricas tiene una serie de preocupaciones y decisiones para tomar: En qu momento dejarn de aparecer defectos ms rpido de lo que se pueden corregir? En qu momento ser posible estabilizar la suite de casos de test (baseline)?

Basados en estos datos, evidentemente no se ha alcanzado an el hito cdigo congelado El equipo de Calculator+ decide tomar este hecho como una oportunidad, no como un desastre . Definen criterios de entrada al test de sistema, de forma de lograr una cantidad acotada y confiable de tests.

CASO DE ESTUDIO: CALCULATOR+

LECCIONES APRENDIDAS

La recoleccin y anlisis de mtricas aportan claridad sobre la percepcin de la calidad del producto. Sobre el concepto de calidad: Para los testers, era la ausencia de defectos Para los programadores, era respetar el schedule. Antes de ver los datos, para los gerentes de producto, era la performance y las nuevas funcionalidades. Existen momentos crticos del proyecto para definir y revisar mtricas para el shipment: Durante la definicin del producto (requerimientos / diseo) Al principio del test final (system test) Al principio del beta test Al final del test de release final

[4] CRITERIOS DE ENTRADA AL TEST DE SISTEMA

EJEMPLOS

REQUERIMIENTOS DEL TEST DE SISTEMA Definir tests de caja blanca para las funcionalidades definidas en la especificacin <ABC> Definir tests de caja negra para todas las dems funcionalidades. Automatizar todos los test de compatiblidad entre browsers El producto debe ser capaz de completar las funcionalidades bsicas descriptas en <ESRE, Casos de Uso, Flujos>. Todos los mdulos deben: tener cdigo congelado y completo en sus funcionalidades pasar las revisiones (cuando corresponde), las pruebas unitarias y de integracin. METAS DEL TEST DE SISTEMA Automatizar las pruebas que se estimen en ms de 4 hs. No ms de 30 defectos crticos y no ms de 100 defectos no crticos. Todas las revisiones de cdigo planificadas deben ser realizadas.

CRITERIOS DE ENTRADA AL TEST DE SISTEMA

Ejemplos de criterios definidos para Calculator+

Siguiendo con nuestro casos de estudio, el equipo de Calculator+, ha definido los siguientes criterios: Todos los defectos corregidos deben pasar por revisiones de pares antes del check-in. Como mnimo, el porcentaje de xito de los test de regresin debe ser un 95%. Todas las fallas de los test de regresin deben ser conocidas, definidas por bugs y planificadas para ser resueltas inmediatamente. Todas las pruebas de performance deben pasar. Confiablidad de datos 100%: Todos los commits deben ser impactados Todos los rollbak deben ser exitosos Todos los mecanismos de data recovery deben ser exitosos.

[5] CRITERIOS DE ENTRADA AL BETA TEST

Ejemplos de criterios definidos por el equipo de Calculator+

El cdigo debe ser branched. 98% de los test de regresin en pasa Los defectos no pueden provocar cadas del sistema 90% de cobertura mnima en los test de regresin

El beta test asegura que los clientes no reciben un producto con ms cantidad de defectos que aquellos que se pueden manejar por el equipo.
El criterio de entrada al Beta test debe ser definido tan pronto como sea posible en el proyecto. La gerencia, el equipo de desarrollo y el equipo de QA deben estar de acuerdo en los criterios. Es conveniente estimar el tiempo en el cual sern satisfechos los criterios. Esto brinda una perspectiva histrica para esta etapa que puede ser til en los prximos proyectos.

[6] EVALUACIN DE LAS MTRICAS

LOS CRITERIOS EN LA PRCTICA

Evaluar los criterios de entrada es una cuestin de recoleccin de datos y revisin del match entre datos y criterios. Tarea de recoleccin de datos: Test Manager, Team Leader, Analista Se presentan los resultados al Project Leader durante la revisin de readiness para el test de sistema.

Esta evaluacin indicar que algunos criterios s cumplen, y otros no.

En la revisin se discuten los riesgos y se toma la desicin de retrasar el ingreso a testing o ingresar con ciertas acciones de mitigacin y contingencia.

CASO DE ESTUDIO: CALCULATOR+

Evolucin del producto luego de definir los criterios para los test de sistema / beta test

La actividades de correccin / revisin encontraron ms defectos hasta la semana 18 aprox. La cantidad de check-ins muestra la cantidad de archivos que se vieron afectados por los defectos, un indicador de la estabilidad del producto. A partir de la semana 18, los archivos check-in comienzan a bajar, y esto motiva que la cantidad de defectos comience a descender.

Del folklore popular: cambi slo una lnea, qu tanto puede impactar?

CASO DE ESTUDIO: CALCULATOR+

Evolucin del producto luego de definir los criterios para los test de sistema / beta test

El hecho que la cantidad de casos planificados se incremente cada semana (hasta la semana 22) es un efecto del tradicional retraso de la transferencia de conocimiento sobre las funcionalidades al equipo de testing.

[7] CONCLUSIONES
SOBRE EL USO Y EL BENEFICIO DE LAS MTRICAS

No importa cul es la definicin de calidad del producto, estas mtricas ayudan a la organizacin a comprender el estado del producto. El software debe mostrar que su estabilidad aumenta a lo largo del tiempo: Menos check-ins Menos bugs detectados Menos bugs nuevos Ms bugs cerrados Menos bugs activos Las decisiones basadas en mtricas permiten negociaciones menos consumidoras de energa, y sirven como elementos para asumir riesgos conocidos.

AHORA SI, BUEN VIAJE!!!

CONTACTO: SILVIAN@INFOCORP.COM.UY
Infocorp - [QA Manager / SEPG Leader] Plaza Cagancha 1335 / 605 Montevideo Uruguay