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 :)
No hay comentarios:
Publicar un comentario