Taller introductorio al testing, primera clase de una capacitación que realiza Engee IT.

1. Desarrollo de software e Ingeniería de calidad

2. Conceptos e
Introducción

3. • Ingeniero en Sistemas – CAECE.
• +10 años de experiencia en calidad
• QA Manager Engee IT
nicolas.pintos@engee.com.ar
www.linkedin.com/in/NicolasPintosBarreto/ Auditor interno
ISO 9001:2008
Nicolás Pintos Barreto
Nosotros

4. andres.grosso@engee.com.ar
ar.linkedin.com/in/andresgrosso
Auditor interno
ISO 9001:2008
Andrés Grosso
Nosotros
• Analista de Sistemas de Computación – O.R.T.
• +10 años de experiencia en software
• Creador del patrón criteria
• COO en Engee IT
twitter.com/yairgrosso

5. Según IEEE standard 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
Testing

6.  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
 Un buen nivel de calidad implica un diseño
correcto y un producto de acuerdo con su diseño.
Conceptos
Calidad

7.  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.
¿QA o QC?

8. En otras palabras, QA es proactivo ya que trata
sobre los procesos y cómo prevenir defectos.
Mientras que QC es reactivo, ya que trata sobre
los productos y como encontrar defectos .
En criollo

9. Etapas de un proyecto de Testing
Startup
Preparación
ambiente
Definición
casos
EJECUCIÓN
Seguimiento
de incidentes

10.  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.
Definiciones

11.  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.
Relación entre
error, defecto
y falla

12.  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
Definiciones

13.  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.
 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.
Definiciones

14.  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.
Definiciones

15. ¿Por qué siempre
hay que volver a
probar?
public static int binarySearch(int[] a, int key) {
int low = 0;
int high = a.length - 1;
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.
}
Joshua Bloch–JDK (java.util.Arrays):
int mid = (low + high) / 2;

16. 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.
Técnicas de Testing
Estático
Se ejecuta y observa el comportamiento
de un producto.
Estímulo  Proceso  Respuesta
Tipos
 Caja Negra: Requerimientos
 Caja Blanca: Código
DinámicoE D

17.  Tipos de problemas que se
encuentran
 Indefiniciones
 Inconsistencias
 Qué revisar
 Requerimientos
 Diseños
 Casos de pruebas
 Planes de proyecto
Revisión de la
documentación
Testing EstáticoE

18. Walkthroughs
- Presentador
- Sin preparación de los
participantes
- Gran cantidad de
participantes
- Sin informe
Técnicas
Testing EstáticoE
Inspecciones (peer-reviews)
- Presentador
- Con preparación de los
participantes
- Informe
- Generalmente 2 a 4
participantes
Auditorías
- Preparada
- Sin presentador
- Auditor y auditado
- Informes

19. Break
5 minutos

20.  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ámicoD
Niveles de
Testing

21.  De Volumen: Verifican que el sistema soporte
grandes volúmenes 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ámicoD
Niveles de
Testing

22.  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.
Técnicas de derivación de casos de prueba
Testing DinámicoD

23.  Escribir programas para que realicen pruebas que se harían manualmente.
 Ventajas
 Ejecuta más pruebas en menos tiempo.
 Efectúa pruebas muy difíciles 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!
Técnicas automatizado
Testing DinámicoD

24. Herramientas
Testing DinámicoD Automatización

25. Otras Herramientas
Testing DinámicoD Automatización

26. Testing Independiente
 El que desarrolla no prueba.
 Mayor experiencia y concentración.
 Nadie está motivado para encontrar sus propios errores.
Test exploratorio
 Definir y ejecutar el testing al mismo tiempo (testing intuitivo).
Risk-based Testing
 Priorizar los componentes y los tipos de testing más críticos.
Testing de Contenidos
 Ortografía.
 Gramática.
Testing manual – Algunos Nombres
Testing DinámicoD Automatización

27.  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.
 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.
Testing manual – Algunos Nombres
Testing DinámicoD Automatización

28.  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
Testing manual – Algunos Nombres
Testing DinámicoD Automatización

29. Detección tardía

30.  Analítico
 Perfeccionista
 Creativo
 Capacidad de abstracción y
modelado
 Facilidad de comunicación
 Pensamiento crítico
 Pragmatismo
 Aptitudes para el trabajo en
equipo
Perfil del Tester

31. Nuestro objetivo es
desarrollar un software
con 0 bugs.
Pagaré un bono de 10
dólares por cada bug que
encuentren y arreglen.
¡¡Somos ricos!! Espero que esto conlleve
al comportamiento
correcto.
Me “escribiré” una nueva
minivan esta tarde!
¿Preguntas?