MODELOS Y CONTROL DE CALIDAD

SEMANA 7

Calidad enfocada en el
desarrollo de software

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 7
ninguna clase.
 2
ESTE DOCUMENTO CONTIENE LA SEMANA 7
ÍNDICE
CALIDAD ENFOCADA EN EL DESARROLLO DE SOFTWARE................................................................... 5
OBJETIVOS ESPECÍFICOS ........................................................................................................................... 5
INTRODUCCIÓN ...................................................................................................................................... 5
1. PRINCIPIOS FUNDAMENTALES DE LA CONSTRUCCIÓN DE SOFTWARE ..................................................... 6
1.1. MINIMIZAR COMPLEJIDAD ........................................................................................................... 8
1.2. ANTICIPAR CAMBIOS ................................................................................................................... 8
1.3. CONSTRUIR PARA VERIFICAR......................................................................................................... 9
1.4. UTILIZAR ESTÁNDARES ................................................................................................................. 9
2. MECANISMO DE CALIDAD EN EL DESARROLLO DE SOFTWARE.............................................................. 10
2.1. DISEÑO POR CONTRATO ............................................................................................................ 10
2.2. ANÁLISIS DE RENDIMIENTO......................................................................................................... 12
2.3. DEPURACIÓN............................................................................................................................ 12
3. INGENIERÍA DE TESTING ................................................................................................................. 14
3.1. FUNDAMENTOS DE PRUEBAS DE SOFTWARE ................................................................................ 15
3.1.1. TERMINOLOGÍA RELACIONADA CON LAS PRUEBAS......................................................................... 16
3.1.2. CASOS DE PRUEBA..................................................................................................................... 16
3.1.3. ELEMENTOS CLAVE.................................................................................................................... 18
3.1.4. TIPOS DE PRUEBA ...................................................................................................................... 19
3.1.5. ESTABLECER OBJETIVOS DE LA PRUEBA......................................................................................... 20
3.2. TÉCNICAS DE PRUEBA Y SU APLICACIÓN........................................................................................ 21
3.2.1. EXPERIENCIA DEL INGENIERO DE SOFTWARE ................................................................................. 21
3.2.2. ESPECIFICACIÓN ........................................................................................................................ 21
3.2.3. PROGRAMACIÓN DEL CÓDIGO.................................................................................................... 22
3.2.4. ERRORES.................................................................................................................................. 22
3.2.5. EN EL USO DE LA FUNCIONALIDAD ............................................................................................... 23
3.2.6. NATURALEZA DE LA APLICACIÓN.................................................................................................. 23
3.3. PLAN DE PRUEBAS ..................................................................................................................... 24
3.3.1. ESTRUCTURA DEL PLAN DE PRUEBAS............................................................................................ 24
COMENTARIO FINAL.......................................................................................................................... 27
REFERENCIAS........................................................................................................................................ 28

3
ESTE DOCUMENTO CONTIENE LA SEMANA 7
ÍNDICE DE FIGURAS
Figura 1: Actividades del desarrollo de software ................................................................................ 7
Figura 2: Relación de contratos entre componentes de software ..................................................... 11
Figura 3: Relación de contrato entre dos componentes de software ................................................ 11
Figura 4: Ciclo de pruebas y depuración. ........................................................................................... 13
Figura 5: El proceso de pruebas en el ciclo de vida del desarrollo..................................................... 15
Figura 6: Definición de escenarios ..................................................................................................... 17
Figura 7: Ejemplo de un caso de prueba simple ................................................................................ 18

ÍNDICE DE TABLAS
Tabla 1: Escenarios de prueba ........................................................................................................... 17
Tabla 2: Estructura del plan de pruebas ............................................................................................ 26

4
ESTE DOCUMENTO CONTIENE LA SEMANA 7
CALIDAD ENFOCADA EN EL DESARROLLO DE SOFTWARE

OBJETIVOS ESPECÍFICOS
 Conocer los principios que gobiernan el desarrollo de software de calidad
 Conocer los mecanismos que permiten los requisitos de calidad en el software
 Comprender los conceptos básicos de la ingeniería de testing
 Aplicar los diferentes tipos de prueba existentes al desarrollo de software

INTRODUCCIÓN
El desarrollo de software de calidad demanda una serie de aspectos que incluyen una buena
definición de requerimientos, y que posteriormente se traducen en un conjunto de
especificaciones funcionales y no funcionales de la solución. Asimismo, quienes desarrollan el
software toman esta información como la entrada a su proceso de implementación y pruebas.
Estas actividades deben estar bien definidas y en concordancia con las definiciones realizadas en el
proyecto. Para guiar el desarrollo de manera que el resultado sea un producto consistente,
robusto, confiable y fácil de usar, existen fundamentos para la programación. Así también, para
verificar que la solución de software haga lo que tiene que hacer, pero además para validar que el
software se desarrolle de acuerdo a normas o estándares acogidos por la organización. Estos
conceptos se desarrollarán en el contenido de esta semana, abordando los aspectos
fundamentales en el desarrollo de software y el proceso de pruebas.

5
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 1. PRINCIPIOS FUNDAMENTALES DE LA CONSTRUCCIÓN DE
SOFTWARE
La construcción de software (en adelante, desarrollo de software) es una de las principales
actividades que realiza la ingeniería de software. Esta última es la disciplina del área informática o
ciencias de la computación, que define métodos y técnicas especializadas para implementar y
mantener software de calidad. De esta manera el desarrollo de software es una actividad cuyo
producto satisface una diversa demanda de servicios y necesidades en el quehacer de hoy
(Pressman, 2010).

Profundizando la definición de desarrollo de software, corresponde a un proceso donde se

escriben líneas de código en algún lenguaje determinado, posteriormente se verifica la adhesión a
normas y estándares, se somete a pruebas (unitarias e integración), y finalmente se realizan
ajustes sobre la base de un proceso de depuración, respecto a las definiciones funcionales dadas
en los requerimientos del usuario.

Se puede señalar que el desarrollo de software se sustenta en ideas fundacionales (principios) y en

el conocimiento adquirido por los ingenieros a través del tiempo. Esto es, desde las primeras
versiones de programas que se ejecutaron en computadores, tales como sistemas operativos y
otras aplicaciones, hasta los desarrollos de última generación que hoy podemos encontrar en una
amplia diversidad de aplicaciones.

En la figura 1 se muestra una representación genérica de un ciclo de desarrollo del software. En

primer lugar, se deben tener bien definidos los requerimientos funcionales que se necesita
implementar en la solución, los cuales aparecen representados desde R1 a Rn. Estos
requerimientos deben ser modelados como parte de la solución en la actividad de diseño.
Posteriormente, habiéndolo validado el usuario, se realiza el proceso de programación, en el cual
se verifican los aspectos técnicos y funcionales, como por ejemplo cumplir con la normas de
programación que la organización defina, como también satisfacer las necesidades funcionales.
Dependiendo del modelo de desarrollo que se utilice, habrá iteraciones que van de la mano del
diseño, programación y pruebas. Una vez ejecutado en forma correcta el ciclo de desarrollo, con
todas las etapas realizadas exitosamente, se tendrá una versión del producto de software.

6
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Figura 1: Actividades del desarrollo de software
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

Durante el proceso de desarrollo, además se deben considerar funciones que pueden realizar
también los mismos miembros del equipo, o bien un grupo dedicado. Por ejemplo, el
aseguramiento de la calidad y administración de la configuración. En este último caso,
corresponde al área encargada de gestionar una cantidad considerable de productos de trabajo
del proyecto, también conocidos como entregables. En tal caso, la organización establece políticas
para la gestión de los entregables en cada proyecto, y un grupo a cargo de gestionarlos.

Algunos ejemplos de ítems de configuración o entregables son los siguientes:

 Documentación de las definciones del proyecto. En este caso corresponde mantener

actualizada y administrada toda la documentación del proyecto que se quiera mantener.
Documentos de análisis, documentos de diseño, especificaciones técnicas y funcionales;
por mencionar algunos.

 Componentes de software del proyecto. Todo desarrollo va generando una serie de piezas
de software, las cuales pueden corresponder al software de aplicación, desarrollos de
bases de datos, archivos de configuración, programas de procesamiento de datos,
configuraciones a nivel de sistemas y otros más.

7
ESTE DOCUMENTO CONTIENE LA SEMANA 7
  Documentos de la gestión del proyecto. Planes de proyecto, cartas Gantt, minutas de
reuniones, informes de avance, control presupuestario, contratos de terceros,
presentaciones para el cliente, gestión de riesgos y otros más.

 Documentos de la gestión de pruebas. Plan de pruebas, scripts con casos de prueba,

registro de resultados, informes de gestión de pruebas.

Como se puede inferir, el desarrollo de software es una actividad elaborada, lejos de ser algo
simple. Requiere disciplina, método, un modelo de gobierno que facilite la administración y
gestión de todas las actividades que se deben desarrollar.

A continuación, se presentan varias definiciones que ayudan a entender algunos objetivos

importantes desde la perspectiva del desarrollo de software.

1.1. MINIMIZAR COMPLEJIDAD

El creciente desarrollo de la industria en sus distintos frentes y mercados ha hecho que las
necesidades sean cada vez más diversas y también complejas. Los procesos de negocio requieren
un alto grado de implementación de soluciones de software para apoyar la gestión y operación, las
que de no ser automatizadas harían más complejas las miles de casuísticas de negocio que a diario
resuelven los sistemas. Asimismo, en el marco del desarrollo de software, también se requiere lo
mismo: minimizar complejidad. Imagine que en el mundo real modelamos una situación en la que
es necesario crear una solución de software para apoyar un proceso de negocio determinado.
¿Qué sentido tendría desarrollar algo tan complejo como el proceso en la vida real, o quizás, más
complejo? ¿Tendría algún éxito nuestra solución?

La necesidad de reducir complejidad se debe aplicar a toda actividad del desarrollo de software,
tomando mayor énfasis en el proceso de verificación y pruebas. De esta forma, al escribir código
se debe realizar en forma simple, ordenada, de acuerdo a una lógica previamente validada.
Siguiendo patrones de desarrollo que adopte la organización, respecto a estándares y modelos de
calidad.

1.2. ANTICIPAR CAMBIOS

En el proceso de desarrollo de software, además de crear una solución en respuesta a los
requerimientos del usuario, también se debe asegurar que ante factores de cambio externos a la
aplicación, tendrá la flexibilidad necesaria para introducir los cambios que requiera. Se debe
señalar que los factores de cambio obedecen a distintos ámbitos. Por ejemplo, un sistema que se
utiliza en el ámbito de la fiscalía nacional deberá adecuarse ante un cambio de las leyes y que esta,
a su vez, genere un cambio en la definición de los requerimientos funcionales. Así también es lo
que se vivió en el cambio de milenio; las organizaciones tuvieron que invertir mucho dinero en
adecuar sus aplicaciones para soportar cuatro dígitos en lugar de los dos que usualmente se

8
ESTE DOCUMENTO CONTIENE LA SEMANA 7
definían (año 2000). Pero además de este tipo de cambios también existen los cambios que se
realizan producto de la renovación de plataformas e infraestructura computacional. En este caso,
las adecuaciones o adaptaciones que se requieren no están dadas por temas funcionales, sino más
bien técnicos. Hay otros casos, sin embargo, en los que la idea es la misma, el desarrollo debe
incorporar estos criterios en el diseño y posteriormente en la implementación de las soluciones.
Un sistema que no tiene flexibilidad para introducir cambios se transformará en un gran problema
en el momento que deba realizarlos. La anticipación a los cambios busca que desde el diseño se
considere introducir los mecanismos necesarios para asegurar que el sistema no tendrá problemas
para adaptarse ante necesidades de cambio.

1.3. CONSTRUIR PARA VERIFICAR

Se refiere a que los ingenieros de software que escriban programas con las convenciones
necesarias para poder acceder en forma clara y directa a las instancias del programa donde se
detectan fallas y potenciales errores. El concepto en este caso es que el software sea fácil de
depurar, analizar y corregir. Para realizar lo anterior, es necesario que el proceso de desarrollo de
software adhiera a métodos estándar de programación, se establezcan normas aplicables y
simples de implementar. Asimismo, en forma permanente, se debe realizar una serie de
actividades tendientes a asegurar la calidad. Por ejemplo, inspecciones de código que sean
realizadas en forma periódica, desarrollo de pruebas unitarias (en el ámbito de quien desarrolla el
software) y revisión entre pares.

1.4. UTILIZAR ESTÁNDARES

La estandarización, como concepto, busca conciliar e integrar las mejores prácticas del ámbito en
el que se requiere realizar una actividad específica. De esta manera, la estandarización promueve
directrices y definiciones que son reconocidas por todos los actores que necesitan utilizar el
estándar para desarrollar sus actividades. Podrían enumerarse diversos estándares, sin embargo
es importante entender y conceptualizar su significado práctico en el desarrollo de software.
Revisemos algunas definiciones de estandarización aplicadas al desarrollo de software como
disciplina de la ingeniería de software.

Métodos de comunicación, donde se define el formato de los documentos que se utilizan para
dejar documentada una solución. Por ejemplo, para elaborar el análisis, el diseño de una solución,
la especificación técnica, cartas Gantt para los proyectos, informes de gestión de los proyectos,
minutas de trabajo, entre otros.

Lenguajes de programación, en este caso al utilizar un determinado lenguaje, lo recomendable es

incorporar en el proceso de programación todas las convenciones orientadas a lograr una mejor
utilización de los recursos y técnicas, para obtener un producto de calidad. Por ejemplo, el uso de
estructuras especiales, manejo de variables dentro del programa, comunicación entre
componentes, por mencionar algunas.

9
ESTE DOCUMENTO CONTIENE LA SEMANA 7
Plataformas sobre las cuales corren los programas. Así, un programador aplicará las definiciones
correctas para interactuar a través del programa con el sistema operativo.

Herramientas para la diagramación de documentos requeridos en el proceso de desarrollo. Por

ejemplo, adherir a la notación de UML (lenguaje universal de modelado).

Así como existen convenciones internacionales que definen estándares, las organizaciones
internamente también pueden definir sus propios estándares para el desarrollo de software. Estas
definiciones obedecen a particularidades que deben ser consideradas y se adoptan con el objetivo
de uniformar las actividades realizadas en el ámbito de la programación.

2. MECANISMO DE CALIDAD EN EL DESARROLLO DE SOFTWARE

2.1. DISEÑO POR CONTRATO

Corresponde a una forma de modelar el comportamiento entre componentes de software al
momento de diseñar o programar una solución de software (Pressman, óp. cit.). El concepto fue
introducido en 1992 por Bertrand Meyer, utilizando su lenguaje de programación Eiffel.

El diseño por contrato en el desarrollo de software obedece a la aplicación de los contratos que
conocemos en el ámbito de las personas, en los cuales se establecen relaciones de obligación y
beneficios entre las partes. Al desarrollar software, se establece el tipo de relación entre distintos
componentes, en forma específica y sin ambigüedades. Quien llama y quien responde a ese
llamado es un contrato y pasa a formar parte de un requisito a nivel de sistema para cumplir uno o
más objetivos. De esta manera, si se amplía esta definición a una solución de software, se puede
señalar que existen componentes de software interrelacionados entre sí a través de contratos —
donde cada componente puede ser un emisor o receptor de mensajes— los cuales están definidos
como contratos que establecen obligaciones y beneficios, de acuerdo al tipo de relación que se
defina entre los componentes.

10
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Figura 2: Relación de contratos entre componentes de software
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

En la figura 2, se presenta una relación entre componentes de software, donde se ha establecido

la relación que existe entre ellos. Se puede observar que la componente C1 se relaciona con la
componente C2, a través de un mensaje tipo 1. Asimismo, los demás componentes establecen
relaciones entre ellas, de acuerdo al tipo de mensaje. En el caso de las componentes C2 y C4,
además de recibir mensajes, también envían. Por tanto, al diseñar una solución de software y
definir la forma como cada componente se relacionará en el sistema, asegura de forma clara el
flujo funcional y de datos que corresponde en cada caso. Por ejemplo, si hiciéramos un zoom a la
relación entre los componentes C4 y C5, veríamos lo siguiente:

Figura 3: Relación de contrato entre dos componentes de software

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

11
ESTE DOCUMENTO CONTIENE LA SEMANA 7
El componente C4 hace una solicitud al componente C5, para lo cual, de acuerdo al contrato entre
ambos, debe enviar un set de datos de entrada para ser procesados en las precondiciones del
procesamiento que realiza el componente C5. Posteriormente, el componente C5 envía el
resultado al componente C4, cumpliendo así con el contrato de comunicación que el sistema ha
definido entre ambos.

2.2. ANÁLISIS DE RENDIMIENTO

El rendimiento en un sistema de software es un requerimiento que va más allá de la necesidad
funcional definida en los requerimientos de negocio o funcionales. Es necesario que la solución
tenga un comportamiento sólido para soportar la demanda de servicio para la cual fue
desarrollado. Imagine un sistema que ante el aumento de solicitudes (consultas, informes,
ingresos, modificaciones, o bien, cualquier uso de la funcionalidad para la cual fue desarrollado)
presente problemas en sus tiempos de respuesta de cara al usuario. En oportunidades, cuando
esto ocurre en algunos servicios genera molestias en los clientes y da una mala imagen. Por esta
razón es necesario, como parte del desarrollo de una solución, se realicen en forma permanente
pruebas y análisis de rendimiento. En este contexto, se asume que existe un plan de pruebas y que
estas, a su vez, son realizadas en forma unitaria e integrada. Para precisar la idea, en primera
instancia, la prueba unitaria es responsable de probar la funcionalidad en sí. En tanto la prueba
integral pone la funcionalidad en el contexto de la solución completa. En ambos casos, es
necesario realizar un análisis de rendimiento.

2.3. DEPURACIÓN
La depuración es el proceso que se desprende luego de realizar pruebas en la funcionalidad de una
solución de software. Busca determinar las causas que generan un error a nivel de aplicación, con
el objeto de establecer las correcciones que correspondan. Se inicia con la ejecución de un caso de
prueba, del cual se evalúa el resultado, donde aparece una diferencia respecto del resultado
esperado y el real que se obtiene. En primera instancia, cuando no existe tal correspondencia
(esperada vs. real), se puede inferir la existencia de un error, aun cuando no se tenga claro el
problema que lo origina. De esta forma, el proceso de depuración ayuda a encontrar una causa
que puede dar origen a la diferencia. De lo anterior, se puede identificar el error y el tipo de
corrección que se debe realizar. Cabe destacar que el proceso de depuración no es en sí la prueba
del software, pero sí debe estar considerado dentro del proceso de pruebas. En la figura 4 se
muestra un ciclo de pruebas, donde se realiza el proceso de depuración.

12
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Figura 4: Ciclo de pruebas y depuración.
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

13
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 3. INGENIERÍA DE TESTING
Todo proceso productivo debe asegurar la calidad de sus productos. En el ámbito del desarrollo de
software, se ha mencionado en los contenidos de las semanas anteriores que existen procesos
orientados a asegurar la calidad del producto de software. Sin embargo, una de las actividades que
deben ser desarrolladas es precisamente evidenciar que el resultado obtenido a través de la
aplicación de métodos, procedimientos y ejecución de actividades dan como resultado un
producto de calidad. Por lo anterior, se han desarrollado modelos de referencia para ejecutar en
forma eficiente un conjunto actividades para probar el software. Así también, la gestión de estas
actividades es apoyada por artefactos (documentos) y en algunos casos también por herramientas
que asisten el proceso de pruebas.

La prueba del software es, entonces, una de las actividades que ayudan a validar las características
del software y, en particular, la correcta implementación de los requerimientos funcionales y no
funcionales, bajo los escenarios en los cuales se entiende deben operar.

A considerar:

De acuerdo a ISO 12207:2008, el aseguramiento de la calidad de software, se encarga de proveer

la confianza respecto a que los productos de trabajo y procesos cumplen con las previsiones y
planes previamente establecidos.

El testing (o pruebas de software) permite medir la calidad del software en función de los errores
que se puedan encontrar, aplicándolo tanto en el ámbito funcional, como también en aquellas
necesidades no funcionales de la solución.

A través de las pruebas de software se puede establecer también el nivel de seguridad que ofrece
el producto desarrollado. No es lo mismo una solución con muchos errores, frente a una que luego
de ser probada (de acuerdo al ámbito que corresponda) no presenta problemas.

Finalmente, se puede inferir que mientras menos errores sean detectados por el testing, mayor
será el grado de calidad del producto. Esto implica que reduce la incertidumbre respecto a la
planificación, mejora los indicadores de calidad y rentabilidad al producir software y, finalmente,
ayuda a controlar los costos por concepto de mantenimiento posterior.

A continuación, se presenta con más detalle el concepto de testing o pruebas de software.

14
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 3.1. FUNDAMENTOS DE PRUEBAS DE SOFTWARE
Como se ha señalado, las pruebas de software ayudan a verificar la calidad de un producto de
software, en forma previa a la entrega de la solución al cliente final. La prueba de software se
integra en distintas etapas del ciclo de vida del proceso de desarrollo de software, donde se
aplican técnicas especializadas orientadas a detectar errores en el software (Pressman, óp. cit.). En
la figura 5, se muestra cómo las actividades de prueba deben ir siendo definidas, diseñadas,
elaboradas y ejecutadas, durante el ciclo de desarrollo del software.

Figura 5: El proceso de pruebas en el ciclo de vida del desarrollo

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

Es importante recalcar que para realizar pruebas del software es necesario planificarlas y también
saber cómo se va a medir la prueba, con el objeto de poder determinar objetivamente el
cumplimiento de los requerimientos tanto funcionales como no funcionales.

Las pruebas del software nunca se deben realizar en ambientes operativos o productivos. Siempre
se deben ejecutar en ambientes de prueba, los cuales deben cumplir con las mismas
características técnicas y funcionales con que se ejecutará el nuevo sistema, o bien donde
actualmente se ejecuta el sistema que se está modificando.

15
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 3.1.1. TERMINOLOGÍA RELACIONADA CON LAS PRUEBAS
a. Distinción entre errores y fallas
Para describir un funcionamiento incorrecto de un sistema, se pueden utilizar varias
denominaciones, por ejemplo falta, error o simplemente fallo. Lo trascendental es diferenciar que
una falla en el sistema es el síntoma cuyo origen obedece a un error. Y es este último el que se
debe corregir. Las pruebas deberán cumplir ese objetivo, encontrar errores.

b. Validación
Establecer objetivamente a través de las pruebas y revisiones que el producto de software que se
está desarrollando satisface el uso para el cual fue concebido en el ambiente donde debe operar.

c. Verificación
Por otra parte, este proceso asegura que el producto de software cumpla con los requerimientos
necesarios. Estos requerimientos, formalmente deben estar escritos, revisados y acordados por las
partes interesadas (cliente, desarrolladores). De esta forma, la verificación debe velar por que el
producto de software se desarrolle de la forma correcta.

3.1.2. CASOS DE PRUEBA

Corresponde a un conjunto entradas, condiciones de ejecución y resultados esperados, el cual es

diseñado para lograr un objetivo específico o condición de prueba. Un caso de pruebas se puede
identificar como la unidad básica en un escenario de pruebas, donde se definen condiciones
específicas. Para definirlo y posteriormente ejecutarlo, se deben definir las condiciones iniciales y
finales, valores de entrada y los resultados esperados que deberá entregar el sistema.

Los pasos a seguir en la creación de caso de prueba corresponden a los siguientes (Pressman, óp.
cit.):

16
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 a. Definición de escenarios

Para una determinada funcionalidad del software, se establecen las distintas casuísticas de
acuerdo a las definiciones dadas en las especificaciones funcionales. Por ejemplo, gráficamente se
puede representar de la siguiente forma en la figura 6.

Figura 6: Definición de escenarios

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

De acuerdo a la lógica que representa este flujo de estructura de control, los eventuales caminos
de ejecución son:

Escenario Secuencia de eventos del sistema

Camino 1 1 -2 – 4 -6

Camino 2 1–2–4–7

Camino 3 1–3–5

Tabla 1: Escenarios de prueba

Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

Donde cada escenario representa un camino con un conjunto de valores y condiciones distintas al
momento de ejecutar el software.

b. Identificar condiciones de entrada

Las condiciones de entrada son parte del dominio de valores que permite procesar el sistema.
Estas condiciones de entrada pueden contener valores válidos, inválidos, o bien aquellos que no
aplican a la condición de prueba.

17
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Figura 7: Ejemplo de un caso de prueba simple
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

En la figura 7, se muestran los resultados esperados en una aplicación bancaria donde el usuario
debe ingresar su clave para seleccionar la operación que requiera realizar. En este caso, opera la
tarjeta de crédito y solamente el camino 2 representa una secuencia exitosa para la prueba de
operación sobre la tarjeta. Los otros casos presentarán problemas de clave y vigencia.

3.1.3. ELEMENTOS CLAVE

a. Criterios de selección de pruebas

Al diseñar las pruebas, es necesario establecer cuáles serán los casos de prueba que se deben
desarrollar. Para realizar lo anterior, se debe considerar la factibilidad de poder ejecutar la prueba
y la efectividad de esta. Se puede establecer un set de casos de prueba altamente complejo, sin
embargo su aplicación práctica no necesariamente conseguirá obtener buenos resultados para la
prueba. El caso de prueba es un escenario de negocio representativo y cuyo resultado es
esperable, sea un caso exitoso o no. Por ejemplo, dado un valor de entrada como un número de
cliente existente en un sistema, al ingresarlo en una consulta, el resultado esperado son los datos
del cliente. Caso contrario, al ingresar un número de cliente inválido, entonces el sistema debiera
arrojar un mensaje indicándolo.

b. Efectividad de las pruebas

La efectividad se mide en función del objetivo que se requiere medir. Por tanto, al diseñar los
casos de prueba, es relevante identificar en forma precisa el objetivo de la prueba.

c. Pruebas para identificar defectos

Este tipo de prueba se focaliza en encontrar defectos y va a ser efectiva si se encuentran errores
en el software. Por lo cual, no corresponde a la prueba que busca verificar que el software
satisface las especificaciones de requerimientos del sistema.

d. Limitaciones técnicas y teóricas

Como estrategia de prueba, es necesario establecer escenarios finitos y orientados a mitigar los
riesgos que eventualmente podrían darse a nivel del software. Pensar en un universo de casos de
prueba muy amplio puede traducirse en un esfuerzo que no logre orientar el sentido de la prueba.
Asimismo, al planificar la prueba, se puede abordar en fases y de acuerdo a las prioridades que el
proyecto establezca.

18
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 e. Relación de las pruebas con otras actividades
Es importante destacar que el proceso de pruebas, como se ha mencionado anteriormente, está
inserto dentro de una serie de actividades orientadas a producir software de calidad. Por tanto, la
prueba además de atender los aspectos funcionales también debe abordar otros aspectos, tales
como seguridad, validez y verificación, depuración, programación de componentes y la
certificación final del software.

3.1.4. TIPOS DE PRUEBA

Como se mencionó anteriormente, las pruebas son aplicadas en distintos contextos durante el
ciclo de vida del desarrollo. De esta manera, se pueden establecer tres niveles de prueba:

a. Pruebas unitarias
Permiten verificar el funcionamiento en forma aislada de una o más piezas o componentes del
software. La prueba se realiza monitoreando el código fuente, lo cual se apoya con el uso de
herramientas del entorno de desarrollo que permiten visualizar la ejecución en cada línea de
código. Esta actividad es propia del equipo de desarrollo, no del usuario final.

b. Pruebas de integración
Permite verificar la interacción entre distintos componentes de software. Se basa principalmente
en la arquitectura del sistema, por lo cual el objeto de prueba es una cadena de funcionalidad
conocida que involucra una serie de desarrollos (piezas de software) que en conjunto satisfacen
una funcionalidad final del usuario. Por lo anterior, el ingeniero debe orientar la prueba en un
nivel de abstracción más cercano al negocio, en lugar de una revisión netamente técnica. Lo que
se debe evitar es abordar las pruebas de integración, abarcando de una vez la totalidad de la
funcionalidad, ya que resulta riesgoso y se pierde la oportunidad de hacerlo en forma incremental,
no permitiendo el avance progresivo del total de la solución.

a. Pruebas de sistemas

Finalmente, se llega a las pruebas de sistema. En este contexto, el objeto de la prueba es el

sistema completo. Lo esperado es que en el proceso previo de pruebas (unitarias e integración), se
haya detectado gran parte de las fallas y errores funcionales. Y es esperable también que en este
tipo de pruebas se verifique el sistema en los aspectos de seguridad, rapidez, confiabilidad,
conexiones a otros sistemas, dispositivos de hardware y sistema operativo.

19
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 3.1.5. ESTABLECER OBJETIVOS DE LA PRUEBA

Establecer previamente objetivos al momento de diseñar y posteriormente ejecutar las pruebas.

Permite medir y evaluar cuantitativamente el resultado de estas. Es decir, ayuda a controlar el
proceso de pruebas y determinar el éxito de estas. Por lo anterior, se pueden categorizar las
pruebas de acuerdo a lo siguiente:

a. Pruebas de aceptación
En este tipo de prueba se compara el comportamiento del sistema versus los requerimientos del
cliente. Para realizarlo, el cliente o usuario final establece las tareas o actividades a realizar con el
sistema, de manera que pueda comprobar que se satisface la lista de requerimientos que se han
definido.

b. Pruebas de instalación
Realizadas las pruebas de aceptación, el software se debe verificar nuevamente en el ambiente o
entorno definitivo. Estas pruebas se enfocan en mayor grado en los requerimientos de sistema
respecto a la configuración del hardware. Asimismo, el procedimiento de instalación es parte de la
prueba que se debe realizar.

c. Pruebas de conformidad
Se orientan a verificar el comportamiento del software respecto a las especificaciones realizadas
en la etapa de diseño, tomando como base los requerimientos funcionales y no funcionales del
sistema.

d. Pruebas de regresión
Estas pruebas son necesarias ante modificaciones o cambio en las especificaciones (funcionales y
no funcionales). Tienen por objeto demostrar que ante cambios, aun cuando el software haya sido
previamente probado, se debe volver a probar y su comportamiento debe mantenerse, salvo en
las modificaciones especificadas. Estas pruebas son aplicables en las pruebas unitarias, integrales o
de sistema

e. Pruebas de rendimiento
Prueba enfocada en los requerimientos de capacidad y tiempos de respuesta especificados en la
operación de las funciones del software. Por ejemplo, esta prueba se puede realizar con un
volumen alto en la carga de datos, para verificar el comportamiento del software.

f. Pruebas de configuración
Los usuarios del software usualmente tienen o utilizan configuraciones específicas. Por ejemplo,
roles especiales y accesos determinados. Entonces, estas pruebas se enfocan en verificar que las
configuraciones asignadas sean las correctas.

20
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 g. Pruebas de facilidad de uso
El enfoque de estas pruebas está dado en la facilidad de uso de las funciones del software que
utiliza el usuario, la documentación existente para guiarlo en la ejecución de sus tareas y, también,
la facilidad del software para superar errores provocados por el usuario.

3.2. TÉCNICAS DE PRUEBA Y SU APLICACIÓN

Las técnicas ayudan a ejecutar una prueba con el objeto de encontrar la mayor cantidad de
defectos en el software. Por una parte, recoge conjuntos representativos de datos, escenarios de
negocio, flujos de información y estados definidos dentro de la funcionalidad. Sobre la base de lo
anterior, se establecen caminos representativos diseñados a través de casos de pruebas y se
aplican en la funcionalidad de acuerdo a la técnica seleccionada. La selección de la técnica va a
depender de la necesidad, experiencia del profesional, especificaciones funcionales, el tipo de
aplicación y los errores o defectos que se requiere pesquisar.

Las técnicas de pruebas pueden ser clasificadas de dos formas: pruebas de caja blanca, en el caso
que se basen en el diseño del software, es decir, sabiendo cómo este fue desarrollado; o bien, caja
negra, donde solamente interesa saber el dato que entra y sale del sistema.

Las técnicas de prueba se pueden basar en lo siguiente (Pressman, óp. cit.):

3.2.1. EXPERIENCIA DEL INGENIERO DE SOFTWARE

a. Pruebas ad hoc
Comúnmente utilizada, surge de la experiencia e intuición del ingeniero de software, lo cual se ha
aprendiendo de la experiencia en otros proyectos similares. En este caso, se genera un grado de
sensibilidad en la prueba, el cual es beneficioso al momento de seleccionar casos de prueba que se
pueden aplicar en un ámbito determinado.

b. Pruebas por exploración

A diferencia de la prueba anterior, en este caso se va diseñando y ejecutando a la vez. Es un
aprendizaje que incorpora además las habilidades del ingeniero y también experiencias anteriores.
Este tipo de prueba es generado en forma dinámica, no hay una planificación específica. El éxito
dependerá del grado de asertividad del profesional y los conocimientos específicos que tenga en el
ámbito o escenarios donde se desarrolla.

3.2.2. ESPECIFICACIÓN

a. Análisis de valores límite

Los casos de prueba son seleccionados de acuerdo a valores límite definidos en la funcionalidad
del software. Es decir, para los valores permitidos en las variables de entrada se asignan valores

21
ESTE DOCUMENTO CONTIENE LA SEMANA 7
límite para validar la robustez ante datos que no corresponden al dominio de información del
sistema.

b. Tablas de decisión
Corresponden a relaciones lógicas entre datos y acciones dentro del sistema. Los casos de prueba
son generados a partir de las combinaciones que existen entre los datos y las acciones definidas
funcionalmente en el sistema.

c. Basadas en máquinas de estado finito1

Al modelar una aplicación como una máquina de estado finito, se pueden buscar casos de prueba
que cubran todos los estados definidos en el software y sus transiciones correspondientes. Por
ejemplo, podemos abordar de esta manera la implementación de un flujo de trabajo (workflow).

3.2.3. PROGRAMACIÓN DEL CÓDIGO

a. Flujo de control
Esta técnica de prueba busca explorar todos los flujos de control que la funcionalidad tiene
definidos como parte de la programación. Se puede señalar que la forma más representativa de
realizarlo es recorriendo todos los caminos que las condiciones y decisiones del código pueden
tomar en función de los datos de entrada/salida en el sistema. De igual forma se presentan
algunas restricciones, como por ejemplo abordar los bucles de código. Sin embargo, la prueba
cumple su objetivo cuando al ejecutarse abarca la totalidad de condiciones, al menos una vez.

b. Flujo de datos
Esta técnica de prueba se centra en los datos y el flujo que deben seguir de acuerdo a la lógica que
se ha programado. Las variables pasan a ser el objeto de revisión, respecto al valor del dato
asignado y cómo este varía en la medida que se ejecutan los distintos flujos del programa. Dada la
gran cantidad de variables y caminos lógicos que se pueden ejecutar, una estrategia es seleccionar
los datos más sensibles y los caminos (condiciones/decisiones) más críticos para el funcionamiento
de la aplicación.

3.2.4. ERRORES

a. Defectos, fallas o errores

Esta técnica de prueba se centra en establecer errores predefinidos en el sistema. Es decir, se
diseñan escenarios en los cuales se espera un error. El objeto es manejar una serie de errores
conocidos y ante los cuales el sistema informará, de acuerdo al contexto, el problema que ocurre y
cómo debe corregirse. Por ejemplo, si el usuario de una aplicación contable está tratando de
ingresar datos a una cuenta que no se encuentra habilitada, el sistema lo detectará y le informará

1
Correspondería a un flujo de proceso que tiene estados definidos, es decir, que presenta un inicio y un
final.

22
ESTE DOCUMENTO CONTIENE LA SEMANA 7
que para poder asignar un determinado valor debe configurar la cuenta a través del sistema.
Donde, además, el sistema requiera de un rol que permita realizar la habilitación. Esta técnica
también es útil en la depuración de las validaciones que debe realizar la funcionalidad.
b. Mutaciones (pruebas de acoplamiento)
Técnica basada en la generación de versiones distintas del software, donde se introducen
pequeñas modificaciones y a las cuales se les denomina mutantes. Los casos de prueba son
aplicados en la versión original y también en las versiones mutantes. Si el caso de prueba logra
establecer una diferencia entre ambas versiones, se entenderá que se ha identificado la versión
mutante. En estos casos, pequeñas modificaciones de sintaxis pueden dar cabida al
descubrimiento de problemas más complejos a nivel del software, por ejemplo acoplamiento de la
funcionalidad.

3.2.5. EN EL USO DE LA FUNCIONALIDAD

a. Perfil operativo
Una de las premisas en el ámbito de las pruebas es hacer que estas sean ejecutadas bajo
condiciones iguales o muy similares al entorno donde el software será puesto en operación. Esto
implica que a nivel de infraestructura, las condiciones deben ser recreadas en similitud al
ambiente productivo. Asimismo, la demanda de servicios o carga de trabajo del software también
debe estar en el mismo contexto que el esperado en el ambiente productivo. Por lo anterior se
puede inferir el grado de confiabilidad que se espera de la solución en el ambiente donde se
utilizará.

b. Confiabilidad
Estas pruebas buscan determinar el grado de confiabilidad de la solución, para lo cual están
basadas en los objetivos de confiabilidad que se han definido en los requerimientos (no
funcionales) del sistema y el uso esperado que este tendrá. Dado el escenario anterior, se busca
evaluar el grado de criticidad que presentarán las distintas componentes funcionales de la
solución.

3.2.6. NATURALEZA DE LA APLICACIÓN

Todas las técnicas de pruebas mencionadas anteriormente, en general, son aplicables a cualquier
tipo de software. No obstante, hay algunos casos en los cuales se requiere conocimientos
específicos en función de la naturaleza de las aplicaciones (Pressman, óp. cit.). Un ejemplo de lo
anterior, corresponde al siguiente tipo de aplicaciones:

 Pruebas de software orientado a objetos

 Pruebas basadas en componentes
 Pruebas para aplicaciones que se ejecutarán en internet
 Pruebas para validar interfaz de usuario (GUI)
 Pruebas de programas concurrentes

23
ESTE DOCUMENTO CONTIENE LA SEMANA 7
  Pruebas de protocolos de comunicación
 Pruebas para sistemas en tiempo real
 Pruebas para sistemas de seguridad

En cada caso, además de la naturaleza que se persigue con las pruebas de software, lo que se
pretende destacar es el hecho de existir una serie de características y condiciones particulares
dependiendo el tipo de aplicación que se requiere probar. En este sentido, se hace necesaria una
mirada especializada en cada tipo de aplicación. Lo ideal es que un ingeniero de software conozca
lo general y también lo particular. Entonces, al momento de planificar las pruebas también debe
considerarse este punto.

3.3. PLAN DE PRUEBAS

El plan de pruebas corresponde a la declaración de un conjunto de actividades en el marco de las

pruebas de software, en el cual se establecen los mecanismos que determinan el alcance,
actividades, responsables, criterios, plazos, excepciones y técnicas que dan forma al proceso de
prueba de una aplicación de software. Corresponde entonces a la instancia donde se define cómo
se realizarán las pruebas, los actores que participan, sus responsabilidades y los recursos que se
van a utilizar en un plazo determinado. Al definir el plan de pruebas, se entiende también que
todos los involucrados están de acuerdo en la forma y contenido, por ello es necesario que sea
formalizado dentro de la organización y de cara al cliente o usuario final.

La estructura de un plan de pruebas debe ser acordada y aprobada por los integrantes del equipo
de trabajo, como también por las partes interesadas como por ejemplo, el usuario final de la
solución. Lo anterior, dado que al momento de definir y ejecutar las pruebas se va a requerir la
participación de distintos actores, por lo cual deben estar debidamente coordinadas y planificadas
en una carta Gantt.

3.3.1. ESTRUCTURA DEL PLAN DE PRUEBAS

El plan de pruebas consolida la planificación requerida para el control y gestión del proceso de
pruebas, para ello se debe elaborar como parte de la documentación del proyecto. De esta forma,
a modo de orientación, se presenta a continuación un esquema de índice que debiera tener el
plan de pruebas.

Parte 1 1. Introducción  Se menciona la audiencia a la cual va

dirigido y se realiza una descripción
general del documento, comentando
cómo está estructurado e indicando muy
brevemente el contenido de cada punto
descrito.
2. Alcance  Se señala el o los tipos de prueba que se
realizarán, la funcionalidad que

24
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 corresponde probar, aspectos que se
requiera explicitar respecto a alguna
condición especial de las pruebas.
 Debe ser explicitado todo aquello que se
va a probar
o Aspectos funcionales
o Aspectos técnicos
o Aspectos de seguridad
o Otros
 De la misma forma, se debe declarar lo
que no formará parte de la pruebas.
3. Referencia de  Se indica la definición de requerimientos,
documentación especificaciones funcionales y técnicas de
la solución.
Parte 2 4. Estrategia  Se declaran los tipos de prueba que se
realizarán (unitarias, integrales, sistema,
etc.).
 Se definen los casos de prueba que se
desarrollarán y la técnica de prueba que
se utilizará.
 En esta definición, se establece el grado
de cobertura que habrá sobre cada
aspecto a probar (funcional, técnico u
otro). Es decir, se indicará que se
ejecutará una cantidad determinada de
casos de prueba para los aspectos
funcionales, otra para aspectos de
seguridad y, así, respondiendo a los
aspectos considerados en el alcance de la
prueba.
5. Ítems de prueba  Si bien en el punto donde se define el
alcance se indican, por ejemplo, aspectos
funcionales a probar, en este punto se
debe especificar cuál es la funcionalidad
que se probará. Se hace en forma
detallada.
6. Casos de prueba  Se definen los escenarios de prueba.
 Casos que abarcan la funcionalidad que
se probará.
Parte 3 7. Estado del plan  De acuerdo a los convenios que
determinen el plan de pruebas con los
actores involucrados, se deben

25
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 establecer parámetros que determinen el
estado del plan de pruebas. Esto es, bajo
qué condiciones el plan puede
suspenderse, repetirse, anularse, o bien
darse por finalizado.
 Es decir, se establecen criterios para dar
fluidez y continuidad a la ejecución del
plan de pruebas.
 Se podría acordar que el plan se define
como exitoso si en su ejecución se logra
abarcar el 80% de los casos de prueba.
 Otros factores que también inciden son el
costo y la duración.
8. Entregables  Corresponde a la definición de todos los
documentos que formarán parte de los
entregables asociados al plan de pruebas.
 Casos de prueba, registro de las pruebas,
informes de resultado.
9. Recursos necesarios  Se deben señalar las necesidades de
ambiente para ejecutar las pruebas.
 Disponibilidad de quienes realizarán las
pruebas.
 Habilitación del software, en una versión
específica para la ejecución de la prueba.
 Espacios físicos y otros aspectos
logísticos.
10. Calendarización de  Se debe señalar el plan de actividades y la
actividades programación de estas.
 Usualmente en formato Gantt.
11. Puntos de atención  Identificación de riesgos y la forma de
mitigarlos en el caso que se presenten.
12. Matriz de  Se explicitan las tareas principales y los
responsabilidades responsables de gestionarlas y
ejecutarlas.
13. Referencias  Antecedentes generales que ayuden a
buscar información referente a la
planificación del plan de pruebas.
Tabla 2: Estructura del plan de pruebas
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)

26
ESTE DOCUMENTO CONTIENE LA SEMANA 7
COMENTARIO FINAL

Cuando una organización adopta un conjunto de buenas prácticas orientadas a desarrollar

software de calidad fortaleciendo el proceso de pruebas los resultados en la solución final pueden
mejorar respecto a no innovar en estos aspectos. El desarrollo de software, como se ha indicado,
es una disciplina dentro de la ingeniería de software, por tanto debe ser realizada conforme a las
buenas prácticas. Estas muchas veces nacen de las mismas organizaciones, dado que la madurez
del proceso va definiendo la mejor forma de hacer las cosas. No obstante, existen estándares
reconocidos que ayudan a mejorar la forma como desarrollar el software y dar una estructura ad
hoc al procedimiento de pruebas. Ambas tareas son fundamentales para el desarrollo y entrega de
un software de calidad.

27
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 REFERENCIAS
Pantaleo, G. (2011). Calidad en el desarrollo de software. México: Alfaomega Grupo Editor.

Pressman, R. (2010). Ingeniería de software, un enfoque práctico. 7.ª edición. España: Editorial

McGraw-Hill Interamericana S. A.

Zahran, S. (1998). Software Process Improvement: Practical Guidelines for Business Success.

Gran Bretaña: Addison-Wesley.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2016). Calidad enfocada en el desarrollo de software. Modelos y Control de Calidad.

Semana 7.

28
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 29
ESTE DOCUMENTO CONTIENE LA SEMANA 7