CAPITULO 5:

ASEGURAMIENTO DE
LA CALIDAD
5.7 ASEGURAMIENTO DE CALIDAD EN EL DESARROLLO DEL
SOFTWARE
5.7.1 PRINCIPIOS FUNDAMENTALES EN LAS PRUEBAS
5.7.2 TIPOS DE PRUEBAS
5.7.2 TIPOS DE PRUEBAS
5.7.4 HERRAMIENTAS AUTOMÁTICAS PARA EL PROCESO DE PRUEBAS
2 5.7 ASEGURAMIENTO DE CALIDAD EN EL
DESARROLLO DEL SOFTWARE
• El Aseguramiento de Calidad es un proyecto dentro de un proyecto informático y no debe ser
considerado como una etapa más dentro del Ciclo de Vida del Software, actualmente los
proyectos informáticos llevan a cabo el proceso de pruebas en las etapas finales antes de
implantar el software en el ambiente de producción, sin embargo si se considera este proceso
como transversal no se generarían defectos con altos costos en tiempo y dinero, ya que se
debe afrontar desde etapas tempranas como las de análisis y diseño, debido a que si no se realizan
pruebas de especificaciones o requerimientos los defectos o bugs van a ser altamente
costosos en etapas finales del software, por lo tanto el proceso de pruebas ahí que asumirlo con
responsabilidad y no a la ligera como lo hacen la gran mayoría de las compañías de desarrollo de
software a la medida.
• Según la Norma ISO 9000:2000, el aseguramiento de la calidad es la parte de la gestión de la
calidad orientada a proporcionar confianza en que se cumplirán los requisitos de calidad.
3 5.7 ASEGURAMIENTO DE CALIDAD EN EL
DESARROLLO DEL SOFTWARE
El Aseguramiento de Calidad del Software es el conjunto de actividades planificadas y sistemáticas
necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Este
aseguramiento se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El
aseguramiento de la calidad del software engloba:
1. Un enfoque de gestión de calidad,
2. métodos y herramientas de Ingeniería del Software,
3. revisiones técnicas formales aplicables en el proceso de software,
4. una estrategia de prueba multiescala,
5. el control de la documentación del software y de los cambios realizados,
6. procedimientos para ajustarse a los estándares de desarrollo del software y
7. mecanismos de medición y de generación de informes.
4 5.7 ASEGURAMIENTO DE CALIDAD EN EL
DESARROLLO DEL SOFTWARE
• Las revisiones del software son un "filtro" para el proceso de Ingeniería del Software. Esto es, las
revisiones se aplican a varios momentos del desarrollo del software y sirven para detectar errores y
defectos que pueden ser eliminados. Las revisiones del software sirven para "purificar" las actividades de
la Ingeniería del Software que suceden como resultado del análisis, diseño y codificación.
• La revisión técnica formal (RTF), a veces llamada inspección, es el filtro más efectivo desde el punto de
vista del aseguramiento de la calidad y es un medio efectivo para mejorar la calidad del software.
• El defecto se define como una anomalía del producto. Dentro del contexto del proceso del software, los
términos defecto y fallo son sinónimos. Ambos implican un problema de calidad que es descubierto
después de entregar el software a los usuarios finales.
• El objetivo principal de las RTF es encontrar errores durante el proceso, de forma que se conviertan en
defectos después de la entrega del software. El beneficio de estas RTF es el descubrimiento de errores al
principio para que no se propaguen al paso siguiente del proceso de software.
5 5.7 ASEGURAMIENTO DE CALIDAD EN EL
DESARROLLO DEL SOFTWARE
Las actividades de diseño introducen entre el 50 y 65% de todos los errores durante el proceso de
software. Sin embargo, se ha demostrado que las RTF son efectivas en un 75% a la hora de detectar
errores. Con la detección y la eliminación de un gran porcentaje de errores, el proceso de revisión
reduce substancialmente el coste de los pasos siguientes en las fases de desarrollo y mantenimiento.
Los objetivos de la RTF son:
1. Descubrir errores en la función, la lógica o la implementación del software,
2. Verificar que el software bajo revisión alcanza sus requisitos,
3. Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos,
4. Conseguir un software desarrollado en forma uniforme y
5. Hacer que los proyectos sean más manejables.
6 5.7 ASEGURAMIENTO DE CALIDAD EN EL
DESARROLLO DEL SOFTWARE
• La RTF sirve para promover la seguridad y la continuidad, ya que varias personas se
familiarizarán con partes del software que, de otro modo, no hubieran visto nunca. Es una clase
de revisión que incluye recorridos, inspecciones, revisiones cíclicas y otro pequeño grupo de
evaluaciones técnicas del software. Cada RTF se lleva a cabo mediante una reunión y solo tendrá
éxito si es bien planificada, controlada y atendida.
• El aseguramiento de calidad se refiere a validar los procesos usados para crear los productos. Es
una herramienta especialmente útil para administradores y patrocinadores, ya que permite discutir
los procesos usados para crear los productos para determinar si son razonables. Este
aseguramiento tiene asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan
el trabajo técnico y un grupo de SQA (Software Quality Assurance) que tiene la responsabilidad
de la planificación de aseguramiento de la calidad, supervisión, mantenimiento de registros,
análisis e informes.
7 5.7.1 PRINCIPIOS FUNDAMENTALES EN LAS
PRUEBAS
Las pruebas es el proceso de establecer la confianza que el programa o el sistema hace lo que supuestamente debe
hacer, Hetzel 1973, comienzo este punto con esta frase ya que el proceso de pruebas es establecer la confianza de
que el software hace lo que debe hacer sujeto a las necesidades que tenga el usuario, los cuales son plasmados en
documentos como: Requerimientos Funcionales, Requerimientos No Funcionales, Diagramas de Casos de Uso
tanto de Negocio y de Sistema. Por tanto, existen algunos principios tales como:
• Las pruebas ayudan a prevenir deficiencias
• Las pruebas deben estar basadas en el riesgo, ya que es imposible probar todo el software.
• Las pruebas deben ser planeadas
• Las pruebas que revelen problemas son un éxito.
• El propósito de encontrar problemas es corregirlos.

Por lo tanto las pruebas deben estar basadas en el riesgo del negocio y el objetivo es reducir el riesgo inherente al
desarrollo del sistema y asegurar los errores que más impactan en el negocio.
8 5.7.2 TIPOS DE PRUEBAS

Dentro del proceso de pruebas existen diversos tipos, entre ellos son:
• Pruebas de Requerimientos: Son las que detectan fallos en las especificaciones funcionales, existen diferentes
técnicas tales como: Examinación que es la verificación actual del negocio, Fact Finding que es el
acompañamiento al usuario en el negocio, WalkThrougths que son talleres que se realizan a los usuarios que están
directamente relacionados con el software y el negocio y las listas de chequeo. Son realizadas entre el equipo de
especificadores y los analistas de pruebas.
• Pruebas Unitarias: Son las que validan cada pieza de código de manera individual y deben ser realizadas por el
equipo de desarrollo del proyecto con el fin de disminuir los defectos cuando se realicen las pruebas funcionales.
• Pruebas de Integración: Son las que validan la interrelación entre cada uno de los módulos que compone el software
y deben ser planeadas y ejecutadas por el Integrador o Arquitecto Funcional.
• Pruebas de Caja Blanca: Son las que detectan las malas prácticas en el código fuente, tales como: la declaración de
variables que no son utilizadas y código muerto o lavaflow y son planeadas y ejecutadas por los desarrolladores y
el líder técnico.
9 5.7.2 TIPOS DE PRUEBAS

• Pruebas Funcionales o de Caja Negra: Son las que detectan problemas o defectos en cuanto a la funcionalidad,
es importante en este punto la intervención del usuario y el analista de pruebas ya que el primero conoce el
negocio y el segundo determina la estrategia de pruebas, ya que como se mencionó anteriormente es imposible
probar todo el software. Son realizadas por el usuario del negocio y el analista de pruebas
• Pruebas de Regresión: Son las que verifican que después de corregir un defecto no se haya afectado otras
funcionalidades del software. Son realizadas por el analista de pruebas
• Pruebas de Sistema o No Funcionales: Son las que detectan fallos en cuanto a carga, concurrencia de usuarios,
stress y rendimiento por lo general están basadas en los Requerimientos No Funcionales. Son realizadas por el
analista de pruebas.
• Pruebas de Producción: Son las que después de implantado el software en ambiente de producción se realicen
pruebas al software realizando un seguimiento al software en el entorno real y son realizadas por el equipo del
proyecto.
10 5.7.3 METODOLOGÍAS DE PRUEBAS

Una de las metodologías más utilizada en cuanto a pruebas es Rational Unified Process (RUP), que
en esta etapa considera los siguientes pasos:
• Se debe generar un plan de pruebas para definir el alcance de los tipos de pruebas que se van a
realizar dentro de un proyecto informático, además se deben tener en cuenta las estrategias y
técnicas para cada tipo de prueba ejecutado y definir los hitos de iteración y los criterios de
terminación o suspensión del proceso de pruebas en el software.
• Definir el Set de Pruebas funcional que es el conjunto de casos de prueba que están basados por lo
general en artefactos como los casos de uso en donde se analizan los f lujos normales y
alternativos, los casos correctos e incorrectos tanto de validación de campos (capa de
presentación), a nivel de lógica de negocio y de datos si está realizando de acuerdo a las
especificaciones funcionales lo que debe hacer el software, el set de pruebas es el libreto de este
proceso que nos ayuda a planear las pruebas y disminuir el riesgo en etapas futuras.
11 5.7.3 METODOLOGÍAS DE PRUEBAS

• Realizar las listas de chequeo, esto consiste en diseñar una serie de preguntas en cuanto a
la realización de pruebas unitarias, de integración y caja blanca que se ejecutan al equipo
del proyecto con el fin de generar alarmas y prevenir errores que son costosos en etapas
posteriores. Estas listas es recomendable ejecutarlas tres veces al inicio del proyecto, en
etapa de desarrollo y en etapas finales del software.
• Set de Pruebas No Funcional, consiste en diseñar casos de prueba que verifiquen el
rendimiento en cuanto a carga de datos, concurrencia de usuarios y stress del software
con el fin de mitigar el riesgo en cuanto a estos aspectos en el entorno real del negocio.
• Generar consolidados de pruebas funcionales en cuanto a reporte de incidencias
funcionales y no funcionales.
12 5.7.4 HERRAMIENTAS AUTOMÁTICAS PARA EL
PROCESO DE PRUEBAS
• Existen diversas herramientas en el mercado, pero no hay que comprar sino de acuerdo
con las necesidades que se requieran para el proceso de pruebas. Las más conocidas son
la suite de Rational Tester de IBM que permite automatizar las pruebas funcionales y No
funcionales de un proyecto de software, Silkper former de Segue para la automatización
de pruebas funcionales y no funcionales, Visual Studio Team Tester 2005, JMeter,
Grinder para aplicaciones JEE.
• Sin embargo, existen otras herramientas para reporte de incidentes que son el Team
Foundation Server de Microsoft, Mantis, WebTracker que son herramientas libres para
estos fines.