TPI Testing Process Improvement

19th June 2007 by Javierpello under Procesos, Quality Engineering

Es bueno tu proceso de testing? Esta es una pregunta muy fcil de hacer y muy dificil de contestar. Las pruebas de software amenudo consumen mucho tiempo y dinero. Muchas organizaciones se han dado cuenta que mejorando sus procesos de pruebas pueden solucionar estos problemas. Sin embargo, en la practica resulta mucho ms dificil saber que medidas tomar para mejorar y controlar el proceso. El modelo TPI est basado en las mejores prcticas de la industria relativas a la mejora del proceso de pruebas. El modelo incluye guas prcticas para evaluar el nivel de madurez de prueba de una organizacin as como los pasos para mejorar el proceso.

El modelo se compone de 20 reas Clave, que constituyen la base para mejorar y estructurar el proceso de Test. Esta es la lista completa: -Test strategy -Life-cycle model -Moment of involvement -Estimating and planning -Test specification techniques -Static test techniques -Metrics -Test automation -Test environment -Office environment -Commitment and motivation -Testing functions and training -Scope of methodology -Communication -Reporting -Defect management -Testware management -Test process management -Evaluation -Low-level testing

Niveles de Madurez Los requisitos para cada nivel estn definidos en forma de Checkpoints, que son preguntas que necesitan ser respondidas afirmativamente para poder calificar a dicho nivel. A partir de las listas de verificacin se puede evaluar un proceso de pruebas y se puede determinar para cada rea Clave el Nivel alcanzado. A medida que se considera mejorada cada rea Clave, los checkpoints son acumulables.

Para poder clasificar para el nivel B, el proceso de pruebas necesita responder afirmativamente tanto a los Puntos de Verificacin del nivel B como del nivel A. Matriz de madurez Cada rea con diferentes niveles de madurez. Los niveles de todas las reas Clave estn integrados en una Matriz de Madurez. Por consiguiente, los niveles de madurez indican el estado de cada rea clave.

La matriz de madurez viene determinada por una escala que va del 1 al 13:

- Controlada (1 al 5) - Eficiente (6 al 10) - Optimizada (11 al 13) El modelo TPI ofrece el soporte necesario para mejorar el proceso de test a travs de la obtencin de rpida manera, se considera el modelo como una herramienta de estructuracin de acciones de mejora del proceso de test.

Buenos Das: Actualmente andamos en bsqueda de herramientas que nos ayuden al rea de control de calidad. Luego de haber visto las demos, especificaciones tcnicas de algunos productos, nos hemos quedado al final con 2 frentes: IBm - Rational - Rational Robot - Rational Manual Tester

- Rational Performance Tester y por otro lado el frente: HP - Quality Center - Test Director - Funcional Testing (Qtp y winnruner) Alguno de ustedes me podra ayudar dndome mayor informacin de ambas opciones, y as poder tomar la opcin ms adecuada al momento de comprar las herramientas?? Gracias Saludos Ronald ronaldarce

Mensajes: 2 Registrado: Jue Sep 18, 2008 10:54 am Arriba

Re: Herramientas para Control de Calidad Software

por orebravo el Vie Sep 19, 2008 9:56 pm Hola Ronald Bienvenido al foro, he utilizado algo de Win Runner y QTP y me parecen un poco duras, es decir no son demasiado intuitivas. No he tenido an experiencia con la Suite de Rational, en todo caso el ms indicado para responder esta consulta es el amigo mored, nuestro especialista en pruebas automatizadas: Mored quedamos a la espera de tus comentarios orebravo Site Admin

Mensajes: 15 Registrado: Vie Mar 28, 2008 11:40 pm Arriba

Re: Herramientas para Control de Calidad Software

por mored el Sab Sep 20, 2008 10:03 pm Hola Ronald, Exactamente que informacin deseas saber??? Osea me refiero, ambas herramientas son muy buenas. Pero viendo la lista que pones en verdad no van cumplir los mismos objetivos. Te explico por el aldo de IBM, pones Robot, manual tester y performance tester. Estas tres te van a servir para poder hacer pruebas funcionales y no funcionales. Robot automatizar pruebas y en si procesos, manual tester ejecutar las pruebas manuales paso a paso de tu test plan y el performance para hacer prueabs de stress. Creo que en este punto de falta un par de cosas a tu solucion, como por ejemplo, donde gestiono los defectos encontrados, si vas a usar IBM, te falta el clear quest para eso. Por otro lado como integro todas mis pruebas para eso seria el test manager. Osea tienes cubierto crear un test plan y ejecutarlo manual o automaticamente, ademas puedes ahcer pruebas de stress. Pero te falta manejar los defectos y sus estados. Eh integrar todo tu proyecto de pruebas en forma global para eso es el testmanager. Por el lado de HP, tienes el manejo de defectos, de plan de pruebas y de gestion de todos tus casos manuales o

automaticos con el testdirector, para poder hacer pruebas automatizadas vas usar el QTP y WR. Ahora en tu lista con HP no tienes con hacer stress, no esta en tu lista el Loadrunner o el performance test (las herramientas para hacer stress en HP). Ahora el TD (testdirector) en forma base te deberia venir para que peudeas implementar estos modulos el testplan (manejar tus bibliotecas de casos), el testlab (donde manejas tus casos con respecto de sus ejecuciones, osea x aca ejecutas manual o automaticamento los casos creados en el testplan), el defecttracking (gestion de defectos amarrados a ejecuciones en el testlab o si keires sueltas), requirement (manejo de tus requerimientos de pruebas para poder la covertura de tus ejecuciones cuanto abarca los requerimientos de tus usuarios a validar) y el dashboard (aca puedes revisar de forma rapida todos las metricas de tus pruebas tus kpis Key Performance Indicators). Ahora tb puedes comprar licencias q ya son quality center que con un par de modulos mas ademas de los anteriores, esto es Bussines componets y releases. El primero es para crear desde el QC casos de prueba automaticos de forma muy rapida, con script ya hechos o recien crearlos desde usando un repositorio de objetos. El segundo no lo eh usado aun ..

Ahora en grandos razgos te digo .. las dos son muy buenas.. pero las de ibm se enfocan mas a realziar preuabs por proyecto esto es no reutilizas tus test plan creados tienes q crealos otra vez las de hp separan mas esas partes y tu peudes reutilizar toda esa info. Saludos Edwin (mored) mored

Mensajes: 8 Registrado: Vie Ago 15, 2008 4:58 pm Arriba

Re: Herramientas para Control de Calidad Software

por ronaldarce el Lun Sep 22, 2008 11:18 am Edwin, gracias por la respuesta. En el caso de IBM, tambin estamos considerando el testmanager (Viene incluido con el rational robot). En el caso de HP no consideramos el load runner ya que es demasiado costoso y estamos pensando usar el performance tester de IBM para lo que es performance. Andamos todava en la duda de cual es la mejor opcin (hay una gran diferencia de precios entre ibm y hp (hp cuesta casi el doble que ibm), adems si elegimos HP tendrasmo que comprar el performance tester de ibm para complementar el test director y qtp. Desde tu experiencia que nos recomendaras?? Favor si tienes ms detalles decirnoslo, nos sera de gran ayuda Saludos Ronald

CASOS DE USO

Diagrama de casos de uso

De Wikipedia, la enciclopedia libre Saltar a: navegacin, bsqueda

Componentes de un diagrama de casos de uso.

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento. UML mejorado El Lenguaje de Modelado Unificado define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso.

Contenido
[ocultar]

1 Diagramas de Casos de Uso UML o 1.1 Relaciones de Casos de Uso 1.1.1 Inclusin (include o use) 1.1.2 Extensin (Extend) 1.1.3 Generalizacin 2 Vase tambin 3 Enlaces externos

[editar] Diagramas de Casos de Uso UML

La descripcin escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripcin se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de uso coherentes, consistentes promueve una imagen fcil del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.

Es prctica comn crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del mbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen rendimiento, temas de escalabilidad/gestin, o cumplimiento de estndares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso estn representados por elipses y los actores estn, por ejemplo, los casos de uso se muestran como parte del sistema que est siendo modelado, los actores no. La interaccin entre actores no se ve en el diagrama de casos de uso. Si esta interaccin es esencial para una descripcin coherente del comportamiento deseado, quizs los lmites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interaccin entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. As el Chef y el Cajero podran ser realmente la misma persona.

[editar] Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estndar UML, el cual describe notacin grfica para esas relaciones. Veamos una revisin de ellas a continuacin:
[editar] Inclusin (include o use)

Es una forma de interaccin o creacin, un caso de uso dado puede "incluir" otro. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es til para extraer comportamientos verdaderamente comunes desde mltiples casos de uso a una descripcin individual, desde el caso de uso. El estndar de Lenguaje de Modelado Unificado de OMG define una notacin grfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocacin pensando que un caso de uso es una notacin grfica (o es su descripcin). Mientras la notacin grfica y las descripciones son importantes, ellos forman parte de la documentacin de un caso de uso --un propsito para el que el actor puede usar el sistema. La notacin es de una flecha de punta abierta con lnea discontinua desde el caso de uso que lo incluye hasta el caso de uso incluido, con la etiqueta "include". Este uso se asemeja a una expansin de una macro, donde el comportamiento del caso incluido es colocado dentro del comportamiento del caso de uso base. No hay parmetros o valores de retorno. Aqui tambien podemos decir que ste va de padre a hijo.
[editar] Extensin (Extend)

Es otra forma de interaccin, un caso de uso dado (la extensin) puede extender a otro. Esta relacin indica que el comportamiento del caso de la extensin se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensin o inclusin. El caso de uso extensin puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notacin, es una flecha de punta abierta con lnea discontinua, desde el caso de uso extensin al caso de uso extendido, con la etiqueta extend. Esto puede ser til para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensin .

"La extensin, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensin son los ejemplos o instancias de los conceptos."

[editar] Generalizacin

"Entonces la Generalizacin es la actividad de identificar elementos en comn entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonmicas entre conceptos que entonces se representan en jerarquas de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intencin y extensin." En la tercera forma de relaciones entre casos de uso, existe una relacin generalizacin/especializacin. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notacin es una lnea slida terminada en un tringulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la prctica puede ser til factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados. esto es gran mentira

COMO REALIZAR CASOS DE PRUEBA

Cuando mi colega Alexander (creador de este Site) me pidi realizar un artculo en base a los Casos de Prueba pens que fcil, si crear casos de prueba es parte de nuestro da a da, la verdad es que lo difcil es plasmar en forma clara, concisa, entendible y sobretodo til este conocimiento, he tratado de darles una idea global del tema, orientado a pruebas funcionales pero los conceptos expuestos son aplicables a todo tipo de prueba, espero les sea til. Segn WIKIPEDIA: En la Ingeniera del software, los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cules el analista determinar si el requisito de una aplicacin es parcial o completamente satisfactorio, clarsimo no?, pero para reforzar la idea y ser an ms claros, podemos decir que los casos de prueba nos ayudan a validar que el aplicativo desarrollado realice las funciones para las que ha sido creado en base a los requerimientos del usuario solicitante. Esto nos indica que por lo menos deber existir un caso de prueba por cada requerimiento que la aplicacin deba cumplir; fcil!!, bueno, lo sera si tenemos claro los requerimientos, si el analista de sistemas o llamado tambin analista funcional realiz un buen levantamiento de la informacin y lo que l indica como verdad es lo que el usuario pidi, pero ese es otro tema que da para largo y que podramos ver en otro artculo, la idea aqu es que nosotros como analistas de pruebas debemos tener claro que debe hacer el aplicativo y cul ser el alcance de las pruebas, una buena documentacin es bsica, como quien dice papelito manda. Pensemos que estamos en una empresa que tiene alguna documentacin de sus desarrollos y nos puede servir como punto de partida. Que debemos hacer para desarrollar nuestros casos de prueba? Primero que nada, documentarnos!!, no podemos aventurarnos a escribir casos de prueba por que s, sin algn fundamento o conocimiento previo del tema, debemos tener claro que har el aplicativo a validar, debemos conversar con el equipo de desarrollo y/o analista funcional o con la persona que levant la informacin para que absuelva las dudas que podamos tener, amigo hgalo! vaya que lo esperolisto?, pues sigamos.

Ok, ya sabemos que debe hacer la aplicacin, aplicativo, sistema o como quiera llamarlo, ahora hagamos una lista de los requerimientos que debemos verificar, por ejemplo si quisiramos hacer casos de prueba sobre la calculadora de windows deberamos primero leer el manual o el help sobre este aplicativo para saber que funciones realiza. Aplicativo: Calculadora de Windows Requerimientos: 1. 2. 3. Etc A cada punto de la lista debemos darle cuerpo con informacin como: que queremos verificar en ese punto, que tipo de datos de entrada necesitamos (si esto aplica), que acciones previas hay que tomar (si esto aplica), que resultado estamos esperando, ojo resultado correcto o incorrecto, ms adelante entenders a que me refiero, entre otras cosas, en resumen estamos creando nuestros escenarios de pruebas, es decir, las diferentes condiciones en las que el aplicativo deber trabajar y por cada escenario es posible contar con uno o varios casos de pruebas. Que tal?, espero que bien y que algo de lo que te cuento te pueda estar sirviendo o dndote una idea ms clara del asunto, bueno pues, hasta el momento hemos dicho que debemos saber que hace el aplicativo y hemos dado alguna pauta para empezar a crear nuestros casos de prueba, ahora bien te cuento que personalmente al crear casos de prueba comienzo por los casos correctos, es decir aquellos requerimientos que la aplicacin debe cumplir si o si, y luego en base a estos cre casos de prueba incorrectos, es decir, aquellos en los cules espero forzar a errores a la aplicacin y esperar una respuesta adecuada pero incorrecta, por ejemplo si la aplicacin tiene como un requerimiento enviar un email y para esto tenemos un campo donde ingresar el email destino , si ponemos un email destino con un formato correcto y que existe luego mandamos el mensaje esperando que este llegue a destino, si esto sucede es un caso correcto, pero que pasa si escribimos el email destino con un formato incorrecto o el email no existe y mandamos el mensaje que debe hacer la aplicacin? Enviarlo y caerse al no encontrar el destino?, o en otras palabras colgarse!!, sera muy decepcionante que esto suceda, en este caso lo que deberamos esperar es que al mandar el mensaje de email, nos aparezca una alerta, mensaje, etc. Cualquier tipo de comunicacin que nos indique que el formato del email destino es incorrecto, o que el mensaje no se pudo entregar porque el destino no existe, bueno pues ese es un caso de prueba incorrecto pero si el resultado es la alerta esperada esta bien. En pocas palabras en la creacin de casos de prueba debemos aplicar la lgica del usuario tonto, es decir, nos ponemos en la situacin de un usuario que va a reventar la aplicacin ingresando emails falsos (para el caso de ejemplo), o datos con formatos incorrectos o no va a seguir las indicaciones de algn flujo o proceso secuencial, es decir a cada validacin de un proceso en situacin ideal habra que probar el mismo proceso con situaciones no ideales y que nos ayuden a encontrar errores. En conclusin no solo debemos verificar que el aplicativo haga bien las cosas que debe sino tambin que no haga lo que no debe. Cuando tengamos nuestros casos de prueba, ahora debemos alimentarlos, darles vida, existen casos en los cules necesitaremos data, otros quizs sean simples en lectura pero impliquen todo el recorrido de un flujo para poder ser completados, otros pueden ser tan simples como dar un clic o verificar el diseo de una pantalla o reporte, esto se puede complicar tanto como queramos por eso es muy importante tener claro el alcance de las pruebas, hasta donde queremos llegar, luego de tener todo listo no nos queda ms que ejecutar los casos de prueba y verificar los resultados, la parte ms pensada debe ser la creacin del caso de prueba y la bsqueda de data correcta de ser el caso, luego de ello la ejecucin y verificacin ser un mero trmite, nuestro mayor logro esta en encontrar errores o defects y contribuir en primera lnea a obtener un producto de calidad. El programador es nuestro amigo, somos del mismo equipo, hay que tener mucho criterio al indicarle los errores encontrados ya que muchos programadores piensan que son infalibles, quizs algunos errores no sean tcnicos sino funcionales, depende mucho como hayamos planteado los casos y nuestra estrategia de pruebas. Bueno para terminar y no desplayarme demasiado, te habl de la informacin que debe tener un caso de prueba, esto es relativo y depende mucho de la informacin que uno necesite para ejecutar el caso de prueba y que quiera hacer con l, para almacenarlo, para tener un buen registro, para informar sobre las pruebas, es decir, no existe una ley que debamos seguir al pie de la letra pero te indico un formato, plantilla con informacin que puede ayudarte: Sumar dos o ms nmeros Restar dos nmeros Dividir dos nmeros

Id de caso de prueba. Mdulo a probar Descripcin del caso Pre-requisitos Data necesaria (valores a ingresar) Pasos o secuencia lgica Resultado esperado (correcto o incorrecto)

Resultado obtenido Observaciones o comentarios Analista de Pruebas (responsable de las pruebas) Fecha de Ejecucin Estado (concluido, pendiente, en proces

As por ejemplo usando algunos campos:

Id Caso Modulo a probar Descripcin del Pre requisitos de caso prueba CP001 VENTAS Verificar que se - Que exista data genere el archivo para el archivo. de ventas - Que exista la ruta correctamente destino CP002 LOGISTICA Verificar que se - Ingresar datos graben los datos -Tener Permisos de de ingreso en la lectura a la BD. tabla Movimientos.

Resultado esperado OK

Resultado obtenido OK

Estado

Concluido

OK

Pendiente

As amigo, puedes utilizar los campos y la informacin que mejor se adecue a tus necesidades, la idea es estar ordenados, organizados y tener una buena informacin de las pruebas. Espero haber podido serte til con mis comentarios y sugerencias y nos encontramos en algn otro artculo dios mediante. Slds.

A investigar
1. Introduccin 1.1 Presentacin 1.2 Tabla de Contenidos 1.3 Organizaciones Internacionales 1.4 Programa de Estudios y Evaluacin 1.5 Objetivos 2. Fundamentos de Pruebas 2.1 Comprendiendo el Proceso de Pruebas de Software. 2.2 Los Siete Principios Generales del Proceso de Pruebas de Software.

2.3 Proceso de Pruebas Bsico. 2.4 Psicologa en el Proceso de Pruebas. 3. Pruebas a travs del Ciclo de Vida del Software. 3.1 Modelos de Desarrollo Software. 3.2 Niveles de Prueba del Modelo-V. 3.3 Tipos de Prueba - Objetivos de las Pruebas. 4. Tcnicas Estticas 4.1 Revisiones y el Proceso de Pruebas. 4.2 Anlisis Esttico basado en Herramientas. 5. Tcnicas de Diseo de Pruebas. 5.1 Diseo de Casos de Prueba. 5.2 Categoras de las Tcnicas de Diseo de Pruebas. 5.3 Tcnicas de Caja Negra (Black Box). 5.4 Tcnicas de Caja Blanca (White Box). 5.5 Tcnicas Basadas en la Experiencia. 5.6 Seleccin de las Tcnicas de Pruebas. 6. Gestin de Pruebas 6.1 Organizacin del Proceso de Pruebas (Test Organization). 6.2 Planificacin y Estimacin del Proceso de Pruebas (Test Planning and Estimation). 6.3 Seguimiento y Control del Estado de las Pruebas (Test Progress Monitoring and Control). 6.4 Gestin de la Configuracin (Configuration Management). 6.5 Riesgo y Proceso de Pruebas (Risk and Testing). 6.6 Gestin de Incidencias (Incident Management). 7. Herramientas de Pruebas 7.1 Tipos de Herramientas de Pruebas. 7.2 Uso Efectivo de Herramientas de Pruebas. 7.3 Introduccin de Herramientas de Pruebas en una Organizacin. 7.4 Resumen.