Software Testing

Que es Pruebas de Software?

Es el proceso de Verificar y Validar que una aplicación o

programa de software:

• Cumple con los requerimientos técnicos y de negocio que

guiaron
su diseño y desarrollo.

• Funciona según lo esperado.

• También se encarga de identificar defectos, errores y áreas

de oportunidad que debieran ser corregidos.
 Que validar?

Requerimientos Requerimientos
Funcionales De Calidad

Que se supone el Que se supone el • Tiempo de

sistema SI debe hacer sistema NO debe hacer respuesta
• Eficiencia
• Portabilidad
• Carga y Stress
• ...
 Calidad.
La calidad del software es el conjunto de cualidades que lo caracterizan y
que determinan su utilidad y existencia.

La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad,

mantenibilidad, portabilidad, usabilidad, seguridad e integridad.

En si la calidad de Software es el grado en el cual un componente,

sistema o proceso cumple con los requerimientos especificados,
necesidades y expectativas de los usuarios y clientes.

La calidad del software es medible y varía de un sistema a otro o de un

programa a otro
 Aseguramiento de la calidad (QA).
 Es el conjunto de actividades planificadas y sistemáticas necesarias para
aportar la confianza en que el producto (software) requiere para satisfacer
los requerimientos dados de calidad por parte del cliente.

 Se trata de actividades tendientes a verificar que los procedimientos y

prácticas de calidad establecidas se aplican correcta y efectivamente en el
proyecto, focalizadas en la prevención de fallas y mediciones de calidad.

Un acuerdo de nivel de servicio, también

conocidas por las siglas SLA, es un
acuerdo escrito entre un proveedor de
servicio y su cliente con objeto de fijar el
nivel acordado para la calidad de dicho
servicio.
Por que es importante realizar
pruebas de software?
 Es absolutamente esencial para identificar los errores que se han
cometido en las fases de desarrollo.
 Garantiza que el software es fiable, de calidad y asegura la satisfacción
del cliente.
 Los programas de software cada vez tienen más competencia, son más
complejos y cuentan con más usuarios hoy en día una empresa sobrevive
sólo si puede ofrecer un producto fiable y de calidad.
 Apliquemos siempre la máxima “si no se ha probado, no sube a
producción”.
 Ofrece a los comerciales de la compañía la confianza que necesitan a la
hora de vender el producto, es decir, pueden estar seguros de que no
tiene defectos y proporciona las funcionalidades que se supone debe
proporcionar. Al fin y al cabo, el objetivo de una empresa es vender su
producto
 Puede resultar muy costoso corregir los errores en fases más avanzadas
del desarrollo de la aplicación. Los errores hallados en etapas tempranas
del desarrollo es 200 veces menor frente a aquellos identificados de
forma tardía.
Por que es importante realizar
pruebas de software?
Planning
Analysis
System Design
$140
Code

Unit
Test COST TO Production
$1000 REPAIR 1
DEFECT $14,000

Integration
Certification
Test
System Test

$2500 Test
$7000
$4500
 Proyecto.
 Un proyecto consiste en un conjunto de actividades
planificadas e interrelacionadas que desarrollan un grupo
de personas de manera coordinada para alcanzar un
determinado objetivo
Ciclo de vida de un Proyecto
 Rol del ingeniero de pruebas
Estrategia: diseñar y definir la estrategia de pruebas de acuerdo a
los requerimientos y el entorno del proyecto/ aplicación

Caso de prueba: diseñar caso de prueba para la validación de los

casos de uso que hagan lo que tienen que hacer y que no hagan lo
que no tienen que hacer.

Ejecución de prueba: llevar a cabo la ejecución de cada uno de los

casos de pruebas y realizar el registro del resultado obtenido.

Reportar defectos y hallazgos: reportar de manera clara y concisa

los defectos y o hallazgos encontrados durante la ejecución.

Reporte de prueba: reportar a los responsables del proyecto del

estado de la ejecución así como de los defectos encontrados
 Conceptos básicos del Testing.
 Una falla ocurre cuando un programa no se comporta
adecuadamente .
 Un defecto existe en el código – si se encuentra puede causar falla.
 Un error es una acción humana que resuelta en software contiene
un defecto – puede llevar a incluir un defecto en el sistema,
haciéndolo fallar.
 Un test exitoso es aquel en donde se encuentran muchos defectos,
no lo opuesto.
Que es un requerimiento

 Un requerimiento es un enunciado de algo que

esperamos que el sistema realice.
 Una necesidad especifica en un sistema

Ejemplo: El sistema debe permitir a los clientes reservar vuelos

nacionales e internacionales

Existen niveles de requerimiento:

Alto nivel No detalles

Bajo nivel Mucho detalle

Ejemplo: El sistema deberá permitir a los clientes reservar
vuelos nacionales e internacionales estos solo en horario
matutino y si cuentan con Visa y\o pasaporte vigente
Que es un escenario?
 Un escenario es una situación que pudiera posiblemente pasar
cuando la aplicación está en producción. Generalmente un
requerimiento o una función tienen más de un escenario.

Ejemplo: Requerimiento.- El sistema debe permitir a los clientes

checar el estatus de sus vuelos.

Escenarios:
Checa el estatus de una orden que:
•no existe
•fue enviada
•no ha sido enviada
•ha sido cancelada
Que es un caso de prueba?
 Conjunto de datos que causarán al sistema ejecutar una
condición o escenario especifico.
 Ejemplo: Validar que si la orden fue cancelada se
muestre el estatus “cancelada”
Que es un script de
pruebas?
 Procedimiento paso a paso para usar un caso de prueba y
probar una unidad específica de código, función o
capacidad.
 Conjunto de instrucciones a ser seguidas para ejecutar un
número de casos de prueba relacionados.

Que es un caso de uso?

Caso de uso: es una descripción de los pasos o las
actividades que deberán realizarse para llevar a cabo algún
proceso.
Que es un ambiente de
pruebas?
 Se refiere a todo lo necesario para realizar las pruebas
 Los ambientes de prueba pueden ser utilizados para
actividades de pruebas de aceptación del usuario. Se
suelen utilizar configuraciones de hardware similares a
las del entorno de producción
 El término "ambiente" se utiliza en este contexto, en
lugar de "máquina de prueba", porque la fase de
ambiente de prueba se llevará a cabo en uno o más
servidores.
 Tipos de pruebas
Prueba de caja negra
Pruebas de Caja Negra.
Prueba basada en el análisis de la especificación del producto, sin referenciarse en el
funcionamiento interno.
Intenta corregir:
Funcionalidad incorrecta o faltante.
Errores de interfaz.
Errores en la BD.
Errores en el comportamiento.

Métodos de caja negra.

Partición equivalente.
Análisis de valores límites.
Basado en grafos.

Entradas Salidas
 Prueba de caja blanca

• Prueba que se basa en el análisis del funcionamiento interno y la

estructura del software (código).

• Por ejemplo, validar bases de datos, validar logs para verificar el

correcto registro, etc.

Entradas Der=3;
If (f>12) {

Salidas
f=as;
}
Else {
f=34;
}
Der=2;
 Otros tipos de pruebas.
 Positiva: Prueba individual que se enfoca en mostrar que el producto
funciona siguiendo el procedimiento correcto.

 Negativa: Prueba que consiste en hacer todo lo contrario a lo que debería

de hacerse.

 Pruebas unitarias: Son realizadas principalmente por los desarrolladores y

su objetivo es probar de manera individual cada programa desarrollado.

 Pruebas de aceptación (Smoke): Asegurar que la construcción del código

está lista para ser probada.
Otros tipos de pruebas de software
• Pruebas de integración: son aquellas que permiten probar en conjunto distintos
subsistemas funcionales o componentes del proyecto para verificar que
interactúan de manera correcta y que se ajustan a los requisitos especificados
(sean estos funcionales o no).
• Pruebas no funcionales o de performance: Pruebas de rendimiento de software se
centra en determinar la velocidad con la que el sistema bajo pruebas realiza una
tarea en las condiciones particulares del escenario de pruebas.
• Pruebas de usabilidad: consisten en seleccionar a un grupo de usuarios de una aplicación
y solicitarles que lleven a cabo las tareas para las cuales fue diseñada
• Regresión: Consiste en re-probar el producto después de alguna modificación
para asegurar que la funcionalidad no ha cambiado.
Otros tipos de pruebas de software
• Pruebas de aceptación o UAT: Son las pruebas que se llevan en conjunto con
el usuario que va ser el responsable de la aplicación y estas deben de ser la fase
final de un esfuerzo de pruebas. Son las mas importantes ya que definen si el
sistema se va o no a producción.

• Pruebas en móviles tienen una característica muy peculiar por la diversidad de

modelos de dispositivos móviles y estas se realizan utilizando guiones y
simuladores considerando diferentes entornos.

• Pruebas de paginas web se utilizan generalmente la tecnica de pruebas

exploratorias para determinar si no hay errores en la usabilidad y se utilizan los
diferentes navegadores soportados
Diseño de Prueba

 Para cada requerimiento, identifica todos los posibles

escenarios
 • Para cada escenario, determina todos los casos incluyendo
entradas, precondiciones, salidas y pos condiciones.
 • Usa técnicas como: Clases de Partición Equivalente
 Gráficas de Causa y Efecto
 Tablas de Decisión
 Árboles de Decisión
 Casos de Uso
 Modelos de Estado
 Herramientas de pruebas

• Hay tres tipos:

• 1.- Para administrar todo el proceso de pruebas funcionales.

( HP ALM, Testlink, Mantis, Redmine, Eventum, QC, etc. )

• 2.- Para automatizar las pruebas

(Watir, Selenium, QTP, etc. )

• 3.- Para realizar las ejecuciones de pruebas no funcionales

(Jmeter, Neoload, Load runner, etc.)
 Defectos.

Anatomía Reporte de Defectos.

 Bien organizado.
 Escritura clara y concisa.
 NO incluir comentarios o lenguaje acusatorios.
 Incluir toda la información clave.
 Describir el alcance e impacto.
 Especificar síntomas y escenarios.
 Especificar el impacto y severidad del defecto.
 Defectos.
Formato de reporte de defectos.
 Id de Defecto
 Descripción
 Prioridad
 Severidad
 Caso de Prueba en donde se encontró el Defecto.
 Pasos para reproducir el Defecto
 Resultado Esperado
 Resultado Actual
 Describir como se reproduce el defecto.
 Defectos.

Vida de un defecto
 Plan de pruebas.

 Plan de Pruebas
 Es la base de pruebas para el proyecto. Nos ayuda a determinar:
 ¿Qué Probar?
 ¿Cómo Probar?
 ¿Cuándo Probar?
 ¿Quién va a Probar?
 ¿Con qué herramientas Probar?
 ¿Cuándo empezamos y Cuándo terminamos de Probar?
 Cuantos recursos se requieren?
 Criterios de aceptación
 Plan de pruebas.
 Formato del plan de pruebas
1. Id del documento.
2. Resumen de elementos software a probar.
3. Características a probar.
4. Características que no se probarán.
5. Enfoque general de la prueba.
6. Criterios de paso/fallo de cada elemento.
7. Criterios de suspensión y criterios de reanudación.
8. Documentos a entregar.
9. Actividades de preparación y ejecución de pruebas.
10. Necesidades de entorno.
11. Responsabilidades de la organización.
12. Necesidades del personal y formación.
13. Esquema de tiempos.
14. Riesgos asumidos por el plan y planes de contingencias.
15. Necesidades de ambiente.
16. Ciclos de prueba que aplican
 Formato casos de prueba.
Matriz de prueba: agrupación de casos de prueba de manera logica y ordenada
1. Identificador de caso de prueba.
2. Nombre del caso de uso
3. Precondiciones.
4. Poscondiciones.
5. Resultado Esperado (Salida).
6. Titulo del caso de prueba.
7. Descripción del caso de prueba.
8. Tipo de Prueba.
9. Prioridad de ejecución
10. Pasos
11. Caso de Prueba Predecesor
12. Estatus
13. Tipo de Flujo
14. Comentarios

Nota: Los casos de prueba tienen que estar diseñados lo mas detallado posible.
 Hábitos de un tester.
 Ve el producto a través de los ojos del Cliente.
 Encuentra defectos insignificantes extremadamente fácil.
 Siempre ve más allá del “Funciona como fue diseñado” (Propone).
 Influye y controla el diseño y la calidad del producto.
 Se toma el tiempo para “jugar” con la interfaz antes de sumergirse en la
funcionalidad:
 Toma notas rápidas de posibles defectos, cambios o correcciones.
 No lee la ayuda en su primer intento.
 Siente curiosidad
 Pregunta instrucciones.
 Hace preguntas por más obvias que parezcan.
 Cree solo en lo que puede comprobar
 Hábitos de un tester.

Busca las debilidades clave del producto.

Tiene habilidad de proponer/sugerir.
 Su valor no es solo detectar defectos.
 Un Tester tiene una posición de guiar el código hacia un
excelente producto.
 Sugiere cambios funcionales.
 Sugiere nuevas funciones.