Testing y algo más . . .

1. Testing y algo más . . . andres.grosso@engee.com.ar

2. 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 procesoquecompara “lo quees” con “lo quedebería ser”.

3. 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

4. ¿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.).

5. Etapas de un proyecto de Testing Preparaciónambiente Startup Ejecución Seguimiento de incidentes Definicióncasos

6. 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.

7. Másdefiniciones • 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 Testingsolo 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.

8. Másdefiniciones • 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.

9. Másdefiniciones • 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 agregarunanuevafuncionalidad, se vuelven a probar (casosmásimportantes) de lasfuncionalidadesyaexistentes.

10. ¿Por qué siempre hay que volver a probar? Joshua Bloch–JDK (java.util.Arrays): int mid = (low + high) / 2; public static intbinarySearch(int[] a, int key) {int low = 0;int high = a.length - 1; while (low <= high) {intmidVal = 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 unapresentación de Ernesto Kiszkurno

11. Técnicas de testing • Estático • Buscanfallassobre el sistema en reposo. • Se puedeaplicarsobreartefactos 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 • CajaNegra: Requerimientos • Caja Blanca: Código

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

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

14. Testing estático Técnicas • Auditorías • Preparada • Sin presentador • Auditor y auditado • Informes

15. Break 5 minutos

16. 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 • Verificanque el sistema/móduloestélistoparasuuso • De Usabilidad • Verifican la calidad de uso

17. Testing dinámico Niveles de testing • De Volumen • Verificanque el sistemasoportegrandesvolumenes de datos • De Performance • Verificanque el sistema se encuentredentro de los parámetros de performance definidos • Stress • Verificanque el sistemasoportegrandescargas de procesamiento • Del Sistema (o Sub-Sistema) • Pruebasenfocadas a los requerimientosoriginales

18. 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.

19. Testing dinámico Testing automatizado • Escribirprogramasparaquerealicenpruebasque se haríanmanualmente. • Ventajas • Ejecutamáspruebas en menostiempo. • Efectuapruebasmuydificiles de realizarmanualmente. • Integracióncontinúay desplieguecontinuo. • Desventajas • No reemplazanlaspruebasmanuales, lascomplementan. • Encuentranmenosdefectosquelaspruebasmanuales. • Aplicarlobien, requiere un gran esfuerzo. • Hay que saber dónde y cuantoaplicarlo!

20. Testing dinámico Testing automatizado Herramientas JMeter Selenium Selenium RC Python Ruby Quick Test Professional – QTP Cacique

21. Testing dinámico Testing automatizado Otrasherramientas NUnit moq Testlink Bugzilla, Mantis, etc. Visual Studio ForTesters

22. 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 • Definir y ejecutar el testing al mismo tiempo (testing intuitivo). • Risk-basedTesting • 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.). • DeliveryTesting • Testear el website en un ambiente real o con sus condiciones.

23. Testing dinámico Otrosnombres • FuzzTesting • Automatizada o semi-automatizada. • Proveeingreso de datosinválidos, inesperados y aleatorios en búsqueda de excepciones y caídas. • Utilizadocomumenteparadetectarproblemas de seguridado robustez. • SmokeTesting • Primer test realizadodespués de un release (pruebasbásicas). • Determinasiesposiblecontinuar con el testing (pruebasmásintensas). • Generalmenteutilizadoparavalidar un pasaje al ambiente de testing. • Sanity Testing • Generalmenteutilizadodespués de un smoke test. Validatambién un pasaje a test. • Ejecución de un pequeñoconjunto de funcionalidades. • Determinasi la lógica de funcionamiento del programaescorrecta. • PairwiseTesting • Para cada par de parámetros prueba todas las combinaciones posibles

24. Deteccióntardía

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