Soft Quality Manual Buenas Practicas Testing Enero 2011 v1.0

BUENAS PRCTICAS PARA EL DESARROLLO CON ESTNDARES DE CALIDAD DE SOFTWARE
SoftQuality Incorporacin de Metodologas Avanzadas de Testing
AGRUPACIN EMPRESARIAL INNOVADORA DE EMPRESAS DE DESARROLLO DE SOFTWARE VERTICAL DE ANDALUCA
Versin 1.0. 04/01/2011
Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software
NDICE 1. CAPITULO 1: INTRODUCCIN A LA MEJORA DEL PROCESO DE PRUEBAS........................5 1.1. 1.2. 1.3. 1.4. CONTEXTO..................................................................................................................... 6 MODELOS Y ESTANDARES DE PROCESO DE PRUEBAS .................................................. 8 POR QUE TMMi?.......................................................................................................... 9 ESTRUCTURA DEL MODELO TMMi .............................................................................. 10 REPRESENTACIN POR ETAPAS .......................................................................... 10 NIVELES DE MADUREZ......................................................................................... 10 ESTRUCTURA DE COMPONENTES DEL MODELO TMMi ...................................... 15 REAS DE PROCESO............................................................................................. 17
1.4.1. 1.4.2. 1.4.3. 1.4.4. 1.5. 2.
RECUERDE ................................................................................................................... 20
CAPITULO 2: BUENAS PRCTICAS PARA LA IMPLANTACIN DE UN PLAN DE MEJORA...21 2.1. 2.2. 2.3. INTRODUCCIN........................................................................................................... 22 CARACTERIZACIN DEL PROCESO MADURO DE PRUEBAS DE SOFTWARE................. 23 HOJA DE RUTA PARA LA MEJORA DEL PROCESO DE PRUEBAS ................................... 24 Anlisis de situacin actual ................................................................................. 25 Elaboracin del plan de mejora........................................................................... 26 Implantacin del plan de mejora ........................................................................ 27 Certificacin......................................................................................................... 28
2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.5. 3.
MTODO DE EVALUACIN .......................................................................................... 29 LA INSTITUCIONALIZACIN COMO GESTIN DEL CAMBIO......................................... 30
CAPITULO 3: BUENAS PRCTICAS DEL PROCESO DE PRUEBAS. NIVEL DE MADUREZ 2. ..32 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. INTRODUCCIN........................................................................................................... 33 ESTABLECER UNA POLITICA Y UNA ESTRATEGIA DE PRUEBAS (PA 2.1)...................... 35 PLANIFICAR LAS PRUEBAS (PA 2.2) ............................................................................. 36 SEGUIR Y CONTROLAR LAS PRUEBAS (PA 2.3) ............................................................ 38 DISEAR Y EJECUTAR LAS PRUEBAS (PA 2.4) .............................................................. 39 ENTORNO DEL TESTING (PA 2.5) ................................................................................. 41 META Y PRCTICAS GENRICAS PARA EL NIVEL 2....................................................... 42
Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software 4. CAPITULO 4: BUENAS PRCTICAS DEL PROCESO DE PRUEBAS. NIVEL DE MADUREZ 3. ..43 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 5. INTRODUCCIN........................................................................................................... 44 ORGANIZACIN DEL TESTING (PA 3.1)........................................................................ 45 PLANIFICAR LA FORMACIN EN TESTING (PA 3.2)...................................................... 46 INTEGRAR LAS PRUEBAS EN EL CICLO E VIDA DEL TESTING (PA 3.3) .......................... 47 PRUEBAS NO FUNCIONALES (PA 3.4) .......................................................................... 49 PEER REVIEWS (REVISIONES ENTER PARES) (PA 3.5) .................................................. 51 META Y PRCTICAS GENRICAS PARA EL NIVEL 3....................................................... 52
CAPITULO 5: RECURSOS DE REFERENCIA .....................................................................53 5.1. 5.2. HERRAMIENTAS........................................................................................................... 53 BIBLIOGRAFA.............................................................................................................. 56
PROPIEDAD INTELECTUAL
Marcas y servicios registrados citados en el presente documento: CMM, CMMI, TMMi, TMap y TPI. CMM and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. IDEAL and SCAMPI are service marks of Carnegie Mellon University. TMM is a registered service mark of Illinois Institute of Technology. TMMi is a registered trademark of TMMi Foundation. TMap and TPI are registered trademarks of Sogeti, The Netherlands.
1. CAPITULO 1: INTRODUCCIN A LA MEJORA DEL PROCESO DE PRUEBAS

1.1. CONTEXTO
La mejora del proceso de pruebas de software es clave para asegurar la calidad del producto al estar integrado en el ciclo de vida de desarrollo y mantenimiento.
Las pruebas o testing constituyen un proceso crtico para asegurar la calidad de un producto software, sin embargo, en muchas Organizaciones, se tiende a relegar a las ltimas etapas de un proyecto de desarrollo o de mantenimiento, a veces de forma improvisada, sin una asignacin de recursos y, en la mayora de estas situaciones, ejecutadas por los aquellos desarrolladores que escribieron el cdigo. La prueba de usuario o funcional, en este contexto, es la practica mas seguida, que no la mejor, para la validacin de un producto de software, detectndose, en consecuencia, durante la fase final de un proyecto de desarrollo o mantenimiento una cantidad imprevista de errores, fallos o defectos, que impide el funcionamiento conforme a lo esperado, que provoca costes no deseados de correccin y demora en el plazo previsto de entrada en operacin del producto. Para asegurar el resultado esperado por el usuario (funcionalidad, pero tambin el plazo y presupuesto) y por la Organizacin desarrolladora (rentabilidad prevista, satisfaccin de su cliente), la prueba de software debe ser un proceso gestionado, es decir, planificado y controlado, siguiendo las normas o estndares de referencia, los modelos de capacidad o madurez de los procesos y las buenas practicas, eso s, adaptadas al entorno de cada Organizacin, permitiendo integrar en el ciclo de vida del software, todas aquellas actividades y responsabilidades relacionadas con la calidad del producto software. La forma ms eficaz, rpida y segura para que una Organizacin desarrolladora aborde la innovacin de su produccin de software, ya sea evolutiva o disruptiva, es seleccionar y adoptar un modelo de procesos y de mejora que sea reconocido como un estndar por la industria.

Las ventajas que aporta esta aproximacin a la mejora a travs de un modelo, se resumen a continuacin:
El modelo sirve de gua a la Organizacin para elaborar un plan estructurado, permitiendo establecer metas y prioridades para la mejora escalonada de los procesos, mediante niveles de madurez o de capacidad.
El modelo recopila las mejores prcticas existentes en la industria de software, facilitando la adaptacin al entorno de cada Organizacin.
El modelo permite la comparacin competitiva o el benchmarking entre equipos o unidades (internamente) y con otras Organizaciones (externamente) que hayan adoptado, lgicamente, el mismo modelo de referencia.
El modelo facilita la medicin objetiva de la mejora conseguida, en trminos de eficiencia de los procesos para la Organizacin y, en otro plano, el retorno del esfuerzo invertido en la mejora.

1.2. MODELOS Y ESTANDARES DE PROCESO DE PRUEBAS Entre los modelos y estndares de referencia para la mejora del proceso de pruebas de software los ms relevantes son los siguientes 1. TPI: El modelo denominado Test Process Improvement o Mejora del Proceso de Testing a. b. se desarroll basndose en el conocimiento y la experiencia de SOGETI. TPI asiste en la mejora de los procesos de pruebas dentro de la organizacin, permitiendo definir pasos de mejora controlables y graduales c. TPI tiene en cuenta los diversos aspectos del proceso de pruebas, tales como el uso de herramientas de test, las tcnicas de diseo de pruebas o la realizacin de informes. En su anlisis, se hacen visibles los puntos fuertes y dbiles del proceso de pruebas. Estos aspectos se denominan reas clave. d. TPI cuenta con 20 reas clave y clasifica el estado de una Organizacin utilizando niveles, que van de A a B a C, identificando la madurez de cada uno de ellos 2. TMMi: El modelo denominado Test Maturity Model Integration o Modelo de Madurez Integrado de Pruebas a. Esta estructurado de forma detallada para la mejora de los processo de pruebas b. Esta alineado y es complementario con el modelo Capability Maturity Model Integration ( CMMI) pero no exige el seguimiento de este c. Publicado en 2008 por TMM Foundation, organizacin de la industria no lucrativa d. Esta apoyado por grandes actores de la industa del software como Accenture Wipro y General Electric 3. El estndar ISO/IEC 29119 Software Testing a. b. Publicado el borrador en el 2008, se encuentra en elaboracin este estndar tiene como caracterstica que puede ser aplicado de forma independiente por diferentes organizaciones y/o proyecto. c. El estndar remplazar a las normas IEEE 829 Test Documentation y IEEE 1028 Unit Testing, y las BS 7925-1 Vocabulary of Terms in Software Testing y BS 7925-2 Software Component Testing Standard.

1.3. POR QUE TMMi?
Es un modelo de mejora del proceso de pruebas de software que proporciona las mejores prcticas en detalle para los ciclos de desarrollo y mantenimiento de productos y servicios.
Se esta convirtiendo en el estndar internacional de facto de la industria de software.
Su estructura de componentes (niveles, reas de proceso, practicas, goals, etc.) es idntica a la del modelo CMMI, facilitando su comprensin y uso inmediato por aquellas Organizaciones que lo utilizan
Su complementariedad con el modelo CMMI For Development es muy elevada, aunque no excluye la aplicacin de otros modelos.
Cuenta con un mtodo objetivo de evaluacin de niveles de madurez, denominado TMMi Assessment Method Application Requirements (TAMAR), fundamentado en la determinacin de niveles de capacidad de los procesos de acuerdo con la norma internacional ISO IEC 15504-2
Es un modelo promovido y soportado por una organizacin sin nimo de lucro que actualmente no hace uso comercial de los materiales del modelo.
Existe un esquema de acreditacin formal de niveles de madurez para las Organizaciones regulado por TMMi Foundation con requisitos para los evaluadores (Lead-Assessor and Assessor).

1.4. ESTRUCTURA DEL MODELO TMMi A continuacin, se definen las caractersticas principales del modelo TMMi, de acuerdo con la versin ms reciente (TMMi V 1.3) publicada en diciembre de 2010, que contempla las buenas prcticas de pruebas a lo largo del ciclo de vida relativas a los Niveles de Madurez 2, 3 y 4, encontrndose el Nivel 5 en desarrollo. 1.4.1. REPRESENTACIN POR ETAPAS TMMi permite abordar la mejora de procesos de pruebas, usando una evolucin o representacin por etapas o escalonada, que aporta las siguientes ventajas: Proporciona una hoja de ruta para la mejora de la organizacin basado en un grupo probado y ordenado de procesos.
Utiliza niveles de madurez para caracterizar la mejora. Un nivel de madurez consta de un conjunto predefinido de reas de proceso que mejoran la eficiencia de una Organizacin.
Propone una secuencia para la mejora de las reas de proceso. Cada nivel de madurez prepara a la Organizacin para pasar al siguiente, es decir, son acumulativos.
1.4.2. NIVELES DE MADUREZ TMMi, como ya se ha referido, esta estructurado en Niveles de madurez, del 1 al 5, al igual que CMMI, que se representan a continuacin:
Fuente: TMMi Foundation. Versin 1.3.
10

La descripcin de cada Nivel de Madurez es la siguiente:
Nivel 1. Inicial.
En el Nivel 1 de TMMi, el testing no es un proceso, caracterizado por ser catico y confundido con la subsanacin de errores, fallos y problemas del cdigo (debugging). En el Nivel 1 la Organizacin desarrolladora no prev ni proporciona recursos o medios especializados para el entorno de pruebas. El xito en los proyectos de las Organizaciones e Nivel 1 tiene una dependencia total del la competencia profesional y el herosmo de sus tcnicos y no de procesos estructurados. Las pruebas de software, si se acometen, son ejecutadas por los propios desarrolladores de una forma ad hoc, una vez ha finalizado la codificacin, y estn mezcladas con la correccin de los errores, fallos y problemas (debugging). El principal objetivo del testing en una Organizacin de Nivel 1 es demostrar que el producto funciona. En resumen: El proceso de pruebas est caracterizado como ad hoc o catico.
Las pruebas se desarrollan ad hoc despus de la codificacin
Falta de profesionales especializados en testing
Falta de herramientas de automatizacin y gestin.
El objetivo de las pruebas es demostrar el funcionamiento del software
Nivel 2. Gestionado.
En el Nivel 2 de TMMi, el testing es un proceso gestionado y claramente diferenciado del debbuging. En el Nivel 2 existen prcticas que se mantienen en los periodos de estrs de la
Organizacin desarrolladora, aunque el testing an es percibido por algunos como una fase final del proyecto que sigue a la codificacin.
11

El principal objetivo del testing en una Organizacin de Nivel 2 es verificar que el producto satisface los requisitos especificados. La mayor cantidad de fallos, defectos o problemas de calidad en este nivel se generan porque el testing se introduce demasiado tarde en el ciclo de vida de desarrollo. Los defectos, no obstante en este Nivel, se propagan desde los requisitos y el diseo hasta el cdigo, pues no hay un programa de revisiones formales que lo eviten. En resumen: Se identifica el testing como una funcin separada del debugging.
Las pruebas se convierten en una fase del proyecto
Se implantan procesos estandarizados y tcnicas de pruebas
El objetivo de las pruebas es demostrar que el software/sistema cumple con las especificacin de requisitos
Las cinco (5) reas de proceso de Nivel 2 son las siguientes: 1. Estrategia y Poltica de testing 2. Planificacin del testing 3. Seguimiento y control del testing 4. Diseo y ejecucin del testing 5. Entorno de testing
Nivel 3. Definido.
En el Nivel 3 de TMMi, el proceso de testing esta estandarizado, documentado y seguido por toda la Organizacin, adems de no ser una fase que sigue a la codificacin, sino que se integra a lo largo de todo el ciclo de vida del software. La planificacin del testing se inicia en la fase de requisitos y contina durante todo el ciclo de vida (en V). Los objetivos del testing se establecen respecto a los requisitos a partir de las necesidades del cliente/usuario, y se usan en el diseo de los casos de prueba.
12

En el Nivel 3 existe una organizacin de testing con formacin especializada, adems de un proceso de control y seguimiento para tomar acciones correctivas frente a
desviaciones en relacin con el plan previsto. En resumen: Las pruebas estn integradas en el ciclo de vida Se establece una organizacin formal de testing Se planifica y desarrolla una formacin estructurada en tcnicas de testing Se monitoriza y controla el proceso de pruebas Se inicia la adopcin de herramientas de automatizacin de pruebas El enfoque de las pruebas se centra en la verificacin y validacin de los requisitos
La Direccin de la Organizacin reconoce las pruebas como una actividad profesional
Las cinco (5) reas de proceso de Nivel 3 son las siguientes: 1. Organizacin de testing 2. Plan de formacin de testing 3. Ciclo de vida de testing e Integarcin 4. Testing no funcional 5. Peer Reviews
Nivel 4. Gestin cuantitativa.
En el Nivel 4 de TMMi, el testing es un proceso medido y cuantificado. Las revisiones e inspecciones que se llevan a cabo en todas las fases del desarollo se reconocen como actividades de control de calidad y de testing. Estas actividades son complementarias a la ejecucin de pruebas para detectar, evaluar y mejorar la calidad del producto software. Los productos software de la Organizacin se prueban en cuanto a atributos tales como: fiabilidad, usabilidad y mantenibilidad. Los casos de pruebas de todos los proyectos de la Organizacin se recopilan y registran en un repositorio para su reutilizacin y uso en las pruebas de regresin. Los defectos se registran y se les asigna un nivel de severidad para su priorizacin.
13

Las deficiencias del proceso de pruebas provienen an de la falta de una filosofa de prevencin y de la cobertura insuficiente de la automatizacin de la recoleccin, el anlisis y la fragmentacin de mtricas de las pruebas. En resumen: El proceso de testing se mide y controla estadsticamente
Se prueban los atributos de calidad de los productos desarrollados como la fiabilidad, usabilidad y mantenibilidad
Los casos de pruebas se recopilan y registran en un repositorio para su reutilizacin y pruebas de regresin
Los defectos detectados durante la ejecucin de las pruebas se registran, se les asigna un nivel de severidad y de prioridad para su correccin
Las tres (3) reas de proceso de Nivel 4 son las siguientes: 1. Organizacin de testing 2. Evaluacin de calidad del producto 3. Peer Reviews avanzadas
Nivel 5. Nivel optimizado.
En el Nivel 5 de TMMi, debido a que el proceso de testing esta gestionado (Nivel 2), definido (Nivel 3) y cuantificado (Nivel 4), la Organizacin se pude concentrar en su optimizacin de su eficiencia y coste. La prevencin de los defectos y el control de calidad son los focos de la Organizacin. Para dar soporte a la mejora continua y la optimizacin de procesos la Organizacin crea un grupo de mejora de alta cualificacin y especializacin. Las actividades que guan el proceso de pruebas son el anlisis estadstico, las mtricas de niveles de confianza, la confiabilidad y fiabilidad. Las herramientas de automatizacin dan cobertura completa al diseo y la ejecucin de los casos de pruebas, ascomo a la recopilacin y anlisis de defectos y mtricas. Los procesos se reutilizan gracias a la automatizacin de la Librera de Activo de Proceso (PAL).
14
En resumen: El proceso de testing esta institucionalizado en la Organizacin El proceso de testing esta bien definido y gestionado Se controlan los costes y la eficacia de las pruebas Los procesos de pruebas estan automatizados Existe un procedimiento establecido para seleccionar y evaluar herramientas de pruebas
Las tres (3) reas de proceso de Nivel 4 son las siguientes: 1. Prevencin de defectos 2. Optimizacin del proceso de pruebas 3. Control estadstico de la calidad
1.4.3. ESTRUCTURA DE COMPONENTES DEL MODELO TMMi
La estructura de componentes genricos del Modelo TMMi se representa a continuacin:
Niveles de Madurez
rea de Proceso 1
rea de Proceso 2
rea de Proceso
Objetivos Especficos
Objetivos Genricos
Prcticas Especficas
Prcticas Genricas
15

Fuente: TMMi Foundation, Versin 1.3. Los distintos componentes del modelo TMMi se agrupan en tres categoras que se exponen a continuacin:
Requeridos: describen lo que una Organizacin debe hacer para satisfacer un rea de proceso. Son los objetivos o metas.
Objetivos genricos: asociados a un nivel de capacidad, establecen lo que una organizacin debe alcanzar en dicho nivel.
Objetivos especficos: se aplican a una nica rea de proceso y describen qu se debe implementar para satisfacer el propsito del rea.
Esperados: describen lo que una Organizacin implanta para lograr los objetivos. Son las prcticas y sirven de gua a quienes implementan mejoras o realizan evaluaciones.
Prctica genrica: se aplica a cualquier rea de proceso porque puede mejorar el funcionamiento y el control de cualquiera de ellos.
Prctica especfica: es una actividad que se considera importante en la realizacin del objetivo especfico al cual est asociado. Las prcticas especficas describen las actividades esperadas, para lograr la meta especfica de un rea de proceso.
Informativos: proporcionan detalles que ayudan a las organizaciones en la definicin de procesos que satisfagan los objetivos y prcticas. Ejemplo:
Productos de trabajo tpicos: listado de muestras de resultados de una prctica especfica.
Subprcticas:
descripcin
detallada
que
sirve
como
gua
para
la
interpretacin e implantacin de una prctica genrica o especfica.
16

La satisfaccin de objetivos se utiliza en las evaluaciones como base para determinar si un rea de proceso ha sido satisfecha. Las prcticas, tal como se describen en el modelo o prcticas aceptables alternativas, debern estar presentes en los procesos implementados de la organizacin para que se evalen los objetivos como satisfechos.
1.4.4. REAS DE PROCESO
Un rea de proceso es un grupo de prcticas relacionadas que, cuando se implementan de forma conjunta, satisfacen un grupo de objetivos
considerados importantes para la mejora de dicha rea.
El modelo TMMi consta de 16 reas de proceso, que mostramos en la siguiente tabla, junto el nivel de madurez en el que se enmarcan.
17
Nivel de rea de proceso madurez

1. Estrategia y Poltica de testing 2. Planificacin del testing 3. Seguimiento y control del testing 4. Diseo y ejecucin del testing. 2 2 2 2
5. Entorno de testing 6. Organizacin de testing
2 3
7. Plan de formacin de testing
8. Ciclo de vida de testing e Integracin
9. Testing no funcional
10.Peer Reviews
11.Mtricas de testing
12.Evaluacin de calidad de producto
13.Peer Reviews avanzadas 14.Prevencin de defectos
4 5
15.Optimizacin del proceso de testing
16.Control estadstico de la calidad
Fuente: TMMI Foundation v1.3.
18
19

1.5. RECUERDE
TMMi (Test Maturity Model Integration) es un modelo de madurez de procesos, que describe detalladamente las mejores prcticas para las pruebas de productos software, cubiertas en el ciclo integral de vida, desde la concepcin a la entrega y el mantenimiento.
El modelo TMMi se estructura en cinco (5) Niveles de madurez que, a su vez, estn integradas por reas de proceso, que se configuran por un grupo de prcticas relacionadas que, cuando se implementan de forma conjunta, satisfacen un grupo de objetivos considerados importantes para la mejora en dicha rea.
La agrupacin de reas de Proceso por Niveles de Madurez proporciona una evolucin o representacin por etapas que facilita la fijacin y medicin de la consecucin de los objetivos de mejora
El modelo TMMi esta promovido por la industria del software a travs de la organizacin sin animo de lucro denominada TMMi Foundation.
20
2. CAPITULO 2: BUENAS PRCTICAS PARA LA IMPLANTACIN DE UN PLAN DE MEJORA
21

2.1. INTRODUCCIN
Los objetivos principales de la implantacin de un plan de mejora de los procesos de pruebas del ciclo de vida del software son: Reducir radicalmente el time to market de desarrollo de nuevos productos software Eliminar la tasa de defectos, fallos y problemas del producto software, reduciendo radicalmente el coste de no calidad Ganar en eficiencia interna en todas las fases y actividades del ciclo de vida y, en consecuencia, mejorar de forma relevante la competitividad empresarial. Evidenciar frente a terceros los niveles de madurez o capacidad de los procesos de pruebas alcanzados mediante la certificacin TMMi.
Mejorar relevantemente el cumplimiento de las previsiones de plazo y coste del proceso de pruebas
En este capitulo se expondrn las caractersticas, los riesgos, las claves y los beneficios de la puesta en marcha de un plan de mejora del proceso de pruebas del producto software de acuerdo con el modelo TMMi, los diferentes mtodos de evaluacin y se abordar la institucionalizacin como gestin del cambio. Asimismo, se hace nfasis en la evaluacin del nivel de madurez de una Organizacin como herramienta para caracterizar la capacidad de los procesos de pruebas y as poder determinar las acciones de mejora para alcanzar el nivel de madurez establecido como objetivo. Para finalizar, se proponen las buenas practicas de gestin del cambio organizativo teniendo en cuenta los riesgos asociados a una penetracin limitada de las practicas del modelo, logrando as la institucionalizacin del modelo.
22
2.2. CARACTERIZACIN DEL PROCESO MADURO DE PRUEBAS DE SOFTWARE
Como premisa se exponen, a continuacin, las principales diferencias entre un proceso inmaduro y un proceso maduro de software.
PROCESO DE PRUEBAS INMADURO
PROCESO DE PRUEBAS MADURO
Proceso Ad hoc, improvisado.
Proceso definido y documentado, comprendido, utilizado y vivo.
Ni seguido, ni impuesto rigurosamente.
Respaldado visiblemente por la direccin de la Organizacin.
Dependiente organizacin.
de
los
profesionales
de
la
Clara definicin y comprensin de los roles y responsabilidades durante todo el proyecto y en toda la organizacin.
Hay dificultad para predecir la calidad del producto. Tiene alta posibilidad de problemas de coste y planificacin, debido a una estimacin ineficaz. La funcionalidad del producto y la calidad a menudo se resienten para cumplir el plan. No se toman mediciones.
Se revisa la adherencia al proceso y se hace cumplir. Es coherente con la forma en que el trabajo se hace.
Est respaldado por la tecnologa.
Medido, como base para la mejora. Fuente: Propio.
23

2.3. HOJA DE RUTA PARA LA MEJORA DEL PROCESO DE PRUEBAS Un plan de mejora del proceso de pruebas del producto software debe cubrir los hitos parciales que, a continuacin, se describen. Evaluar las fortalezas y debilidades de la Organizacin e identificar los gaps en relacin con un modelo de proceso de referencia, en este caso TMMi. Identificar las acciones de mejora para la consecucin del Nivel de madurez fijado como objetivo de TMMi, consensuadas por la direccin y el equipo de profesionales de la Organizacin. Definir un plan de accin global para la implantacin de las mejoras, que incorpore la adecuacin de los procesos y herramientas, la formacin, la gestin del cambio y el seguimiento del avance que garantice una exitosa adaptacin de toda la organizacin. Redisear los procesos y definir los ajustes necesarios en la Organizacin Implantar las herramientas para automatizar la gestin y la ejecucin de las pruebas. Establecer un procedimiento para la medicin constante de la mejora obtenida tras la implantacin de las mejoras y adopcin de una filosofa de mejora continua.
Para estructurar el plan de mejora, las fases a considerar son las siguientes:
Fuente: Propio.
24

1. Anlisis de situacin actual. Evaluacin de los procesos actuales de pruebas del ciclo de vida del software que permita conocer la situacin de partida de la organizacin. Estudio del mtodo de trabajo actual y de las herramientas de soporte.
2. Elaboracin del plan de mejora. Identificacin de las reas de proceso a mejorar, estableciendo los objetivos o metas a alcanzar en la organizacin (relacionadas con el nivel de madurez escogido) y elaborando un plan de accin para alcanzar la meta marcada.
3. Implantacin del plan de mejora. Implantacin de las prcticas genricas y especficas para lograr las metas del nivel del modelo CMMI establecido como objetivo para la organizacin. Incluye el diseo o ajuste de los procesos y los desarrollos o ajustes necesarios sobre las herramientas de soporte al proceso de mejora.
4. Acreditacin. Evaluacin final, de clase A, dirigida por un Lead Assesor reconocido por TMMi Foundation, de acuerdo con la metodologa conocida como Standard CMMI Appraisal Method for Process Improvement (en adelante, TAMAR) de TMMi Foundation.
2.3.1. Anlisis de situacin actual
El objetivo de esta fase es realizar una valoracin del grado de madurez del proceso de pruebas del producto software y establecer el gap al modelo objetivo, en este caso, TMMi.
Actividades a considerar en esta fase:
Identificacin de roles y personas: seleccin de los grupos participantes en el proceso de evaluacin.
Recogida de datos del proceso: o Realizar entrevistas y sesiones de realimentacin, diseadas para recoger y sintetizar datos sobre los resultados del proceso
25

de pruebas del producto software y de la metodologa de la Organizacin. o Identificar los objetivos de negocio de la Organizacin y sus plazos. o Identificar las iniciativas de mejora existentes.
Anlisis de gaps: o Determinar las fortalezas y debilidades de la Organizacin en relacin con el nivel objetivo de TMMi. o Identificar mejoras del proceso alineadas con los objetivos estratgicos. Lo habitual es que esta evaluacin inicial de madurez de los procesos de pruebas del producto software por un Assessor reconocido por TMMi Foundation y se realice de acuerdo con la metodologa TAMAR Clase B o C.
2.3.2. Elaboracin del plan de mejora
El plan de accin de mejora deriva del proceso de diagnstico de la situacin de partida del proceso de pruebas del producto software. Este plan determinar los pasos a seguir, de acuerdo con las carencias y reas de mejora detectadas.
Asimismo,
el
plan
se
desglosar
en
unidades
de
trabajo,
con
la
correspondiente descripcin de actividades y responsabilidades.
Es imprescindible obtener la aprobacin y el compromiso de la direccin con el plan para garantizar que la implantacin se pueda ejecutar con xito.
26
2.3.3. Implantacin del plan de mejora
Como actividad inicial deberemos contemplar la definicin o reingeniera de procesos de pruebas, comprendidos en el nivel TMMi objetivo:
Definir polticas y objetivos de las reas de proceso.
Definir el proceso de cada rea para la Organizacin: se genera la documentacin correspondiente a cada rea que mejor se ajuste, en funcin de los objetivos y criterios.
Definir roles, responsabilidades y procedimientos para cada rea de proceso.
Definir los estndares en cada rea de proceso.
Conjuntamente con la adaptacin de los procesos se deben considerar las herramientas de soporte.
Una vez definidos los procesos, guas, estndares y herramientas, se debern identificar las necesidades formativas y definir los planes de formacin especficos para la difusin del nuevo modelo. Por ejemplo, ordenar la formacin por perfiles de la Organizacin.
Lo habitual es identificar un equipo de mejora en la organizacin, responsable de la definicin de procesos y de la difusin al resto de los equipos.
Se recomienda que el modelo diseado se implante progresivamente, definiendo pilotos y valorando la adecuacin del modelo en escenarios controlados.
27

Para ello se selecciona un equipo piloto formado por integrantes de la Organizacin y aquellos proyectos e iniciativas susceptibles de actuar como banco de pruebas y ajustes del modelo. Previamente deber formarse a quienes intervengan en la mejora.
Tras la aplicacin de los pilotos se realiza una valoracin para detectar los puntos de mejora. Luego se realizarn los ajustes o la redefinicin en el modelo de procesos que se consideren necesarios para facilitar su extensin al resto de la organizacin.
Finalmente, se despliega el nuevo modelo definido en un escenario de aplicacin total en la organizacin. Dicha aplicacin se realiza, en cualquier caso, de forma paulatina, de acuerdo a la estrategia de despliegue definida para la incorporacin de los proyectos al modelo.
2.3.4. Certificacin
Antes de la evaluacin final se puede realizar una intermedia de los procesos de pruebas del producto de software implantados en una muestra de proyectos, para determinar la preparacin necesaria para la evaluacin final y tomar las debidas acciones correctivas de los gaps correspondientes.
Por ltimo, se procede a la evaluacin formal dirigida por un Lead Assessor reconocido por el TMMi Foundation.
La metodologa a utilizar ser TMMi Assessment Method Application Requirements (TAMAR V2.0) de TMMi Foundation.
28

2.4. MTODO DE EVALUACIN
El mtodo de evaluacin del Modelo TMMi es TMMi Assessment Method Application Requirements (TAMAR) de TMMi Foundation. Todos las evaluaciones formales deben ser supervisados por un Lead Assessor autorizado por la TMMI Foundation para garantizar interpretaciones correctas. A continuacin, se incluyen los requisitos exigidos para actuar como Lead Assessor y asesor.
29

2.5. LA INSTITUCIONALIZACIN COMO GESTIN DEL CAMBIO
La institucionalizacin es el conjunto de acciones que debe realizar una organizacin para asegurar que un proceso o, en general, cambios o mejoras se utilizan y perduran en el tiempo y son repetibles. La institucionalizacin se aborda a travs de los objetivos y prcticas genricos aplicados a cada una de las reas de procesos del nivel objetivo.
La puesta en marcha de un plan de mejora de TMMi, lleva asociado una serie de beneficios: Homogeneizacin y optimizacin de los procesos de pruebas. Los procesos se estandarizan y se adaptan a las necesidades reales de la organizacin. Reduccin significativa de los costes de no calidad. Reduccin de la complejidad de mantenimiento de los sistemas y del retrabajo: menor ndice de errores. Desde el punto de vista interno de la organizacin: potenciacin de la imagen del departamento de sistemas ante el resto de reas de negocio y generacin de confianza mutua. Desde el punto de vista externo: reconocimiento del mercado. Incremento de la integracin de los proveedores externos en los procesos internos de desarrollo de sistemas, al trabajar de forma homognea con el resto de la organizacin.
30

Los principios a considerar cuando nos embarcamos en un plan de mejora de procesos de pruebas son los que se mencionan seguidamente: Es responsabilidad de la direccin patrocinar la mejora. La mejora debe concentrarse en arreglar el proceso, no en buscar culpables. Primero hay que entender el proceso actual, luego simplificarlo, integarlo y automatizarlo La mejora debe medirse peridicamente. El proceso de mejora requiere constancia en la inversin. La mejora es un proceso continuo. La implantacin de las mejoras la realizan las personas de la Organizacin.
31
3. CAPITULO 3: BUENAS PRCTICAS DEL PROCESO DE PRUEBAS. NIVEL DE MADUREZ 2.
32

3.1. INTRODUCCIN
El Nivel 2 de madurez de TMMi persigue que los procesos de pruebas estn gestionados, adems de ser repetibles y que no ocurran de forma aislada en los proyectos de la Organizacin.
Para lograr estos objetivos, las siguientes reas de Proceso:
Polticas de pruebas y estrategia (Test policy and strategy) Planificacin de pruebas (Test Planning) Monitorizacin de pruebas y control (Test monitoring & control) Diseo de pruebas y ejecucin (Test Design & Execution) Entorno de pruebas (Test environment)
Uno de los objetivos principales de este nivel es garantizar que las actividades de pruebas comienzan en fases tempranas del ciclo de vida de desarrollo. Es importante mitigar la propagacin de defectos desde los requisitos y el diseo en la fase de codificacin. Esto slo se consigue involucrando a los equipos de calidad en fases tempranas del desarrollo y prevenir, prevenir y prevenir. Es importante trabajar en el cambio cultural de la organizacin, el management debe de dejar de ver a las pruebas de software como una fase ms del Ciclo de vida. que se inicia cuando finaliza la codificacin.
El objetivo de esta rea de proceso es que todos en la Organizacin conozcan las polticas de pruebas y la estrategia de testing de la misma. Las pruebas de software debes estar bien instauradas en la empresa. Para ello, se debe definir cuales son los objetivos y asegurar que estn alineado con los objetivos de negocio de la Organizacin.
Adems se debe realizar un anlisis de riesgo a nivel de producto para identificar las reas ms crticas que supondr la entrada principal del plan de pruebas.
El plan de pruebas debe definir el alcance, las tcnicas de pruebas y las responsabilidades de ejecucin, basndose en la estrategia de pruebas y el anlisis de riesgos realizado. Adems incluir el calendario de pruebas, las prioridades de ejecucin, el esfuerzo estimado para el testing y los recursos asignados.
Es importante definir y establecer indicadores representativos de eficacia y eficiencia de los procesos de pruebas y, as, identificar y oner en marcha las debidas acciones de mejora segn los resultados obtenidos.
33

La monitorizacin y el control de las pruebas proporcionarn la informacin necesaria para determinara en cualquier momento del proyecto el progreso y la evolucin de las pruebas previstas en el plan de pruebas, detectando posibles desviaciones con respecto al plan inicial y poniendo en marcha las debidas acciones correctivas para su subsanacin.
El diseo y la ejecucin de pruebas pretende mejorar los procesos de pruebas mediante la correcta gestin del diseo y la ejecucin de pruebas, incluyendo la priorizacin de pruebas, la identificacin de los juegos de datos, la trazabilidad y la definicin del plan de ejecucin de pruebas.
Por ltimo, el entorno de pruebas tiene como propsito la definicin y el mantenimiento de todos los componentes constitutivo del entorno.
A continuacin, se describe en mayor detalles tanto las metas como las practicas asociadas a cada rea de proceso presentada.
34

3.2. ESTABLECER UNA POLITICA Y UNA ESTRATEGIA DE PRUEBAS (PA 2.1)
El propsito de esta buena prctica es establecer una poltica de testing
y una
estrategia, a nivel de la Organizacin, en la que se definan de forma no ambigua los niveles del testing a ejecutar en los proyectos. A continuacin se definen las metas y las prcticas especficas. META SG1: Establecer una poltica de Testing o PRACTICAS ESPECIFICAS SP 1.1 Definir los objetivos del Testing SP 1.2 Definir la Poltica de Testing SP 1.3 Distribuir la Poltica a los interesados
META SG 2: Establecer una estrategia de Testing o PRACTICAS ESPECIFICAS SP 2.1 Realizar una evaluacin de riesgos de producto genrica SP 2.2 Definir una estrategia de Testing SP 2.3 Distribuir la estrategia a los stakeholders.
META SG 3: Establecer indicadores de rendimiento del testing o PRACTICAS ESPECIFICAS SP 3.1 Definir los indicadores de rendimiento del Testing SP 3.2 Implementar los indicadores
35

3.3. PLANIFICAR LAS PRUEBAS (PA 2.2)
El objetivo de la planificacin de las pruebas es definir el enfoque
basado en los
riesgos identificados y la estrategia definida, y establecer y mantener los planes que definan las actividades, recursos y plazos del mismo para asegurar que el producto software cumpla con los requisitos. El plan de pruebas proporciona la base para su gestin, constituyendo el marco para realizar y comprobar las actividades de testing del proyecto dirigidas a cumplir los compromisos con el cliente. A continuacin se definen las metas y las prcticas especficas.
META SG1: Evaluar los riesgos del producto o PRACTICAS ESPECIFICAS SP 1.1 Definir las fuentes y categoras de los riesgos de producto SP 1.2 Identificar los riesgos SP 1.3 Analizar los riesgos
META SG 2: Establecer el enfoque del Testing o PRACTICAS ESPECIFICAS SP 2.1 Identificar productos y caractersticas a testear SP 2.2 Definir el enfoque del Testing SP 2.3 Definir los criterios de entrada SP 2.4 Definir los criterios de salida SP 2.5 Definir los criterios de suspensin y reanudacin
36

META SG 3: Establecer estimaciones del Testing o PRACTICAS ESPECIFICAS SP 3.1 Establecer una estructura de descomposicin del trabajo (WBS) de alto nivel SP 3.2 Definir el ciclo de vida del Testing SP 3.3 Determinar las estimaciones de esfuerzo y coste del testing Establecer indicadores de rendimiento del testing META SG4: Desarrollar un plan de Testing o PRACTICAS ESPECIFICAS SP 4.1 Establecer el calendario del testing SP 4.2 Planificar el personal del testing SP 4.3 Planificar la involucracin de los stakeholders SP 4.4 Identificar los riesgos de Testing del proyecto SP 4.5 Establecer el Plan de Testing META SG 5: Obtener el compromiso con el plan de Testing o PRACTICAS ESPECIFICAS SP 5.1 Revisar el plan de pruebas SP 5.2 Reconciliar los niveles de trabajo y de recursos SP 5.3 Obtener el compromiso con el plan de Testing
37

3.4. SEGUIR Y CONTROLAR LAS PRUEBAS (PA 2.3) El propsito de esta rea de proceso es proporcionar el conocimiento del progreso de las pruebas y de la calidad del producto software, de forma que se puedan tomar las acciones correctivas adecuadas cuando se detecten desviaciones significativas al plan o desviaciones de calidad del producto frente a lo esperado.
A continuacin, se escriben las metas y las prcticas especficas.
META SG 1: Monitorizar el proceso de testing frente al plan o PRACTICAS ESPECIFICAS SP 1.1 Monitorizar los parmetros de planificacin del Testing SP 1.2 Monitorizar los recursos de entorno proporcionados y usados SP 1.3 Monitorizar los compromisos SP 1.4 Monitorizar los riesgos SP 1.5 Monitorizar la involucracin de los stakeholders SP 1.6 Llevar a cabo revisiones de progreso SP 1.7 llevar a cabo revisiones de hitos
META SG2: Monitorizar la calidad del producto frente al plan y las expectativas o PRACTICAS ESPECIFICAS SP 2.1 Verificar los criterios de entrada SP 2.2 Monitorizar las incidencias SP 2.3 Monitorizar los riesgos SP 2.4 Monitorizar los criterios de salida SP 2.5 Monitorizar los criterios de suspensin y reanudacin SP 2.6 Llevar a cabo revisiones de calidad del producto SP 2.7 Llevar a cabo revisiones de hitos de calidad
38

META SG 3: Gestionar las acciones correctivas hasta su cierre o PRACTICAS ESPECIFICAS SP 3.1 Analizar los problemas SP 3.2 Tomar acciones correctivas
3.5. DISEAR Y EJECUTAR LAS PRUEBAS (PA 2.4)
El propsito de esta rea de proceso es mejorar la capacidad del proceso de testing durante su diseo y ejecucin, estableciendo especificaciones de diseo, usando tcnicas de diseo, ejecutando un proceso de testing estructurado y gestionando las incidencias hasta su cierre.
META SG 1: Desarrollar anlisis y diseo del Testing o PRACTICAS ESPECIFICAS SP 1.1 Identificar y priorizar las condiciones del Testing SP 1.2 Identificar y priorizar los casos de prueba SP 1.3 Identificar los datos de testing necesarios SP 1.4 Mantener la trazabilidad horizontal con los requisitos
META SG 2: Preparar el Testing o PRACTICAS ESPECIFICAS SP 2.1 Desarrollar y priorizar los procedimientos de Testing SP 2.2 Crear los datos de Testing necesarios SP 2.3 Definir procedimiento de entrada al testing SP 2.4 Definir calendario de ejecucin de Testing
39

META SG 3: Ejecutar el Testing o PRACTICAS ESPECIFICAS SP 3.1 Ejecutar procedimiento de entrada. SP 3.2 Ejecutar casos de prueba SP 3.3 Reportar las incidencias SP 3.4 Escribir el log de testing
META SG 4: Gestionar las incidencias hasta su cierre o PRACTICAS ESPECIFICAS SP 4.1 Decidir sobre las incidencias en el comit de gestin de configuracin SP 4.2 Tomar incidencias SP 4.3 Gestionar el estado de las incidencias de testing las acciones para la resolucin de las
40

3.6. ENTORNO DEL TESTING (PA 2.5) El propsito de esta rea de proceso es establecer y mantener un entorno adecuado, incluyendo los datos de testing, forma gestionable y repetible. A continuacin, se escriben las metas y las prcticas especficas. en el cual sea posible ejecutar el testing de una
META SG 1: Desarrollar las necesidades del entorno de Testing o PRACTICAS ESPECIFICAS SP 1.1 Obtener las necesidades de entorno de testing SP 1.2 Desarrollar los requisitos de entorno de testing SP 1.3 Analizar los requisitos de entorno de testing
META SG 2: Preparar el entorno de Testing o PRACTICAS ESPECIFICAS SP 2.1 Implementar el entorno de testing SP 2.2 Crear datos de testing genricos SP 2.3 Especificar procedimiento de entrada al entorno de testing SP 2.4 Ejecutar test de entrada de entorno
META SG 3: Gestionar el entorno de Testing o PRACTICAS ESPECIFICAS SP 3.1 Gestionar el sistema SP 3.2 Gestionar los datos de testing SP 3.3 Coordinar la disponibilidad y uso de los entornos de testing SP 3.4 Reportar y gestionar las incidencias de entorno
41

3.7. META Y PRCTICAS GENRICAS PARA EL NIVEL 2
A continuacin, se describen la meta y las practicas genricas para la institucionalizacin de Nivel 2 de Madurez de los procesos de TMMi.
META GG 2: Institucionalizar un proceso gestionado. PRACTICAS GENERICAS GP 2.1: Establecer una poltica organizativa. GP 2.2: Planificar el proceso. GP 2.3: Suministrar recursos para la realizacin del proceso. GP 2.4: Asignar responsabilidades para realizar el proceso. GP 2.5: Entrenar a las personas que realizan el proceso. GP 2.6: Gestionar la configuracin de los elementos del proceso. GP 2.7: Identificar e involucrar a los agentes relevantes del proceso. GP 2.8: Seguir y controlar la realizacin del proceso. GP 2.9: Evaluar objetivamente el cumplimiento del proceso. GP 2.10: Revisar el estado con la direccin de la Organizacin.
42
4. CAPITULO 4: BUENAS PRCTICAS DEL PROCESO DE PRUEBAS. NIVEL DE MADUREZ 3.
43

4.1. INTRODUCCIN
En el Nivel 3 de TMMi, el proceso de testing esta estandarizado, documentado y es seguido por toda la Organizacin, adems de no ser una fase que sigue a la codificacin, sino que se integra a lo largo de todo el ciclo de vida del software. La planificacin del testing se inicia en la fase de requisitos y contina durante todo el ciclo de vida (en V). Los objetivos del testing se establecen respecto a los requisitos a partir de las necesidades del cliente/usuario, y se usan en el diseo de los casos de prueba. En el Nivel 3 existe una organizacin de testing con formacin especializada en tcnicas de testing, adems de un proceso de control y seguimiento para tomar
acciones correctivas frente a desviaciones en relacin con el plan previsto.
En este Nivel 3 se inicia la adopcin de herramientas de automatizacin de pruebas y el enfoque de las pruebas se centra en la verificacin y validacin de los requisitos
Finalmente,
la direccin de la Organizacin reconoce las pruebas como una actividad
profesional especializada y con entidad propia.

Las cinco (5) reas de proceso de Nivel 3 son las siguientes: 1. Organizacin de testing 2. Plan de formacin de testing 3. Ciclo de vida de testing e Integarcin 4. Testing no funcional 5. Peer Reviews
A continuacin, se describe en mayor detalles tanto las metas como las practicas asociadas a cada rea de proceso presentada.
44

4.2. ORGANIZACIN DEL TESTING (PA 3.1)
El propsito de esta buena prctica es identificar y organizar un grupo de personas formadas que sea responsable del testing. Adems el grupo de testing gestiona las mejoras a los procesos y dems activos de testing de la organizacin , basadas en el entendimiento de las fortalezas y debilidades del activo de procesos actual.
A continuacin se definen las metas y las prcticas especficas.
META SG1: Establecer la Organizacin del Testing o PRACTICAS ESPECIFICAS SP 1.1 Definir la Organizacin del Testing SP 1.2 Obtener compromisos con la organizacin del Testing SP 1.3 Ejecutar la organizacin del testing
META SG 2: Establecer las funciones de los especialistas del Testing o PRACTICAS ESPECIFICAS SP 2.1 Identificar los perfiles SP 2.2 Desarrollar las descripciones de los perfiles SP 2.3 Asignar miembros de la organizacin a los perfiles de testing
META SG 3: Establecer planes de carrera de Testing o PRACTICAS ESPECIFICAS SP 3.1 Definir los planes de carrera SP 3.2 Desarrollar los planes de carrera
45

META SG 4: Determinar, planificar e implementar mejoras al Proceso de Testing o PRACTICAS ESPECIFICAS SP 4.1 Evaluar el proceso de Testing de la organizacin SP 4.2 Identificar mejoras al proceso de Testing SP 4.3 Planificar las mejoras del proceso P 4.4 Implementar las mejoras del proceso
META SG 5: Implementar el Proceso de Testing de la organizacin e incorporar las lecciones aprendidas o PRACTICAS ESPECIFICAS SP 5.1 Implementar el proceso estndar y dems activos de Testing SP 5.2 Monitorizar la implementacin SP 5.3 Incorporar las lecciones aprendidas en el proceso de Testing de la organizacin
4.3. PLANIFICAR LA FORMACIN EN TESTING (PA 3.2)
El propsito de esta rea de proceso es desarrollar un programa de formacin que facilite el conocimiento y habilidades al personal para que puedan ejecutar las tareas y roles del testing de forma eficaz. A continuacin se definen las metas y las prcticas especficas.
46

META SG1: Establecer una capacidad de formacin en Testing en la organizacin o PRACTICAS ESPECIFICAS SP 1.1 Establecer las necesidades estratgicas de Testing SP 1.2 Alinear las necesidades de formacin en Testing de los proyectos y la organizacin SP 1.3 Establecer un plan de formacin en Testing en la organizacin SP 1.4 Establecer la capacidad de formacin en Testing
META SG 2: Proporcionar la formacin necesaria o PRACTICAS ESPECIFICAS SP 2.1 Impartir la formacin en Testing SP 2.2 Establecer registros de la formacin SP 2.3 Evaluar la eficacia de la formacin
4.4. INTEGRAR LAS PRUEBAS EN EL CICLO E VIDA DEL TESTING (PA 3.3)
El propsito de esta rea de proceso es establecer y mantener un conjunto de activos de procesos de testing en la organizacin y estndares de entorno de
trabajo, e integrar el ciclo de vida de testing con el ciclo de vida de desarrollo. El ciclo de vida integrado asegura la involucracin temprana del testing proyectos. El propsito es tambin definir un enfoque de testing coherente para los mltiples niveles de testing, basado en los riesgos identificados y en la estrategia definida, y proporcionar un plan de testing global, basado en el ciclo de vida definido. A continuacin, se escriben las metas y las prcticas especficas. en los
47

META SG 1: Establecer el Activo de Procesos de Testing de la Organizacin o PRACTICAS ESPECIFICAS SP 1.1 Establecer los procesos estndar de testing SP 1.2 Establecer las descripciones de los modelos de ciclo de vida de testing a todos los niveles SP 1.3 Establecer los criterios y las guas de adaptacin SP 1.4 Establecer el repositorio de procesos de Testing de la organizacin SP 1.5 Establecer la biblioteca de activos de procesos de testing de la organizacin SP 1.6 Establecer los esndares del entorno de trabajo META SG2: Integrar los modelos de ciclo de vida de testing con los modelos de desarrollo o PRACTICAS ESPECIFICAS SP 2.1 Establecer los modelos de ciclo de vida integrado SP 2.2 Revisar los modelos de ciclo de vida integrado SP 2.3 Obtener compromisos de los roles de Testing con los modelos de ciclo de vida integrado META SG 3: Establecer Plan Maestro de Testing o PRACTICAS ESPECIFICAS SP 3.1 Evaluar los riesgos del producto SP 3.2 Establecer el enfoque de Testing SP 3.3 Establecer estimaciones de Testing SP 3.4 Definir la organizacin del Testing SP 3.5 Desarrollar el plan maestro de Testing SP 3.6 Obtener el compromiso con el plan maestro
48

4.5. PRUEBAS NO FUNCIONALES (PA 3.4)
El propsito de esta rea de proceso es mejorar la capacidad del proceso para el testing no-funcional, durante la planificacin, el diseo y la ejecucin. Se hace definiendo un enfoque basado en los riesgos no-funcionales identificados,
estableciendo especificaciones de testing no-funcional y ejecutando un proceso estructurado.
META SG 1: Evaluacin de riesgos de producto no-funcional o PRACTICAS ESPECIFICAS SP 1.1 Identificar riesgos de producto no-funcional SP 1.2 Analizar riesgos de producto no-funcional
META SG 2: Establecer enfoque de Testing no-funcional o PRACTICAS ESPECIFICAS SP 2.1 Identificar caractersticas a testear SP 2.2 Definir el enfoque del Testing no-funcional SP 2.3 Definir criterios de salida
META SG 3: Desarrollar un anlisis y el diseo de Testing nofuncional o PRACTICAS ESPECIFICAS SP 3.1 Identificar y priorizar las condiciones de Testing nofuncional SP 3.2 Identificar y priorizar los casos de prueba SP 3.3 Identificar los datos de prueba necesarios
49

SP 3.4 Mantener la trazabilidad horizontal con los requisitos no-funcionales
META SG 4: Implementar el Testing no-funcional o PRACTICAS ESPECIFICAS SP 4.1 Desarrollar y priorizar procedimientos de Testing nofuncional SP 4.2 Crear datos de prueba especficos
META SG 5: Ejecutar el Testing no-funcional o PRACTICAS ESPECIFICAS SP 5.1 Ejecutar los casos de prueba SP 5.2 Reportar las incidencias de las pruebas SP 5.3 Escribir el log de pruebas
50

4.6. PEER REVIEWS (REVISIONES ENTER PARES) (PA 3.5) El propsito de esta rea de proceso es establecer y mantener un entorno adecuado, incluyendo los datos de testing, forma gestionable y repetible. A continuacin, se escriben las metas y las prcticas especficas. en el cual sea posible ejecutar el testing de una
META SG 1: Preparar las Peer Review o PRACTICAS ESPECIFICAS SP 1.1 Identificar los productos de trabajo a revisar SP 1.2 Definir criterios de Peer Review
META SG 2: Llevar a cabo las Peer Reviews o PRACTICAS ESPECIFICAS SP 2.1 Realizar las peer reviews SP 2.2 Revisin de documentos base de Testing SP 2.3 Analizar los datos de las peer reviews
51

4.7. META Y PRCTICAS GENRICAS PARA EL NIVEL 3
A continuacin, se describen la meta y las practicas genricas para la institucionalizacin de Nivel 3 de Madurez de los procesos de TMMi.
META GG 2: Institucionalizar un proceso gestionado.
PRACTICAS GENERICAS
o GP 2.1: Establecer una poltica organizativa. o GP 2.2: Planificar el proceso. o GP 2.3: Suministrar recursos para la realizacin del proceso. o GP 2.4: Asignar responsabilidades para realizar el proceso. o GP 2.5: Entrenar a las personas que realizan el proceso. o GP 2.6: Gestionar la configuracin de los elementos del proceso. o GP 2.7: Identificar e involucrar a los agentes relevantes del proceso. o GP 2.8: Seguir y controlar la realizacin del proceso. o GP 2.9: Evaluar objetivamente el cumplimiento del proceso. o GP 2.10: Revisar el estado con la direccin de la Organizacin.
META GG3: Institucionalizar el Proceso Definido PRACTICAS GENERICAS o o GP 3.1 Establecer un proceso definido GP 3.2 Recoger informacin de mejora
52
5. CAPITULO 5: RECURSOS DE REFERENCIA 5.1. HERRAMIENTAS
JUnit (http://www.junit.org/) o o o o o o Las pruebas se escriben en Java Clases derivadas de TestCase Comparacin salidas (assertXXX) Automatizacin prueba de regresin Pruebas autodocumentadas (en el cdigo) Independiente e Integrado en Eclipse
Extensiones Junit (Xunit) o Interfaz de usuario swing: JFCUnit (http://jfcunit.sourceforge.net/) Identificar e interactuar con objetos grficos o Interfaz Web: HttpUnit (http://httpunit.sourceforge.net/) y JWebUnit (http://jwebunit.sourceforge.net/) Identificar e interactuar con objetos de la pgina Manejo de request/response o Datos: DBUnit (http://dbunit.sourceforge.net/) Conexin con la base de datos Diversos formatos para cargar datos (XML, base de datos, CSV, etc.) Mtodos assertXXX para comparar las estructuras de tablasCargas masivas de datos: DBMonster (http://dbmonster.kernelpanic.pl/)NUnit (entorno .NET) (http://www.nunit.org/) o o Equivalente a Junit, diversos lenguajes Menor nivel de integracin
53
Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software Anlisis de cobertura de cdigo Clover (http://www.cenqua.com) o o Integracin con Eclipse Cobertura de lneas y decisiones.
EstadsticasCarga y Stress: OpenSTA (http://www.opensta.org/) o o o o Registro de una sesin interactiva Lenguaje de programacin, modificar script Ejecutar, simulando usuarios y controlando la carga Estadsticas
Seguimiento de defectos: o Bugzilla - http://www.bugzilla.org/ Todo desarrollador de software parece haber odo hablar de esta herramienta. No es ni el ms interesante de las herramientas open source de gestores de fallos ni el ms fcil de configurar, pero probablemente el mejor en trminos de funcionalidad, flexibilidad y complementos. o Mantis - http://www.mantisbt.org/ Uno de los principales recursos el rea de seguimiento de fallos y con una interfaz decente. Es necesario cierta capacidad tcnica para realmente configurarlo bien, con eso dicho, es una buena, fiable y bien probada herramienta fuera de la caja. o TestLink - http://www.teamst.org/
CUCUMBER - http://cukes.info/ Cucumber permite escribir la prueba y secuencias de comandos en texto sin formato. Los scripts de prueba describen cmo el software debe comportarse. Puede servir como documentacin, pruebas automatizadas y ayuda al desarrollo, todo en uno. Cucumber trabaja con Ruby, Java, NET, Flex o aplicaciones web, se ha traducido en ms de 30 idiomas.
Watir - http://watir.com/ Watir permite escribir pruebas con el nfasis en la simplicidad, flexibilidad y el mantenimiento. Soporta aplicaciones web desarrolladas en cualquier idioma y una amplia gama de navegadores. Una gran comunidad se ha desarrollado en torno al producto, que ha llegado a ser muy bien considerado en los ltimos aos. 54
Apache Jmeter - http://jakarta.apache.org/jmeter/ Posiblemente el ms antiguo y mejor considerado de las herramientas de pruebas de rendimiento, Jmeter es una herramienta funcionalmente rica para el funcionamiento y la carga de prueba, que ha atrado un seguimiento significativo en los ltimos aos. La interfaz no ser delgusto de todos, pero es una herramienta muy potente y flexible que posee muchos seguidores.
RADview WebLOAD - http://www.webload.org/
Como herramienta de prueba RADview deben se elogiado por el acceso a la base de cdigo abierto, aunque la estrategia ha oscilado durante los aos. En un principio fue 100% de cdigo abierto, y ms tarde trabajo con el modelo de "ncleo abierto" de la actual WebLOAD abierta. WebLOAD fuente abierta constituye el motor de WebLOAD Profesional, la oferta de este ltimo tiene muchas caractersticas adicionales y soporte comercial. Sin duda, es un gran producto, pero no ha desarrollado realmente una comunidad en torno a la herramienta hasta la fecha, que otras herramientas de open sourece como SugarCRM lo han hecho con xito. Sera bueno observar que el WebLOAD se mueva en esta direccin. Links de inters: o o Software testing tools FAQ (http://www.testingfaqs.org/) Software QA Testing and Test Tool Resources (http://www.aptest.com/resources.html)
55

5.2. BIBLIOGRAFA
1. Software Testing: An ISEB Foundation. Brian Hambling, Geoff Thompson, Angelina Samaroo, Peter Morgan. British Computer Society, 2006, ISBN 1902505794 2. Software Testing in the Real World: improving the process. Ed Kit. Addison-Wesley, 1995, ISBN 0-201-87756-2 3. The Complete Guide to Software Testing. Bill Hetzel. QED, 1984, ISBN 0-89435-2423 4. Black Box Testing. Boris Beizer. John Wiley & Sons, 1995, ISBN 0-471-12094-4. 5. Testing Computer Software, 2nd edition. Cem Kaner, Jack Falk, & Hung Quoc Nguyen. Van Nostrand Reinhold, 1993, ISBN 0-442-01361-2. 6. The Art of Software Testing. Glenford J. Myers. Wiley, 1979, ISBN 0-471-04328-1 7. Software Testing Techniques, 2nd edition. Boris Beizer. Van Nostrand Reinhold, 1990, ISBN 0-442-20672-0. 8. The Craft of Software Testing: Subsystem Testing, including Object-based & ObjectOriented Testing. Brian Marick. Prentice-Hall, 1995, ISBN 0-13-177311-5. 9. The Handbook of MIS Application Software Testing: Methods, Techniques & Tools for Assuring Quality Through Testing. Daniel J. Mosley. Yourdon Press, 1993, ISBN 0-13907007-9. 10. Testing Client/Server Applications. Patricia A. Goglia. QED, 1993, ISBN 0-89435-4507. 11. Software Testing: a craftsman's approach. Paul Jorgensen. CRC Press, 1995, ISBN 08493-7345-X. 12. Software Inspection: An Industry Best Practice. David A. Wheeler, Bill Brykczynski & Reginald N. Meeson, Jr. IEEE Computer Society Press, 1996, ISBN 0-8186-7340-0. 13. Software Inspection Process. Susan H Strauss and Robert G. Ebenau. McGraw-Hill, 1993, ISBN 0-07-062166-7. 14. Software Inspection. Tom Gilb and Dorothy Graham. Addison-Wesley, 1993, ISBN 0 201 63181 4. 15. The Journal of Software Testing, Verification and Reliability. John Wiley & Sons Ltd., Baffins Lane, Chichester, West Sussex PO19 1UD. 16. Software Testing and Quality Engineering Magazine
56

17. Software Quality Engineering, 3000-2 Hartley Road, Jacksonville, FL 32257 USA $85 (European) $59 (USA) Six issues per year 18. Testing Object-Oriented Systems: Models, Patterns and Tools. Robert V. Binder. Addison-Wesley, 1999, ISBN 0-201-80938-9. 19. Managing Software Quality and Business Risk. Martyn A. Ould. John Wiley & Sons, 1999, ISBN 0-471-99782-X. 20. Managing the Testing Process: Practical tools and techniques for managing hardware and software testing. 21. Rex Black. Microsoft Press, 1999, ISBN 0-7356-0584-X. 22. Automated Software Testing: Introduction, Management and Performance. Elfrieda Dustin, Jeff Rashka and John Paul. Addison Wesley, 1999. ISBN 0-201-43287-0. 23. Software Test Automation: Effective use of test execution tools. Mark Fewster and Dorothy Graham. Addison Wesley, 1999. ISBN 0-201-33140-3. 24. Surviving the Top Ten Challenges of Software Testing: a People-Oriented Approach. William E. Perry and Randall W. Rice. Dorset House Publishing, 1997. ISBN 0032633-38-2. 25. The SPIRE Handbook: Better, faster, cheaper software development in small organizations. Ed Marty Sanders. Centre for Software Engineering, 1998. ISBN 1874303-02-9 26. Software Verification and Validation: a Practitioner's Guide. Steven R. Rakitin. Artech House, 1997. ISBN 0-89006-889-5 27. Testing Safety-Related Software: a practical handbook. Ed Stewart Gardiner. Springer-Verlag, 1999. ISBN 1-85233-034-1 28. Software Reliability Engineering. John Musa. McGraw-Hill, 1999. ISBN 0-07-9132715. 29. Structured Testing of Information Systems: an introduction to TMap. Martin Pol and Eric Van Veenendaal. Kluwer, 1998. ISBN 90 267 2910 3 30. Bad Software: what to do when software fails. Cem Kaner and David Pels. John Wiley & Sons, 1998. ISBN 0-471-31826-4 31. Software Projects: Evolutionary vs. big-bang delivery. Felix Redmill. John Wiley & Sons, 1997. ISBN 0-471-93343-0 32. Software Process Improvement: practical guidelines for business success. Sami Zahran. Addison Wesley, 1998.ISBN 0-201-17782-X
57

33. Test Process Improvement. Martin Pol et al. ISBN 34. Software Risk Management. Barry W. Boehm. IEEE Computer Society Press, 1989. ISBN 0-8186-8906-4 35. Brilliant Project Management. Stephen Barker & Rob Cole. ISBN 0-2737-0793-0 36. Project Manager: Mastering the Art of Delivery in Project Management Richard Newton. ISBN 0273701738 37. Applied Software Project Management. Jennifer Greene O'Reilly & Andrew Stellman ISBN 0596009488 38. The definitive Guide to Project Management. Sebastian Nokes, Ian Major, Alan Greenwood & Mark Goodman. ISBN 0273663976 39. The Fast Forward MBA in Project Management. Eric Vurzuh. ISBN 0787963984 40. Fundamentals of Project Management. James P Lewis. ISBN 0814471323 41. All Change: The Project Leaders Secret Handbook. Eddie Obeng. ISBN 0273622218 42. Managing Successful Government Office Projects With Prince2. ISBN 0113309465 43. Project Management Pocket Book. Keith Posner, Mike Applegarth & Phil Hailstone. ISBN1903776872 44. Project Management for Dummies. Stanley Portny. ISBN 0470049235 45. Software Configuration Management Implementation Roadmap. M.E. Moreira. ISBN 0470862645 46. A Guide to Software Configuration Management. Alexis Leon. ISBN 1580530729 47. Software Configuration Management. Bernard Westfechtel & Andre Van Der Hoek. ISBN 3540140360 48. Microsoft's Software Configuration Management Best Practice. Vincent Maraia. ISBN 0321332059 49. Pulling Strings with Puppet Configuration Management. James Turnbull. ISBN 1590599780 50. Software Configuration Management A Standards based Guide. Donald F Shafer. ISBN 0471683639 51. Software Configuration Management Handbook. Alexis Leon. ISBN 1580538827 52. Software Configuration Management Patterns:Effective Teamwork. Steve Berczuk & Brad Appleton. ISBN 0201741172 .
58

53. Configuration Management principles and Practice
. Anne Mette & Jonassen Hass. ISBN 0321117662
54. Configuration Management: Changing Image. The Marion & Vilvandre Kelly. ISBN
59

Soft Quality Manual Buenas Practicas Testing Enero 2011 v1.0

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Soft Quality Manual Buenas Practicas Testing Enero 2011 v1.0

Caricato da

Copyright:

Formati disponibili

BUENAS PRCTICAS PARA EL DESARROLLO CON ESTNDARES DE CALIDAD DE SOFTWARE

SoftQuality Incorporacin de Metodologas Avanzadas de Testing

AGRUPACIN EMPRESARIAL INNOVADORA DE EMPRESAS DE DESARROLLO DE SOFTWARE VERTICAL DE ANDALUCA

Versin 1.0. 04/01/2011

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

1.4.1. 1.4.2. 1.4.3. 1.4.4. 1.5. 2.

2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.4. 2.5. 3.

MTODO DE EVALUACIN .......................................................................................... 29 LA INSTITUCIONALIZACIN COMO GESTIN DEL CAMBIO......................................... 30

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

1. CAPITULO 1: INTRODUCCIN A LA MEJORA DEL PROCESO DE PRUEBAS

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Se esta convirtiendo en el estndar internacional de facto de la industria de software.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Fuente: TMMi Foundation. Versin 1.3.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Las pruebas se desarrollan ad hoc despus de la codificacin

Falta de profesionales especializados en testing

Falta de herramientas de automatizacin y gestin.

El objetivo de las pruebas es demostrar el funcionamiento del software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Las pruebas se convierten en una fase del proyecto

Se implantan procesos estandarizados y tcnicas de pruebas

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

La Direccin de la Organizacin reconoce las pruebas como una actividad profesional

Nivel 4. Gestin cuantitativa.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Nivel 5. Nivel optimizado.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

1.4.3. ESTRUCTURA DE COMPONENTES DEL MODELO TMMi

La estructura de componentes genricos del Modelo TMMi se representa a continuacin:

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Productos de trabajo tpicos: listado de muestras de resultados de una prctica especfica.

interpretacin e implantacin de una prctica genrica o especfica.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

1.4.4. REAS DE PROCESO

considerados importantes para la mejora de dicha rea.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Nivel de rea de proceso madurez

5. Entorno de testing 6. Organizacin de testing

7. Plan de formacin de testing

8. Ciclo de vida de testing e Integracin

12.Evaluacin de calidad de producto

13.Peer Reviews avanzadas 14.Prevencin de defectos

15.Optimizacin del proceso de testing

16.Control estadstico de la calidad

Fuente: TMMI Foundation v1.3.

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

2. CAPITULO 2: BUENAS PRCTICAS PARA LA IMPLANTACIN DE UN PLAN DE MEJORA

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

Buenas Prcticas para la Mejora de los Procesos de Pruebas de Software

2.2. CARACTERIZACIN DEL PROCESO MADURO DE PRUEBAS DE SOFTWARE

PROCESO DE PRUEBAS INMADURO

PROCESO DE PRUEBAS MADURO

Proceso Ad hoc, improvisado.

Proceso definido y documentado, comprendido, utilizado y vivo.

Ni seguido, ni impuesto rigurosamente.

Respaldado visiblemente por la direccin de la Organizacin.

Est respaldado por la tecnologa.