1.1 CALIDAD DEL SOFTWARE
·
1.1.1 ¿Qué es calidad de software?
Desde los inicios de la ingeniería
del software se ha intentado formalizar una definición de calidad que esté
enmarcada dentro del contexto del desarrollo de software. Muchos autores están
de acuerdo con la importancia que tiene la calidad del software para obtener
aplicaciones con un rendimiento óptimo que cumplan con todos los requisitos
establecidos por el cliente.
Tomando
como base una definición genérica de calidad, desarrollada en el estándar ISO
9000,"grado en el que un conjunto de características inherentes cumple con
los requisitos", se puede empezar a concebir calidad aplicada al
desarrollo de software. Algunos autores han enmarcado la definición de calidad
dentro de este contexto. Autores como William E. Lewis en su libro Software
"Testing And Continuous Quality Improvement" definen calidad de
software desde dos puntos de vista2. El primero, hace alusión al cumplimiento
de requerimientos; de acuerdo a eso, obtener un producto de calidad implica
tener requerimientos medibles, y que se cumplan. Con este significado la
calidad de un producto pasa a ser un estado binario en donde se tiene o no
calidad. El segundo, tiene en cuenta al cliente; el cual define calidad de un
producto o servicio como el cumplimiento de las necesidades presentadas por el
mismo. Otra forma de expresar lo mencionado anteriormente es la capacidad del
producto de "ajustarse para el uso".
Una
definición más concreta de calidad de software, propuesta por Roger S. Pressman3,
sugiere que "la calidad de software es el cumplimiento de los requisitos
de funcionalidad y desempeño explícitamente establecidos, de los estándares de
desarrollo explícitamente documentados y de las características implícitas que
se esperan de todo software desarrollado profesionalmente". Se puede ver
que los dos autores exponen versiones similares de la definición de calidad de
software y en general en el mundo la definición puede variar o extenderse
dependiendo del autor, y no es el objetivo de este proyecto decidir cuál es la
definición correcta, sin embargo, se puede concluir que la calidad de software
es una compleja combinación de factores que varían entre las diferentes
aplicaciones y los clientes que las solicitan.
·
1.1.2 Factores que determinan la calidad del
software
En
el año de 1970, McCall propuso unos factores de calidad que siguen vigentes en
la actualidad, lo que quiere decir que los factores que afectan la calidad del
software no cambian en el tiempo. Estos factores se dividen en dos grandes
grupos; aquellos que pueden ser medidos directamente, es decir aquellos defectos
descubiertos en las pruebas; y factores que pueden ser medidos únicamente de
manera indirecta, como por ejemplo el mantenimiento y la facilidad de uso.
McCall
y su equipo de trabajo plantearon una clasificación basada en tres aspectos
importantes de todo producto de software: operación, que incluye corrección,
confiabilidad, usabilidad, integridad y eficiencia; transición, compuesta por
portabilidad, reutilización y compatibilidad; y por último revisión de un producto,
donde se encuentran factores como facilidad de mantenimiento, flexibilidad y
facilidad de prueba. A continuación, se proporcionará una breve descripción de
cada factor previamente citado:
ü CORRECCIÓN:
está compuesto por dos aspectos; cumplimiento por parte del software de las
especificaciones técnicas, y satisfacción de objetivos del cliente.
ü CONFIABILIDAD:
Expectativa que un programa desempeñe la función para la cual está hecho.
ü USABILIDAD:
Esfuerzo necesario para aprender, operar y preparar los datos de entrada de un
programa e interpretar la salida.
ü INTEGRIDAD:
Grado de control sobre el acceso al software o la manipulación de los datos por
parte de personas no autorizadas.
ü EFICIENCIA:
Cantidad de recursos necesarios para que un programa realice su función.
ü PORTABILIDAD:
Esfuerzo necesario para transferir el programa de un entorno de hardware o
software a otro.
ü REUTILIZACIÓN:
Grado en que un programa o parte de él puede usarse en otras aplicaciones.
ü COMPATIBILIDAD:
Esfuerzo necesario para acoplar un sistema con otro.
ü FACILIDAD DE MANTENIMIENTO:
Esfuerzo necesario para localizar y corregir errores en un programa.
ü FLEXIBILIDAD:
Esfuerzo necesario para modificar un programa en operación.
ü FACILIDAD DE PRUEBA:
Esfuerzo que demanda un programa con el fin de asegurar que cumpla su función.
ü Se
puede observar que muchos de los factores previamente mencionados se convierten
en grupo de factores cuantitativos y por tanto, desarrollar medidas que
permitan realizar una adecuada medición se convierte en una actividad
frustrante debido a la naturaleza subjetiva de la misma.
·
1.1.3 Aseguramiento de la calidad del software
Se
puede definir el aseguramiento de la
calidad del software como "las actividades sistemáticas que proveen
evidencia del uso apropiado de la capacidad total del software"4. En otras
palabras, el aseguramiento de la calidad del software es una colección de
actividades y funciones usadas para monitorear y controlar un proyecto de
software desde su concepción hasta la salida en vivo, con el fin de que los objetivos
específicos se cumplan con un nivel deseado de confianza.
El
aseguramiento de la calidad es un esfuerzo planeado para asegurar que el
producto (software) cumpla con los criterios y los factores de calidad
mencionados en el numeral anterior. Estas actividades y funciones no solo son
responsabilidad del equipo asegurador de calidad, sino que incluyen también al
gerente/líder del proyecto, el personal del proyecto y los usuarios.
La
definición de aseguramiento plantea, que sí los procesos planteados dentro del
plan de calidad son seguidos de acuerdo
a los lineamientos pactados, asegurarán la gestión de la calidad del producto.
Los objetivos de la calidad del
software se logran siguiendo el plan de aseguramiento de calidad de software,
el cual establece los métodos que el proyecto debe emplear para asegurar que
los documentos y/o productos generados y revisados en cada etapa, sean de alta
de calidad.
El
aseguramiento de la calidad del software es una estrategia adoptada por la
gestión del riesgo. Considerar la calidad de software dentro de la gestión del
riesgo es importante porque en muchas ocasiones la calidad tiene un alto costo
en los proyectos de software. A continuación, se mostrarán algunos ejemplos de
mala calidad en materia de software:
ü Fallas
frecuentes en la funcionalidad del software.
ü Consecuencias
secundarias de fallas en el software, como problemas
financieros.
ü Sistemas
no disponibles cuando se requiere.
ü Costosas
mejoras en el software.
ü Altos
costos en la detección y corrección de errores.
Parte
de los riesgos con respecto a la calidad están relacionados a los defectos del
producto. Un defecto es una falla o falta de cumplimiento con un determinando
requisito. Si dicho requisito está planteado de una forma incorrecta, generará
una mayor posibilidad de que ocurran riesgos, teniendo como resultado la
aparición de posibles defectos posteriores en la aplicación y productos poco
verificables. Algunas de las técnicas y estrategias de gestión de riesgos
incluyen Testing de software, revisiones técnicas, revisión de pares (peers) y
verificación de conformidad.
El
aseguramiento de la calidad de software posee tres componentes expuestos a continuación:
ü TESTING DE SOFTWARE:
Componente usado para verificar que los requisitos funcionales de una
aplicación se cumplan. El Testing de software tiene limitaciones en cuanto al
aseguramiento de la calidad se requiere, ya que una vez hecho el Testing, se
dejarán descubiertos posibles defectos que cuestionan la calidad del producto
evaluado, con poco o nada de tiempo para mitigar dicha falta de calidad.
ü CONTROL DE CALIDAD:
Compuesta por métodos y procesos usados para monitorear el trabajo y observar
si los requisitos son cumplidos. Se enfoca en la revisión y posterior
eliminación de defectos antes de la entrega del producto final. El control de
calidad debe ser responsabilidad de la unidad organizacional que está encargada
de generar el producto. En general el control de calidad consiste en una serie
de revisiones (incluida en el plan de aseguramiento de la calidad) realizadas a
un producto. Para el caso de los productos de software, el control de calidad
generalmente incluye revisión de las especificaciones, inspecciones de código y
documentación, y revisiones para los entregables. Usualmente las inspecciones
del producto y de la documentación son llevadas a cabo en cada etapa del ciclo
de vida de software, para demostrar que los ítems producidos cumplen con los
criterios especificados en el plan de aseguramiento de la calidad. Estos
criterios están determinados por las especificaciones de los requisitos, por la
documentación del diseño, y por los planes de prueba. Dependiendo del tamaño
del proyecto, el control de calidad puede estar cargo bien sea, del personal
del departamento de calidad de software del proyecto, en caso de que el
proyecto sea pequeño, o de una junta de control de configuración si el proyecto
es grande. Dicha junta debe incluir un representante por parte del usuario, un
miembro del departamento de calidad de software, y el líder del proyecto.
ü GESTIÓN DE LA CONFIGURACIÓN DEL
SOFTWARE: Tiene que ver con el seguimiento y control de
cambios de los elementos de software en un sistema. Controla la evolución de un
sistema software por medio del manejo de versiones de los componentes de
software y sus relaciones. El propósito de la gestión de la configuración del
software es el de identificar todos los componentes de software
interrelacionados y controlar su evolución a través de los diferentes ciclos de
vida. La gestión de la configuración del software es una disciplina que puede
ser aplicada a actividades como el desarrollo de software, el control de la
documentación, control de cambios y mantenimiento. Puede proveer un alto ahorro
de costos en la reutilización del software porque cada componente de software y
su relación con otros componentes de software ya han sido previamente
definidas. Cabe mencionar también que la gestión de la configuración del
software consta de actividades que aseguran que el diseño y el código estén
definidos previamente, y por tanto no se puedan cambiar sin antes hacer una
revisión del efecto de tal cambio. A continuación, se mencionarán los elementos
que hacen parte de la gestión de la configuración del software: Identificación
de componentes, control de versiones, construcción de la configuración, control
del cambio.
La ilustración 1 muestra que no solo es necesario
tener en cuenta los tres componentes del aseguramiento de la calidad antes
mencionados, sino también una serie de estándares, mejores prácticas,
convenciones, y especificaciones para de cierto modo asegurar la calidad en
cuanto a software se refiere.
Ilustración
1. Software Quality Assurance
Cuando
se habla de aseguramiento de calidad de software es de vital importancia tener
un plan que garantice que todos los procesos y/o procedimientos llevados a cabo
dentro del aseguramiento de la calidad se cumplan de una manera eficiente. El
plan de aseguramiento de la calidad de software (SQA, por sus siglas en inglés)
es un conjunto de medidas con la finalidad de asegurar ciertos niveles de
calidad dentro de las fases del desarrollo de software. El plan es usado como
base para comparar los niveles actuales de calidad durante el desarrollo con
los niveles planeados. Dicho plan sugiere un marco de trabajo y unos lineamientos
para el desarrollo de código entendible y de fácil mantenimiento. El plan de
SQA determinará si los procedimientos para asegurar la calidad del software
serán desarrollados dentro del equipo de desarrollo o estarán a cargo de
terceros. Para desarrollar e implementar un plan de aseguramiento de calidad de software (SQA), es necesario tener
en cuenta ciertos pasos mencionados a continuación:
ü DOCUMENTAR EL PLAN:
Todo plan debe estar documentado para su posterior aprobación y ejecución.
ü OBTENER APROBACIÓN DE LA GERENCIA
DEL PROYECTO: La participación de la gerencia del
proyecto es necesaria para poder implementar de manera exitosa un plan de SQA.
La gerencia del proyecto es responsable tanto de asegurar la calidad en un
proyecto de software, como de proveer los recursos necesarios para el
desarrollo del mismo.
ü OBTENER APROBACIÓN DEL EQUIPO DE
DESARROLLO: Los principales usuarios de un plan de SQA son los
miembros del equipo de desarrollo, por lo tanto, es de vital importancia su
aprobación y cooperación en el plan.
ü PLANEAR LA IMPLEMENTACIÓN DEL SQA:
El proceso de planear, formular y esbozar un plan de SQA requiere de personal y
acceso a recursos tecnológicos. La persona responsable de implementar el plan
de SQA debe tener acceso a estos recursos y adicionalmente, necesita aprobación
y soporte constante del gerente del proyecto para garantizar la disponibilidad
de los mismos. El gerente del proyecto debe considerar todos los riesgos que
puedan impedir que el proceso se lleva a cabo, como por ejemplo la
disponibilidad de personal o equipos. Es necesario también desarrollar un
cronograma que incluya revisiones y aprobaciones para el plan de SQA.
ü EJECUTAR EL PLAN DE SQA:
El actual proceso de ejecutar un plan de SQA involucra puntos de auditoría que
permiten monitorear dicho plan. La auditoría debe ser programada durante la
fase de implementación del software, para que así el plan de SQA no se vea
afectado por un mal monitoreo del proyecto de software. Las auditorias deben
darse periódicamente durante el desarrollo o en las etapas especificas del
proyecto.
1.2 ESTRATEGIAS DE PRUEBA DE SOFTWARE
Aclarar
el concepto de estrategia dentro del contexto de pruebas de software es
sumamente difícil ya que los autores usan el término "estrategia"
para exponer diferentes ideas todas ellas relacionadas con proyectos de prueba
de software. Para algunos5 la estrategia son las técnicas y metodologías que
deben aplicarse al momento de realizar las pruebas; otros como William Perry y
Roger Pressman, recurren a la palabra estrategia dentro de dos enfoques. El
primero se refiere a estrategia como el plan general que guía y permite el
seguimiento del proyecto de pruebas, e integra los métodos de diseño de casos
de pruebas en una serie bien planeada de pasos; y el segundo, estrategia como
las técnicas y metodologías que deben aplicarse en cada uno de los tipos de
pruebas que se consideran dentro de las etapas del plan general. Autores más
especializados en el tema como Rick D. Craig y Stefan P. Jaskiel, consideran el
concepto de estrategia mencionada por Pressman como una planeación maestra de
pruebas a lo que denominan "Master Test Planning".
A
pesar de las diferencias conceptuales con las que se refieren al termino
estrategia, los autores coinciden que antes de empezar a realizar cualquier
actividad relacionada con pruebas de software, debe existir un plan de pruebas
(De ahora en adelante plan) que soporte y considere todas las decisiones
administrativas que se toman a partir de las condiciones que rodean el
proyecto, como: riesgos, recursos (tanto humanos como materiales) y tiempo,
para lograr el buen desarrollo del mismo. Además de lo anterior, el plan debe
tener objetivos medibles y alcanzables que conlleven al desarrollo de software
de calidad.
El
nivel de detalle a alcanzar por el plan debe permitir al desarrollador basar su
trabajo diario de acuerdo a lo estipulado en el mismo y sobre todo, servir de
guía para que el gerente realice control sobre el proyecto.
·
1.2.1 Estrategias de pruebas: enfoque de R.
Pressman
Pressman,
como se mencionó anteriormente, describe la estrategia general de software
"como un aspecto que reúne todos los métodos de diseño de caso de prueba
en una serie bien planteada de pasos; proporcionando un mapa que describe los
pasos que se darán como parte de la prueba e indica cuándo se planean y cuándo
se dan estos pasos, además de cuánto esfuerzo, tiempo y recursos consumirán.
Por lo tanto, cualquier estrategia de prueba debe incorporar la planeación de
pruebas, el diseño de casos de pruebas, la ejecución de pruebas y la evaluación
de los datos resultantes." Al mismo tiempo el autor menciona cuatro
estrategias por cada una de las etapas en las que divide las pruebas de
software, asegurando también, que por cada proyecto de desarrollo de software
debe existir una estrategia de pruebas diferente manteniendo una estructura
básica general, ya que cada proyecto tiene tanto necesidades particulares como
generales (Estrategia). De esta forma se asegura que la gestión administrativa
del proyecto pueda ser llevada a cabo con facilidad.
En
la actualidad existen tantas estrategias de pruebas de software como enfoques
de desarrollo, pero como se mencionó anteriormente, todas ellas mantienen en
común unas características
generales. A continuación, se nombran las características que se encuentran
frecuentemente en las plantillas de pruebas.
Ø Para
realizar testing efectivo el equipo desarrollador de software debe realizar
revisiones técnicas formales (RTF) con el fin de eliminar errores antes del
inicio de la etapa de pruebas.
Ø El
testing empieza en un nivel bajo (de componentes) y trabaja "hacia
afuera" con el fin de integrar todo el sistema. De lo menos hacia lo más.
Toda estrategia de pruebas de software debe incluir pruebas de bajo nivel,
necesarias para verificar que pequeños segmentos de código estén correctamente
implementados (unidades lógicas), como también debe incluir pruebas de alto
nivel que validen la funcionalidad general del sistema.
Ø Se
deben aplicar diferentes técnicas de prueba en diferentes puntos del testing.
Ø Las
pruebas son dirigidas por el grupo desarrollador del software, y en caso de que
sea un gran proyecto, dichas pruebas son desarrolladas por un grupo de pruebas
independiente (GPI).
Ø El
testing y la depuración son actividades diferentes, pero la depuración debe
ocupar un lugar dentro de cualquier estrategia de prueba de software. El punto
de vista de R. Pressman respecto a cómo deben realizarse las pruebas es
bastante interesante en la medida que sugiere como el mejor método, el realizar
pruebas constantemente desde el momento de codificación del software hasta las
pruebas del sistema, repitiendo el proceso por cada cambio realizado al código
a partir de un error localizado por el equipo en pruebas anteriores.
Si se considera
el proceso de prueba de software desde un punto de vista procedimental, las
pruebas consisten en una serie de pasos que se implementan de manera
secuencial. Estos pasos empiezan desde la prueba de unidad, asegurando que
funciona de manera apropiada como unidad; continúan con prueba de integración,
que se realizan cuando se integran los paquetes y que considera problemas como
doble verificación y construcción del programa; prueba de validación, primera
prueba de alto nivel y se realiza cuando se ha integrado y probado el programa,
en ella se debe evaluar los criterios de validación establecidos en la etapa de
análisis de requisitos incluyendo requisitos funcionales, de comportamiento y
de desempeño; y por último se realiza la prueba de sistema, la cual queda por
fuera de todos los límites del ingeniero de software, ya que cuando el producto
está listo debe combinarse con otros elementos del sistema como hardware,
personas, bases de datos, etc. En esta prueba se verifica que todos los
elementos encajen apropiadamente y que se logre la función y el desempeño
generales del sistema.
Las
cuatro etapas mencionadas anteriormente son descritas para lo que el Autor
denomina "software convencional", manifestando que se pueden realizar
estas mismas pruebas en arquitecturas orientadas a objetos considerando como
unidad a las clases.
Muchas
organizaciones desarrolladoras de software pueden aplicar diferentes
estrategias para probar sus productos. En un extremo, el equipo desarrollador
podría esperar a que el sistema esté terminado para realizar las pruebas y
esperar encontrar los errores que no se encontraron o no se preocuparon por
encontrar durante todo el proceso de desarrollo. Este enfoque puede resultar
muy atractivo para el equipo de pruebas, pero según la experiencia de Pressman
no funciona. El resultado de realizar pruebas basadas en este enfoque es un
software lleno de errores y que seguramente generará en el cliente y el usuario
final una experiencia molesta. En el otro extremo, el ingeniero de software
puede optar por el enfoque, mencionado anteriormente, realizando pruebas
diariamente sin importar que parte del programa se haya desarrollado. El
enfoque, aunque asegurará una aplicación de calidad, no es muy atractivo por el
tiempo y recursos que consume. Resultado que puede obtenerse siguiendo lo
descrito en la estrategia general de manera puntual y aplicando una estrategia
(método) de prueba adecuada para cada una de las etapas sugeridas.
Para
Tom Gilb, citado por Pressman en su libro, las cuatro etapas de toda estrategia
de pruebas deben tener unas directrices o que llevan a que la estrategia de
prueba de software tenga éxito. Dichas directrices fueron publicadas en el
articulo "What we fail to do in our current testing culture", y
continuación serán expuestas:
Ø Especificar
los requerimientos del software de manera cuantificable, previa a la ejecución
de las pruebas. Aunque el objetivo primordial de la prueba es encontrar
errores, una buena estrategia de prueba también evalúa otras características de
la calidad, como las opciones de llevarla a otra plataforma, además de la
facilidad de mantenimiento y uso. Esto debe especificarse de manera tal que
permita medirlo para que los resultados de la prueba no resulten ambiguos.
Ø Establecer
explícitamente los objetivos de la prueba. Los objetivos específicos de la
prueba se deben establecer en términos cuantificables. Por ejemplo, dentro del
plan de prueba deben establecerse la efectividad y la cobertura de la prueba,
el tiempo medio de falla, el costo de encontrar y corregir defectos, la
densidad o la frecuencia de las fallas restantes, y las horas de trabajo por
prueba de regresión.
Ø Entender
las necesidades del usuario del software, y crear un perfil por cada categoría
de usuarios. Los casos de uso que describan el escenario de interacción para
cada clase de usuario reducen el esfuerzo general de prueba, ya que concentran
la prueba en la utilización real del producto.
Ø Desarrollar
un plan de pruebas enfocado en "ciclos rápidos de pruebas". Se recomienda
que un equipo de ingeniería de software "aprenda a probar en ciclos
rápidos (2% del esfuerzo del proyecto) los incrementos en el mejoramiento de la
funcionalidad, la calidad, o ambas, de manera que sean útiles para el cliente y
se puedan probar en el campo". La retroalimentación que generan estas
pruebas de ciclo rápido se utilizan para controlar los grados de calidad y las
correspondientes estrategias de prueba.
Ø Construir
software "robusto" diseñado para probarse a sí mismo. El software
debe diseñarse de manera tal que use técnicas anti error. Es decir, el software
debe tener la capacidad de diagnosticar ciertas clases de errores. Además, el
diseño debe incluir pruebas autorizadas y de regresión.
Ø Utilizar
las revisiones técnicas formales como filtro antes de comenzar las pruebas. Las
revisiones técnicas formales posibilitan descubrir inconsistencias, omisiones y
errores evidentes en el enfoque de la prueba. Esto ahorra tiempo y también mejora
la calidad del producto.
Ø Desarrollar
un enfoque de mejora continua para el proceso de prueba. Es necesario medir la
estrategia de prueba. Las medidas reunidas durante la prueba deben usarse como
parte de un enfoque estadístico de control del proceso para la prueba de
software.
Ø Siguiendo
el orden de ejecución de un proyecto y con todas las estrategias propuestas
para concluir de forma eficaz un proyecto de pruebas de software, Pressman toca
un punto muy importante relacionado con esto último. Comúnmente se da por
sentado que las pruebas tienen
una duración o terminación conocida pero es común que surjan muchas
dificultades a la hora de conocer realmente cuando se deben dar por terminadas
las pruebas. Existen varias aproximaciones que tratan de resolver dicha
problemática. Una de ellas sugiere que en realidad las pruebas nunca terminan,
sino más bien se transfiere la responsabilidad de hacerlas, ya que una vez
terminado el producto el encargado de seguir haciendo las pruebas es el
usuario. Otra de las aproximaciones propuestas, pero muy poco aceptada, dice
que las pruebas acaban cuando se agota el tiempo y/o el dinero. En general, uno
de los criterios más utilizados para determinar cuándo acabar las pruebas es la
experiencia adquirida en proyectos anteriores. Son también de gran ayuda
modelos estadísticos que recopilan ciertas métricas de software.
·
1.2.2 Estrategias de pruebas: Enfoque de Rick
Craig y Stefan Jaskiel
Craig
y Jaskiel, autores del libro "Systematic Software Testing", aseguran
que una de las claves para alcanzar el éxito en las pruebas de software es la
planeación de pruebas de software. Es común que en la mayoría de los proyectos
informáticos no se dé la debida importancia a la planeación debido a la falta
de tiempo, recursos, entrenamiento o vías culturales generando productos que en
gran medida no cumplen las expectativas de los clientes. Las pruebas de
software no son ajenas a error y de ahí la necesidad de crear un plan que
determine los lineamientos para un buen desarrollo de pruebas.
1.2.2.1 Niveles de planeación de pruebas.
Según
el estándar 829-1998 propuesto por la IEEE para la documentación de pruebas de
software existen 4 niveles: pruebas de unidad, pruebas de integración, pruebas
de sistema, y pruebas de aceptación (o validación). Para cada uno de estos
niveles debe existir un plan correspondiente, definido de acuerdo al nivel de
complejidad y la duración del proyecto. Se debe considerar entonces un plan
maestro de pruebas (MTP por sus siglas en ingles) que orqueste las pruebas en
todos los niveles.
Adicionalmente
al MTP, es común que sea necesario crear planes de pruebas detallados. En un
proyecto largo y complejo, a menudo vale la pena crear un plan de pruebas de
aceptación, sistema, integración, de unidad, y muchos otros planes, dependiendo
del alcance del proyecto en cuestión. Proyectos pequeños, es decir, proyectos
con alcances cortos, menos número de participantes, y organizaciones de menor
tamaño, puede que solo necesiten un solo plan para abarcar todos los niveles de
las pruebas. Decidir el número y alcance de los planes de prueba debe ser la
primera estrategia de decisión desarrollada dentro del plan de pruebas.
Mientras la complejidad del proceso de pruebas se incrementa, se incrementa
exponencialmente la necesidad de tener un buen MTP.
El
ingeniero encargado del plan de pruebas debe ver el MTP como su máximo canal de
comunicación con todos los participantes del proyecto. El proceso de prueba
tiene como objetivo generar un documento que permita a todas las partes
involucradas en las pruebas a decidir proactivamente cuales son los aspectos
que se presentan en cualquier proyecto de testing como: la utilización de los
recursos, responsabilidades, roles, riesgos y prioridades. Al comparar este
enfoque con el enfoque de Pressman, se puede
observar que ambos usan el MTP o la estrategia, según sea el caso, como guía para
los miembros del equipo y posibilitarles herramientas que faciliten terminar el
proyecto de prueba. Dos aspectos importantes a tener en cuenta a la hora de
diseñar un plan de pruebas son:
Ø La
planeación de pruebas debe ser un complemento de la planeación general del
proyecto, ya que lo que se defina en el plan de pruebas debe estar reflejado en
el plan general del proyecto.
Ø La
planeación de pruebas debe ir separada del diseño de pruebas.
1.2.2.2 Tiempos de actividad.
Ø La
planeación de prueba debe empezar tan pronto como sea posible. Generalmente es
deseable empezar el MTP casi en el mismo tiempo que se desarrolla el plan del
proyecto y la especificación de requisitos.
Si la planeación se empieza tempranamente,
puede y debe afectar significativamente
el impacto del contenido del plan del proyecto. El plan de pruebas de
aceptación puede empezar tan pronto como el proceso de definición de requisitos
ha empezado. Igualmente, las pruebas de sistema, integración y unidad deben
empezar tan pronto como sea posible.
Ø
En la siguiente figura se muestran los tiempos
aconsejados para iniciar los planes de cada etapa.
Ilustración 2. Tiempos de planeación de
pruebas
1.2.2.3 Componentes del plan.
A
pesar que la IEEE propone un formato que contiene varios aspectos que deben
tenerse en cuenta al momento del desarrollo del plan de pruebas no es una
exigencia considerarlos todos siempre que se realice un plan de prueba, es
decir, la propuesta es flexible y puede ser modificada agregando o eliminando
secciones dentro del mismo. A continuación, se mencionaran cada uno de los
componentes propuestos por la IEEE, incluyendo además algunas secciones
propuestas por Craig y Jaskiel (identificadas con un asterisco) que pueden ser
usadas al momento de crear cualquier clase de plan, ya sea el plan maestro,
aceptación, sistema, integración, unidad o cómo haya nombrado los niveles del
plan prueba dentro del proyecto.
v IDENTIFICADOR DEL PLAN.
El objetivo del identificador del plan es brindar la posibilidad de seguimiento
de las versiones del plan de prueba. Es por eso que a cada una de las versiones
debe asignárseles un número de identificación. Cuando la organización que
desarrolle el proyecto tenga algún estándar para control de documentación, debe
implementarlo para las versiones del plan. El identificador del plan es un
número único generado por la organización que gestiona el proyecto y este se
usa, como se mencionó antes para identificar la versión del plan, el nivel, y
la versión de software a la que pertenece dicho plan. No puede olvidarse que el
plan de pruebas es como cualquier otra documentación de desarrollo de software,
es dinámico y por lo tanto debe mantenerse actualizado.
vTABLA DE CONTENIDOS*.
Debe incluir todos los temas que se trabajen en el plan, así como también
referencias, glosarios, y apéndices. Si es posible, es aconsejable desarrollar
la tabla de contenidos hasta dos o más niveles de profundidad para que el
lector pueda ver en detalle el contenido del plan.
vREFERENCIAS.
Según el estándar 829-1998 de la IEEE para la documentación de pruebas, las
referencias están incluidas dentro de la Introducción, pero Craig y Jaskiel
consideran que debe ser dividido cada ítem en una sección para hacer énfasis en
su importancia, los ítems son: Autorización del proyecto, plan del proyecto,
plan de aseguramiento de calidad, plan del manejo de la configuración,
políticas relevantes y estándares relevantes. La IEEE también sugiere que, para
planes multinivel, cada nivel inferior debe referenciar al siguiente nivel superior.
v
GLOSARIO. El glosario es usado para
definir algunas de las palabras y términos utilizados en el documento del plan.
Es conveniente que cuando se realice el glosario se tenga en cuenta el público
que recibirá el documento, recuerde que pueden existir diferentes perfiles de
personas dentro de proyecto y que cada uno tiene conocimientos técnicos
diferentes.
v INTRODUCCIÓN.
Según la plantilla sugerida por la IEEE la introducción está compuesta por dos
componentes principales: una descripción del alcance del proyecto, que incluye
las características, historia, entre otros.; y una introducción que describa el
alcance del plan.
v
ÍTEMS A PROBAR. La sección describe
de una manera secuencial, que elementos se van a "testear" de acuerdo
al alcance del proyecto y debe realizarse con la colaboración del gerente y el
equipo de desarrollo. Este componente del plan puede variar entre niveles; para
niveles superiores los ítems se deben organizar por versiones o aplicaciones,
mientras que para los niveles inferiores dichos ítems se pueden organizar en
módulos, unidades o programas. Los ítems o elementos que vayan a ser excluidos
de las pruebas deben ser especificados en esta sección.
v
RIESGOS. Craig y Jaskiel sugieren
que el propósito de incluir los riesgos de software dentro de un plan de
software es el de determinar el enfoque que deben tener las pruebas. Explican
qué determinar los riesgos de software
ayuda a los ingenieros a establecer una prioridad entre las pruebas y a
concentrarse en aquellas áreas donde puede presentarse mayor riesgo a fallas o
que tengan alto impacto para el cliente en caso de fallas. Algunos de los
riesgos más comunes pueden ser: Interfaces con otros sistemas, alta complejidad
del software, módulos que históricamente han presentado fallas o con muchos
cambios, aspectos relacionados con la seguridad, desempeño, fiabilidad.
Para determinar las
áreas que sean propensas a falla dentro del proyecto en el que está trabajando
es aconsejable realizar una lluvia de ideas, preguntando a los miembros del
equipo "¿Qué los preocupa?", sin usar la palabra riesgo dentro de la
pregunta, ya que por experiencia de los Craig y Jaskie dicha palabra puede
intimidar a los participantes.
v CARACTERÍSTICAS A PROBAR.
A diferencia de la sección "ítems a probar", donde se tienen en
cuenta los ítems que se deben probar desde el punto de vista del equipo
desarrollador, esta sección del plan contiene una lista de los elementos que
serán probados desde la vista del usuario o el cliente. Por cada característica
mencionada dentro de la lista debe haber una columna por cada uno de los
siguientes aspectos: tipo de requisito al que pertenece el ítem, frecuencia de
ocurrencia, impacto y prioridad. Para definir la escala por cada característica
de la lista, pueden usar las concepciones definidas, para el proyecto en
general, respecto a los riesgos.
v CARACTERÍSTICAS NO PROBADAS.
En esta sección del plan debe enunciar todas las características o elementos
que no serán tenidos en cuenta dentro de las pruebas, explicando el motivo para
descartarlas dentro del plan. Existen varias razones por las cuales no se
prueba una característica. Puede que la característica no haya cambiado, no
esté disponible para el uso, etc. Pero por la razón que sea la característica
debe aparecer en esta lista,
generalmente la razón principal es un riesgo bajo dentro del proyecto.
v ESTRATEGIA.
La estrategia es considerada por Jaskiel y Craig, el corazón del plan de
pruebas. Esta sección contiene una descripción detallada de cómo serán
desarrolladas las pruebas y también una explicación de los temas que tengan un
alto impacto tanto para las pruebas, como para el proyecto en general. La
estrategia incluye una serie de secciones o componentes explicados en detalles
en el siguiente numeral.
v CRITERIO DE ACEPTACIÓN/RECHAZO DE
LOS ÍTEMS. Esta sección describe los criterios de aceptación
y rechazo sobre los ítems expuestos en la sección "Ítems a probar".
Generalmente dichos criterios se aplican a los casos de pruebas y están
expresados por: número, tipo, severidad y ubicación del error, usabilidad,
fiabilidad y/o estabilidad. Dependiendo del nivel, y del proyecto, los
criterios de aceptación/rechazo pueden variar. Algunos ejemplos de criterios
incluyen: porcentaje de casos de pruebas aprobados, cantidad, severidad y
distribución de defectos, alcance de los casos de pruebas.
v CRITERIOS DE SUSPENSIÓN Y
REQUISITOS DE REANUDACIÓN. En esta sección se identifican
las condiciones que obligan una suspensión temporal de las pruebas y los
criterios de reanudación de las pruebas. Los criterios de suspensión pueden
incluir: tareas incompletas en la ruta crítica del proyecto, muchos errores
encontrados, errores críticos. Ambientes de pruebas incompletos, faltas de
recursos.
v ENTREGABLES DE PRUEBAS.
En esta sección se define una lista de entregables que incluye documentos,
herramientas y otros componentes a desarrollarse y mantenerse bajo los
esfuerzos de las pruebas. Ejemplos de entregables de pruebas pueden ser: plan
de pruebas, especificaciones de diseño, casos de pruebas, procedimientos, lo es,
reporte de incidentes, resumen, entre otras. Es importante aclarar que no es
válido incluir dentro de la lista de entregables el software que está siendo
puesto a prueba. Los elementos que hayan servido de soporte para las pruebas
deben ser identificados en el plan general del proyecto como entregables y
deben tener una asignación adecuada de recursos en el sistema de seguimiento
del proyecto. Esto garantizará que el proceso de pruebas tenga una visibilidad
importante dentro del proceso de seguimiento del proyecto y que las tareas
resultantes de las pruebas para generar los entregables sean iniciadas a
tiempo. Las dependencias entre los entregables de las pruebas y las entregables
del producto de software deben ser plasmadas en un diagrama de Gantt (se
exponen en la sección "Cronograma").
v TAREAS.
Definida por la IEEE para identificar el conjunto de tareas necesarias para
llevar a cabo las pruebas. También se listan todas las dependencias entre
tareas y cualquier habilidad especial requerida.
v NECESIDAD DEL ENTORNO.
Las necesidades del entorno incluyen, hardware, software, datos, lugares
apropiados, accesos, y otros requisitos que permitan el normal desarrollo de
las pruebas. Se debe entonces crear un entorno lo más cercano a la realidad del
sistema que va a ser sometido a pruebas. En caso de que el sistema este
diseñado para ser ejecutado con múltiples configuraciones (bien sea de hardware
o de software), se debe decidir si bien se replican todos los escenarios los
mas riesgosos o las más comunes. Una vez se hayan determinado los escenarios se
deben listar, tantos las configuraciones de hardware como las de software.
Adicional a esto es necesario identificar de donde vendrán los datos para
generar una base de datos referentes a las pruebas. Dicha base de datos puede
contener: datos de producción, de compra y los suministrados por el usuario.
v RESPONSABILIDADES.
Craig y Jeskiel formularon una matriz que muestra como está distribuida las
responsabilidades de las diferentes actividades que requieren las pruebas
frente a los diferentes miembros del equipo encargado de realizar el Testing.
La matriz contiene responsables, y tareas o actividades a realizar. Los
responsables se pueden categorizar en: Director de desarrollo, director de
pruebas, ejecutores de pruebas, coordinador del entorno de pruebas y director
de librerías. Y algunos ejemplos de tareas a realizar pueden incluir: coordinar
el desarrollo del MTP (plan general de pruebas), desarrollar el plan para la
prueba de sistema, de unidad e integración, mantener el entorno de pruebas,
entre otros.
v NECESIDADES DE PERSONAL Y
ENTRENAMIENTO. Dependiendo del alcance, los objetivos
y otros factores influyentes en el proyecto, se determina la cantidad de
personas y las cualidades necesarias que deben tener para llevar a cabo el
Testing. Algunos ejemplos de capacitaciones pueden incluir: usos de cierta
herramienta en particular, metodologías de pruebas, interfaces, entre otras.
Las capacitaciones pueden variar de acuerdo al proyecto.
v CRONOGRAMA.
El cronograma de pruebas debe ser generado a partir de las fases existentes en
el plan del proyecto como las fechas de entrega de varios documentos y módulos,
la disponibilidad de recursos, interfaces, etc. Después añadir las fases de las
pruebas. Estas fases serán diferentes para cada nivel de planificación
existente dependiendo del nivel del plan de pruebas creado. En un MTP, las
fases se construirán alrededor de los eventos importantes, como las revisiones
de requerimientos y diseño, entrega de código, terminación del manual de
usuario y disponibilidad de interfaces. Inicialmente es de mucha ayuda
construir un cronograma genérico sin fechas; esto es, identificar el tiempo
requerido para las tareas, las dependencias, etc. Todo esto sin especificar
tiempos de inicio o entrega. Normalmente este cronograma debe ser una grafica
de un diagrama de Gantt en orden de mostrar las dependencias entre tareas.
v RIESGOS DE PLANEACIÓN.
Jaskiel y Craig argumentan que cualquier actividad que suponga en un obstáculo
para el cronograma de las pruebas se considera un riesgo de planeación. Dentro
de los riesgos de planeación más comunes se encuentran: fechas de entregas
imposibles de cumplir, disponibilidad del personal, presupuesto, insuficiencia
de inventario de herramientas, alcance de las pruebas mal propuesto, entre
otras. Por otra parte esta sección debe mencionar las contingencias que se
deben tener en cuenta para mitigar los riesgos antes mencionados. Algunas de
dichas contingencias pueden ser: reducción del alcance de la aplicación,
retrasar la implementación, añadir recursos adicionales, reducir procesos de
calidad.
v APROBACIONES.
Las aprobaciones deben ser firmadas o aceptadas por miembros del equipo de
pruebas que estén en capacidad de determinar si el software está listo para
avanzar hacia el siguiente paso. Para cada uno de los niveles de pruebas,
existirán aprobaciones que estarán a cargo de los directores de dichos niveles,
por ejemplo, para el plan de prueba de unidad la persona que autoriza debe ser
el gerente de desarrollo. Las personas que firman deben incluir la fecha en el
que realizan la aprobación para que exista un registro dentro del proyecto.
1.2.2.4 Componentes de la estrategia
v SELECCIÓN DE METODOLOGÍAS.
Para definir la metodología a utilizar en una estrategia de pruebas es
necesario tener en cuenta una serie consideraciones básicas como: el número de
miembros del equipo de pruebas designados para la planeación el diseño y las
pruebas, el inicio de las pruebas, la utilización de pruebas piloto, las técnicas
y niveles de pruebas (Unidad, Integración, Aceptación o de Sistema) a utilizar,
entre otras. Por ejemplo, para la selección de los niveles de pruebas que se
van a aplicar en un determinado proyecto se deben tener en cuenta factores que
influyen en la decisión como lo son las políticas, los riesgos, la complejidad
del sistema, los recursos y el tiempo disponible entre otros.
v RECURSOS.
Se necesita tener una estrategia solida frente al manejo de los recursos, sobre
todo humanos, ya que estos son escasos y son la clave del éxito en cualquier
tipo de proyectos incluyendo proyectos de software.
En casos donde no se
tenga un equipo de pruebas o se tenga uno pero con poco personal o dedicados a
otras actividades diferentes a las de pruebas, se deberá acudir a la
contratación de personal adicional lo cual retrasaría todo el proceso debido a
la curva de aprendizaje. También incrementaría costos. Por otro lado, se puede
conformar un equipo de pruebas desde el inicio del proyecto, pero aumentaría
costos al tener sin hacer nada a consultores que por lo general devengan un
buen salario. Por lo cual se hace necesario encontrar un equilibrio entre los
dos puntos.
v DETERMINACIÓN DEL ALCANCE.
Actualmente existen diferentes medidas para el alcance de las pruebas, entre las
cuales se encuentran las coberturas de requisitos, diseño e interfaces. Pero
una de las más conocidas y usadas, la cobertura de código, se encarga de medir
el Porcentaje de condiciones, ramificaciones o rutas de código ejecutadas por
un grupo específico de casos de pruebas. Para determinar que partes del código
fuente han sido ejecutadas es necesaria la ayuda de herramientas especializadas
que faciliten dicha labor. Otra de las medidas utilizadas para el
reconocimiento del alcance en las pruebas, el cubrimiento de los requisitos,
mide el porcentaje de los requisitos de negocio cubiertos por los casos de
prueba. De forma similar se mide el cubrimiento de la interface al considerar
las interfaces que están siendo intervenidas por las pruebas. Y en lo concerniente
a la medición del alcance que puedan tener las pruebas en el diseño, se
determina que partes del mismo son cubiertas por las pruebas.
v RECORRIDOS E INSPECCIONES.
Las revisiones, junto con el Testing y el análisis, hacen parte del proceso de
evaluación del software (ver Ilustración 2). En las revisiones se encuentran
técnicas de verificación, como revisiones formales de código, requisitos y
diseño, que no hacen parte de actividades de Testing como tal, pero afectan de
manera significativa la estrategia, por lo que se deben considerar en el plan
general de pruebas (MTP). Dos de los tipos de revisiones más comunes se
encuentran los recorridos y las inspecciones. Un recorrido, hablando en
términos de pruebas de software, se conoce como la revisión de pares a un
producto de software en específico, que consiste en recorrer de manera
secuencial el software para determinar la calidad que posee el producto y
descubrir posibles defectos. Y en el caso de las inspecciones, tienen la misma
razón de ser de los recorridos, pero son pruebas mucho más rigurosas y emplean
procesos de control estadístico con el fin de medir la efectividad de la
inspección e identificar oportunidades de mejoramiento en el proceso de
desarrollo de software. La IEEE define la inspección como "la técnica de
evaluación formal de software, en la cual los requisitos, el diseño o el código
son examinados en detalle por una persona o un grupo, diferente al autor, con
el objetivo de detectar fallas, violaciones de estándares de desarrollo y otros
problemas". Según Craig y Jaskiel, la inspección se rige por las siguientes
observaciones a continuación Mencionadas: Verificar que los
elementos del software satisfagan las especificaciones, verificar que los
elementos del software se ajustan a los estándares aplicables, identificar las
desviaciones de los estándares y especificaciones anteriormente mencionados,
recolectar datos provenientes de la ingeniería de software (como por ejemplo
datos de
defectos
o esfuerzos), y por ultimo no examinar aspectos alternativos o estilísticos.
Ilustración
3. Proceso evaluación de software
Dentro
de las diferencias entre recorrido e inspección, planteadas por Craig y
Jaskiel, se puede citar la informalidad del recorrido frente a la formalidad de
la inspección, resaltando los propósitos de cada una de ellas, siendo el de la
primera muy subjetivo dependiendo de la persona encargada, mientras que en la
segunda se utilizan técnicas de medición para la mejora de determinados
procesos. Debido a que tanto el proceso
de recorrido como el de inspección requieren tanto de esfuerzo humano como de
muchos recursos para llevarse a cabo, es que existe la necesidad de priorizar
la inspección y recorrido de ciertos elementos, ya que resultaría casi
imposible evaluar todos los componentes de un producto de software. Por otro
lado, se debe tener en cuenta el tipo de personal que se necesitará para
realizar bien sea la inspección o los recorridos. Para realizar dichas
actividades, es ideal tener personal de prueba que esté involucrado con las
pruebas del nivel de sistema y tengan habilidades en la revisión de código.
v GESTIÓN DE LA CONFIGURACIÓN.
En esta sección de la estrategia incluida en el plan general de pruebas (MTP),
es necesario considerar el manejo que se le dará a la gestión de la
configuración dentro del marco de las pruebas. Dicha gestión de la
configuración incluirá la gestión de cambios, de vital importancia para el
proyecto en general, llevando a cabo un control de versiones del software y sus
respectivas documentaciones que vayan siendo "testeadas", así como
también para un generar un proceso que permita tomar decisiones útiles para la
priorización de errores. De los niveles de pruebas expuestos en el numeral
anterior, Craig y Jaskiel sugieren utilizar el nivel de aceptación para validar
el proceso de la gestión de la configuración.
v RECOLECCIÓN Y VALIDACIÓN DE
MÉTRICAS. Es necesario discutir e incluir las métricas a
utilizar en el proyecto dentro de la estrategia del plan general de pruebas,
debido a que todo esfuerzo en cuanto a pruebas de software se refiere, debe
medirse en términos de efectividad, calidad, cumplimiento al cronograma, entre
otros.
vHERRAMIENTAS Y AUTOMATIZACIÓN.
Otra de las consideraciones a tener en cuenta en la estrategia es el uso de
herramientas de automatización útiles para el buen desarrollo del proyecto. Es
necesario entonces generar un buen plan sobre el empleo de dichas herramientas,
que incluya las respectivas capacitaciones de estas hacia los miembros del
equipo. Cambios al plan de pruebas. En
esta sección se debe abordar el manejo de cambios en el plan general de
pruebas, así como también en los planes de los niveles existentes, debido a los
constantes cambios que se presentan a lo largo del proyecto. Por eso es
necesario que el encargado de coordinar la estrategia de prueba tenga en cuenta
las siguientes consideraciones: determinar qué cambios deberán ir al proceso de
aprobación nuevamente (por más pequeño que sean), precisar la frecuencia de
actualización del plan de pruebas, determinar si el plan debe pasar por el
proceso de gestión de configuración, como publicar el plan, entre otras
consideraciones.
vREUNIONES Y COMUNICACIONES.
Resulta conveniente incluir dentro del plan general de pruebas (MTP) los
reportes, comunicaciones y reuniones que se llevaran a cabo durante la duración
del proyecto. Debe existir entonces unos métodos preestablecidos de
comunicación como reuniones y reportes acerca del estatus de las pruebas, mesa
de control de cambios, presentación a usuarios y/o gerentes, entre otros
métodos.
v OTRAS CONSIDERACIONES SOBRE LA
ESTRATEGIA. Durante la ejecución del proyecto pueden ocurrir
una serie de consideraciones acerca de la estrategia no incluidas en el plan
general de pruebas. A continuación, mencionaran dichas consideraciones:
múltiples entornos de producción, seguridad multinivel, beta Testing,
mantenimiento y configuración de entornos de prueba, uso del soporte
contractual, calidad de software desconocidas, entre otras más.
