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 disposicin del pblico 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 ESPECFICOS ........................................................................................................................... 5
INTRODUCCIN ...................................................................................................................................... 5
1. PRINCIPIOS FUNDAMENTALES DE LA CONSTRUCCIN DE SOFTWARE ..................................................... 6
1.1. MINIMIZAR COMPLEJIDAD ........................................................................................................... 8
1.2. ANTICIPAR CAMBIOS ................................................................................................................... 8
1.3. CONSTRUIR PARA VERIFICAR......................................................................................................... 9
1.4. UTILIZAR ESTNDARES ................................................................................................................. 9
2. MECANISMO DE CALIDAD EN EL DESARROLLO DE SOFTWARE.............................................................. 10
2.1. DISEO POR CONTRATO ............................................................................................................ 10
2.2. ANLISIS DE RENDIMIENTO......................................................................................................... 12
2.3. DEPURACIN............................................................................................................................ 12
3. INGENIERA DE TESTING ................................................................................................................. 14
3.1. FUNDAMENTOS DE PRUEBAS DE SOFTWARE ................................................................................ 15
3.1.1. TERMINOLOGA 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. TCNICAS DE PRUEBA Y SU APLICACIN........................................................................................ 21
3.2.1. EXPERIENCIA DEL INGENIERO DE SOFTWARE ................................................................................. 21
3.2.2. ESPECIFICACIN ........................................................................................................................ 21
3.2.3. PROGRAMACIN DEL CDIGO.................................................................................................... 22
3.2.4. ERRORES.................................................................................................................................. 22
3.2.5. EN EL USO DE LA FUNCIONALIDAD ............................................................................................... 23
3.2.6. NATURALEZA DE LA APLICACIN.................................................................................................. 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: Relacin de contratos entre componentes de software ..................................................... 11
Figura 3: Relacin de contrato entre dos componentes de software ................................................ 11
Figura 4: Ciclo de pruebas y depuracin. ........................................................................................... 13
Figura 5: El proceso de pruebas en el ciclo de vida del desarrollo..................................................... 15
Figura 6: Definicin 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 ESPECFICOS
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 bsicos de la ingeniera de testing
Aplicar los diferentes tipos de prueba existentes al desarrollo de software

INTRODUCCIN
El desarrollo de software de calidad demanda una serie de aspectos que incluyen una buena
definicin de requerimientos, y que posteriormente se traducen en un conjunto de
especificaciones funcionales y no funcionales de la solucin. Asimismo, quienes desarrollan el
software toman esta informacin como la entrada a su proceso de implementacin 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 fcil de usar, existen fundamentos para la programacin. As tambin, para
verificar que la solucin de software haga lo que tiene que hacer, pero adems para validar que el
software se desarrolle de acuerdo a normas o estndares acogidos por la organizacin. Estos
conceptos se desarrollarn 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 CONSTRUCCIN DE
SOFTWARE
La construccin de software (en adelante, desarrollo de software) es una de las principales
actividades que realiza la ingeniera de software. Esta ltima es la disciplina del rea informtica o
ciencias de la computacin, que define mtodos y tcnicas 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 definicin de desarrollo de software, corresponde a un proceso donde se

escriben lneas de cdigo en algn lenguaje determinado, posteriormente se verifica la adhesin a
normas y estndares, se somete a pruebas (unitarias e integracin), y finalmente se realizan
ajustes sobre la base de un proceso de depuracin, respecto a las definiciones funcionales dadas
en los requerimientos del usuario.

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

el conocimiento adquirido por los ingenieros a travs 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 generacin que hoy podemos encontrar en una
amplia diversidad de aplicaciones.

En la figura 1 se muestra una representacin genrica de un ciclo de desarrollo del software. En

primer lugar, se deben tener bien definidos los requerimientos funcionales que se necesita
implementar en la solucin, los cuales aparecen representados desde R1 a Rn. Estos
requerimientos deben ser modelados como parte de la solucin en la actividad de diseo.
Posteriormente, habindolo validado el usuario, se realiza el proceso de programacin, en el cual
se verifican los aspectos tcnicos y funcionales, como por ejemplo cumplir con la normas de
programacin que la organizacin defina, como tambin satisfacer las necesidades funcionales.
Dependiendo del modelo de desarrollo que se utilice, habr iteraciones que van de la mano del
diseo, programacin y pruebas. Una vez ejecutado en forma correcta el ciclo de desarrollo, con
todas las etapas realizadas exitosamente, se tendr una versin 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, adems se deben considerar funciones que pueden realizar
tambin los mismos miembros del equipo, o bien un grupo dedicado. Por ejemplo, el
aseguramiento de la calidad y administracin de la configuracin. En este ltimo caso,
corresponde al rea encargada de gestionar una cantidad considerable de productos de trabajo
del proyecto, tambin conocidos como entregables. En tal caso, la organizacin establece polticas
para la gestin de los entregables en cada proyecto, y un grupo a cargo de gestionarlos.

Algunos ejemplos de tems de configuracin o entregables son los siguientes:

Documentacin de las definciones del proyecto. En este caso corresponde mantener

actualizada y administrada toda la documentacin del proyecto que se quiera mantener.
Documentos de anlisis, documentos de diseo, especificaciones tcnicas 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 aplicacin, desarrollos de
bases de datos, archivos de configuracin, programas de procesamiento de datos,
configuraciones a nivel de sistemas y otros ms.

7
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Documentos de la gestin del proyecto. Planes de proyecto, cartas Gantt, minutas de
reuniones, informes de avance, control presupuestario, contratos de terceros,
presentaciones para el cliente, gestin de riesgos y otros ms.

Documentos de la gestin de pruebas. Plan de pruebas, scripts con casos de prueba,

registro de resultados, informes de gestin de pruebas.

Como se puede inferir, el desarrollo de software es una actividad elaborada, lejos de ser algo
simple. Requiere disciplina, mtodo, un modelo de gobierno que facilite la administracin y
gestin de todas las actividades que se deben desarrollar.

A continuacin, 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 ms diversas y tambin complejas. Los procesos de negocio requieren
un alto grado de implementacin de soluciones de software para apoyar la gestin y operacin, las
que de no ser automatizadas haran ms complejas las miles de casusticas de negocio que a diario
resuelven los sistemas. Asimismo, en el marco del desarrollo de software, tambin se requiere lo
mismo: minimizar complejidad. Imagine que en el mundo real modelamos una situacin en la que
es necesario crear una solucin de software para apoyar un proceso de negocio determinado.
Qu sentido tendra desarrollar algo tan complejo como el proceso en la vida real, o quizs, ms
complejo? Tendra algn xito nuestra solucin?

La necesidad de reducir complejidad se debe aplicar a toda actividad del desarrollo de software,
tomando mayor nfasis en el proceso de verificacin y pruebas. De esta forma, al escribir cdigo
se debe realizar en forma simple, ordenada, de acuerdo a una lgica previamente validada.
Siguiendo patrones de desarrollo que adopte la organizacin, respecto a estndares y modelos de
calidad.

1.2. ANTICIPAR CAMBIOS

En el proceso de desarrollo de software, adems de crear una solucin en respuesta a los
requerimientos del usuario, tambin se debe asegurar que ante factores de cambio externos a la
aplicacin, tendr la flexibilidad necesaria para introducir los cambios que requiera. Se debe
sealar que los factores de cambio obedecen a distintos mbitos. Por ejemplo, un sistema que se
utiliza en el mbito de la fiscala nacional deber adecuarse ante un cambio de las leyes y que esta,
a su vez, genere un cambio en la definicin de los requerimientos funcionales. As tambin es lo
que se vivi en el cambio de milenio; las organizaciones tuvieron que invertir mucho dinero en
adecuar sus aplicaciones para soportar cuatro dgitos en lugar de los dos que usualmente se

8
ESTE DOCUMENTO CONTIENE LA SEMANA 7
definan (ao 2000). Pero adems de este tipo de cambios tambin existen los cambios que se
realizan producto de la renovacin de plataformas e infraestructura computacional. En este caso,
las adecuaciones o adaptaciones que se requieren no estn dadas por temas funcionales, sino ms
bien tcnicos. Hay otros casos, sin embargo, en los que la idea es la misma, el desarrollo debe
incorporar estos criterios en el diseo y posteriormente en la implementacin 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 anticipacin a los cambios busca que desde el diseo 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 fcil de
depurar, analizar y corregir. Para realizar lo anterior, es necesario que el proceso de desarrollo de
software adhiera a mtodos estndar de programacin, 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 cdigo que sean
realizadas en forma peridica, desarrollo de pruebas unitarias (en el mbito de quien desarrolla el
software) y revisin entre pares.

1.4. UTILIZAR ESTNDARES

La estandarizacin, como concepto, busca conciliar e integrar las mejores prcticas del mbito en
el que se requiere realizar una actividad especfica. De esta manera, la estandarizacin promueve
directrices y definiciones que son reconocidas por todos los actores que necesitan utilizar el
estndar para desarrollar sus actividades. Podran enumerarse diversos estndares, sin embargo
es importante entender y conceptualizar su significado prctico en el desarrollo de software.
Revisemos algunas definiciones de estandarizacin aplicadas al desarrollo de software como
disciplina de la ingeniera de software.

Mtodos de comunicacin, donde se define el formato de los documentos que se utilizan para
dejar documentada una solucin. Por ejemplo, para elaborar el anlisis, el diseo de una solucin,
la especificacin tcnica, cartas Gantt para los proyectos, informes de gestin de los proyectos,
minutas de trabajo, entre otros.

Lenguajes de programacin, en este caso al utilizar un determinado lenguaje, lo recomendable es

incorporar en el proceso de programacin todas las convenciones orientadas a lograr una mejor
utilizacin de los recursos y tcnicas, para obtener un producto de calidad. Por ejemplo, el uso de
estructuras especiales, manejo de variables dentro del programa, comunicacin 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 travs del programa con el sistema operativo.

Herramientas para la diagramacin de documentos requeridos en el proceso de desarrollo. Por

ejemplo, adherir a la notacin de UML (lenguaje universal de modelado).

As como existen convenciones internacionales que definen estndares, las organizaciones

internamente tambin pueden definir sus propios estndares 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 programacin.

2. MECANISMO DE CALIDAD EN EL DESARROLLO DE SOFTWARE

2.1. DISEO POR CONTRATO

Corresponde a una forma de modelar el comportamiento entre componentes de software al
momento de disear o programar una solucin de software (Pressman, p. cit.). El concepto fue
introducido en 1992 por Bertrand Meyer, utilizando su lenguaje de programacin Eiffel.

El diseo por contrato en el desarrollo de software obedece a la aplicacin de los contratos que
conocemos en el mbito de las personas, en los cuales se establecen relaciones de obligacin y
beneficios entre las partes. Al desarrollar software, se establece el tipo de relacin entre distintos
componentes, en forma especfica y sin ambigedades. 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
ms objetivos. De esta manera, si se ampla esta definicin a una solucin de software, se puede
sealar que existen componentes de software interrelacionados entre s a travs de contratos
donde cada componente puede ser un emisor o receptor de mensajes los cuales estn definidos
como contratos que establecen obligaciones y beneficios, de acuerdo al tipo de relacin que se
defina entre los componentes.

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

En la figura 2, se presenta una relacin entre componentes de software, donde se ha establecido

la relacin que existe entre ellos. Se puede observar que la componente C1 se relaciona con la
componente C2, a travs de un mensaje tipo 1. Asimismo, los dems componentes establecen
relaciones entre ellas, de acuerdo al tipo de mensaje. En el caso de las componentes C2 y C4,
adems de recibir mensajes, tambin envan. Por tanto, al disear una solucin 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 hiciramos un zoom a la
relacin entre los componentes C4 y C5, veramos lo siguiente:

Figura 3: Relacin 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 enva el
resultado al componente C4, cumpliendo as con el contrato de comunicacin que el sistema ha
definido entre ambos.

2.2. ANLISIS DE RENDIMIENTO

El rendimiento en un sistema de software es un requerimiento que va ms all de la necesidad
funcional definida en los requerimientos de negocio o funcionales. Es necesario que la solucin
tenga un comportamiento slido 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
razn es necesario, como parte del desarrollo de una solucin, se realicen en forma permanente
pruebas y anlisis 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 solucin completa. En ambos casos, es
necesario realizar un anlisis de rendimiento.

2.3. DEPURACIN
La depuracin es el proceso que se desprende luego de realizar pruebas en la funcionalidad de una
solucin de software. Busca determinar las causas que generan un error a nivel de aplicacin, con
el objeto de establecer las correcciones que correspondan. Se inicia con la ejecucin de un caso de
prueba, del cual se evala 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 depuracin ayuda a encontrar una causa
que puede dar origen a la diferencia. De lo anterior, se puede identificar el error y el tipo de
correccin que se debe realizar. Cabe destacar que el proceso de depuracin 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 depuracin.

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

13
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 3. INGENIERA 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 travs de la
aplicacin de mtodos, procedimientos y ejecucin 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 tambin, la gestin de estas
actividades es apoyada por artefactos (documentos) y en algunos casos tambin por herramientas
que asisten el proceso de pruebas.

La prueba del software es, entonces, una de las actividades que ayudan a validar las caractersticas
del software y, en particular, la correcta implementacin 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 funcin de los errores
que se puedan encontrar, aplicndolo tanto en el mbito funcional, como tambin en aquellas
necesidades no funcionales de la solucin.

A travs de las pruebas de software se puede establecer tambin el nivel de seguridad que ofrece
el producto desarrollado. No es lo mismo una solucin 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
planificacin, mejora los indicadores de calidad y rentabilidad al producir software y, finalmente,
ayuda a controlar los costos por concepto de mantenimiento posterior.

A continuacin, se presenta con ms 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 sealado, las pruebas de software ayudan a verificar la calidad de un producto de
software, en forma previa a la entrega de la solucin 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 tcnicas especializadas orientadas a detectar errores en el software (Pressman, p. cit.). En
la figura 5, se muestra cmo las actividades de prueba deben ir siendo definidas, diseadas,
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 tambin
saber cmo 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
caractersticas tcnicas 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. TERMINOLOGA RELACIONADA CON LAS PRUEBAS
a. Distincin 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 sntoma cuyo origen obedece a un error. Y es este ltimo el que se
debe corregir. Las pruebas debern cumplir ese objetivo, encontrar errores.

b. Validacin
Establecer objetivamente a travs 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. Verificacin
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 verificacin 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 ejecucin y resultados esperados, el cual es

diseado para lograr un objetivo especfico o condicin de prueba. Un caso de pruebas se puede
identificar como la unidad bsica en un escenario de pruebas, donde se definen condiciones
especficas. 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 creacin de caso de prueba corresponden a los siguientes (Pressman, p.
cit.):

16
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 a. Definicin de escenarios

Para una determinada funcionalidad del software, se establecen las distintas casusticas de
acuerdo a las definiciones dadas en las especificaciones funcionales. Por ejemplo, grficamente se
puede representar de la siguiente forma en la figura 6.

Figura 6: Definicin de escenarios

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

De acuerdo a la lgica que representa este flujo de estructura de control, los eventuales caminos
de ejecucin son:

Escenario Secuencia de eventos del sistema

Camino 1 1 -2 4 -6

Camino 2 1247

Camino 3 135

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 vlidos, invlidos, o bien aquellos que no
aplican a la condicin 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 aplicacin bancaria donde el usuario
debe ingresar su clave para seleccionar la operacin que requiera realizar. En este caso, opera la
tarjeta de crdito y solamente el camino 2 representa una secuencia exitosa para la prueba de
operacin sobre la tarjeta. Los otros casos presentarn problemas de clave y vigencia.

3.1.3. ELEMENTOS CLAVE

a. Criterios de seleccin de pruebas

Al disear las pruebas, es necesario establecer cules sern 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 aplicacin prctica 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 nmero de
cliente existente en un sistema, al ingresarlo en una consulta, el resultado esperado son los datos
del cliente. Caso contrario, al ingresar un nmero de cliente invlido, entonces el sistema debiera
arrojar un mensaje indicndolo.

b. Efectividad de las pruebas

La efectividad se mide en funcin del objetivo que se requiere medir. Por tanto, al disear 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 tcnicas y tericas

Como estrategia de prueba, es necesario establecer escenarios finitos y orientados a mitigar los
riesgos que eventualmente podran 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. Relacin 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 adems de atender los aspectos funcionales tambin debe abordar otros aspectos, tales
como seguridad, validez y verificacin, depuracin, programacin de componentes y la
certificacin 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 ms piezas o componentes del
software. La prueba se realiza monitoreando el cdigo fuente, lo cual se apoya con el uso de
herramientas del entorno de desarrollo que permiten visualizar la ejecucin en cada lnea de
cdigo. Esta actividad es propia del equipo de desarrollo, no del usuario final.

b. Pruebas de integracin
Permite verificar la interaccin 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 abstraccin ms cercano al negocio, en lugar de una revisin netamente tcnica. Lo que
se debe evitar es abordar las pruebas de integracin, 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 solucin.

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 integracin), se
haya detectado gran parte de las fallas y errores funcionales. Y es esperable tambin 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 disear 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 aceptacin
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 instalacin
Realizadas las pruebas de aceptacin, 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 configuracin del hardware. Asimismo, el procedimiento de instalacin 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 diseo, tomando como base los requerimientos funcionales y no funcionales del
sistema.

d. Pruebas de regresin
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
operacin 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 configuracin
Los usuarios del software usualmente tienen o utilizan configuraciones especficas. 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 documentacin existente para guiarlo en la ejecucin de sus tareas y, tambin,
la facilidad del software para superar errores provocados por el usuario.

3.2. TCNICAS DE PRUEBA Y SU APLICACIN

Las tcnicas 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 informacin y estados definidos dentro de la funcionalidad. Sobre la base de lo
anterior, se establecen caminos representativos diseados a travs de casos de pruebas y se
aplican en la funcionalidad de acuerdo a la tcnica seleccionada. La seleccin de la tcnica va a
depender de la necesidad, experiencia del profesional, especificaciones funcionales, el tipo de
aplicacin y los errores o defectos que se requiere pesquisar.

Las tcnicas de pruebas pueden ser clasificadas de dos formas: pruebas de caja blanca, en el caso
que se basen en el diseo del software, es decir, sabiendo cmo este fue desarrollado; o bien, caja
negra, donde solamente interesa saber el dato que entra y sale del sistema.

Las tcnicas de prueba se pueden basar en lo siguiente (Pressman, p. cit.):

3.2.1. EXPERIENCIA DEL INGENIERO DE SOFTWARE

a. Pruebas ad hoc
Comnmente utilizada, surge de la experiencia e intuicin 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 exploracin

A diferencia de la prueba anterior, en este caso se va diseando y ejecutando a la vez. Es un
aprendizaje que incorpora adems las habilidades del ingeniero y tambin experiencias anteriores.
Este tipo de prueba es generado en forma dinmica, no hay una planificacin especfica. El xito
depender del grado de asertividad del profesional y los conocimientos especficos que tenga en el
mbito o escenarios donde se desarrolla.

3.2.2. ESPECIFICACIN

a. Anlisis de valores lmite

Los casos de prueba son seleccionados de acuerdo a valores lmite 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
lmite para validar la robustez ante datos que no corresponden al dominio de informacin del
sistema.

b. Tablas de decisin
Corresponden a relaciones lgicas 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 mquinas de estado finito1

Al modelar una aplicacin como una mquina 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 implementacin de un flujo de trabajo (workflow).

3.2.3. PROGRAMACIN DEL CDIGO

a. Flujo de control
Esta tcnica de prueba busca explorar todos los flujos de control que la funcionalidad tiene
definidos como parte de la programacin. Se puede sealar que la forma ms representativa de
realizarlo es recorriendo todos los caminos que las condiciones y decisiones del cdigo pueden
tomar en funcin de los datos de entrada/salida en el sistema. De igual forma se presentan
algunas restricciones, como por ejemplo abordar los bucles de cdigo. Sin embargo, la prueba
cumple su objetivo cuando al ejecutarse abarca la totalidad de condiciones, al menos una vez.

b. Flujo de datos
Esta tcnica de prueba se centra en los datos y el flujo que deben seguir de acuerdo a la lgica que
se ha programado. Las variables pasan a ser el objeto de revisin, respecto al valor del dato
asignado y cmo este vara en la medida que se ejecutan los distintos flujos del programa. Dada la
gran cantidad de variables y caminos lgicos que se pueden ejecutar, una estrategia es seleccionar
los datos ms sensibles y los caminos (condiciones/decisiones) ms crticos para el funcionamiento
de la aplicacin.

3.2.4. ERRORES

a. Defectos, fallas o errores

Esta tcnica de prueba se centra en establecer errores predefinidos en el sistema. Es decir, se
disean 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
cmo debe corregirse. Por ejemplo, si el usuario de una aplicacin contable est tratando de
ingresar datos a una cuenta que no se encuentra habilitada, el sistema lo detectar y le informar

1
Correspondera 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 travs del sistema.
Donde, adems, el sistema requiera de un rol que permita realizar la habilitacin. Esta tcnica
tambin es til en la depuracin de las validaciones que debe realizar la funcionalidad.
b. Mutaciones (pruebas de acoplamiento)
Tcnica basada en la generacin de versiones distintas del software, donde se introducen
pequeas modificaciones y a las cuales se les denomina mutantes. Los casos de prueba son
aplicados en la versin original y tambin en las versiones mutantes. Si el caso de prueba logra
establecer una diferencia entre ambas versiones, se entender que se ha identificado la versin
mutante. En estos casos, pequeas modificaciones de sintaxis pueden dar cabida al
descubrimiento de problemas ms 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 operacin. 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 tambin
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 solucin en el ambiente donde se
utilizar.

b. Confiabilidad
Estas pruebas buscan determinar el grado de confiabilidad de la solucin, para lo cual estn
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 presentarn las distintas componentes funcionales de la
solucin.

3.2.6. NATURALEZA DE LA APLICACIN

Todas las tcnicas de pruebas mencionadas anteriormente, en general, son aplicables a cualquier
tipo de software. No obstante, hay algunos casos en los cuales se requiere conocimientos
especficos en funcin 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 ejecutarn en internet
Pruebas para validar interfaz de usuario (GUI)
Pruebas de programas concurrentes

23
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 Pruebas de protocolos de comunicacin
Pruebas para sistemas en tiempo real
Pruebas para sistemas de seguridad

En cada caso, adems de la naturaleza que se persigue con las pruebas de software, lo que se
pretende destacar es el hecho de existir una serie de caractersticas y condiciones particulares
dependiendo el tipo de aplicacin que se requiere probar. En este sentido, se hace necesaria una
mirada especializada en cada tipo de aplicacin. Lo ideal es que un ingeniero de software conozca
lo general y tambin lo particular. Entonces, al momento de planificar las pruebas tambin debe
considerarse este punto.

3.3. PLAN DE PRUEBAS

El plan de pruebas corresponde a la declaracin 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 tcnicas que dan forma al proceso de
prueba de una aplicacin de software. Corresponde entonces a la instancia donde se define cmo
se realizarn 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 tambin que
todos los involucrados estn de acuerdo en la forma y contenido, por ello es necesario que sea
formalizado dentro de la organizacin 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 tambin por las partes interesadas como por ejemplo, el usuario final de la
solucin. Lo anterior, dado que al momento de definir y ejecutar las pruebas se va a requerir la
participacin 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 planificacin requerida para el control y gestin del proceso de
pruebas, para ello se debe elaborar como parte de la documentacin del proyecto. De esta forma,
a modo de orientacin, se presenta a continuacin un esquema de ndice que debiera tener el
plan de pruebas.

Parte 1 1. Introduccin Se menciona la audiencia a la cual va

dirigido y se realiza una descripcin
general del documento, comentando
cmo est estructurado e indicando muy
brevemente el contenido de cada punto
descrito.
2. Alcance Se seala el o los tipos de prueba que se
realizarn, la funcionalidad que

24
ESTE DOCUMENTO CONTIENE LA SEMANA 7
 corresponde probar, aspectos que se
requiera explicitar respecto a alguna
condicin especial de las pruebas.
Debe ser explicitado todo aquello que se
va a probar
o Aspectos funcionales
o Aspectos tcnicos
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 definicin de requerimientos,
documentacin especificaciones funcionales y tcnicas de
la solucin.
Parte 2 4. Estrategia Se declaran los tipos de prueba que se
realizarn (unitarias, integrales, sistema,
etc.).
Se definen los casos de prueba que se
desarrollarn y la tcnica de prueba que
se utilizar.
En esta definicin, se establece el grado
de cobertura que habr sobre cada
aspecto a probar (funcional, tcnico 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 cul 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 parmetros 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 ejecucin del
plan de pruebas.
Se podra acordar que el plan se define
como exitoso si en su ejecucin se logra
abarcar el 80% de los casos de prueba.
Otros factores que tambin inciden son el
costo y la duracin.
8. Entregables Corresponde a la definicin de todos los
documentos que formarn parte de los
entregables asociados al plan de pruebas.
Casos de prueba, registro de las pruebas,
informes de resultado.
9. Recursos necesarios Se deben sealar las necesidades de
ambiente para ejecutar las pruebas.
Disponibilidad de quienes realizarn las
pruebas.
Habilitacin del software, en una versin
especfica para la ejecucin de la prueba.
Espacios fsicos y otros aspectos
logsticos.
10. Calendarizacin de Se debe sealar el plan de actividades y la
actividades programacin de estas.
Usualmente en formato Gantt.
11. Puntos de atencin Identificacin 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 informacin referente a la
planificacin 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 organizacin adopta un conjunto de buenas prcticas orientadas a desarrollar

software de calidad fortaleciendo el proceso de pruebas los resultados en la solucin final pueden
mejorar respecto a no innovar en estos aspectos. El desarrollo de software, como se ha indicado,
es una disciplina dentro de la ingeniera de software, por tanto debe ser realizada conforme a las
buenas prcticas. 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 estndares
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. Mxico: Alfaomega Grupo Editor.

Pressman, R. (2010). Ingeniera de software, un enfoque prctico. 7. edicin. Espaa: Editorial

McGraw-Hill Interamericana S. A.

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

Gran Bretaa: 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