Your SlideShare is downloading. ×
Testing en aplicaciones móviles iOS, Android
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Testing en aplicaciones móviles iOS, Android

9,031
views

Published on

Sesión de formación realizada por SlashMobility enfocada al Testing de las aplicaciones móviles (Mobile Apps): IPhone, IOs, Android, BlackBerry...

Sesión de formación realizada por SlashMobility enfocada al Testing de las aplicaciones móviles (Mobile Apps): IPhone, IOs, Android, BlackBerry...

Published in: Technology

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,031
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Sesión 1 – Testing
    Jose Cortés
    SlashMobility
  • 2. LET’S TEST IT!
    Testing
    • Procesos que permiten verificar y revelar la calidad de un producto software.
    • 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 producto
    Program 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
  • 7. Alcance del testing
    • Se pueden realizar testing de aspectos funcionales y no-funcionales:
    • 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
    • 14. Rendimiento: lo que la app hace, lo hace bien
  • Testing y bugs
    • ¿Pruebas? Tengo otras cosas que hacer…!!
    • 15. Cuanto antes aparezca un fallo menos cuesta solventarlo (en $$ y tiempo)
  • ¿Qué testear?
    • Fallo común: testear aspectos no requeridos en la aplicación:
    • 16. ¡La estrategia de testing dependerá de los requerimientos!
  • ¿Cómo testear?
    • ¿Testeamos todas las posibles combinaciones?
    • 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-approach
    10^90 posibles posiciones
  • 23. Testing: boxapproach
    • Metáfora para visualizar las funcionalidades.
    • 24. Desde fuera la funcionalidad sólo nos importa lo que hace, no COMO lo hace (black-box).
    • 25. Desde dentro de la funcionalidad, nos importan los detalles y cómo se llevan a cabo (white-box)
  • Testing: white-box
    • Testeamos la App conociendo sus componentes internos: funciones, algoritmos, estructuras de datos…
    • 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.
    • 32. Algoritmo tarda 1ms en ordenar 100 elementos. Si la aplicación tiene 500 millones, no cumplirá los requisitos funcionales.
  • Testing: black-box
    • Testeamos la App sin conocimiento interno de la aplicación.
    • 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
    • 41. Si tenemos cemento testeado correctamente
  • Testing: clasificación
    • Durante el ciclo de vida del software:
    • 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
    • 48. Acceptancetests: realizado por el cliente para validar que todo está correcto.
  • Testing en Apps Móviles
    • TestingApps Móviles vs otros entornos (WEB) muy diferente.
    • 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…
    • 51. Hay requerimientos funcionales y no-funcionales inherentes: batería, llamadas entrantes, soporte multidispositivos…
  • Testing en Apps Móviles: Testing Interface
    • Validación de botones, inputs de texto…
    • 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?)
    • 54. ¿Qué pasa cuando cambia la orientación del dispositivo?¿y si se hace muy rápido?
  • Testing en Apps Móviles: Usabilidad
    • ¿Es fácil navegar entre pantallas o hay que realizar combinaciones esotéricas?
    • 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!
    • 61. Verificación de las funcionalidades OFFLINE / ONLINE. ¿el usuario va a perder información al enviarla a un server por haber perdido la cobertura temporalmente?
  • Testing en Apps Móviles: Performance
    • ¿Qué pasa si la conexión a un server se hace por 3G en lugar de WIFI?¿y en 2G?
    • 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?
    • 67. ¿Liberamos los recursos (GPS, cámara de fotos) que reservamos?
  • Testing en Apps Móviles: Seguridad
    • Los envíos/recepción de datos sensibles deben ir codificados: CODIFICACIÓN + AUTENTICACIÓN (HMAC-SHA)
    • 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
    • 71. Soporte de multiusuarios sin que interfieran los datos entre ellos
  • Testing en Apps Móviles: Servicios
    • Las Apps móviles deben actuar como clientes, no como servidores.
    • 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?
    • 74. ¿Qué pasa si se intenta acceder a un Servicio sin conexión?¿Y si cae la conexión durante la transmisión de info?
  • Testing en Apps Móviles: Recursos de bajo nivel
    • ¿La App está generando “basura” de algún tipo? Ficheros temporales sin limpiar, base de datos local creciendo demasiado…
    • 75. ¿Estamos utilizando correctamente los sensores?¿Liberamos el GPS?¿Hacemos más llamadas al servidor de las que tocan?
    • 76. ¿Usamos demasiada memoria o no la liberamos correctamente?
  • Testing en Apps Móviles: Operacional
    • ¿Estamos “backupeando” información necesaria en la App?
    • 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?
    • 80. ¿La batería parece bajar radicalmente con el uso de nuestra App?
  • Testing en Apps Móviles: Compatibilidad, multidispositivo y entornos
    • ¿Se ha validado la App en los dispositivos, versiones de SO y modelos acordados?
    • 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?
    • 83. ¿Puede nuestra aplicación afectar a los sistemas de terceros? ¿Puede poner en riesgo los sistemas de otros o degradarlos?
  • Testing: casos prácticos SIT10
  • 84. Testing: casos prácticos LetsBonus
  • 85. Testing: casos prácticos Push-cars