Este documento presenta los conceptos fundamentales del testing de software. Explica que el testing permite verificar la calidad de un producto software asegurando que funcione como se espera de forma eficiente y efectiva. También describe diferentes estrategias de testing como el testing funcional, no funcional, de caja negra y blanca, así como consideraciones importantes para el testing de aplicaciones móviles como la interfaz, usabilidad, rendimiento y seguridad.

1. Sesión 1 – Testing Jose Cortés SlashMobility

3. Es decir: que las aplicaciones funcionen como se espera que lo hagan y de forma eficiente y efectiva.

4. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un productoProgram testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

5. Testing: ¿para qué? + =

6. BUG! Ordenador Mark II Bug encontrado por Grace Murray Hopper

8. FUNCIONAL: ¿Puede el usuario realizar una acción? ¿funciona correctamente una parte de la App? => APP FUNCIONA

9. NO FUNCIONAL: Aspectos no relacionados con acciones o funcionalidades: rendimiento, seguridad … => CALIDAD:

10. Testeabilidad: los componentes sean fácilmente aislables.

11. Escalabilidad: se pueden añadir cambios no-traumáticos

12. Mantenibilidad: fácil de modificar

13. Usabilidad: no hay que hacer maniobras “extrañas” para usarlo

17. ¿ Testeamos sólo algunas partes? Si hay algún bug remoto, quizás no lo encuentren… (una posibilidad entre 1.000)

18. Posibilidad de que 1 usuario NO encuentre bug: 99’99%

19. Posibilidad de que 2 usuarios NO encuentren bug: 99’98 %

20. Probabilidad de que 1.000 usuarios NO encuentren bug: 90’4%

21. Probabilidad de que 100.000 usuarios NO encuentren bug: 4’5%

22. Debemos definir estrategia de testing para buscar un punto medio: nosotros utilizaremos estrategias inspiradas en box-approach10^90 posibles posiciones

24. Desde fuera la funcionalidad sólo nos importa lo que hace, no COMO lo hace (black-box).

26. Perspectiva interna: vemos el mundo desde el interior.

27. Ejemplos:

28. Validación de la API de la aplicación (clases, métodos…)

29. Code-coverage: requerimiento que en los tests se ejecuten el 90% de las líneas de código.

30. Problemas: no puede detectar errores funcionales.

31. Podemos testear la clase Oferta, sus métodos, el Controlador que utiliza esta clase, pero no cómo se está utilizando.

33. Perspectiva externa: vemos el mundo desde el espacio

34. Dada una entrada el componente debe devolver una salida concreta.

35. Testing de una función que dados X y Y, devuelve la multiplicación.

36. Al introducir un texto se devuelve una lista que coincida con el texto

37. Testing de un componente que devuelve la ubicación.

38. Ventajas:

39. Si tenemos ladrillos testeados correctamente

40. Si tenemos vigas testeadas correctamente

42. Unittesting (ComponentTesting): validan código, normalmente funciones y clases (WB). Útil para encontrar casos “raros” (corner cases)

43. Integrationtesting: verifican los “conectores” entre los componentes (APIs, servicios…)

44. SystemTesting: Verifica todo en conjunto.

45. SystemIntegrationTesting: Integración con sistemas de terceros.

46. Por objetivos:

47. Regressiontests: se buscan bugs que vuelven al asalto

49. Testing en Web es feliz, rosa y la persona se puede simplificar en “clicks”

50. Testing en Apps Móviles puede ser infernal: hay que gestionar sensores, el usuario puede cambiar orientación del dispositivo, darle patadas…

52. Validar cada pantalla de forma integral (¿hace lo que se supone que debe hacer?)

53. Validar el flujo de navegación (¿desde la pantalla de listado de restaurantes puedo acceder a los favoritos?)

55. ¿Se muestra información redundante y que no aporta valor?

56. ¿Se puede visualizar en el idioma que corresponde?

57. TODAS (repetimos, TODAS) las interacciones del usuario con el sistema debe generar algún tipo de FEEDBACK!

58. Clicks en botones

59. Llamadas a través de Internet

60. Cualquier operación POTENCIALMENTE lenta: suponer siempre el caso peor!

62. ¿Qué pasa si se debe enviar/recibir mucha información de un servicio web?

63. ¿Las imágenes que usamos son del tamaño “adecuado”?

64. Optimizar: código redundante => ciclos de CPU => +consumo batería => usuario infeliza

65. ¿Cumple la App con los tiempos exigidos por los usuarios?

66. ¿Existen memoryleaks?

68. Detección de puntos en la app que puedan recibir información maliciosa. Corolario: el server no es nuestro amigo (necesariamente)

69. No suponer: ¡el mundo es malvado, cruel y vil!

70. Cualquier archivo que guardemos en la aplicación puede llegar a manos de terceros

72. Debemos validar qué pasa cuando se cae un Servicio, devuelve respuestas mal formadas, errores controlados…

73. ¿Qué pasa si el Servicio tarda demasiado en responder?

75. ¿Estamos utilizando correctamente los sensores?¿Liberamos el GPS?¿Hacemos más llamadas al servidor de las que tocan?

77. ¿Estamos preparados para el modo “espantada”? Si muere la batería, necesitamos tener un plan de Save y Recovery

78. ¿Si se actualiza a una nueva versión del Market correspondiente, se pierden datos?

79. ¿Qué pasa si llaman mientras estamos utilizando la App?¿Y si llega un SMS?

81. ¿Cómo se comporta la aplicación en distintas pantallas y resoluciones?

82. ¿Qué pasa si el servidor de integración cambia?¿Se soporta bien el cambio y sin traumas?

84. Testing: casos prácticos LetsBonus

85. Testing: casos prácticos Push-cars