Testing
y algo más . . .
[email protected]
Conceptos - Testing
• Según IEEE standards 1999. “El testing de software es el proceso
de analizar un producto de software para detectar las diferencias
entre el comportamiento real con el pedido, y para evaluar las
funcionalidades y características no funcionales del software”.
• O sea, es el proceso que compara “lo que es” con “lo que
debería ser”.
Conceptos - Calidad
• Aptitud del producto o servicio para satisfacer las
necesidades del usuario.
• Propiedad o conjunto de propiedades inherentes a algo,
que permiten juzgar su valor.
• Cualidad de un producto de software
¿QA o QC?
•
Mito
 Las tareas de testing muchas veces son mal llamadas como QA (Aseguramiento de la calidad),
cuando en realidad estas tareas son de QC (Control de Calidad).
•
Aseguramiento de la calidad (QA)
 Plantear, organizar, dirigir y controlar la calidad en un sistema con el objetivo de dar al cliente
productos con la calidad adecuada.
•
Control de calidad (QC)
 Mecanismos, acciones y herramientas que se utilizan para detectar la presencia de errores.
•
En otras palabras, QA es proactivo ya que trata sobre los procesos y cómo prevenir
defectos (por ej.: definición de procesos, entrenamiento, auditorías, etc.), mientras que
QC es reactivo, ya que trata sobre los productos y como encontrar defectos (por ej.:
testing, revisiones por pares, inspecciones, etc.).
Etapas de un proyecto de Testing
Preparación
ambiente
Startup
Ejecución
Definición
casos
Seguimiento
de
incidentes
Definiciones
•
Error
 Equivocación cometida por un humano durante el proceso de desarrollo.
•
Defecto (defect o fault)
 Consecuencia de un error: están presentes en un producto de software. La presencia de un
defecto diferencia un producto correcto de uno incorrecto.
•
Fallo (failure)
 Manifestación del defecto: diferencia entre los resultados esperados y reales.
Relación entre error, defecto y falla
•
Un error lleva a uno o más defectos, que están presentes en el código.
•
Un defecto lleva a cero, una o más fallas.
•
La falla es la manifestación del defecto.
•
Una falla tiene que ver con uno o más defectos.
Más definiciones
•
Testear

Ejecutar un programa con el objeto de identificar fallos, comparando el resultado esperado con
el resultado obtenido a partir de la ejecución.
•
Axiomas del testing
 “El Testing solo puede mostrar la presencia de defectos, no su ausencia”. (Dijkstra)
 El objetivo del testing es encontrar errores.
 Un test solo es exitoso si encuentra errores.
 Cuando cumplimos el rol de Tester debemos ser creativos… pero para destruir.
 Bug cero = falacia
•
Cobertura o Cubrimiento
 Es una medida de qué tan completo fue el testing (en función de una estrategia particular).
 Toda estrategia tiene asociado su concepto de cobertura.
Más definiciones
• Casos de prueba
 Descripciones de qué se va a probar.
 Crear casos es un proceso creativo.
• Datos de prueba
 Lotes de datos necesarios para ejecutar un caso de test.
 Crear datos de test es un proceso laborioso, y muy poco creativo.
Más definiciones
• Test Limpio (o positivo)
 Intenta mostrar que el producto satisface sus requerimientos.
• Test Sucio (o negativo)
 El objetivo es romper el sistema.
• Test de regresión
 Luego de agregar una nueva funcionalidad, se vuelven a probar
(casos más importantes) de las funcionalidades ya existentes.
¿Por qué siempre hay que volver
a probar?
Joshua Bloch–JDK (java.util.Arrays):
public static int binarySearch(int[] a, int key) {
int low = 0;
int high = a.length - 1;
int mid = (low + high) / 2;
while (low <= high) {
int midVal = a[mid];
if (midVal < key)
low = mid + 1
else if (midVal > key)
high = mid - 1;
else
return mid; // key found
}
return -(low + 1); // key not found.
}
Sacado de una presentación de Ernesto Kiszkurno
Técnicas de testing
• Estático
 Buscan fallas sobre el sistema en reposo.
 Se puede aplicar sobre artefactos de requerimientos, análisis, diseño y
código.
 Técnicas: Revisiones, Inspecciones, Walkthrough y Auditorías de calidad.
• Dinámico
 Se ejecuta y observa el comportamiento de un producto.
Estímulo  Proceso  Respuesta
 Tipos
 Caja Negra: Requerimientos
 Caja Blanca: Código
Testing estático
Revisiones de documentación
• Tipos de problemas que se encuentran
 Indefiniciones
 Inconsistencias
• Qué revisar
 Requerimientos
 Diseños
 Casos de pruebas
 Planes de proyecto
Testing estático
Técnicas
• Inspecciones (peer-reviews)
• Presentador
• Con preparación de los participantes
• Informe
• Generalmente 2 a 4 partcipantes
• Walkthroughs
• Presentador
• Sin preparación de los partcipantes
• Gran cantidad de partcipantes
• Sin informe
Testing estático
Técnicas
• Auditorías
• Preparada
• Sin presentador
• Auditor y auditado
• Informes
Break
• 5 minutos 
Testing dinámico
Niveles de testing
• De Unidades
• Pruebas de módulos, funcionalidades, etc. de forma unitaria
• De Integración
• Pruebas de módulos, funcionalidades, etc. de forma conjunta
• De Aceptación del Usuario
• Verifican que el sistema/módulo esté listo para su uso
• De Usabilidad
• Verifican la calidad de uso
Testing dinámico
Niveles de testing
• De Volumen
• Verifican que el sistema soporte grandes volumenes de datos
• De Performance
• Verifican que el sistema se encuentre dentro de los parámetros de
performance definidos
• Stress
• Verifican que el sistema soporte grandes cargas de procesamiento
• Del Sistema (o Sub-Sistema)
• Pruebas enfocadas a los requerimientos originales
Testing dinámico
Técnicas de derivación de casos de
prueba
•
Partición de equivalencias
 Particiona el dominio de entrada en un conjunto de clases de entrada (o
inputs) que tienen comportamientos similares .
 Luego se selecciona un valor representativo de cada partición para ser
testeado.
•
Análisis de condiciones de borde
 Variación de la técnica de partición de equivalencias, que se focaliza en los
bordes de cada clase de equivalencia: por arriba y por debajo de cada clase.
•
Test de robustez
 Es una variación de la técnica de análisis de borde.
 Consiste en ingresar no un valor apenas superior al máximo, valor sino
muchísimo mayor, y un valor muchísimo inferior al mínimo valor.
Testing dinámico
Testing automatizado
•
Escribir programas para que realicen pruebas que se harían manualmente.
•
Ventajas
 Ejecuta más pruebas en menos tiempo.
 Efectua pruebas muy dificiles de realizar manualmente.
 Integración continúa y despliegue continuo.
•
Desventajas
 No reemplazan las pruebas manuales, las complementan.
 Encuentran menos defectos que las pruebas manuales.
 Aplicarlo bien, requiere un gran esfuerzo.
• Hay que saber dónde y cuanto aplicarlo!
Testing dinámico
Testing automatizado
Herramientas
• JMeter
• Selenium
• Selenium RC
• Python
• Ruby
• Quick Test Professional – QTP
• Cacique
Testing dinámico
Testing automatizado
Otras herramientas
• NUnit
• moq
• Testlink
• Bugzilla, Mantis, etc.
• Visual Studio For Testers
Testing dinámico
Testing Manual – Algunos nombres
•
•
Testing Independiente

El que desarrolla no prueba.

Mayor experiencia y concentración.

Nadie está motivado para encontrar sus propios errores.
Test exploratorio

•
Risk-based Testing

•
•
Definir y ejecutar el testing al mismo tiempo (testing intuitivo).
Priorizar los componentes y los tipos de testing más críticos.
Testing de Contenidos

Ortografía.

Gramática.
Testing de Compatibilidad

Verificar que la aplicación funciona en distintas plataformas existentes en el mercado (browsers, SOS,
etc.).
•
Delivery Testing

Testear el website en un ambiente real o con sus condiciones.
Testing dinámico
Otros nombres
•
Fuzz Testing
 Automatizada o semi-automatizada.
 Provee ingreso de datos inválidos, inesperados y aleatorios en búsqueda de excepciones y
caídas.
 Utilizado comumente para detectar problemas de seguridad o robustez.
•
Smoke Testing
 Primer test realizado después de un release (pruebas básicas).
 Determina si es posible continuar con el testing (pruebas más intensas).
 Generalmente utilizado para validar un pasaje al ambiente de testing.
•
Sanity Testing
 Generalmente utilizado después de un smoke test. Valida también un pasaje a test.
 Ejecución de un pequeño conjunto de funcionalidades.
 Determina si la lógica de funcionamiento del programa es correcta.
•
Pairwise Testing
 Para cada par de parámetros prueba todas las combinaciones posibles
Detección tardía
¿Preguntas?
Nuestro objetivo es
desarrollar un software con
0 bugs.
Pagaré un bono de 10
dolares por cada bug que
encuentren y arreglen.
Somos ricos!!
Espero que esto conlleve al
comportamiento correcto.
Me escribiré una nueva
minivan esta tarde!
Descargar

descarguen