viernes, 7 de agosto de 2015

¿Es bueno tu proceso de Testing?

Hoy les dejo una propuesta para abordar una metodología, que permita generar mejoras en los procesos de prueba asociado a los Sistemas de Información. El enfoque a utilizar es el modelo Test Process Improvement (TPI®), que incluye guías prácticas para evaluar el nivel de madurez de pruebas de tu organización, así como los pasos para mejorar los procesos. TPI Es un marco de referencia para determinar fortalezas y debilidades del proceso de test actual de una organización.

El modelo cubre 20 áreas claves que podrán requerir de mejoras para lograr un proceso de pruebas bien definido. 


Desarrollar pruebas a un sistema de información, se considera a menudo un proceso problemático  e incontrolable, debido a que realizar pruebas conlleva mucho más tiempo, cuesta mucho más de lo planeado, y ofrece insuficiente información sobre la calidad del proceso de pruebas. Por lo tanto, la calidad del sistema de información y los riesgos para el negocio pueden ser muy  difíciles de determinar. Es  complicado definir los pasos a seguir para mejorar y controlar el proceso de pruebas.

El modelo Test Process Improvement (TPI) [1] se desarrolló basándose en el conocimiento y la experiencia de SOGETI[2].  El    modelo TPI asiste en la mejora de los procesos de pruebas dentro de la organización. 

Incluyo una situación real que realice en una empresa :), revisando  las 16 áreas claves que constituyen la base para mejorar y estructurar el proceso de pruebas, y se identifican las fortalezas y debilidades caracterizadas por los Stakeholders.

Figura 1

En el modelo TPI se propone 20 áreas clave, cada una con diferentes niveles de madurez. Los niveles de todas las Áreas Clave están integrados en una Matriz de Madurez. Cada nivel está descrito por varios Puntos de Verificación. También forman parte del modelo algunas Sugerencias de Mejora que ayudan a alcanzar el nivel deseado. 

Realiza tu diagnóstico inicial a través de entrevistas a los Stakeholders clave, por medio de la planilla TPI_NEXT, te dejo el link para que la bajes.  Clic aquí.

Guía de uso de la planilla, baja el el siguiente pdf. clic aquí.


Cuando hice la prueba, solo tomé 16 área claves :

1.             Compromisos de los Stakeholders
2.             Grado de Participación
3.             Estrategia  de las Pruebas
4.             Organización de las Pruebas
5.             Comunicación
6.             Informes
7.             Gestión del Proceso de Pruebas
8.             Estimación y Planificación
9.             Métricas
10.           Gestión de Defectos
11.           Gestión del Testware
12.           Metodología
13.           Profesionalidad del Tester
14.           Diseño de Casos de Prueba
15.           Herramientas de Test
16.           Ambiente de Pruebas

Las descripciones siguientes caracterizan las situaciones de cada área clave, mencionando las fortalezas y debilidades correspondientes.

Compromisos de los Stakeholders: El compromiso y pro actividad de los Stakeholders crean las condiciones adecuadas para una comunicación y cooperación eficaz.



El  principal stakeholder está definido  y es conocido por los testers.
El presupuesto de los recursos para las pruebas es acordado y negociado con el principal stakeholder.
Actualmente los stakeholders proveen los recursos acordados.
El principal stakeholder no realiza la documentación del análisis de riesgo del producto. No se define la estrategia de pruebas.

Grado de Participación: La participación estrecha de Testing en el proyecto ayuda a mejorar la calidad del producto desde el principio, y ayuda a mantener las actividades de prueba fuera de la ruta crítica del proyecto.



Las actividades de prueba son comenzadas tempranamente, antes de iniciar las actividades de ejecución, con el objetivo de incluir las actividades de test en el camino crítico del proyecto.
El tester está involucrado en la planificación del proyecto: Se tienen en cuenta las dependencias  entre el proceso de pruebas  y otros procesos.
Los testers contribuyen en el análisis de impacto de los defectos.
Los test asignados, alcance y aproximaciones de pruebas no son negociados de forma temprana con el principal Stakeholders.


Estrategia de las Pruebas: La estrategia de prueba orienta el proceso de prueba hacia una asignación óptima de esfuerzos y recursos.



El principal Stakeholder está de acuerdo  con la estrategia de pruebas documentada.
La estrategia de pruebas se basa en el análisis de riesgo del producto.

No se cuenta con  una diferenciación en los niveles, tipos, cubrimiento y la profundidad de las pruebas, dependiendo de los resultados del análisis de riesgo.
No se cuenta con una  estrategia de pruebas que incluya técnicas adecuadas de diseño de pruebas.

Organización de las Pruebas: La organización de las pruebas satisface las necesidades de recursos de los proyectos, productos y servicios de prueba.



Las personas involucradas saben dónde encontrar  a la persona (o al departamento) responsable de los servicios de pruebas.
No existe una estructura de control y reporte  de la organización de pruebas (actividades y recursos asociados a las pruebas).
Las  tareas y las responsabilidades de las pruebas No están definidas (y documentadas) y  asignadas a una persona o unidad.


Comunicación: Las distintas comunicaciones aseguran un entendimiento común y la alineación de expectativas entre todas las partes involucradas.



Cada miembro del equipo es consciente de las decisiones tomadas y del progreso interno.
El equipo de prueba activamente obtiene información relevante de los stakeholders.
El equipo de pruebas participa en las principales reuniones con otros stakeholders.
El equipo de prueba tiene  diferentes medios de comunicación disponibles, para comunicarse con los stakeholders utilizando una forma adecuada.
La organización no ha investigado en  el uso de nuevos medios de comunicación y definir las políticas de comunicación.
No es posible realizar el seguimiento de las acciones, acuerdos y decisiones anteriores del equipo de prueba.

Informes: Los informes proveen a los stakeholders de una visión para apoyar la toma de decisiones y la contabilidad de los proyectos de prueba.



Los informes contienen las tendencias y recomendaciones relacionadas con las metas de las pruebas y riesgos del producto.
Los informes No proporcionan datos y/o medidas que pueden ser utilizadas para realizar las mejoras actuales y futuras del proceso de pruebas y el ciclo de vida del desarrollo de software.
Los informes No contienen los aspectos de tiempo y/o costes, resultados y riesgos.

Gestión del Proceso de Pruebas: La gestión del proceso de pruebas maximiza la ejecución de las pruebas con relación al tiempo requerido, los costos y los resultados.



Cada actividad de pruebas es supervisada y cuando  sea necesario se realizan los ajustes requeridos.
En el principio de las pruebas No se crea un plan de pruebas. En este plan no se incluye por lo menos: La prueba asignada, el alcance, la planificación, los roles y las responsabilidades de las pruebas.

Estimación y Planificación: El uso de las técnicas adecuadas de estimación y de planificación hace que el proceso de prueba de la planificación y estimación sea predecible y confiable.




No se cuenta con las técnicas formales para  realizar una estimación y planificación confiable.
No existe para cada actividad de pruebas una indicación del período en el que se ejecutan, los recursos requeridos y los productos que entregan.
No se cuenta con las actividades que deben ser identificadas como: La planificación y gestión de las  pruebas, la definición de los  casos de prueba y la ejecución de los casos de prueba.

Métricas: Las métricas proporcionan objetividad mediante la cuantificación de las observaciones.




No utilizamos métricas para un proyecto de pruebas.

Con no tenemos  métricas definidas, es imposible estimar y controlar el proceso de pruebas.


Gestión de Defectos: La gestión de defectos trata los defectos, tanto a nivel individual como de grupo, en donde la causa raíz es analizada y las directrices están disponibles.




No se cuenta con registros formales que permitan analizar la gestión de defectos.

No tenemos  definidos  los responsables para el manejo de los defectos.

Gestión del Testware: Los productos de las pruebas deben ser mantenibles y reusables y además se deben administrar como elementos de configuración.




Todas las pruebas realizadas, no cuenta con los documentos de diseño en estado aprobado, y no son identificados individualmente y registrados.

No se cuenta con Gestión de Testware.

Metodología: El método descrito para las pruebas dirige y apoya los proyectos de prueba.




No se cuenta con un proceso de pruebas que siga un método de pruebas documentado.

No se cuenta con un  método de pruebas que permita describir la metas de todas las actividades de prueba, las responsabilidades de los diferentes roles, las técnicas que se utilizarán y las condiciones previas.

Profesionalidad del Tester: La profesionalidad del Tester incluye la combinación adecuada de las diversas destrezas, competencias, disciplinas, funciones y conocimientos que son necesarios para llevar a cabo las actividades de prueba en los niveles esperados.




Los testers no han recibido una formación específica y/o no tienen la suficiente experiencia en el campo de las pruebas estructuradas

Diseño de Casos de Prueba: El diseño de casos de prueba dirige la ejecución de pruebas para buscar defectos de acuerdo con la estrategia de prueba.



Los casos de prueba son registrados en un nivel lógico.
Los casos de prueba consisten en una descripción de: a) la situación inicial, b) el proceso de cambio = Acciones de prueba que deben ser realizadas, c) los resultados esperados.
No se  utilizan  técnicas formales de diseño de pruebas en el diseño de los casos de pruebas.

Herramientas de Test: Las herramientas de prueba habilitan o aceleran las actividades específicas de prueba.





No se cuentan con  herramientas de pruebas  que estén a disposición de los tester en el momento que se requieran.

Ambiente de Pruebas: El entorno de prueba está explícitamente diseñado, implementado y mantenido teniendo en cuenta los objetivos de las pruebas.



Los Entornos de prueba están disponibles al equipo de pruebas durante el tiempo acordado.
Los requisitos del Entorno de Pruebas No están  documentados


Análisis de Resultados





Se puede observar los puntos fuertes y débiles de cada área clave,  en donde las áreas claves sin valores son :

·         Estimación y Planificación
·         Métricas
·         Gestión de Defectos
·         Gestión del Testware
·         Metodología
·         Profesionalidad del Tester
·         Herramienta de Test

Las áreas con puntos son:
·         Compromisos con los Stakeholders
·         Grado de Participación
·         Estrategia de la Pruebas
·         Organización de las Pruebas
·         Comunicación
·         Informes
·         Gestión del Proceso de Prueba
·         Diseños de Casos de Prueba

·         Ambiente de Pruebas


 Propuesta de Mejora


Las acciones de mejora se definen a partir de los objetivos de mejora establecidos, así como de los resultados de la evaluación. Estas acciones se determinan de tal manera que sea posible ir mejorando paso a paso.  Ejemplo:

Áreas Claves
Propuestas de Mejoras
Motivación
Compromiso de los Stakeholder
-Definir Stakeholder claves

-Sub Gerencia Adm y finanzas debe entregar los recursos necesarios para que los involucrados en el desarrollo de pruebas puedan ejecutar el Testing.
El compromiso y la motivación de las personas son pre requisitos para ejecutar el proceso de prueba sin problemas y disminuir  los riesgos del desarrollo del proyecto.

La siguiente figura muestra las diferentes actividades de un proceso de mejora. Esto te permite un flujo de trabajo de propuestas de mejoras asociado al plan.




Te dejó las referencias donde obtuve más información sobre este trabajo de investigación:

[1]     Andersin Jari.. 2004.TPI- a model for Test Process Improvement. 

[2]     Sogeti. http://www.es.sogeti.com/


Nos vemos :)



Enviar mensaje por Correo en forma secuencial

Hola estimados(as) Hoy les dejo un código en Java que permite enviar correos, usando una base de datos, por ejemplo Mysql. Lo que adjunto...