1

2
3
4
5
- Es técnica ya que se apoya en un proceso sistemático y obedece a métodos diversos para ser tanto obtenida como realizada.
- Es un set ya que los requerimientos pueden ser cubiertos por un conjunto de pruebas (TC´s) los cuales pueden determinar que el
componente o proceso bajo observación cumple los requerimientos.

Podemos recurrir a la clásica explicación informal de Boehm de estos conceptos:

Verificación: ¿estamos construyendo correctamente el producto?
Validación: ¿estamos construyendo el producto correcto?

-Actividad estática: Comprende métodos los cuales NO ejecutan el componente o sistema bajo pruebas, estas pruebas incluyen:
-Revisiones: Las cuales son actividades manuales, definidas de la manera más formal posible en los proyectos (Ej:
Walkthrough, Peer reviews).
-Análisis Estático: Las cuales hacen uso de herramientas (Ej: compiladores.)
-Basándose en modelos metodológicos (V ó ETM) de pruebas estas actividades se pueden realizar de manera que cada nivel de prueba
definido en un proyecto las tenga.
-Esto básicamente es un objetivo de las pruebas, adicional a este las pruebas permiten obtener información de riesgos, generar confianza
y aumentar la calidad del producto software.

- Pruebas vs Depuración … No son los mismo ya que:

-Pruebas permite como tal encontrar defectos y es una actividad meramente realizada por un equipo de pruebas.
-La depuración permite encontrar las causas de las defectos y es una actividad realizada por un equipo de desarrollo. Es
la localización y corrección de defectos.
- “Testing” <> “Debugging”:
Testing: muestra los fallos
Debugging: identifica la causa del defecto, repara el código y evalúa que el defecto fue resuelto.

6
 23 May 20

Básicamente estos 3 podrían ocurrir en diferentes espacios de tiempo, y con responsables diferentes:

El error podría producirse en fases iniciales p.e. como en la definición de los Requerimientos o en la construcción de un
componente en una aplicación.
El defecto ocurre cuando ese error ha sido descubierto muy posiblemente por el mismo desarrollador al realizar la
depuración de su código o por el mismo BA al momento realizar un proceso de revisión.
La falla se encuentra cuando el sistema se ha ejecutado por una persona que valida o verifica el componente o
requerimiento (Grupo de pruebas).
23 May 20
 23 May 20

Principio 1: La prueba puede mostrar que los defectos están presentes, pero no pueden probar que no existen defectos.
La prueba reduce la probabilidad de existencia de defectos no descubiertos pero, incluso cuando los defectos no son
encontrados, eso no demuestra su ausencia.
Principio 2: Probar todo (todas las combinaciones de entrada y precondiciones) no es factible excepto para casos triviales.
En lugar de test exhaustivos, utilizamos riesgos y prioridades para enfocar los esfuerzos del test.
Principio 3: Las actividades de test deben comenzar tan pronto como sea posible en el ciclo de vida del desarrollo del
software o sistema y deben ser enfocados sobre objetivos definidos, esto hace que la calidad sea algo que hace parte del
software y no algo adicional que viene en una fase posterior (como sucede en el modelo waterfall). Adicional mencionar el
factor costo que se reduce al momento de encontrar los defectos en fases tempranas de los proyectos.
Principio 4: Un número pequeño de módulos contienen la mayoría de los defectos descubiertos durante la prueba, o
muestran la mayoría de los fallos operacionales.
Principio 5: Si el mismo test se repite una y otra vez, eventualmente el mismo grupo de casos de test ya no encontrará
nuevos errores. Para vencer esta “paradoja del pesticida”, los casos de prueba necesitan ser regularmente revisados y
estudiados, y se necesitan escribir nuevos casos de prueba para ejercitar diferentes partes del software o sistema para
encontrar más defectos potenciales. (en este caso la automatización de pruebas puede resultar benéfica para el caso de
repetir pruebas al momento de haber modificaciones en el software bajo pruebas)
Principio 6: La prueba se realiza de manera diferente en diferentes contextos, ej: (No es lo mismo hacer pruebas para
proceso batch que para un portal web). Depende de la prioridad, importancia y riesgo que tenga para el negocio.
Principio 7: Encontrar y solventar defectos no ayuda si el sistema construido está inutilizado y no satisface las necesidades
y expectativas de los usuarios.
 23 May 20

Planeación de pruebas:
Verificación de la misión de pruebas.
Definición de objetivos de pruebas.
Especificación de las actividades de prueba según los objetivos y misión del proyecto.
Análisis y diseño: Los objetivos generales de las pruebas son transformados en condiciones tangibles y se diseñan las
pruebas.
Implementación y ejecución: Las condiciones de las pruebas son transformadas en casos de prueba y testware y el
ambiente se establece.
Evaluación y reporteo: Los criterios de aceptación deben ser evaluados contra los objetivos finales.
Closedown: Se recolecta la información de las pruebas completadas para consolidar experiencia (testware, hechos y
números).
Control de pruebas:
Se comprara el progreso actual contra el plan.
Reporte de status, incluyendo las desviaciones.
El monitoreo debe ser realizado a través de todo el proyecto.
 23 May 20

Tomando que en el día son 7,5 horas efectivas.

En la semana se trabaja 5 días a la semana.
 23 May 20

Criterios para definir cuantas pruebas son necesarias son los riesgos asociados, el presupuesto y el tiempo asignado a
pruebas.

Los riesgos deben ser identificados para aportar elementos que permitan la priorización de las pruebas e identificar en
dónde debemos enfatizar el esfuerzo de las pruebas. Recordemos que las pruebas exhaustivas son ineficientes y
consumen tiempo y recursos que podrían ser usados de manera mucho más eficiente.

Tener presente qué sistemas o procesos con altos riesgos identificados requieren más esfuerzo de pruebas (a nivel de
casos de pruebas y énfasis) para ser validados y verificados, por el contrario lo contrario.
 23 May 20

Hacer énfasis en que los Riesgos ayudan a priorizar los

esfuerzos de pruebas dando la importancia debida a los
objetos bajo pruebas debidos, obedeciendo a un contexto.

Sin embargo se presenta la pregunta entonces CÓMO

PRIORIZAR basados en el riesgo….?...Lanzar pregunta
al auditorio….
23 May 20
 23 May 20

– Es importante que cada actividad de pruebas se vea enmarcada en estos criterios de salida.
– Los criterios de salida son un elemento necesario para definir finalizaciones de tareas y en un contexto de pruebas, fases
y niveles de pruebas, con ellos podemos nosotros certificar que una actividad ha terminado completamente, es necesario
tener presente que estos Criterios deben cumplirse completamente para asegurar en todo momento los objetivos de las
pruebas.

Ejemplos de Criterios pueden ser:

– Se define un umbral de 10% o menos de defectos en el nivel de sistema de tipo Menor para iniciar las pruebas de
Aceptación de Usuario.
– El 100% de los casos de prueba en el alcance han sido ejecutados por lo menos una vez.
– Las firmas de aceptación se han obtenido de acuerdo a lo requerido.
– La evidencia de pruebas se ha generado de acuerdo al proceso de pruebas.
 23 May 20

Los test basis son los elementos con los que

prácticamente se generarán los artefactos con los cuales
pruebas realizará todas sus actividades de pruebas. De
la calidad con los que estos esten generados dependerán
nuestros artefactos, es por ello que desde el inicio del
SLC las actividades de pruebas deben ser incluidas.
 23 May 20

Nos definen prácticamente qué aspectos del objeto bajo

pruebas serán evaluados en las diferentes actividades de
pruebas definidas, en cierto modo nos definen un alcance
de pruebas para el objeto bajo pruebas, así las cosas los
test conditions nos dictan el propósito final de que debe
ser probado.
23 May 20
 23 May 20

Los conjuntos de valores de entrada podrían entenderse como los datos de prueba necesarios para poder realizar la
ejecución del TC.

Las precondiciones de ejecución nos indican específicamente en q estado o evento previo debe estar el sistema para
poder ejecutar el TC. Es muy general que en set de pruebas definidos se presente que existan CP que deben ser
ejecutados antes que otros la razón, es por q muchas veces un CP ejecutado previamente puede ser el evento o el estado
previo que requiera otro CP más adelante para poder ejecutarse.

Los resultados esperados nos definen respuestas específicas a estímulos específicos realizados sobre el objeto bajo
pruebas.

Las pos-condiciones de ejecución presentan y describen el estado o evento final q debe darse luego de la realizar la
prueba usando el TC. Deben ser definidos específicamente para cada CP.

Los Casos de Prueba deben ser generados respetando el principio de atomicidad, el cual en el contexto de las pruebas
debe validar o verificar un objetivo particular, al respetarse este principio se obtienen pruebas mucho más efectivas ya que
la probabilidad de generar pruebas ineficientes se reduce sustancialmente.

Adicionalmente los elementos mencionados anteriormente deben poder ser obtenidos de los Test basis ya que deben ser
definidos en el CP mucho antes de ser usados para las pruebas (ejecución).
 23 May 20

ISTQB menciona que un CP debe tener:

Un conjunto de valores de entrada
Precondiciones de ejecución
Resultados esperados y/o condiciones post-ejecución.

Según la IEEE 829 un TC debe tener:

Valores de entrada
Precondiciones.
Resultados esperados.
Poscondiciones.
Dependencias.
Identificador distinguigle.
Requisitos (Carácterísticas puntuales del objeto de prueba que el CP debe evaluar, de donde se obtuvo el CP (Test
condition)).
 23 May 20

Preciso: Muestra QUÉ se supone probar.

Efectivo: Encuentra Defectos.
Trazable: Para un Requerimiento.
Evolutivo: Fácil de Mantener
Eficiente: Sin pasos Innecesarios
Estado Inicial: Retorna el ambiente de pruebas al estado Inicial
 23 May 20

El Test procedure es la herramienta que permita saber el COMO podemos realizar una prueba específica para un TC, en un
Test Procedure los pasos descritos deben ser secuenciales, sin saltos y cada uno de ellos debe tener asociado una
respuesta previamente configurada del objeto bajo pruebas, que llevandolo a un contexto de componentes del CP serían los
resultados esperados.

El ser automáticos se refiere al uso de una herramienta la cual permitirá la grabación y ejecución de la prueba de manera
que el tiempo de ejecución de la misma sea mucho menor. Mencionar la importancia que tienen estos scripts en las pruebas
de regresión (pruebas realizadas a una aplicación la cual previamente fue probada y en la cual se han presentado cambios
o adicional a la funcionalidad.)

Los Test scripts deben ser escritos “anti bobos”, es decir cualquier persona debe ser capaz de poderlos ejecutar y seguir, es
importante tener en cuenta que en el diseño de los scripts se tenga en cuenta mencionar que data es requerida (esto es un
Best Practice que hace el CP más robusto).
 23 May 20

Para estos Test Data, el uso de plantillas que permitan tener un registro de la data que será usada para las pruebas es
clave, adicionalmente la data y los CP deben estar relacionados es decir tener una fuerte trazabilidad, ya que cada CP
deberia usar un set de datos de prueba único.

Es importante que se dispongan de procedimientos y procesos (Nivel de Configuration Management) que permitan
administrar la data de pruebas de manera que al momento de requerir de nuevo una ejecución de un TC ya ejecutado se
disponga de la data requerida para q el CP se pueda ejecutar. (Esto es importante mencionarlo en los Criterios de Entrada
definidos en un plan de pruebas).

Aquí es importante que las áreas del negocio apoyen el proceso de levantamiento de la data a ser usada en la pruebas ya
que esta data debe ser lo más próxima posible a la realidad del negocio.

Como viene lo de la calidad, les pregunto que piensan que es la calidad….

 23 May 20

Concepto IEEE 610: un sistema poseerá más calidad en tanto se consiga un porcentaje alto de cumplimiento de los
requisitos acordados, adicionalmente el grado de satisfacción y superación de expectativas debe ser del mismo modo.

Concepto ISO 9126: La calidad se define en el sentido del cumplimiento de la totalidad de las funciones y características
solicitadas por un usuario a través de unos requisitos definidos. Aquí las características implícitas del sistema deben ser
cumplidas, es decir tanto funcionalidad como características de alto desempeño del sistema deben ser evaluadas y
generarán más satisfacción con el usuario.

El proceso de pruebas debe ser uno de los caminos para obtener calidad, en este sentido no se puede introducir calidad
únicamente solo a través de las pruebas, la calidad debe incluirse desde el inicio del SLC, incluyendo a todos los
stakeholders y sus entregables los cuales harán parte de la construcción de un sistema.
Las pruebas son una comparación de unos requisitos definidos contra un producto realizado basado en esos requisitos.
Como lo dice el principio 1 de las pruebas la detección de defectos es uno de los objetivos de las pruebas por ello las
pruebas deben encontrar de manera eficiente la mayor cantidad de defectos posibles incluyendo los defectos mayores o
con más nivel de riesgo sin ser exhaustivos como lo dice el principio 2.

Con respecto a las actividades que mencionan allí como Estáticas, estas son aquellas en las que las verificaciones son
realizadas sin ejecutar el objeto bajo pruebas.
 23 May 20

El testing es igual a una comparación en la cual se toman unas necesidades plasmadas en requisitos por parte de una
persona (cliente) luego de realizar procesos de análisis se determina si lo que se hizo para plasmar esos requisitos (la
solución) es igual a lo requerido (necesidades) del usuario.

Mencionar lo de los dos caminos…

Aunque el resultado sea tener una casa mas grande o mas bonita, esto no fue lo que se pidió…es decir la necesidad
plasmada muy probablemente no se solventó con la solución. (por ello debemos basar nuestras pruebas en lo solicitado
por el cliente Requirements Based Testing).
 23 May 20

La calidad no es intangible.
El propósito de las pruebas es hacer visible la calidad.
La prueba es la medición de la calidad del software
Bill Hetzel 1988

¿Por qué es necesario el Testing?

Uso de sistemas como parte de la vida diaria:
Uso desde aplicaciones de negocio (bancarias) hasta productos de consumidores (carros).
Mejora el costo del proyecto
Es necesario incluir tiempo para la planeación del testing
Apoya la correcta definición de requerimientos y diseño en etapa temprana.
Hace posible medir la calidad del software en términos de defectos encontrados.
Forza a que se enfrenten y encaren los problemas tan rápido a como ocurran.
Menor costo de retrabajo.
Testing pobre causa fallos críticos
Impacta el rendimiento y confiabilidad de la operación.
Puede duplicar o triplicar costos de soporte y mantenimiento.

“Para realizar testing es necesario conocer los requerimientos legales y contractuales y el estándar de la industria
específica”
27
28
 23 May 20

Diseñado por Richard Bender…

El modelo V de Pruebas soporta los principios de pruebas, y también es lo suficientemente flexible para adaptarse a un
proceso Iterativo e incremental del desarrollo de Software, El modelo V presenta las relaciones internas entre:

tipos de pruebas de la aplicación y otras fases del proyecto.

Las actividades de pruebas de cada nivel desde el inicio del proceso de Vida del software.

Entregables de pruebas y otros entregables del proyecto.

Actividades de Pruebas estáticas y Pruebas dinámicas.

Adicionalmente el modelo tiene un enfoque sistemático para:

Verificar requerimientos como entradas a Diseño, codificación y pruebas.

Establecer seguimiento a los requerimientos.

Validar la conformidad del sistema con los requerimientos.

El modelo V es una vista en dos dimensiones y es usado para identificar los diferentes niveles de pruebas que podrían ser
usados en cualquier proyecto. A la izquierda del modelo se presenta el típico modelo en cascada del desarrollo de software
(análisis, desarrollo, pruebas y puesta en marcha). A la derecha del modelo podemos ver los niveles de pruebas asociados
y apropiados para eliminar la mayor cantidad de problemas encontrados en los entregables obtenidos a la Izq del modelo..

Las actividades de planeación e inicio (desarrollo de los CP) de las pruebas comenzarán desde el inicio del modelo y de los
proyectos (con respecto a la calidad esto hace que las pruebas como complemento de esta sean involucradas en fases
tempranas en aras de reducir los riesgos).
En general, hay 4 niveles de las pruebas, aunque esto varía de proyecto a proyecto.
Las pruebas unitarias son el nivel apropiado para verificar que cada Unidad o componente desarrollado individualmente
cumple el diseño técnico detallado.
El nivel de pruebas de integración de componentes verifica que los componentes ahora integrados funcionen de
acuerdo al Documento de Diseño de Arquitectura.
Las pruebas de sistema como nivel verifican que el sistema cumpla apropiadamete los requerimientos funcionales
definidos para el proyecto.
Finalmente las pruebas de Aceptación validan que se cumplan apropiadamente los requerimientos definidos por el
usuario.
El modelo presenta una correspondencia uno a uno entre las fases del modelo Cascada de desarrollo y los
niveles de pruebas, los cuales pueden validar mas de una fase de desarrollo.
El modelo tiene presenta adicionalmente actividades a nivel de controles de liberaciones realizadas por
áreas como Configuration Management las cuales apoyan actualizando los versiones en los ambientes
requeridos sean estos de Pruebas o de UAT. En este mismo nivel se menciona la necesidad de tener un
ambiente controlado el cual debe permitir la ejecución de las pruebas y encontrarse actualizado.
Verificación: Comprobación de la conformidad con los requisitos establecidos (definición según
ISO 9000).
Cuestión clave: ¿se ha procedido correctamente en la construcción del sistema? (Las técnicas,
procesos y procedimientos usados para construir el sistema son los más idoneos)
Validación: Comprobación de la idoneidad para el uso esperado (definición según ISO 9000).
Cuestión clave: ¿Hemos construido el sistema software correcto? (Hicimos lo que nos pidieron, se
suplen las necesidades solicitadas).

29
 23 May 20

Las pruebas tempranas ayudan a reducir costos dado

que los defectos descubiertos en fases tempranas del
proceso software son corregidas con menor esfuerzo.

Built in and not added on significa que no se puede

introducir calidad con las pruebas, o a través de las
pruebas, la calidad como tal tiene que construirse desde
el inicio del proyecto.
23 May 20
23 May 20
23 May 20
23 May 20
23 May 20
36
37
38
39
40
23 May 20
 23 May 20

En este punto son muy importantes las lecciones

aprendidas de proyectos previos. Tener un mecanismo de
gestión de ese conocimiento. Todo el trabajo de ISO en
cuanto a estandarización de procesos y mecanismos de
control apoya la calidad de forma constructiva.
23 May 20
23 May 20
23 May 20
 23 May 20

El análisis estático de un programa, mediante el uso de

herramientas, se desarrolla con un esfuerzo menor que el
necesario en una inspección, por lo tanto, con mucha
frecuencia, el análisis estático se ejecuta antes que tenga
lugar una inspección.
23 May 20
23 May 20
23 May 20
 23 May 20

Las pruebas funcionales se pueden llevar a cabo en todos los niveles de prueba.
Las pruebas no funcionales se pueden llevar a cabo en todos los niveles.
Las pruebas estructurales se realizan de forma conjunta a las pruebas de componente y de integración mediante el uso de
herramientas.
El diseño de pruebas estructurales se finaliza tras haber sido diseñados las pruebas funcionales, con el
propósito de obtener un alto grado de cobertura
Las pruebas de confirmación/regresión pueden ser realizadas en todos los niveles.
Las pruebas típicas tras una modificación son las de confirmación y de regresión:
Las de regresión:
Es la prueba repetida de un programa ya probado, después de alguna modificación, para descubrir cualquier
defecto introducido como resultado de los cambios.
La importancia de la prueba de regresión se basa en el riesgo de no encontrar defectos en el software con el
que se trabaja previamente.
Son un fuerte candidato para la automatización.
23 May 20
 23 May 20

Al reemplazar “drivers” y “stubs” de prueba por

componentes reales se pueden generar nuevos
defectos tales como:
Pérdida de datos, manipulación errónea
de datos o entradas erróneas.
El componente involucrado interpreta los
datos de entrada de una manera distinta.
Los datos son transferidos en un
momento incorrecto: antes de tiempo,
después de tiempo, a una frecuencia
distinta de la requerida.
 23 May 20

Hay diferentes estrategias para las pruebas de integración

Enfoque incremental es un elemento común a la mayoría de las estrategias (excepción: estrategia “Big
Bang”).
Las estrategias ascendente (“bottom - up”) y descendente (“top-down”) son las utilizadas con mayor
frecuencia.
La elección de la estrategia debe considerar también aquellos aspectos relativos a la eficiencia de las pruebas.
En cada proyecto específico se debe considerar el compromiso entre la reducción de tiempo y la reducción esfuerzo en
pruebas
 23 May 20

• Las pruebas alfa consisten en invitar al cliente a que venga al entorno de desarrollo a probar el sistema. Se trabaja en
un entorno controlado y el cliente siempre tiene un experto a mano para ayudarle a usar el sistema y para analizar los
resultados.

• Las pruebas beta vienen después de las pruebas alfa, y se desarrollan en el entorno del cliente, un entorno que está
fuera de control. Aquí el cliente se queda a solas con el producto y trata de encontrarle fallos (reales o imaginarios) de
los que informa al desarrollador.

• Las pruebas alfa y beta son habituales en productos que se van a vender a muchos clientes.
55
56