QA, EL REA ESENCIAL .

Implementacin del rea de aseguramiento de la

calidad.

Las empresas a la hora de certificar, no slo deben

pensar en hacerlo sobre sus reas, proyectos y
servicios sino adems sobre sus recursos humanos.

Francisco Contreras Adrian Ziiga.

06/10/2015
 6-10-2015

QA, EL REA ESENCIAL.

Implementacin del rea de aseguramiento de la calidad.

Los siguientes son los puntos principales considerados para la implementacin de esta rea,
la cual es esencial en la entrega de un buen producto a nuestros clientes.

EQUIPO DE REVISIN DE DEFECTOS

(DEFECT REVIEW TEAM)

Debido a que durante el desarrollo de cualquier producto software se identifican un gran nmero de

defectos, en muchos casos de alta prioridad o prioridad crtica, un equipo para la revisin de defectos

(Defects Review Team) es esencial en cualquier equipo de testing.

Un DRT (Defects Review Team) proporciona una rpida y eficiente respuesta a un defecto en cualquiera

de nuestros entornos y garantiza una oportuna solucin. El equipo estar integrado por los siguientes

miembros:

Responsable del equipo de desarrollo (Development team leader).

Jefe de proyecto (Project manager).

Responsable del equipo de pruebas (QA team lead).

Cliente (Opcional). Es importante que el cliente forme parte de este equipo, aunque no siempre es posible

su participacin.

Plan de accin:

Lo primero que debemos hacer es establecer un plan de accin. Podemos establecer reuniones

semanales para discutir los defectos ms importantespero claro, una revisin semanal en algunos

casos puede no ser suficiente, y una reunin diaria puede ser deficil de conseguir. Que podramos

hacer? Podemos establecer como norma, una reunin semanal y despus, cada miembro del equipo se

debe comprometer a revisar diariamente los defectos. En caso de que sea necesario se pueden

establecer reuniones ocasionales si fuese requerido.

Nuestro plan de accin:

1
 6-10-2015

1. Todos los miembros del DRT deben de ser notificados, por ejemplo via email, de todos los defectos de

prioridad alta y crtica.

2. Semanalmente se discuten los defectos ms importantes. Los defectos ya existentes se revisan para

asegurarnos que el defecto no est duplicado.

3. Si el defecto es vlido, se introduce en nuestro DTS (Defect Tracking System) como OPEN (ms tarde

sern asignados por el responsable de desarrollo).

4. Se revisan los defectos crticos que deberan haber sido arreglados y que an no estn solucionados. Se

analizan las causas y se establece un plan de accin, cmo podemos arreglar lo antes posible?

5. Haremos anlisis a largo plazo Qu acciones debemos tomar para que defectos as no vuelvan a

repetirse?

6. Debemos de establecer timelines en la resolucin de defectos a corto plazo.

PLANES DE PRUEBAS

El Plan de pruebas describe la estrategia, recursos y planificacin de nuestras pruebas. Esta estrategia

incluye la definicin del tipo de pruebas a realizar para cada iteracin, la cobertura y objetivosen

definitiva, el test plan representa el proceso de pruebas. Es importante detallar lo que est dentro del

scope de las pruebas y lo que no se testear.

La funcin principal del Test Plan es ayudarnos en la realizacin de las pruebaspor ello debe al menos

incluir:

Definir objetivos de las pruebas.

Definir de los elementos que se van a probar.

Enfoque o estrategia que se usar.

Recursos y planificacin necesarios.

2
 6-10-2015

RAPID SOFTWARE TESTING

James Bach es uno de los Gurus sobre Rapid Testing, realiza multiples seminarios y conferencias

alrededor del mundo (junto con Michael Bolton) sobre este tema. Os recomiendo la asistencia a alguno de

estos seminarios si teneis la oportunidad, sino, hay un libro introductorio a esta materia que es de muy

facil lectura que se titula Introducction to Rapid Software Testing escrito por Chris Brown, Gary Cobb,

Robert Culbertson en el 2002.

Rapid Testing quiere decir hacer pruebas ms rpido de lo que las haces ahora, manteniendo

mejorndo nuestros estndares de calidad. Al estar en un ciclo de desarrollo corto y rpido, necesitamos

que nuestras pruebas se adapten al ciclo.

Componentes Esenciales:

People

Como bien todos los test manager saben, tener las personas apropiadas es el ingrediente esencial para

conseguir rapid testing. Rapid testing en particular, necesita de personas que sean disciplinadas,

ordenadas, flexiblespersonas que puedan soportar la presin de planificaciones ajustadas, y que sean

capaces de contribuir desde fases tempranas del ciclo de vida de desarrollo.

Integrated Test Process:

No importa cmo sea de buena tu gente, si no tenemos un proceso sistemtico y disciplinado de

ejecucin de pruebas, no ern eficaces al mximo. Un proceso de pruebas necesita estar basado en

principios fundamentales, y se debe integrar bien con el proceso total del proceso desarrollo. .

Static Testing

El Static Testing se hacen con el fin de validar que el producto est siendo hecho tal y como las

especificaciones de diseo describen, cumpliendo todas y cada una de las especificaciones del sistema,

mejorando as la calidad del diseo. Static Testing es uno de los medios ms eficaces de detectar

defectos en las primeras fases del desarrollo, ahorando tiempo y dinero. Implica inspecciones,

walkthroughs, y revisiones de diseo, del cdigo, as como anlisis esttico para detectar defectos en

sintaxis, estructura de datos, y otros componentes del cdigo.

3
 6-10-2015

Dynamic Testing

A menudo, cuando los ingenieros de testing piensan en testing, estn pensando en las pruebas

dinmicas, que implica el hacer funcionar el sistema con el propsito de encontrar defectos. En

generalmente, los test dinmicos consisten en comparar su funcionamiento real con el esperado. Si el

comportamiento real difiere del comportamiento previsto, se ha encontrado un defecto.

Los test dinmicos los usaremos para realizar un gran variedad de pruebas, desde test funcionales, de

rendimiento, stressson muy importantes, ya que si la planificacin, diseo, desarrollo y ejecucin de los

test dinmicos no se hace correctamente, el proceso de testing ser ineficiente. Los test dinamicos no

slo son ejecutados por el equipo de testing, debera de ser tambin parte de los test unitarios y de

integracin del equipo de desarrollo.

SEVERIDAD Y PRIORIDAD
Este artculo describe las diferencias entre la severidad y la prioridad de los defectos. Es muy importante

que el QA Manager o la persona encargada de la calidad del proyecto, defina los niveles

de prioridad antes de comenzar. Una vez definidos los niveles, deben de ser comunicados al equipo de

desarrollo, bien mediante una reunin o por email, de modo que todos los integrantes de su equipo

conozcan los baremos a utilizar, previamente acordados con el equipo de desarrollo.

Otro aspecto a tener en cuenta es que no todos los requisitos de una aplicacin son iguales. Es decir,

algunos requisitos sern de mayor importancia o tendrn mayor peso en nuestra aplicacin. Por ejemplo,

la compaa donde trabajo realiza aplicaciones para la gestin de datos clnicos as como diagnstico y

tratamiento de enfermedades. Mientras es importante que los datos de los informes salgan correctamente,

es requisito fundamental que las dosificaciones de medicamentos se hagan en la dosis correcta. Un

defecto de estas caractersticas, que causa un peligro potencial, ser asignado el nivel ms alto de

la severidad. La severidad es directamente proporcional al impacto del defecto. El software se

desarrolla para alcanzar un propsito; tratamiento y diagnstico, y este defecto interfiere gravemente el

alcance de esa meta.

La Severidad

Por ejemplo, podemos utilizar cinco niveles de severidad:

Showstopper

Problema de seguridad o que afecta a un requisito primordial para el cual no hay una solucin alternativa.

Impide el uso o la prueba del sistema.

Alto

Un defecto que afecta a un requisito primordial para el cual existe una solucin alternativa. El uso o la

prueba del sistema puede continuar de modo degradado.

4
 6-10-2015

Medio

Una defecto que afecta un requisito no-primordial para el cual no haya solucin alternativa. La

caracterstica no puede ser utilizada.

Bajo

Una defecto que afecta un requisito no- primordial para el cual exista una solucin alternativa.

Cosmtico

La informacin se muestra correctamente pero el aspecto es incorrecto, por ejemplo palabras deletreadas

mal, fuente incorrecta, etc.

La Prioridad

La prioridad de defectos es el orden en el cual los defectos son tratados por los desarrolladores. En mi

empresa, los defectos son asignados por el Jefe de proyecto a los desarrolladores, y es el Jefe de

Proyecto el que podra ajustar de nuevo la severidad y prioridad de los defectos. En muchas ocasiones las

personas encargadas de la calidad de software tendemos a poner niveles y severidades muy altas. El

Jefe de proyecto es el que decide en funcin del tiempo estimado de desarrollo.

La severidad de los defectos da a los jefes de proyecto una buena impresin del estado actual del

software. Tambin sirve para priorizar los defectos, que a su vez proporciona a los desarrolladores una

comprensin clara del orden en la cual deben realizar las reparaciones pertinentes. Esto ayuda a su vez a

los miembros del equipo de QA a realizar mtricas, pero este ya es otro tema del que hablaremos en otro

artculo.

ITIL GESTIN DE SERVICIOS TI

El ao pasado, en la coferencia internacional de QA&Test, estuve en una presentacin sobre ITIL. Era la

primera vez para m que oa hablar de ello (aunque estoy seguro que se lleva aos implantando), pero

han pasado los meses y no paro de ir gente hablar de la Gestin de Servicios TI usando ITIL. Parece que

se est poniendo de moda dentro de grandes organizaciones. Slo quiero comentar un poco que es ITIL y

a quin va dirigido y por si alguien no ha oido nunca hablar de ITIL, sepa al menos que es y donde puede

encontrar ms informacin.

ITIL (IT Infraestructure Library) fue desarrollado en la dcada de los 80 en Inglaterra. Es el framework o

marco de procesos de Gestin de Servicios de TI que proporciona un conjunto de mejores prcticas

recogidas por la Oficina Gubernativa de Comercio Britnica y que describe los procesos necesarios para

administrar el rea de TI eficazmente con el fin de optimizar beneficios y garantizar la integracin de los

servicios en la cadena de valor de las unidades de negocio.

El conjunto de best practices de ITIL permite hacer ms eficiente la gestin de servicio de TI, generar

orden, lenguaje y procesos comunes, que establecen la mejor manera de hacer las cosas. Este estndar

5
 6-10-2015

no es una solucin en s; para lograrlo es fundamental contar con personas con el conocimiento para

aplicar las recomendaciones y procesos necesarios.

Esta es un breve descripcin del modelo actual:

+ Perspectiva de Negocios (The Business Perspective)

+ Administracin de la Infraestructura de TIC (ICT Infrastructure Management)

+ Soporte de Servicios (Service Support)

+ Entrega de Servicios (Service Delivery)

+ Planeacin para implementar la Administracin de Servicios (Planning to implement Service

Management)

+ Administracin de la Seguridad( Security Management)

+ Administracin de Aplicaciones (Application Management)

Cuales son los beneficios de implantar ITIL:

* Aumentar la satisfaccin de los clientes.

* Reducir el costo de desarrollo de prcticas y procedimientos.

* Mejorar los flujos de comunicacin entre el personal de informtica y los clientes o usuarios.

* Aumentar la productividad, las capacidades y la experiencia de los colaboradores.

* Enfocar los servicios de TI hacia la calidad.

* Obtener una visin clara de la capacidad de las TI y sus ventajas para la organizacin.

* Obtener informacin acerca de los cambios que proporcionarn un mayor beneficio para la organizacin.

* Permitir la implantacin efectiva de las TI.

* Favorecer una acertada toma de decisiones con base en indicadores de TI y organizacionales.

* Conocer los procesos de las TI y la forma en que apoyan a los procesos estratgicos.

Os recomiendo la siguiente web, es un curso online de fundamentos de ITIL:

http://itil.osiatis.es/Curso_ITIL/index.php

Donde implantan cursos:

En Barcelona podemos encontrar varios sitios que imparten cursos sobre ITIL, como la Fundaci UPC,

SoftwareAG, netmind la ati. Con unos precios que rondan los 600 1100 . Podeis visitar sus webs

para ms info.

Preparar la Certificacin:

Si estais pensado en preparar la certificacin, la empresa americana SelfTest Software venda examenes

prcticos para la certificacin de los fundamentos en ITIL:

+ http://www.selftestsoftware.com/dept.aspx?dept%5Fid=13000

Referencias:

+ http://www.itil.co.uk/

6
 6-10-2015

En Castellano:

+ http://itil.osiatis.es/Curso_ITIL/index.php

PRIORIDAD EN LOS CASOS DE

PRUEBA
Todo el mundo conoce la importancia de asignar prioridades a los defectos. La prioridad que asignamos a

los defectos es crucial para el xito de un proyecto. Por tanto, la prioridad que se le asigna a un Caso de

prueba (test case) es igual de importante. Podramos discutir durante horas cual es la mejor herramienta

para gestionar este tipo de situaciones, al igual que usamos una herramienta para gestionar y priorizar

nuestros defecto se podran usar muchas de las herramientas de este tipo que hay en el mercado, pero

este no es el objetivo de este artculo.

El concepto de la priorizacin de Casos de Prueba

Bsicamente, un Caso de Prueba en s mismo, slo, no significa nada para nadie. Un Caso de Prueba es

una pieza en un puzle, una pieza no nos sirve de nada si no tenemos el conjunto completo que forme un

contexto. Cmo creamos un contexto? Agrupando nuestros casos de prueba dentro de reas

funcionales. Una vez tenemos definidas nuestras reas funcionales, asociamos cada caso prueba a su

rea y le asignamos una prioridad. As, la prioridad es usada para identificar como de importante un Caso

de Prueba es dentro de un contexto definido. Los valores de la prioridad son especificados en trminos,

por dar un ejemplo, de P1, P2, P3, P4 P5 siendo P1 la prioridad ms alta y P5 la ms baja.

Como establecer la prioridad correcta.

No te puedo ayudar a decidir con precisin la prioridad de tus pruebas, ya que depende de otros factores

como el producto o la aplicacin a probar. Aun as, puedo darte algunas recomendaciones que pueden

ayudarte para comenzar. Hay algunos aspectos para establecer correctamente la prioridad de tus casos

de prueba:

o Define el significado de cada nivel de prioridad

o Revisa los resultados de ejecuciones anteriores para determinar la prioridad.

o Revisa el nmero de defectos encontrados en versiones anteriores.

o Identifica en qu reas los defectos han sido arreglados.

o Identifica la nueva funcionalidad.

Comentar un poco ms en profundidad cada uno de esto aspectos

7
 6-10-2015

1 Define el significado de cada nivel de prioridad

Puede ser de mucha ayuda se escribe un documento con la descripcin de cada uno de los 5 niveles.

Este documento le ser de gran utilidad al equipo de calidad.

2 Revisa los resultados de ejecuciones anteriores para determinar la prioridad

Revisar los resultados de versiones anteriores te ayudar a priorizar mejor los casos de prueba de la

prxima versin. Todo depende si se han encontrado un gran nmero de defectos en rondas pasadas si

simplemente se ha aadido nueva funcionalidad.

3 Revisa el nmero de defectos encontrados en versiones anteriores.

Basndonos en el punto anterior, los defectos encontrados en versiones pasadas nos pueden gran

muchas pistas del nivel de prioridad que debemos de asignar a nuestros casos de prueba.

4 Identifica en qu reas los defectos han sido arreglados.

Si tenemos reas con muchos defectos arreglados esto significa que nuevo cdigo ha sido aadido,

quitado o modificado. Esto implicar que los casos de pruebas afectados por estas modificaciones, deben

de ser ejecutados y se les debe asignar una prioridad mayor. Identifica estos casos.

5 Identifica la nueva funcionalidad

Los casos de prueba a hayan sufrido modificaciones por aadirse nueva funcionalidad o cambios en

requisitos, etcdeben de ser identificados y ser asignado con prioridad alta.

6 Ejecuta los casos de prueba de prioridad alta primero.

Como es de imaginar, aunque no siempre sucede, los casos de prueba a los que les hemos asignado una

prioridad alta, los debemos de ejecutar primero.

Resumen

En este breve pero importante artculo, he explicado algunas de las consideraciones que tenemos que

tener en cuenta a la hora de asignar prioridades a nuestros casos de prueba. Una labor muy importante

que ayuda a los jefes de equipo de QA a saber la el peso de cada caso de prueba dentro del proyecto,

una tarea crtica para el xito del proyecto.

QU ES EL MODELO CMM?
El CMM (Capability Maturity Model for Software), es decir, Modelo de Madurez de Capacidades. Fue

creado por el Software Engineering Institute (SEI) y tiene como Meta el describir los elementos

principales para llegar a cabo los procesos de software de una forma efectivos. El CMM consiste en una

serie de procedimientos destinados a evaluar y mejorar los procesos de desarrollo, implementacin y

mantenimiento del software. Aunque an est en vas desarrollo, es un estndar que la industria acepta

para evaluar y garantizar la calidad y madurez de sus aplicaciones. Por otro lado, hay CMMs para

8
 6-10-2015

procesos que no son estrictamente en el sector del software, como por ejemplo el BMP (Business Process

Management).

Niveles del CMM

CMM define cinco niveles de madurez para una organizacin y proporciona un marco para moverse a

partir de un nivel al siguiente. Las guas CMM contienen actividades diseadas para ayudar a una

organizacin para mejorar sus procesos con la meta de alcanzar capacidad de repeticin, y control de los

mismos. El CMM ha ganado considerable credibilidad en las industrias intensivas en el uso de

conocimientos. La implantacin del CMM ha permitido mejoras considerables en la calidad de los

productos y bajado perceptiblemente el costo del desarrollo dentro de grandes compaas.

Las organizaciones han probado que mejorando sus procesos de desarrollo, CMM del nivel 1 al nivel 3,

puede bajar su costo por hasta 50-60%. An ms, quienes han estado en el negocio de la productividad

del desarrollo del software por aos, sostienen que la rentabilidad resultada de mejoras en productividad y

reduccin en tiempo de llegada al mercado.

Los niveles del CMM son:

1 Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y

mantenimiento de software. Aunque se utilicen tcnicas correctas de ingeniera, los esfuerzos se ven

minados por falta de planificacin. El xito de los proyectos se basa la mayora de las veces en el

esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobre costes. El

resultado de los proyectos es impredecible.

2 Repetible. En este nivel las organizaciones disponen de unas prcticas institucionalizadas de gestin

de proyectos, existen unas mtricas bsicas y un razonable seguimiento de la calidad. La relacin con

subcontratistas y clientes est gestionada sistemticamente.

3 Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones disponen de

correctos procedimientos de coordinacin entre grupos, formacin del personal, tcnicas de ingeniera

ms detallada y un nivel ms avanzado de mtricas en los procesos. Se implementan tcnicas de revisin

por pares (peer reviews).

4 Gestionado. Se caracteriza por que las organizaciones disponen de un conjunto de mtricas

significativas de calidad y productividad, que se usan de modo sistemtico para la toma de decisiones y la

gestin de riesgos. El software resultante es de alta calidad.

5 Optimizado. La organizacin completa est volcada en la mejora continua de los procesos. Se hace

uso intensivo de las mtricas y se gestiona el proceso de innovacin.

Beneficios de la implantacin del modelo CMM

o Mayor efectividad en la deteccin de errores a lo largo del ciclo de vida del desarrollo del software,

reduciendo drsticamente el nmero de defectos.

9
 6-10-2015

o Reduccin de las desviaciones en plazo de los proyectos.

o Mayor tolerancia al cambio e incremento de la capacidad de adopcin y adaptacin de nuevas

Tecnologas.

o Mejora en la rapidez y efectividad de respuesta ante exigencias del negocio.

o Mejora en la colaboracin y comunicacin.

o Mitigacin de Riesgo.

o Reduccin de los costes del proyectos.

Implementacin en la Organizacin:

Una empresa que decide implementar el modelo CMM, indica que no slo se preocupa por la calidad de

su organizacin sino que quiere constituir un proceso continuo de mejora.

Una de las principales ventajas de una empresa que implanta CMM es que es mucho ms flexible a la

hora de integrar nuevos procesos.

Referencias:

+ Wikipedia, La enciclopedia libre

http://es.wikipedia.org

+ Software Engineering Institute, SEI

DESCUBRE EL TMM
22nd marzo 2007 by Javierpello under Metodologias, Quality Engineering

TMM es la abreviacin usada para Test Maturity Model. El TMM es un proceso de madurez del test que

fue originalmente creado por el Illinois Institute of Technoloogy como gua para la mejora de procesos de

testing y como complemento al CMM(i).

La estructura del TMM est basada en el CMM y en sus fases, ya que consiste tambin en 5 niveles que

reflejan el grado de madurez del test. Para cada nivel de madurez, hay definidas un nmero de procesos.

Los cinco niveles del TMM ayudarn a una organizacin a determinar la madurez de sus procesos de test

y a identificar los pasos a seguir para introducir las mejoras necesarias para lograr niveles mayores de

madurez.

Los niveles de madurez son:

o Nivel 1 Inicial: El test est sumido en un proceso catico simplemente no hay test alguno.

10
 6-10-2015

o Nivel 2 Definicin: Se caracteriza por la utilizacin de tcnicas bsicas de test que identificarn si el

software est de acuerdo con sus especificaciones. Estructuracin del proceso de test, planificaciones y

estrategias.

o Nivel 3 Integracin: Se caracteriza por el test est completamente integrado en el ciclo de vida del

software y es reconocido a todos los niveles del modelo en V. El Plan de test est terminado, las

estrategias han sido determinadas en funcin del previo anlisis de riesgos basados en los requisitos.

o Nivel 4 Gestin y Medicin: El test es un proceso medido y cuantificado. La usabilidad es uno de los

atributos de calidad utilizados en el test de software.

o Nivel 5 Optimizacin, Prevencin de defectos y control de calidad: Se caracteriza por

mecanismos precisos para que el test pueda ser mejorado continuamente. En este nivel se utilizan

procedimientos para seleccionar y evaluar herramientas de test.

Cada da los sistemas son ms y ms complejos, haciendo necesario que se tomen en cuenta mejoras en

la calidad de nuestros procesos para mejorar as la calidad final del producto. El modelo TMM nos

proporcionar y proceso de desarrollo de software ms eficiente y efectivo. Nuestro objetivo ser a

prevencin y no en la deteccin.

En la web de la fundacin TMM se puede encontrar muchsima documentacin sobre el modelo TMM y

algunos casos prcticos.

Referencias:

+ http://www.tmmifoundation.org/

SOFTWARE TESTING LIFE CYCLE

Normalmente, el testing est considerado como parte del Ciclo de Vida de Desarrollo de cualquier

aplicacin (Requisitos, anlisis & diseo, implementacin, testing y deployment), pero el testing, a su vez,

tiene su propio ciclo de vida. Dependiendo de la organizacin, este ciclo puede tener ms o menos fases,

pero acontinuacin comentar las fases que son siempre comunes.

A grandes rasgo, podemos decir que el ciclo de vida del Software Testing incluye las siguientes fases:

1. Planificacin.

2. Anlisis

3. Diseo

4. Ejecucin

5. Ciclos

6. Pruebas Finales e Implementacin

7. Produccin

11
 6-10-2015

En qu fase del ciclo de vida deben comenzar las pruebas?

Lo antes posible. Si dividimos el ciclo de desarrollo en cuatro etapas: Inicio, Elaboracin, Construccin y

Transicinel equipo de Quality Assurance debera comenzar sus labores entre la fase de Inicio y

Elaboracin. Es recomendable que al menos el responsable del equipo de calidad asista a las reuniones

de toma de requisitos.

1. Planificacin de las pruebas (Fase de definicin del Producto):

La fase de planificacin de pruebas significa redactar el Test Plan o Plan de Pruebas. El Test Plan es un

documento a alto nivel que describe las estrategias a seguir durante el desarrollo de las pruebas.

Contenidos de un Test Plan:

+ Alcance de las pruebas.

+ Comienzo y fin (planificacin)

+ Estrategias (Black Box, White Box, etc.)

+ Niveles de Pruebas (Integration testing, Regression testing, etc.)

+ Limitaciones

+ Riesgos

+ Revisiones y entregables.

+Tcnicas de Pruebas (Boundary Value Analysis, Equivalence Partitioning, etc.)

Herramientas para realizar las pruebas (Automticas, carga, integracin co

+ Reporting (How would bugs be reported)

+ Hitos

+ Mtricas

+ Recursos y planes de formacin

+ Tareas y responsabilidades

Estas son slo algunos de los contenidos de un Plan de pruebas aunque muchas veces vara

dependiendo de la empresa. Hay algunas plantillas interesantes en internet, como la de la IEEE.

2. Anlisis de pruebas (Fase de Documentacin)

La fase de anlisis es una extensin de la fase de la planificacin. Mientras que la fase de planificacin es

a ms alto nivel, la fase de anlisis es donde se comienza a documentar los planes detallados. Se

comienza a analizar los casos de prueba:

+ Revisin de los Inputs: Se consideran, el documento de especificacin de requisito y otros documentos

de planificacin del proyectomientras, el plan de pruebas se rompe en pequeas partes que sern los

futuros casos de prueba.

12
 6-10-2015

+ Formatos: Generalmente en esta fase se crea una matriz de validacin basada en los requisitos. Estas

matrices nos ayudarn a la hora de ejecutar los test cases. Tambin, usando alguna de las herramientas

de planificacin de proyectos que hay en el mercado (phpcollab, MS project, gantt) creamos la

planificacin de las pruebas basndonos en cada uno de los hitos del plan de proyecto. Las mtricas a

utilizar, tambin se disean en esta fase.

+ Test Cases: casos de prueba. Siguiendo la matriz de validacin y otros documentos de entrada

(inputs), se escriben los test cases. Comenzamos tambin a vincular los requisitos con cada test case.

+ Automatizacin: Mientras se crean test cases, se identifican los casos que deben ser automatizados.

Tambin se identifican las reas para las pruebas de rendimiento, de carga y de stress.

+ Plan de Regresin: Los ciclos de pruebas, es decir, nmero de veces que se probar de nuevo la

aplicacin para verificar que los defectos encontrados no han introducido nuevos errores.

3. Diseo de pruebas:

Tenemos que darnos cuenta que el ciclo de vida de pruebas transcurre en paralelo al de desarrollo. As,

una vez que hayamos llegado a esta fase (el equipo de desarrollo probablemente habr comenzado a

escribir las primeras lneas de cdigo) comenzaremos el diseo.

Durante esta fase todos los planes, test cases, etc de la fase de anlisis son revisados y finalizados. E

Nuevos test cases pueden ser aadidos y se realiza el documento de gestin de riesgos. Tambin es el

momento para hacer los scripts de pruebas automticas (nuevos o update de los ya existentes).

Finalmente, los informes de pruebas, especialmente los informes sobre pruebas unitarias.

4. Ejecucin de las pruebas:

En este momento el equipo de desarrollo tiene una versin estable y lista para testear. Lo ms

recomendable es hacer un test de cualificacin de la versin (qualification testing) para evaluar que la

aplicacin es lo suficientemente estable para comenzar la ejecucin de las pruebas. De nada sirve

comenzar una ronda de test si al cabo de cinco golpes de ratn la aplicacin rompe. Tiene que tener un

mnimo de estabilidad.

Una vez terminado el Qualification, los ingenieros de pruebas ya pueden comenzar a ejecutar el plan de

test. As como los test automticos (si los hubiera), unit testing, revisiones de cdigo, performance.etc.

Para llevar el seguimiento de la ejecucin de los test cases podemos utilizar alguna de las herramientas

comerciales que hay en el mercado o utilizar una matriz de Excel donde iremos apuntado nuestros

PASSED o FAILED (OK o NOK).

5. Ciclo de pruebas (Regresin):

En este momento del ciclo al menos alguna ronda de test ya se habr ejecutado y algunos issues se

habrn reportado. Una vez que el equipo de desarrollo ha arreglado los defectos, la segunda ronda de

pruebas comienza. Esta nueva ronda de pruebas podra solamente centrarse en las reas o

funcionalidades que han sido arregladas. Pero tambin podra ser regresin testing, donde la aplicacin

13
 6-10-2015

es testeada nuevamente para verificar su correcto funcionamiento y que el arreglo de los defectos no ha

afectado otras partes del cdigo.

Pruebas > Reporte de Defectos > Arreglo de Defectos (y mejoras) > Nueva ronda de Pruebas

Aqu es donde pruebas automticas pueden ser de gran ayuda para repetir el mismo test case una y otra

vez.

Durante esta fase es importante revisar el documento de requisitos (CRD) y el Project Plan por si ha

habido modificaciones.

14