Intro Ducci On Prueba S de Software

INTRODUCCIÓN A
LAS PRUEBAS Y
CALIDAD DE
SOFTWARE
750073 - PRUEBAS Y CALIDAD DE SOFTWARE
MAESTRÍA EN INGENIERÍA – ÉNFASIS EN INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN
FACULTAD DE INGENIERÍA
UNIVERSIDAD DEL VALLE
SEMESTRE 2017A - DOCENTE BEATRIZ FLORIAN GAVIRIA

CONTENIDO
•  Crisis en el Desarrollo de Software

•  Conceptos Generales de Pruebas
•  Tipos de Pruebas
•  Pruebas de Software en el Ciclo de Vida de Desarrollo de SW
§  Introducción a la Calidad de Software
EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

CRISIS EN EL
DESARROLLO DE
SOFTWARE

LA LLAMADA “CRISIS DEL SOFTWARE”
•  ¿Por qué toma tanto tiempo desarrollar software?
•  ¿Por qué es tan elevado su costo?
•  ¿Por qué no se puede entregar programas libres de errores?
•  ¿Por qué es tan costoso su mantenimiento?
•  ¿Por qué resulta tan difícil constatar el progreso del desarrollo de
software?
•  ¿La calidad se mide o se construye?

LA LLAMADA “CRISIS DEL SOFTWARE”
La crisis del software aparece en la segunda era de

la evolución de los sistemas informáticos (alrededor
de 1968).
Las actividades de mantenimiento del software

(corrección de fallas, modificación por cambios de
requerimientos de usuarios, y adaptación a nuevos
dispositivos) y el costo en dicho mantenimiento
comenzó a absorber recursos en una medida
alarmante.

LA CRISIS DEL SOFTWARE
1970’s - Crisis del software
•  Exceso en la capacidad para desarrollar software grande y complejo,

con la tecnología existente.
•  Costo de las actividades de mantenimiento del software superior a los
costos de nuevos desarrollos.
•  Inicio el descenso en los costos del hardware.
•  Aumento de proyectos que fallaron a causa del software.
Soluciones
•  Mejores lenguajes de programación (PL/1, APL, Jovial)
•  Lenguajes formales para especificar requerimientos
•  Lenguajes estructurales y multitareas.

1985
•  Crecimiento de la Industria del Software a $ USD 300 MM

•  Reconocimiento de la Ingeniería de Software como una disciplina de la
Ingeniería.
•  Los costos del hardware continúan disminuyendo.
•  Surgen las herramientas CASE y lenguajes de modelamiento:
•  Implementación de un proceso específico de desarrollo
•  Representar gráficamente los diseños del software
•  Fácil de mantener, validar y entender.
Soluciones
•  Muchas compañías se dieron cuenta que necesitaban realizar mejoras
significativas en su proceso de desarrollo.

CASOS DE FRACASO
London Ambulance Dispatching System

(1992)
•  Sistema para gestionar las llamadas de emergencias.

•  Inversión :1.8 millones €.
•  Pérdidas: se estima 20 vidas.
•  Problema: El sistema no distinguía llamadas distintas.
•  Retenía llamadas durante horas.
•  Usuarios sin formación.
•  Implantación del sistema de manera apresurada.

CASOS DE FRACASO
Agencia Espacial Europea (1996)
•  Sistema de navegación del Ariane 5. Evolución del Ariane 4

•  Inversión: 7 billones de dólares.
•  Pérdidas: 2 satélites se desintegraron.
•  Problema: Sobrecarga al operar con la velocidad 5 veces mayor que
en el Ariane 4)
•  No se controlaban las excepciones.

CASOS DE FRACASO
Nike (2001)
•  Sistema para automatizar la gestión, producción y venta.

•  Inversión : 400 millones dólares.
•  Pérdidas: 100 millones en ventas. Reducción de un tercio del valor de
las acciones
•  Problema: El sistema intercambiaba órdenes de producción.
•  Exceso de stock en algunos productos y falta en otros.

CASOS DE FRACASO
FBI (2005)
•  Sistema para aumentar la seguridad de las redes y modernizar las

aplicaciones de investigación
•  Inversión : 581 millones dólares (450 millones €)
•  Pérdidas: 170 millones de dólares y 5 años de trabajo
•  Problema: Prisas tras el 11S
•  Continuos cambios en los requerimientos y en los responsables
•  Poca preparación de los directores de proyecto

ACTUALIDAD
•  Los proyectos sobrepasan los cronogramas establecidos.
•  Errores funcionales.
•  Calidad por debajo de lo esperado.
•  Se requiere re-ingeniería constantemente.
•  Necesidad de maduración continua en los procesos y profesionales.
•  Los requerimientos no-funcionales sin certificación o pruebas.
•  Soluciones
•  Idea de dividir para vencer
•  Metodologías ágiles
•  Test-Driven Development (TDD)
•  Behavior-Driven Development (BDD)
•  Herramientas para pruebas no-funcionales

CONCEPTOS
GENERALES DE
PRUEBAS

CONCEPTOS GENERALES DE PRUEBAS
¿Qué son las Pruebas?
“Las pruebas muestran la presencia de errores pero nunca la ausencia de

ellos”
“El proceso de operar un sistema o un componente bajo condiciones

especificadas, observando o registrando los resultados, y de hacer una
evaluación de un cierto aspecto del sistema o del componente.”
IEEE Estándar Glossary of Software Enginerineering Terminology


Ideas Generales - Pruebas
La prueba exhaustiva del software es impracticable (no se pueden probar todas las
posibilidades de su funcionamiento ni siquiera en programas sencillos)
El objetivo de las pruebas es la detección de defectos en el software (descubrir un

error es el éxito de una prueba)
El descubrimiento de un defecto significa un éxito para la mejora de la calidad del

producto de Software.
Todos los errores deben ser registrados y tenidos en cuenta para su corrección.

Objetivos de las Pruebas de Software - Producto
Detectar defectos antes de que el producto sea instalado en el cliente o usuario

final.
Garantizar la aceptación de los productos por parte de los clientes o usuarios

finales.
Asegurar que el producto (Sistema) este listo para ser utilizado desde el punto
desde las diferentes características de calidad definidas.
Mejoramiento en la satisfacción de clientes o usuarios finales.

Objetivos de las pruebas – Equipo de desarrollo
Disminución del reproceso de corrección de defectos
Apropiación de la cultura de calidad por parte del equipo humano
Medición y control del producto durante la etapa de desarrollo de software.
Análisis de causas de defectos para apoyar la mejora de procesos de desarrollo

de software.

Pruebas Estáticas – La evaluación del software no

implica su ejecución. Se evalúan los productos
intermedios de trabajo.
Pruebas Dinámicas - La evaluación del software

implica su ejecución. Se evalúa el producto de
software o un componente funcionalmente operable.

TIPOS DE PRUEBAS DE SOFTWARE
Pruebas Estáticas de Software:
Revisión de Requerimientos
Revisión de Diseño
Inspección de Código
Revisión de Reléase

Los Tipos de Pruebas se pueden visualizar desde dos enfoques:
Estrategia (momento en el que se realiza) – Niveles Prueba

•  Pruebas Unidad
•  Pruebas Integración
•  Pruebas Sistemas
•  Pruebas Regresión
•  Pruebas Alpha & Beta
•  Pruebas Aceptación
El objetivo
•  Pruebas funcionales
•  Pruebas Seguridad
•  Pruebas Desempeño (Carga)
•  Pruebas Resistencia (Stress) No-Funcionales
•  Pruebas Volumen
•  Pruebas Concurrencia

Niveles de Pruebas

Pruebas Unidad - Pretenden probar que los fragmentos individuales (unidades)

que forman el sistema cumplen las especificaciones y tienen el comportamiento
esperado. Cumplimiento del objetivo de un componente de software (Método-
Clase)
Pruebas Integración – Módulos o componentes funcionan integrados.

Los datos enviados de un módulo o componente se reciben de manera
consistente en el otro.
Pruebas Proceso – Tiene como objetivo determinar el estado de las

funcionalidades independientes de un sistema. (Pueden ser módulos o
componentes funcionales)

Pruebas Regresión – Asegurar que cualquier no conformidad encontrada en

el sistema ha sido corregida y que ninguna de las funcionalidades liberadas
previamente ha fallado como resultado de las correcciones.
Pruebas Sistemas – Los procesos soportados por la aplicación se cumplen

completamente, es decir, los procesos fluyen desde su inicio hasta el final.
Reutilización de Instrumentos de prueba.
Pruebas de Aceptación – Realizadas con los clientes y define su aceptación

del software.
•  ¿Quién define el nivel de la prueba de aceptación?
•  ¿Quién plantea y escribe los instrumentos de pruebas?
•  ¿Quién ejecuta las pruebas?
•  ¿Cuál es el criterio de éxito / falla para la prueba de aceptación?

Pruebas Alpha y Beta - Son pruebas de Sistemas que se realizan

integrando al grupo de testers un conjunto de potenciales usuarios de la
aplicación.
Estos usuarios conscientes de que el producto no ha sido liberado usan
su experiencia para advertir sobre potenciales fallas de la aplicación.
•  La diferencia fundamental entre estas pruebas radica en la ubicación
del equipo de pruebas;
•  Alpha son las pruebas que se realizan internamente en la casa de
software
•  Beta las que se realizan externamente en el cliente.

Pruebas de Seguridad - La prueba de seguridad intenta verificar que los

mecanismos de protección incorporados en el sistema lo protegerán, de hecho,
de accesos impropios. Durante la prueba de seguridad, el responsable de la
prueba desempeñe el papel de un individuo que desea entrar al sistema.
Pruebas Rendimiento
•  Carga de Información
•  Volumen de Datos
•  Concurrencia (Funcionalidades o Usuarios)
•  Stress


PRUEBAS EN EL CICLO DE DESARROLLO DE SOFTWARE
Pruebas en el Proceso de desarrollo de Software




INTRODUCCIÓN A
CALIDAD DE
SOFTWARE

¿QUÉ NOS HACE PENSAR EN CALIDAD?

CALIDAD
Definición de diccionario:
“Conjunto de cualidades que constituyen la manera
de ser de una persona o cosa”.
Superioridad en su línea; nobleza de linaje;

importancia o gravedad de una cosa.
En términos generales podemos definir la calidad

como conjunto de características que se pueden
esperar de un producto o servicio.

CALIDAD EN SOFTWARE
FUNCIONAMIENTO: Nivel elemental de calidad.

El software siempre debe funcionar, debe permitirnos usarlo
cuando sea necesario. Funciona todas las veces que se
requiere.
FUNCIONALIDAD: Nivel intermedio de calidad.

El software debe hacer lo que dice que hace.
Es importante contar con las facilidades para conocer las tareas
que hace (manual de usuario completo)
USABILIDAD: Nivel superior de calidad.

El software no solo debe hacer lo que dice que hace sino
permitirnos hacerlo de forma adecuada, natural.

¿CUÁNDO EVIDENCIAMOS LA CALIDAD EN EL SOFTWARE?
Cuando un programa no tiene errores de

sintaxis.
Cuando un programa tiene un buen manejo de
excepciones durante su ejecución
Existen datos de pruebas para los cuales el
programa arroja salidas correctas.
•  Para conjunto típicos de datos, el programa arroja salidas
correctas.
•  Para un conjunto de datos límites, el programa arroja salidas
esperadas.
•  Para todos los posibles conjuntos de datos de prueba y todas
las condiciones de entrada inválida, el programa da respuestas
esperadas.

CALIDAD EN SOFTWARE
En el software se esperan, entre otras, algunas de estas

cualidades, (atributos de calidad):
Robustez: El sistema funciona aun en circunstancias
anormales.
Confiabilidad: Funcionalidad + Robustez.
Extendibilidad: Facilidad de adaptarse a cambios en las
especificaciones.
Reutilización: Capacidad del software para ser utilizado
total o parcialmente en otros software.
Eficiencia: Capacidad del software para usar el mínimo
de recursos en sus procesos.

¿QUIÉN ES EL RESPONSABLE DE LA CALIDAD?
Un conjunto de características de calidad determinados

deben ser comunes a todos los productos creados por un
ente dado.
Es por ello que una entidad debe ser encargada de definir

e implementar la calidad de su producto.
En el software este es, la Fabrica de Software.

LA FÁBRICA DE SOFTWARE
Gestión de infraestructuras
*
Equipos de documentación
(Adm de BD y de S.O) (Describe funcionalidades del producto)
EQUIPO DE DESARROLLO
Núcleo
Equipos de pruebas
del software * Equipos de apoyo a la gestión
(Económico y recursos humanos) *
*Equipos de apoyo

LA FÁBRICA DE SOFTWARE
- Se responsabiliza de la realización de un producto, no de

disponer de las personas para realizarlo.
- Se orienta a la realización de productos, es decir,

soluciones software genéricas orientadas a las
necesidades generales de un sector o negocio.

FÁBRICA DE SOFTWARE
ORIENTADA A LA CALIDAD
Recursos Humanos: Las personas son el engranaje

principal de la fabrica de software, de ellos se espera:
– Profesionalidad (Conocimientos, Ética).
– Aptitud Critica y de Aprendizaje continuo.
– Trabajo en equipo.
Infraestructura: Las instalaciones debe ser acordes al

proyecto a realizar y debe ofrecer todas la necesidades al
equipo de desarrollo.

ORIENTADA A LA CALIDAD
Metodología: Define el procedimiento como se generara

el producto, debe estar asociada a la sensatez.
Gestión: Define la manera como se van a distribuir todos

los recursos (incluyendo el tiempo) en la diferentes
actividades definida por la metodología De igual manera
debe estar asociada a la sensatez, y estar basada en
elementos para determinar el estado de cualquier proceso
(Métricas).

MÁS ALLÁ DE LA
La fábrica de software solo es un componente de una gran

cadena de suministro compuesta de:
•  Universidades: Proveen nuevo conocimiento
(Conceptos y Tecnologías).
•  C o n s t r u c t o r e s d e C o m p o n e n t e s : To m a l o s
conocimientos dados por la universidades y los
transforman en componentes de alto nivel.
•  Fabrica de Software: Ensambla los componentes para
construir software para propósitos específicos
•  Administradores de Información.

ROLES EN UN PROYECTO DE SOFTWARE
Administrador del Proyecto: Determina las

actividades a realizar y los recursos dados a cada
una. Asegura el cumplimiento de plazos y de la
ejecución de las políticas de la Fábrica de
Software. Atento al manejo de riesgos.
Intermediador entre los participantes.
Gestor de Calidad: Es el que se encarga de

implementar el SGC, nombrar los inspectores de
las tareas del proceso de desarrollo, controlar las
pruebas, el análisis de las mediciones y proponer
con el grupo de desarrollo modificaciones o
mejoras al proceso.

Líder de Configuración: Es el que se encarga

de manejar los elementos generados en el
proceso de software y registrar sus cambios.
Analistas: Analizan el problema y determinan

las soluciones a estos, dichas soluciones se
plasman como requerimientos
Arquitectos: Diseñan el sistema a diferentes

niveles y perspectivas, a partir de un análisis
del negocio (Requerimientos).

Programadores: Son los encargados de construir los

diseños de los arquitectos.
Equipo de Pruebas: Son los encargados de probar los

diferentes elementos generados en el proyecto, en
supervisión del gestor de calidad.

ACTIVIDADES DE CALIDAD
Garantía de la Calidad: Establecimiento de un conjunto de

procedimientos y estándares que lleven a la calidad Sistema de
Gestión de Calidad (ISO 9000).
Planificación de la Calidad: Adaptación de los procedimientos y

entandares a un proyecto definido.
Control de la Calidad: Definición y ejecución de procedimientos, que

garanticen la ejecución de los mecanismos de calidad definidos.
Aseguramiento de Calidad: Proveer los recursos para que los

procesos se desarrollen de la forma prevista. Orientada a proporcionar
confianza en que se cumplirán los requisitos de la calidad

REFERENCIAS
Engineering models and software quality models: an example and a discussion –

Paolo Salvaneschi, Ugo Piazzalunga. May 2008
ISO/IEC SQuaRE. The second generation of standards for software product

quality, Witold Suryn, Alain Abran. Department of Electrical Engineering, École de
Technologie Supérieure.
ISO/IEC 9126 Information technology - Software Product Evaluation- Quality

characteristics and guidelines for their use.
ISO/lEC 2382-1:1993, Tecnología de la información. Vocabulario. Parte 1:

Términos fundamentales.
ISO 8402:1994,Gestión de la calidad y aseguramiento de la calidad. Vocabulario.
ISO/lEC 9126-1:2001, Tecnología de la Información. Calidad del producto

software. Parte 1: Modelo de calidad. ISO/lEC 12207:1995 - Tecnología de la
información. Procesos de ciclo de vida del software.
REFERENCIAS
ISO/IEC 9126: Software Engineering - Product quality. To be published in

2003
ISO/IEC 14598: Information Technology – Software product evaluation.

1999-2001
Krause P., Freimut B., Suryn W., “New Directions in Measurement for Software
Quality Control.” Proceedings of STEP2002, Computer Society Press, 2003
Suryn W., Abran A., Bourque P., Laporte C., “Software Product Quality
Measurement and Evaluation: An integrated life cycle quality model using TL9000
and ISO/IEC 9126.” Submitted to JISBD 2003 - VIII Jornadas de Ingeniería del
Software y Bases de Datos 12-14 November 2003, Alicante, Spain
Bevan N., Bohomolni I., “Incorporating user quality requirements in the software
development process,” In: Proceedings of 4th International Software Quality
Week Europe, Brussels, pages 1192-1204, 2000.

REFERENCIAS
Vliet, H., Software Engineering, Principles and Practice, Second Edition.

John Wiley & Sons, 2002
Pfleeger S.L. “Software Engineering, Theory and Practice” Second Edition,

Prentice Hall 2001

Intro Ducci On Prueba S de Software

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Intro Ducci On Prueba S de Software

Transféré par

Droits d'auteur :

Formats disponibles

INTRODUCCIÓN A

SEMESTRE 2017A - DOCENTE BEATRIZ FLORIAN GAVIRIA

• Crisis en el Desarrollo de Software

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 2

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 3

• ¿Por qué toma tanto tiempo desarrollar software?

• ¿Por qué es tan elevado su costo?

• ¿Por qué no se puede entregar programas libres de errores?

• ¿Por qué es tan costoso su mantenimiento?

• ¿Por qué resulta tan difícil constatar el progreso del desarrollo de

• ¿La calidad se mide o se construye?

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 4

La crisis del software aparece en la segunda era de

Las actividades de mantenimiento del software

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 5

1970’s - Crisis del software

• Exceso en la capacidad para desarrollar software grande y complejo,

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 6

• Crecimiento de la Industria del Software a $ USD 300 MM

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 7

London Ambulance Dispatching System

• Sistema para gestionar las llamadas de emergencias.

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 8

Agencia Espacial Europea (1996)

• Sistema de navegación del Ariane 5. Evolución del Ariane 4

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 9

• Sistema para automatizar la gestión, producción y venta.

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 10

• Sistema para aumentar la seguridad de las redes y modernizar las

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 11

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 12

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 13

¿Qué son las Pruebas?

“Las pruebas muestran la presencia de errores pero nunca la ausencia de

“El proceso de operar un sistema o un componente bajo condiciones

IEEE Estándar Glossary of Software Enginerineering Terminology

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 14

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 15

Ideas Generales - Pruebas

El objetivo de las pruebas es la detección de defectos en el software (descubrir un

El descubrimiento de un defecto significa un éxito para la mejora de la calidad del

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 16

Objetivos de las Pruebas de Software - Producto

Detectar defectos antes de que el producto sea instalado en el cliente o usuario

Garantizar la aceptación de los productos por parte de los clientes o usuarios

Mejoramiento en la satisfacción de clientes o usuarios finales.

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 17

Objetivos de las pruebas – Equipo de desarrollo

Disminución del reproceso de corrección de defectos

Apropiación de la cultura de calidad por parte del equipo humano

Medición y control del producto durante la etapa de desarrollo de software.

Análisis de causas de defectos para apoyar la mejora de procesos de desarrollo

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 18

Pruebas Estáticas – La evaluación del software no

Pruebas Dinámicas - La evaluación del software

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 19

Pruebas Estáticas de Software:

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 20

Los Tipos de Pruebas se pueden visualizar desde dos enfoques:

Estrategia (momento en el que se realiza) – Niveles Prueba

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 21

EISC - PRUEBAS Y CALIDAD DE SOFTWARE - BEATRIZ FLORIAN GAVIRIA 22

Pruebas Unidad - Pretenden probar que los fragmentos individuales (unidades)

•  Crisis en el Desarrollo de Software

•  ¿Por qué toma tanto tiempo desarrollar software?

•  ¿Por qué es tan elevado su costo?

•  ¿Por qué no se puede entregar programas libres de errores?

•  ¿Por qué es tan costoso su mantenimiento?

•  ¿Por qué resulta tan difícil constatar el progreso del desarrollo de

•  ¿La calidad se mide o se construye?

•  Exceso en la capacidad para desarrollar software grande y complejo,

•  Crecimiento de la Industria del Software a $ USD 300 MM

•  Sistema para gestionar las llamadas de emergencias.

•  Sistema de navegación del Ariane 5. Evolución del Ariane 4

•  Sistema para automatizar la gestión, producción y venta.

•  Sistema para aumentar la seguridad de las redes y modernizar las

- Se responsabiliza de la realización de un producto, no de

- Se orienta a la realización de productos, es decir,