fundamentos de calidad del desarrollo...
TRANSCRIPT
QUALITY ASSURANCE
FUNDAMENTOS DE CALIDAD
DEL DESARROLLO SOFTWARE
2
INTRODUCCIÓN
27/05/2013
3
INTRODUCCIÓN
Software testing es un proceso usado
para indentificar la corrección, la
entereza y calidad del software
desarrollado Incluye una serie de actividades con el propósito de encontrar
errores en el software para poder ser corregidos antes de que el
producto es lanzado al cliente.
Software testing es una actividad para
asegurar que los resultados actuales
equivalen a los esperados y asegurar
que el software está libre de defectos.
4
INTRODUCCIÓN
Por qué el testeo
es importante?
5
INTRODUCCIÓN
ChinaAirlines Airbus A300 se estrelló debido a un bug en el software el 26 de Abril de 1994 matando a 264 inocentes. Los bugs pueden causar pérdidas monetarias y humanas, la historia está llena de ejemplos
En 1985, El Canada's Therac-25 una máquina de terapia por radiación malfuncionó debido a un bug de software y causó deliveradas radiaciones letales a los pacientes. Murieron 3 personas y otras 3 quedarón críticamente perjudicadas
6
OBJETIVOS DE LAS PRUEBAS
Como se ha podido ver, testing es importante
porque los defectos del producto pueden
causar altos costes y pueden ser peligrosos Como Paul Ehlrich escribió – “Errar es humano, pero para
cargarla realmente hace falta un ordenador”
Objetivos de las pruebas Adquirir conocimiento sobre los defectos en un objeto de
prueba (“test object”)
Comprobar la funcionalidad
Generar información
Generar confianza
7
SIETE PRINCIPIOS DEL TESTEO
27/05/2013
8
SIETE PRINCIPIOS DEL TESTEO
Principio 1: El proceso de pruebas demuestra la presencia de defectos
La causa de un fallo puede no ser obvia
El proceso de pruebas no puede demostrar la ausencia de defectos
Las pruebas reducen la probabilidad de la presencia de defectos que permanecen sin ser detectados
El mismo proceso de pruebas puede contener errores
Principio 2: No es posible realizar pruebas exhaustivas Pruebas exhaustivas (“exhaustive testing”)
Enfoque de pruebas donde el conjunto de pruebas abarca todas las combinaciones de valores de entrada y precondiciones
Explosión de casos de pruebas (“test case explosion”)
Define el incremento exponencial de esfuerzo y coste en el caso de pruebas exhaustivas
Prueba de muestra (“sample test”)
Incluye un subconjunto de todos los posibles valores de entrada
Probar todas las combinaciones posibles de entradas y precondiciones sólo es económicamente viable en casos triviales
Se necesita una cantidad óptima de tests basados en la evaluación del riesgo de la aplicación
9
SIETE PRINCIPIOS DEL TESTEO
Principio 3: Pruebas tempranas (”early
testing”) La correción de un defecto es menos costosa en la medida
en la cual su detección se realiza en fases más tempranas
del proceso software
Se obtiene una máxima rentabilidad cuando los errores son
corregidos antes de la implementación
Los conceptos y especificaciones pueden ser probados
Los defectos detectados en la fase de concepción son
corregidos con menor esfuerzo y costos
Ls preparación de una prueba también consume tiempo
El proceso de prueba implica más que sólo la ejecución de
pruebas
Las actividades de prueba deben ser ejecutadas en paralelo
a la especificación y diseño software
10
SIETE PRINCIPIOS DEL TESTEO
Que operación es la más problable que cause el fallo del
Operating system?
1. Abrir Microsoft Word
2. Abrir Internet Explorer
3. Abrir 10 aplicaciones diferentes al
mismo tiempo
Multitarea
11
SIETE PRINCIPIOS DEL TESTEO
Principio 4: Agrupamiento de defectos
(”defect clustering”) Encuentre un defecto y encontrará más defectos
”cerca”!
Los defectos aparecen agrupados como hongos o
cucarachas
Cuando se detecta un defecto es convenienti investigar el
mismo módulo en el que ha sido detectado
Los probadores (testers) deben ser flexibles
La identificación/localización de un defecto puede ser
investigada con un mayor grado de detalle, por ejemplo,
realizando pruebas adicionales o modificando pruebas
existentes
12
SIETE PRINCIPIOS DEL TESTEO
Principio 5: Paradoja pesticida Repetir pruebas en las mismas condiciones no es
efectivo
Cada caso de prueba debe contar con una combinación
única de parámetros de entrada para un objeto de prueba
particular, de lo contrario no se prodrá obtener información
adicional
Si se ejecutan las mismas pruebas de forma reiterada no se
podrán encontrar nuevos defectos
Las pruebas deben ser revisadas/modificadas
regularmente para los distintos módulos (código)
La automatización de pruebas puede resultar conveniente si
un conjunto de casos de prueba se debe ejecutar
frecuentemente
13
SIETE PRINCIPIOS DEL TESTEO
Principio 6: Las pruebas dependen del
contexto Las pruebas se desarrollan de forma diferente en
diferentes contextos
Objetos de prueba diferentes son probados de forma
diferente
Entorno de pruebas (”test environment”, cama de
pruebas – ”test bed”) vs entorno de producción
(”production environment”)
El entorno de pruebas debe ser similar al entorno de
producción
14
SIETE PRINCIPIOS DEL TESTEO
Principio 7: La falacia de la ausencia de
errores Un proceso de pruebas adecuado detectará los fallos
más importantes
En la mayoría de los de los casos el proceso de pruebas no
enconrará todos los defectos del sistema (ver principio 2),
pero los defectos más imprtantes deberían ser detectados
Esto en sí no prueba la calidad del software
La funcionalidad del software puede no satisfacer las
necesidades y expectativas de los usuarios
No se puede introducir la calidad a través de las pruebas,
ella tiene que construirse desde el principio
15
No se puede asegurar que el
software está libre de bugs
16
SIETE PRINCIPIOS DEL TESTEO
Resumen Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismas no pueden demostrar la ausencia de defectos
Salvo en casos triviales las pruebas exhaustivas son imposibles, las pruebas de muestra son necesarias
Las pruebas tempranas ayudan a reducir costos dado que los defectos descubiertos en fases tempranas del proceso software son corregidos con menor esfuerzo
Los defectos se presentan agrupados
Repetir pruebas idénticas no genera nueva información
Cada entorno particular determina la forma en la cual se ejecutarán/desarrollarán las pruebas
Un software libre de errores no implica que sea adecuado para el uso
17
SIETE PRINCIPIOS DEL TESTEO
Principios Definición
Principio 1 Testing muestra la presencia de
defectos
Principio 2 Testing exaustivo es imposible
Principio 3 Testing tan pronto como sea
posible
Principio 4 Defect Clustering
Principio 5 Pesticide Paradox
Principio 6 Testing es dependiente del
contexto
Principio 7 Abstinencia de defectos -
ERROR
18
SDLC VS STLC
27/05/2013
19
DESARROLLO SOFWARE PARA EL CLIENTE
1. Obtener toda la información
posible sobre los detalles y
especificaciones del software
deseado para el cliente
2. Decidir el lenguaje de
programación como Java,
PhP, .NET, database como
Oracle, mysql etc los cuales
idean el proyecto. ”Alto nivel
de arquitectura”
3. Implementación del software
4. Testear el software para
verificar que se ha
implementado acorde con las
especificaciones dadas por el
cliente
Requisitos
Diseño
Programación
Test
Mantenimiento
Sofware development live cycle
SDLC
20
DESVENTAJAS
Errores en
requisitos
Diseño para
contemplar los
requisitos
Desarrollo para
contemplar el
diseño
Producto
incorrecto
Se tendrá que comenzar de
nuevo con el proyecto
Requisitos
Diseño
Programación
Test
Mantenimiento
21
DESVENTAJAS
Requisitos
Diseño
Incorrecto
Desarrollo para
contemplar el
diseño
Producto
incorrecto
Rediseño para corregir los
defectos
Requisitos
Diseño
Programación
Test
Mantenimiento
Cerca del 50% de los defectos son introducidos durante las fases de requerimientos y diseño
22
PRUEBAS A TRAVÉS DEL MODELO-V GENERAL
Desarrollo y pruebas son dos ramas iguales
Cada nivel de desarrollo tiene su correspondiente nivel de pruebas
Rama desarrollo software
Definición de requisitos
Diseño funcional del sistema
Diseño técnico del sistema
Especificación de los componentes
Programación
Rama pruebas software
Pruebas de aceptación
Pruebas de sistema
Pruebas de integración
Pruebas de componente
23
VERIFICACIÓN VS VALIDACIÓN
Verificación
Comprobación de la conformidad con los requisitos establecidos
(ISO 9000). Si los requisitos y definiciones de niveles previos han
sido implementados correctamente
Cuestión clave: ¿Se ha procedido correctamente en la construcción
del sistema?¿Hemos sumado 1+1 correctamente?
Cada nivel de desarrollo se verifica respecto de los contenidos del
nivel que precede
Validación
Comprobación de la idoneidad para el uso esperado (ISO 9000).
Validar significa comprobar lo adecuado de los resultados de un
nivel de desarrollo
Cuestión clave: ¿Hemos construido el sistema software correcto?¿El
objetivo era sumar 1+1 o debeíamos haber restado?
La validación se refiere a la correción de cada nivel de desarrollo
24
CICLO DE VIDA ITERATIVO
Requisitos
Diseño
Build
Test
Mantenimiento
Requisitos
Diseño
Build
Test
Mantenimiento
Requisitos
Diseño
Build
Test
Mantenimiento
Fase 1 Fase 2 Fase 3
25
TESTEO EN LOS MODELOS DE CICLO DE VIDA
Hay numerosos modelos del ciclo de vida de
desarrollo
El modelo de desarrollo seleccionado depende
de las necesidades y objetivos del proyecto
Testing no es una actividad stand-alone y tiene
que adaptarse al modelo de desarrollo
seleccionado para el proyecto
En cualquier modelo seleccionado, testing
debe ser aplicado en todos los niveles (para
mantener los requerimientos)
26
PRUEBAS DE COMPONENTE
(UNIT TESTING)
27/05/2013
27
UNIT TESTING
¿Por qué es importante el unit testing? Desarrolladores software optimizan el tiempo
aplicando un mínimo de unit testing
Unit testing reduce el coste de arreglar desfectos
durante las fases de system testing, integration
testing e incluso beta testing una vez la aplicación es
desarrollada por completo
Aplicar unit testing durante el estado de desarrollo
reduce tanto tiempo como dinero empleado en el
proyecto
28
CONSTRUIR CASOS DE COMPONENTE
Comunmente Unit Testing es ejecutado de
manera automática pero puede ser manual
Aproximación automática Un desarrollador puede implementar otra sección de código
en la aplicación solo para testear la funcionalidad (el código
de testeo es eliminado una vez el desarrollo es completado)
Se puede asilar la funcionalidad para ser testeada más
rigurosamente. Aislar el código ayuda a revelar innecesarias
dependencias entre el código testeado y otras unidades del
producto
Se puede usar un Unit Test Framework para desarrollar
casos automatizados
Reporte automático de casos fallidos
29
UNIT TESTING
Mock Objects Objetos creados para testear secciones de código aún
incompletas
Simulan variables u objetos unicamente con el propósito de
testear esa sección del código
Unit Testing Tools Rational Software – By IBM as ”Rational Test Realtime”. Go
to http://www-01.ibm.com/software/rational/
JavaScript Assertion Unit. Go
to http://jsassertunit.sourceforge.net/docs/index.html
CUT – CUT Freeware unit test tool for C. Go
to http://sourceforge.net/projects/cut/
Dotunit – Dotunit, .NET framework. Go to
http://dotunit.sourceforge.net/
30
PROGRAMACIÓN EXTREMA & UNIT TESTING
Programación extrema implica el uso extensivo
de testing frameworks
Beneficios de la programación extrema Tests son escritos antes que el código
Fiabilidad de herramientas específicadas . Unit Test
Framework
Todas las clases en la aplicación son testeadas
Posibilidad de una facil y sencilla integración
31
MITOS DEL UNIT TESTING
Requiere tiempo y siempre estoy retrasado
Mi código es inmejorable! No necesito unit tests
La verdad es: Unit testing incrementa la velocidad de
desarrollo
Integration testing contendrá todos los defectos. Unit testing
previo implica una integración con defectos triviales facil de
solucionar
32
RESUMEN
Pruebas de componente (Unit testing)
Un componente es la unidad más pequeña
especificada de un sistema
Prueba de módulo, de clase, de unidad y de
desarrollador son utilizados como sinónimos
Las pruebas de componente podrán comprobar
características funcionales y no funcionales de un
sistema
33
PRUEBAS DE INTEGRACIÓN
(INTEGRATION TESTING)
27/05/2013
34
PRUEBAS DE INTEGRACIÓN
Definición y terminología En el testeo de integración, los módulos software
individuales son integrados lógicamente y testeados como
un grupo
Un proyecto software consiste en multiples módulos
implementados por diferentes desarrolladores
El testeo de integración está enfocado en probar la
comunicación entre esos módulos
El testeo de integración es llevado a cabo por los
testeadores
También denominado como ”I & T” (Integration and
Testing), ”String Testing” y aveces ”Thread Testing”
35
PRUEBAS DE INTEGRACIÓN
Necesidad del testeo de integración Módulos son testeados individualmente (Unit Testing), sin
embargo los defectos pueden aún existir por las siguientes
razones
Un módulo es asignado a un programador con un
entendimiento y manera lógica diferente de otro
programador. Integration testing se convierte en necesario
para verificar que los módulos funcionan en unidad
Cambios en los requisitos que implican modificaciones en
los componentes. Los nuevos requisitos pueden no ser
testeados individualmente y por tanto el testeo de
integración es necesario
Las interfaces de los módulos con la base de datos pueden
ser erroneas
Interfaces hardware esternas pueden ser erroneas
Excepciones no controladas pueden causar defectos
36
PRUEBAS DE INTEGRACIÓN
Casos de testeo Enfocados principalmente en las interfaces y flujo de datos/ información entre modulos
Prioriza la integración de links frente a las funciones unitarias las cuales son previamente testeadas
Ejemplo de una aplicación con 3 módulos: ”Loging page”, ”Mail Box” y ”Borrar Emails”
Test case ID Objetivo Descripción Resultado
esperado
1 Comprobar el link
entre el ”Login” y
”MailBox”
Introducir las
credenciales de
logueo y cliclar en
el boton de login
Redirección a la
bandeja de correo
(MailBox)
2 Comprobar el link
entre el ”MailBox” y
el ”Borrado de
Emails”
Desde la bandeja
de entrada,
seleccionar un
email y clicar en el
botón de borrado
El email
seleccionado debe
aparecer en la
carpeta de
borrado
37
PRUEBAS DE INTEGRACIÓN
Metodologías vs Estrategias Aproximación Big Bang
Aproximación incremental:
Top down
Bottom Up
Sandwitch – Combinación de Top down y Bottom Up
38
METODOLOGÍAS
Big Bang Todos los componentes son integrados a la vez y después
son testeados
Ventajas:
Conveniente para sistemas pequeños
Desventajas
Dificultad para localizar el fallo
El testeo de algún link de interfaz puede ser olvidado
facilmente
Integration testing comienza una vez todos los módulos son
dispuestos por tanto el equipo de testeo tienes menos tiempo
para ejecución de los casos
Módulos críticos no son aislados y testeados con prioridad
39
METODOLOGÍAS
Bottom up integration Cada módulo del nivel inferior es testeado con módulos de niveles
más altos hasta que todos los módulos son testeados. Utiliza
drivers
Ventajas Fácil localización del fallo
Tiempo no perdido esperando por el desarrolo de todos los módulos
Desventajas Módulos criticos son los últimos en testear y pueden tener defectos colaterales
40
METODOLOGÍAS
Top Down integration Cada módulo del nivel superior es testeado con módulos de niveles
inferiores hasta que todos los módulos son testeados. Utiliza Stubs
Ventajas Fácil localización del fallo
Módulos criticos son los últimos en testear y pueden tener defectos colaterales
Desventajas Necesidad de numerosos Stubs
Módulos más inferiores no testeados adecuadamente
41
PRUEBAS DE INTEGRACIÓN
Procedimiento 1. Preparación del Test Plan
2. Diseño, escenarios, casos de prueba y scripts
3. Ejecución de los casos de prueba y reporte de defectos
4. Arreglo y re-testing de defectos
5. Pasos 3 y 4 hasta completar la integración
satisfactoriamente
Descripción Test Plan Métodos utilizados para testear
Alcances y fuera del alcance
Roles y responsabilidades
Pre-requisitos
Testing environment
Riesgos y Mitigation Plans
42
INTEGRATION TESTING
Best Practices/ Guidelines Primero determina la estrategia de testeo que será
adoptada y después prepara los casos de testeo y test data
Estudia el diseño de la arquitectura de la aplicación e
identifica los módulos críticos. Estos deben ser testeados
con prioridad
Obten el diseño de interfaces del equipo de arquitectura y
crea los test cases para verificar todas las interfaces en
detalle (database/external hardware/software)
Siempre tener el mock data preparado previamente a la
ejecución. No seleccionar el test data durante la ejecución
de los casos de prueba
43
RESUMEN
Pruebas de integración
Integración significa construir grupos de
componentes
Las pruebas de integración comprueban la
interacción entre componentes respecto de la
especificación de interfaces
La intergración ocurre de forma ascendente (”botton
up”), descendente (”top-down”) o en forma de
”big bang”
Cualquier estrategia de integración distinta a las
anteriores es integración ad hoc
44
PRUEBAS DE SISTEMA (“SYSTEM
TESTING”) Y DE ACEPTACIÓN
(“ACCEPTANCE TESTING”)
27/05/2013
45
PRUEBAS DE SISTEMA
Las pruebas de sistema (”system testing”) verifican el completo escenario End to End y comprueban el cumplimiento de los requisitos especificados
La calidad es observada dede el punto de vista del usuario
Se refieren a requisitos funcionales y no funcionales (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad)
Los casos de prueba podrán ser obtenidos a partir de : Especificaciones funcionales
Casos de uso
Procesos de negocio
Evaluación de riesgos
Login Current Balance
Transferencia Logout
46
PRUEBAS DE SISTEMA
Alcance: Prueba de un sistema integrado desde el punto de vista del
usuario
Implementación completa y correcta de los requisitos
Despliegue en el entorno real del sistema con datos reales
El entorno de pruebas debería coincidir con el
entorno real Todas las interfaces externas son probadas en condiciones
reales
Emulación próxima al futuro entorno real del sistema
¡No se realizan pruebas en el entorno real!
47
PRUEBAS DE ACEPTACIÓN
Las pruebas de aceptación son pruebas formales llevadas a cabo con el objeto de verificar la conformidad del sistema con los requsitos. Aportar confianza en el sistema para que pueda ser aceptado por el cliente
Es habitual que sean las primeras pruebas en las cuales se vea involucrado el cliente
El cliente selecciona casos de prueba para las pruebas de aceptación
Las pruebas se realizan en el entorno del cliente
El foco no es encontrar defectos sino confirmar que cumple con los requerimientos
Puede ser realizado de dos maneras: pruebas alpha y pruebas beta
Es necesario una versión preliminar y estable del software
El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio cotidianos en las dependencias del proveedor (”Alpha Testing”) o en sus propias dependencias (”Beta Testing”)
Ventajas de las pruebas alpha y beta Reduce el costo de las pruebas de aceptación
Se utilizan distintos entornos
Involucran a un alto número de usuarios
48
RESUMEN
Pruebas de sistema
Las pruebas de sistema se desarrollan utilizando casos de prueba
funcionales y no funcionales
Las pruebas de sistema funcionales confirman que los requisitos
para un uso específico previsto han sido satisfechos (validación)
Las pruebas no funcionales verifican los atributos de calidad no
funcionales, por ejemplo usabilidad, eficiencia, portabilidad, etc
Con frecuencia, los atributos de calidad no funcionales son una
parte implícita de los requisitos, esto hace dificil validarlos
Pruebas de aceptación
Las pruebas de aceptación son pruebas de sistema por parte del
cliente
La prueba de aceptación es una actividad de carácter contractual,
se verificará entonces que el software satisface los requisitos del
cliente
Las pruebas alpha y beta son pruebas ejecutadas por clientes
reales o potenciales
49
SMOKE & SANITY TESTING
27/05/2013
50
SMOKE/SANITY TESTING
Login -> Ver Balance > Transferir 500 eur > Logout
Amaris
Miriam
******* Boom
51
SMOKE/SANITY TESTING
52
SMOKE/SANITY TESTING
Sanity/Smoke testing – Para verificar
funcionalidades críticas del sistema
antes de ser aceptado para un nivel de
testeo más importante
Sanity testing es rápido y no es
exhaustivo
El objetivo no es encontrar defectos
sino verificar la estabilidad del sistema
53
PRUEBAS DE MANTENIMIENTO
(“MAINTENANCE TESTING”) Y
REGRESIÓN
27/05/2013
54
PRUEBAS DE MANTENIMIENTO
Balance
actual
Una vez desarrollado el software, los cambios
en el sistema, mejoras o correciones forman
parte del maintenance testing
55
REGRESIÓN DEL SISTEMA
Balance
Actual
Balance actual = 2000
Balance antiguo = 500
Transferencia 1000
500
Error en la transacción
Cambios introducidos en el código (módulo de balance únicamente) provocan que el módulo de tranferencia se vea afectado
Regression testing es llevado a cabo para verificar que las modificaciones en el producto no causan defectos adversos
56
PRUEBAS NO FUNCIONALES
(“NON-FUNCTIONAL TESTING”)
27/05/2013
57
PRUEBAS NO FUNCIONALES
Aparte de Functional testing, factores asociados al non-functional testing como performance, usability, load son también importantes
Performance testing: Comprueba una respuesta óptima del sistema. El objetivo es reducir el tiempo de respuesta a un nivel aceptable
Load testing: Respuesta del sistema sometida a diferentes cargas, por ejemplo, el número de usuarios accediendo al sistema
58
TIPOS DE PRUEBAS
Tipos de testing
Funcionales No Funcionales Mantenimiento
Unit Testing
Integration Testing
Smoke/Santy Testing
User Acceptance
Localization
Globalization
Interoperability
Etc ..
Performance
Endurance
Load
Volume
Scalability
Usabilty
Etc ..
Regresión
Maintenance
59
CONSIDERACIONES
Mas de 150 tipos de testing
No todos los tipos de testing pueden
ser aplicables a todos los proyectos,
depende de la naturaleza y el alcance
del proyecto
60
DESARROLLO DE CASOS DE
PRUEBA
27/05/2013
61
CONSIDERACIONES AL DESARROLLAR UN CASO DE
PRUEBA
Testing implica la ejecución de varias
secciones de codigo y la verificación
de los resultados
Testing es una actividad muy formal que
es documentada en detalle
El grado de formalidad depende del
tipo de aplicación a testear, los
estandares seguidos por la organización
y la madurez del proceso de desarrollo
62
CASOS DE PRUEBA
Test Cases
Los escenarios de prueba pueden repercutir en un elevado números
de posibilidades
El testing debe ser muy específico
Test Data
Identificar los datos de test puede implicar un consumo de tiempo
elevado y puede aveces requerir de la creación de estos datos
Escenario Test Case Test Data
Verificar la
funcionalidad de
logueo
Verificar la
respuesta frente a
un usuario válido
y contraseña
Usuario: Miriam99
Contraseña: AMARIS
Usuario: Miriam
Contraseña: AMAris
Usuario: 9999
Contraseña: amaris
63
RESULTADOS ESPERADOS
Escenario Test Case Test Data Resultados
Esperados
Verificar la
funcionalidad
de logueo
Verificar la
respuesta
frente a un
usuario válido y
contraseña
Usuario: Miriam99
Contraseña:
AMARIS
Usuario: Miriam
Contraseña: AMAris
Usuario: 9999
Contraseña: amaris
Usuario se loguea
satisfactoriamente
Si los resultados esperados no son documentados no
podremos confirmar que el resultado de una pruebas es
OK.
64
PASOS DE TESTEO
Escenario Test Case Test Steps Test Data Resultados
Esperados
Verificar la
funcionalidad de
logueo
Verificar la
respuesta frente
a un usuario
válido y
contraseña
1. Lanzar la
aplicación
2. Introducir el
usuario
3. Introducir la
contraseña
4. Clicar el
botón OK
Usuario:
Miriam99
Contraseña:
AMARIS
Usuario: Miriam
Contraseña:
AMAris
Usuario: 9999
Contraseña:
amaris
Usuario se
loguea
satisfactoriamen
te
65
PRECONDICIONES
Escenario Test Case Pre-
Condition
s
Test Steps Test Data Resultado
s
Esperados
Verificar la
funcionalidad
de logueo
Verificar la
respuesta
frente a un
usuario
válido y
contraseña
La aplicación
de reserva
de un vuelo
debe ser
instalada
1. Lanzar la
aplicación
2. Introducir
el usuario
3. Introducir
la contraseña
4. Clicar el
botón OK
Usuario:
Miriam99
Contraseña:
AMARIS
Usuario:
Miriam
Contraseña:
AMAris
Usuario: 9999
Contraseña:
amaris
Usuario se
loguea
satisfactoria
mente
Precondiciones indican detalles previos a realizar para
poder ejecutar los casos de prueba
66
POST-CONDITIONS
Escenario Test Case Pre-
Condition
s
Test Steps Test Data Resultado
s
Esperado
s
Verificar la
funcionalidad
de logueo
Verificar la
respuesta
frente a un
usuario válido y
contraseña
La aplicación de
reserva de un
vuelo debe ser
instalada
1. Lanzar la
aplicación
2. Introducir el
usuario
3. Introducir la
contraseña
4. Clicar el
botón OK
Usuario:
Miriam99
Contraseña:
AMARIS
Usuario: Miriam
Contraseña:
AMAris
Usuario: 9999
Contraseña:
amaris
Usuario se
loguea
satisfactoriame
nte
Post-conditions indican la tarea necesaria a ejecutar una vez que el test es completado
El ejemplo: El tiempo y las fecha de loqueo es guardada en la base de datos
67
RESULTADOS
Escenari
o
Test Case Pre-
Conditio
ns
Test
Steps
Test
Data
Resultad
os
Esperado
s
Actual
Results PASS/F
AIL
Verificar la
funcionalida
d de logueo
Verificar la
respuesta
frente a un
usuario
válido y
contraseña
La aplicación
de reserva
de un vuelo
debe ser
instalada
1. Lanzar la
aplicación
2. Introducir
el usuario
3. Introducir
la
contraseña
4. Clicar el
botón OK
Usuario:
Miriam99
Contraseña:
AMARIS
Usuario:
Miriam
Contraseña:
AMAris
Usuario:
9999
Contraseña:
amaris
Usuario se
loguea
satisfactoria
mente
Logue con
éxito
PASS
68
TÉCNICAS DEL TESTEO
No es posible verificar absolutamente todas las
condiciones de la aplicación. Las tecnicas de casos de
prueba ayudan a seleccionar los casos de prueba con
una posibilidad mayor de encontrar defectos
Boundary Value Analysis (BVA): Técnica que define las pruebas de
frontera/límites para la gama especificada de valores
Partición de Equivalencia (PE): Técnica que particiona y agrupa
casos que tienen el mismo comportamiento
Transición de estados: Este método es usado cuando el
comportamiento del software cambia de un estado a otro
siguiendo una acción particular
Error Guessing: Anticipación a los posibles errores que puedan ser
detectados durante el testeo. No es un método formal y depende
de la experiencia del terster
69
CONSIDERACIONES AL ESCRIBIR CASOS DE PRUEBA
1. Los casos de prueba deben ser simples y transparentes
2. Crear casos de prueba considerando el usuario final
3. Evitar repetir casos de prueba
4. No tener asunciones
5. Asegurar el 100% de la cobertura
6. Casos de prueba indentificado por un ID
7. Implementar tecnicas de escritura de casos
8. Revisión de los casos de prueba
70
MATRIZ TRAZABILIDAD
Si los requerimientos son numerados y son
referenciados en una test suit sería muy fácil trazar los
casos de prueba que son afectados por un cambio. Esto
no es nada más que trazabilidad
La matriz de trazabilidad linca un requerimiento con su
correspondiente requerimiento funcional y por tanto sus
correspondientes casos de prueba
Si un caso de prueba falla, la trazabilidad ayuda a
determinar la correspondiente funcionalidad facilmente
Asegura que todos los requerimientos son testeados
71
• Partición de equivalencia y Análisis de agrupación de valores
• Tabla de decisión
• Diagrama de transición de estados
• Caso de Uso
• Testing Review
TÉCNCAS DE TESTEO
27/05/2013
72
TECNICAS DE TESTEO
Hemos aprendido que el testing exhaustivo
no es posible
Se necesitan técnicas para indentificar casos
de pruebas con la mayor probabilidad de
encontrar defectos
Hay muchas técnicas de diseño de casos de
prueba
73
PARTICIÓN DE EQUIVALENCIA
Es una técnica de caja negra la cual se puede aplicar en
todos los niveles de testing como unit, integration,
system etc.
Divide un juego de condiciones de prueba en
particiones que son consideradas la misma
Ejemplo: Tickets en la reserva de un vuelo
Valores entre 1 -10 son considerados válidos para reservar
Valores entre 11 y 99 son considerados inválidos – ERROR mesage
Introducir un valor igual a 100 o mayor: el múmero de ticket por
defecto será de dos dígitos
Introducir un valor igual a 0 o menor: el número de tickets por
defecto será 1
No es viable testear todos los valores, el números de casos de
prueba será mayor de 100
Dividimos los posibles valores en grupos donde el comportamiento
del sistema es considerado el mismo
74
PARTICIÓN DE EQUIVALENCIA
Las agrupaciones son denominadas
particiones de equivalencia o clases de
equivalencia
Se escoje un único valor para cada partición
La hipótesis detrás de esta técnica es que si
una condición/valor de la partición pasa, el
resto también
Si una condición falla, el resto de
condiciones en esa partición serán
consideradas fallidas
75
ANÁLISIS DE VALORES FRONTERA
En boundary values analysis, se testean
valores frontera de la partición de equivalencia
Ejemplo anterior:
Se verifican los valores 0, 1 , 10 y 11
Se testean los valores que constituyen los
límites de aceptación y fallo
Boundary values analysis también es
denominado como range checking
Las técnicas de partición de equivalencia y
valores frontera estan cercanamente
relacionadas y pueden ser usadas
conjuntamente en todos los niveles de testing
76
TABLA DE DECISIÓN
Es una manera de lidiar con combinaciones de valores
de entrada los cuales producen resultados diferentes
Ejemplo: Reserva de vuelo
Origen y destino vacios implica boton desactivado. Se introduce
como FALSE el origen y destino en la tabla de decisión
Origen seleccionado pero destino vacío implica botón desactivado.
Se registra origen a TRUE y el resto a FALSE
Origen vacío y destino seleccionado implica boton desactivado. Se
introduce como FALSE el destino en la tabla de decisión
Origen y destino seleccionados implica botón Activado. Valores a
TRUE en la tabla de decisión
Reglas 1, 2 y 3 permanecen igual. Por tanto solo se selecciona una
de ellas aparte de la regla 4
Esta técnica pone en claro el incremento de los
posibles valores de entrada. Combinaciones posible
2^n (n=10, 1024)
77
DIAGRAMA DE TRANSICIÓN DE ESTADOS
Esta técnica es ayuda cuando es requerido testear
diferentes transiciones en el sistema
Start 1º
intento
2º inten
to
3º inten
to
4º inten
to
Introducir
Usuario
Contraseña
correcta
Acceso
Cierre
Contraseña
Incorrecta
78
DIAGRAMA DE TRANSICIÓN DE ESTADOS
El diagrama es llamado State Chart o Graph
Hay 4 componentes principales
1. Estados del software
2. Transición desde un estado a otro
3. Evento que causa la transición
4. Acciones causadas por eventos
Start
Contraseña
correcta
Cierre
79
TABLA DE ESTADO – TRANSICIONES INVALIDAS
Contraseña
Correcta
Contraseña
Incorrecta
S1 - Start S6 S2
S2 – 1º Intento S6 S3
S3 – 2º Intento S6 S4
S4 – 3º Intento S6 S5
S5 – 4º Intento S6 S7
S6 - Acceso ? ?
S7 - Cierre - -
80
CASO DE USO
Esta técnica ayuda a identificar los casos de prueba que
cubren el sistema completo basados en transiciones
desde desde el comienzo al final
Un caso de uso es una descripción de un uso particular
del sistema por un usuario
Técnica usada en el desarrollo de casos de prueba en el
nivel de sistema o de aceptación
Escenario principal
de éxito
Pasos Descripción
A: Usuario
S: Sistema
1 A: Introducir usuario y
contraseña
2 S: Validar contraseña
3 S: Permitir acceso
Extensiones 2a Contraseña invalida
Mostrar mensaje de error y
preguntar por 4 intentos
2b Contraseña invalidada 4 veces
81
TESTING REVIEW
Review es una reunión donde se analiza el
funcionamiento del producto software y se
recomiendan cambios con el objetivo de mejorar la
calidad
Puede ser convocada para un documento de diseño,
especificaciones de los requerimientos del sistema,
codigo, test plan etc
Ayuda a detectar defecto de manera temprana en el
ciclo de vida del desarrollo y reduce costes
El equipo de testeo debe de estar presente en las
reuniones de revisión
82
FASES EN LA REUNIÓN DE REVISIÓN
Planning stage Enviar convocatoria con la localización y fecha, indicar la agenda y adjuntar la información necesaria
Kick Off (opcional) Revisión previa del motivo de la reunión. Los participanten deben tener conocimiento
Preparación Identificar defectos, comentarios y preguntas para la reunión
Asignación de roles Moderador
Autor
Anotador
Revisores
Re-work El autor aplica los cambios considerados durante la reunión
Seguimiento Verificación de los cambios por parte de los participantes
83
TIPOS DE REVISIÓN
Walk Through
Liderada por el autor
Revisión Técnica
Liderada por un moderador experto sin necesidad de la presencia
de QA manager
Inspección
Liderada por un moderador experto aplicando un criterio de
evaluación
84
• Estimación
• Test Plan
TEST MANAGEMENT
27/05/2013
85
ESTIMACIÓN
Estrategia Bottom - Up Basada en la estimación de tareas. Se indica la duración, las dependencias y recursos
Contribuidores individuales, expertos y miembros experimentados dan estimaciones
La idea es obtener una estimación de tests precisa gracias a la colaboración del equipo
Estrategia Top - Down Basada en la experiencia
Basada en en el tamaño (pequeño, mediano o grande) y complejidad (simple, moderado o complejo) del proyecto a partir de experiencias pasadas
Basado en el esfuerzo medio empleado en casos de prueba similares en el pasado
La mayoría de los proyectos usan estrategias top-down para estimar
La estimación de los casos de prueba puede verse afectada por otros factores como la presión, distribución geográfica del equipo etc
86
TEST PLAN
Scope (dentro del alcance) Ejemplo: functional testing, performance testing, load testing
Out of scope (fuera del alcance) Ejemplo: Platform testing, localization testing
Riesgos Riegos de proyecto
Ejemplo: Un miembro senior del equipo deja el proyecto sin previo aviso
Estimar la probabilidad y el impacto
Identificar la posible solución
Riesgos basados en la estrategia de testing Tiempo consumido
Budget
La estrategia de test
Estimaciones de casos de prueba
El equipo de testeo. Roles
Schedule
El test plan ayuda a monitorizar el progreso de varias actividades de testeo además de controlar acciones de cambio en caso del desvio respecto a las actividades planeadas
87
• Defectos
• Ciclo de vida del bug
• Testing Tools
DEFECTOS
27/05/2013
88
¿QUE ES UN DEFECTO?
Resultados actuales difieren de los resultados esperados
También denominado incidente, bug, problema o issue
¿Que información sería conveniente
para ayudar al desarrollador a
entender el defecto?
89
REPORTE DEL BUG
Defect_ID: Número identificativo para el defecto
Descripción: Información sobre el módulo en el cual el
defecto fué encontrado
Versión:
Pasos: Información para reproducir el problema
Fecha: Cuando el defecto fué encontrado
Referencia: Requerimientos, diseño, arquitectura
Estado: Abierto, en progreso, arreglado y cerrado
Reporter: Nombre/ID de quién lo encontró
Fixed by: Nomnre/ID de quién lo arregló
Fecha de cierre
Severidad: Impacto del defecto en la aplicación
Prioridad: Urgencia
90
CICLO DE VIDA DE UN BUG
Tester encuentra un
defecto
Manager de desarrollo analiza el defecto
Estado = Nuevo
Valido
Estado = Rechazado
Alcance
Duplicado
Estado = Retrasado
Estado = Duplicado
Si Si
No No No
Code
Estado = En progreso
Code Fixed
Estado = Arreglado
Retesteo
PASS?
Estado = Cerrado
Estado = Reabierto
Si No
91
WEB TESTING
27/05/2013
92
¿Que es el testeo Web? Es un término para describir la verificación de una
plaicación Web frete a defectos antes de que el
código es llevado a producción
Durante este proceso se comprueba tanto la
seguridad, el funcionamient de la página, el acceso
por los usuarios como la habilidad de manejar el
tráfico
93
TESTING FUNCIONAL
Usado para verificar que el producto asegura los requerimientos funcionales. Las actividades de testeo son:
Testear todos los links en la página web Outgoing links
Internal links
MailTo links
Anchor links
Testear Forms Scripting para verificar que funcionan correctamente. Por ejemplo: se muestra un error si un campo no es rellenado
Verificar los valores por defecto son rellenados
Una vez rellenado, los datos son guardados en la base de datos o son lincados a una dirección de correo
Forms son formateados para una mejor legibilidad
Testear cookies Cookies son borradas cuando la cache es limpiada o expiran
Borrar un cookie y testear que las credenciales son solicitadas
Testear HTML y CSS Verificar la sintaxis
Legibles esquemas de colores
Asegurar estandares como W3C, OASIS, ISO
Testear business workflow Verificar End to End workflow/business escenarios que llevan al usuaro al completado de páginas web
Verificar escenarios negativos
94
USABILITY TESTING
Se ha convertido en una parte vital de cualquier
proyecto Web
Puede ser testeado por testers o incluso grupo de
usuarios
Testear la navegación de la página
Menus, botones o links que llevan a paginas diferentes deben ser
facilmente visibles y consistentes en todas las páginas
Testear el contenido
El contenido debe ser legible sin errores gramaticales
Si hay imagenes deben contener texto
95
INTERFACE TESTING
Hay tres areas a testear
Aplicación: Peticiones son enviadas correctamente a la base de
datos y la salida en pantalla por parte del cliente es mostrada
perfectamente. Los errores deben ser registrados y solo mostrados
al administrados
Web server: Manejo de todas las peticiones de cliente sin
problemas de servicio
Database server: Asegurar que las peticiones enviadas a la base de
datos dan los resultados esperados
Testear las respuestas del sistema cuando la
comunicación entre las tres ”layers” (aplicación, Web
y database) no puede ser establecida
Errores son mostrados al usuario final
96
DATABASE TESTING
La base de datos es un componente crítico en la
aplicación web y es importante verificar su
comportamiento frente a actividades de carga
Testear si los errores son mostrados cuando se ejecutan peticiones
La integridad de los datos se mantiene si se crean, actualizan o se
borran datos de la base de datos
Verificar el tiempo de respuesta
Testear la muestra de datos procedentes de la base de datos
97
COMPATIBILITY TESTING
Aseguran que la aplicación web es mostrada
correctamente en diferentes dispositivos.
Browser compatibility test: Misma website en
diferentes browsers es mostrada correctamente. Testear
si es mostrada sobre browsers, javascript, AJAX y la
autenticación funciona correctamente
Mobile browser compatibility
Operating System: Windows, Linux, Mac y browsers
como Firefox, IE, Safari etc
98
PERFORMANCE TESTING
Verificación frente a cargas Tiempo de respuesta de la aplicación Website a
diferentes velocidades de conexión
Tests de carga para verificar el comportamiento frente
a picos altos
Test de estres para determinar si hay un punto de
rotura frente a altos picos
Testear si la aplicación crashes, como se recupera?
Tecnicas de optimización como la compresión gzip
99
SECURITY & CROWD TESTING
Security testing es vital para los website de e-commerce
los cuales guardan información sensible de clientes
Verificar accesos desautorizados para securizar paginal
Ficheros restringidos deben no ser descargables sin un acceso
correcto
Verificar que las sesiones con un largo periodo de inactividad son
cerradas
Con el uso de certificados SSL, la pagina web debe ser
redireccionada a una página encriptada SSL
Se selecciona a un gran número de personas (crowd)
para ejecutar tests. Esto ayudar a encontrar defectos
escondidos
100
AUTOMATION TESTING
27/05/2013
101
¿POR QUÉ DEBEMOS AUTOMATIZAR
Automatizar es importante por las siguientes razones
El testeo manual de de los flujos de trabajo, los campos, los escenarios negativos implica un consumo de tiempo y costes elevados
Es complejo testear multi lenguajes de sitios manualmente
La automatización no requiere intervención humana
La automatización incrementa la velocidad de ejecución de los casos de prueba
La automatización ayuda a incrementar la cobertura de los tests
El testeo manual se puede convertir en aburrido y causar errores
102
¿QUE CASOS DE PRUEBA SE DEBEN AUTOMATIZAR?
Los casos de prueba automáticos pueden ser seleccionados siguiendo el siguiente criterio
Alto riesgo – casos de prueba críticos para el producto
Casos de prueba que son ejecutados repetidamente
Casos de prueba complejos de ejecutar manualmente o aburridos
Casos de prueba que requieren un consumo de tiempo elevado
Casos de prueba que no deben ser automatizados
Nuevos casos de prueba que aún no han sido ejecutados manualmente
Casos de pruebas en lo cuales los requerimientos cambian constantemente
Casos de prueba ejecutado de una manera ad-hoc
103
PROCESO DE AUTOMATIZACIÓN
Pasos a seguir en el proceso de
automatización
Selección de la herramienta Depende de la tecnología de construcción de la aplicación
a testear
Prueba de concepto de la herramienta
Selección de la herramienta
Definición del alcance de la automatización
Plan, diseño y desarrollo
Ejecución de los tests
Mantenimiento
104
PROCESO DE AUTOMATIZACIÓN
Definición del calcance de la automatización. Los siguientes puntos ayudan en determinar el alcance
Funcionalidad que es importante para el negocio
Escenario con una alta cantidad de datos
Funcionalidades comunes del producto
Complejidad de los casos de prueba
Viabilidad tecnica
Plan, diseño y desarrollo. Detalles en la estrategia de automatización
Herramienta seleccionada
Diseño del framework y sus funcionalidades
In-scope y Out-of-scope items de automatización
Preparación de test bed
Schedule y timeline de la ejecucion y desarrollo de los scripts
Entregas del testeo automático
105
PROCESO DE AUTOMATIZACIÓN
Ejecución de los tests Los scripts automáticos son ejecutados durante esta fase
Los scripts necesitan datos de entrada previos a ser
ejecutados
Una vez ejecutados proporcionan reportes
La ejecución pueder ser realizada por la herramienta de
automatización directamente o a través de la herramienta
de management
Mantenimiento Nuevas funcionalidades son añadidas al sistema con ciclos
excitosos
Los scripts automáticos necesitan ser añadidos, revisados y
mantenidos para cada release cycle
El mantenimiento se convierte necesario para mejorar la
efectividad de los scripts automáticos
106
COMO SELECCIONAR UNA HERRAMIENTA DE
AUTOMATIZACION
La selección de la herramienta es uno de los mayores
desafíos. Primero identifica los requerimientos, explora
varias herramientas y sus capacidades, realiza una
prueba de concepto
Soporte del entorno
Facilidad en el uso
Testeo de la base de datos
Testeo de imagenes
Lenguaje de scripting
Soporte para varios tipos de testeo – funcional, mobile etc
Facil de debugar
Reporte y resultdos extensivos
Training mínimo
107
OBTENER EL MAYOR PARTIDO DE LA
AUTOMATIZACIÓN
Las necesidades del alcance de la automatización
deben ser determinadas antes de estar el proyecto
Slecciona la herramienta apropiada. No debe ser
seleccionada por popularidad sino por cubrir mejor
los requerimientos
Escoger un framework apropiado
Estandares de scripting
Medición de las métricas Porcentaje de defectos encontrados
Tiempo requirido para automatizar en el ciclo de lanzamiento
(release cycle)
Tiempo mínimo tomado para el lanzamiento
Indice de satisfacción del cliente
Mejora en la productividad
108
BENEFICIOS
70% más rápido que los tests manuales
Más amplia cobertura de pruebas de las funcionalidad
Asegura consistencia
Reduce tiempo y coste
Mejora la precisión
Intervención humana no requerida
Mejor velocidad ejecutando los casos de prueba
Scripts reusables
Reducción del tiempo para el lanzamiento al mercado
109
PERFORMANCE TESTING
27/05/2013
110
¿QUE ES EL TETING DE PERFORMANCE?
Implica testear la aplicación software para asegurar un comportamiento aceptable frente a las espectativas de carga
Tiempo de respuesta es importante para el rendimiento
El objetivo del performance testing no es encontrar bugs sino eliminar cuellos de botella
Puntos de enfoque: Velocidad – Determina si la aplicación responde rapidamente
Escalabilidad – Determina la carga máxima de usuarios que la aplicación puede soportar
Estabilidad – Determina si la aplicación es estable frentre a varias cargas
111
¿POR QUÉ EL PERFORMANCE TESTING?
Cubre parte de las pruebas necesarias para la
mejora del producto antes de ser lanzado al
mercado
Sin performance testing, el software tendrá
problemas frente: Comportamiento lento frente a una carga simultánea de
usuarios
Inconsistencias debido a diferentes Operating systems
Pobre usabilidad
Determina si el software tiene una velocidad,
escalabilidad y estabilidad aceptable
112
TIPOS DE PERFORMANCE
Load testing – Verifica la habilidad de respuesta de la
aplicación frente a una previa carga
Stress testing – tráfico alto o procesamiento de datos.
El objetivo es identificar puntos de rotura de la
aplicación
Endurance testing – Comportamiento de la aplicación
frente a una carga durante un periodo largo de tiempo
Volume testing – Monitorización del comportamiento
del sistema frente a un volumen de datos altos en la
base de datos
Scalabilty testing – Determinar la efectividad del
software mediante el incremento del volumen de
usuarios
113
PROBLEMAS COMUNES EN EL PERFORMANCE
Largo tiempo de carga – Load time es normalmente el
tiempo inicial tomado por la aplicación para arrancar
Pobre tiempo de respuesta – tiempo consumido por el
usuario desde hacer una petición has tener respuesta.
Debería ser muy rápido, en caso contrario, el usuario
pierde interes
Pobre escalabilidad – No poder atender a un número
esperado de usuarios
Cuello de botella – Obstrucciones en el sistema las
cuales degradan el performance de la aplicación
Utilización de la CPU
Utilizaciñon de la memoria
Utilización de la red
Limitaciones en el OS
Uso del disco
114
PROCESO DEL PERFORMANCE TESTING
La metodología doptada depende depende de los
objetivos de los tests de performance. El proceso
generico es el siguiente
Identificar el entorno de test
Determinar el criterio de performance
Plan y diseño
Configurar el entorno de test
Imprementar los test diseñados
Ejecutar los tests
Analizar y retestear
115
PROCESO DEL PERFORMANCE TESTING
Identificar el entorno de testeo Conocer el entorno físico de testeo, el entorno de producción y que herramientas de testeo estan disponibles
Entender los detalles del hardware, software y configuración de red
Identificar el criterio de aceptación de performance Objetivos y problemas del throughput, tiempos de respuesta y localización de los recursos
Identificar los criterios de éxito del proyecto fuera de estos objetivos y problemas
Planificar y diseñar los test de performance Identificar los escenarios para testear todos los posibles casos de uso
Es necesario simular una variedad de usuarios, test data y describir que métricas serán obtenidas
Configuración del entorno
Implementar los tests diseñados
Ejecutar los tests
Analizar y Re-testear Consolidar, analizar y compartir los resultados
116
RESUMEN
Performance testing es necesario antes
de el lanzamiento de cualquier producto
al mercado
Asegura la satisfacción del usuario y
protege la inversión de los inversores
frente fallos del producto
El coste del performance es usualmente
compensado con la satisfacción del
cliente, la lealtad y su respectiva
retención de uso
117