¿Cómo escribir Tests de Aceptación?

banner

Una habilidad clave para el Tester Agil

A partir de la proliferación de las metodologías ágiles, el rol del Tester ha sufrido un proceso de mutación. En las metodologías tradicionales, el Tester escribía casos de prueba detallados, partiendo de un documento funcional escrito por un Analista, incluso antes de que se escribiera la primera línea de código del proyecto. En el mundo Agil, en cambio, el documento funcional no existe, por lo que el Tester deberá completar las especificaciones para cada historia de usuario (user story), generalmente en forma de Tests de Aceptación.

descarga

¿Qué son los Tests de Aceptación?

A diferencia de las especificaciones tradicionales, las historias de usuario tienen un enfoque de negocio y están escritas por una persona con ese perfil (Product Owner).Típicamente, la historia de usuario tiene el siguiente formato:

Como usuario (X)… Quiero (Y)… De manera que (Z)…

(Y) representa una funcionalidad, (Z) es el beneficio para el negocio y (X) es la persona o rol que se beneficiará con esa funcionalidad.

Como puede verse, las historias de usuario se concentran en qué debe hacer el software para satisfacer una necesidad de negocio, pero dicen poco y nada sobre cómo debe hacerlo.
Esto implica un desafío para todo el equipo, pero especialmente para el Tester, que será el encargado de averiguar y documentar cómo deben ser implementadas cada una de las funcionalidades que el cliente está solicitando.
Para ello se utilizan los Tests de Aceptación (*), también llamados Tests de Historia de Usuario (Acceptance Tests/Story Tests). Los Tests de Aceptación verifican que la historia de usuario se ha desarrollado correctamente y por consiguiente, entregará al usuario el valor esperado para su negocio.

¿Cómo se escriben los Tests de Aceptación?

En primer lugar, el Tester deberá tomar cada una de las historias de usuario y escribir los Tests de Aceptación que verifiquen la funcionalidad solicitada. El formato que se recomienda para escribir dichos Tests es el siguiente:

Si… (X)
Cuando… (Y)
Entonces… (Z)

(X) representa el contexto, todas aquellas condiciones que deben cumplirse para que el usuario pueda realizar la acción y, por lo tanto, ejecutarse el Test.
(Y) es la acción que el usuario va a realizar en el contexto definido previamente.
(Z) es la respuesta esperada del sistema ante las acciones del usuario detalladas previamente.

De esta manera, el Tester comenzará a especificar cómo deberá comportarse el software ante los diferentes escenarios que se vayan planteando, de acuerdo a la funcionalidad requerida por la historia de usuario.
Deberán considerarse la mayor cantidad de escenarios posibles, tanto los normales como los alternativos, intentando abarcar todos los modos de uso del software que estarán a disposición de los usuarios.

¿Y cuando me falta información?

El proceso de escribir los Tests de Aceptación es un proceso iterativo, no es algo de se realiza de una vez. El Tester deberá comenzar con un pequeño set de Tests de acuerdo a la información con la que cuente, y se espera que a partir de ahí, vaya refinando los tests. Es decir, agregando mayor detalle y escribiendo nuevos Tests, a partir de los escenarios que se van disparando cuando va consiguiendo nueva información.
Es evidente que en este proceso, es fundamental la comunicación. El Tester deberá mantenerse en contacto permanente con el Product Owner o con el Analista de Negocio, si lo hubiera, y formular todas las preguntas necesarias para abarcar el mayor número de escenarios posible, llevándolos al mismo tiempo al máximo nivel de detalle necesario.
Resulta imprescindible que el Tester sepa ubicarse en los zapatos del cliente y entender a fondo sus negocios y las necesidades que del mismo se derivan. A su vez, es clave que sepa formular las preguntas correctas para obtener los requisitos. Algunas de esas preguntas podrían ser:

¿Cuál es el objetivo de esta funcionalidad?
¿Qué roles tienen objetivos relacionados a la funcionalidad?
¿Cómo podemos saber que la funcionalidad entregada es la correcta?
¿Cuáles son las salidas que el cliente espera?
¿Qué harán los usuarios antes y después de utilizar esta funcionalidad en particular?
¿Qué es lo peor que podría pasar cuando el usuario utiliza esta funcionalidad? ¿Qué es lo mejor?
¿Se pueden obtener ejemplos de cómo el usuario va a utilizar esta funcionalidad?
¿Existen requerimientos no funcionales que deban tenerse en cuenta?

Estas son sólo algunas de las preguntas que pueden hacerse y normalmente, las respuestas nos dispararán nuevas preguntas. Es por eso que decimos que la escritura de Tests de Aceptación es un proceso iterativo, que se irá refinando con el tiempo, a medida que vayamos obteniendo más información. E, incluso, que el propio cliente vaya teniendo mayor claridad sobre qué es lo que necesita.

Como conclusión, los Tests de Aceptación completos, resultarán sumamente útiles, no sólo para el Tester sino para todo el equipo, ya que los desarrolladores podrán basar su código en ellos, adaptándolo según la especificación de los tests. Por su parte, el Product Owner podrá saber cuándo una historia de usuario puede considerarse “terminada”, en función de que haya superado exitosamente todos los Tests de Aceptación.

 

(*) no confundir con las Pruebas de Aceptación, que se realizan junto con el usuario para validar que el software desarrollado está conforme a los requerimientos.

banner

¿Anda bien?: Así probamos la actualización de la aplicación de TN en iOS y Android

banner

por Guillermo Alvis

No todas las aplicaciones que descargamos funcionan bien. Incluso, muchas de las que lo hacen tienen “oportunidades de mejora” que bordean la frontera con el “bug” o con la “usabilidad discutible”. Las “oportunidades de mejora” se pueden presentar en diferentes áreas: consumo de CPU, memoria o batería; problemas de performance, como puede ser el renderizado de imágenes; o simplemente pueden resultarle lentas a los usuarios.

 

Cuando publicamos nuestras nuevas aplicaciones, la comunicación se enfocó en el funcionamiento. “TN anda bien”, decíamos en las promociones. Y aunque quizás suene redundante porque todas las aplicaciones deberían “andar bien”, ahora queremos compartir con ustedes por qué desde el equipo de QA de TN creemos en eso.

Este fue uno de los proyectos más desafiantes que asumimos por la complejidad de los escenarios a testear. En el plan de pruebas contemplamos:

Pruebas de Performace de la App

Concentramos la mayor cantidad de pruebas sobre el uploader de imágenes y videos de TN y la Gente para realizar publicaciones en bulk (de hasta 1000 usuarios simultáneos).

Para llevar a cabo estas pruebas se tuvo que superar un “desafío técnico” que pudo lograr nuestro equipo de Desarrollo. El mismo tenía que ver con estresar el uploader. Había que contemplar que no podíamos usar los mismos archivos files.json en los que se particiona un video, debido a que cada uno tiene información única e irrepetible vinculada al archivo de video original. En síntesis: no se podía reutilizar el mismo set de archivos y agregarle concurrencia.

Pruebas funcionales y de performace de los servicios .JSON que usa la App

  • Desde lo funcional se probaron todos los servicios .JSON (tanto GET como POST) para constatar que trajeran de manera correcta toda la información requerida.
  • Desde el stressing se probaron todos los servicios con JMeter con altos niveles de concurrencia para ver cómo respondían.

 

Pruebas de performance de la app con diferentes anchos de banda de conectividad de red

Se probó con: 4G, 3G, Edge y 2G. Esto se pudo llevar a cabo mediante el uso de una herramienta llamada Charles, que es paga pero barata (¡Je!) pero que además nos permite apuntar la aplicación, al ambiente en el que quisiéramos probar (Desa/Test/Prepro).

Pruebas de performance de la app en los equipos

Se ejecutó el test en los equipos Android más avanzados, con las siguientes “Opciones de Desarrollador” activas:

  • Mostrar superposición de GPU
  • Si / No: conservar actividades

 

Pruebas funcionales de la App

Para estas pruebas se utilizó el siguiente set de dispositivos:

Los dispositivos en los que probamos la actualización

En estos equipos se realizó un conjunto de pruebas funcionales que consolidamos en un checklist. Para los uploaders de imágenes y videos se usaron todos los formatos no nativos de cada uno de los dispositivos. Para las pruebas del upload de fotos de TN y la Gente se contemplaron: .gif, .png, .tif, .bmp y .jpg; mientras que para el upload de video se usaron: .mp4, .3gp, .flv, .mov, .avi, .mpg y .wmv.

Con eso se consiguió un gran nivel de cobertura entre dispositivos y formatos de archivo.

Testing de las nuevas funcionalidades de video

La nueva versión de la aplicación incorpora dos novedades respecto al video tanto en iOS como en Android. Estos últimos desarrollos le permite al usuario visualizar los videos de una nota sin tener que salir de la portada, con players bien simples que se cargan de manera dinámica y automática a medida que el usuario va descubriendo el contenido.

La señal de TN en vivo se reproduce en un nuevo player de pantalla completa también integrado a la App. El usuario accede a la transmisión con un solo botón y sin demoras. Creemos que esto la convierte en una aplicación ideal para informarse con rapidez y comodidad.

El desarrollo tuvo como objetivo la usabilidad y la mejora de la experiencia en video que muchos usuarios criticaron en los stores. Para eso el equipo de diseño y desarrollo trabajó en los detalles y realizando pruebas con usuarios para poder consolidar mejores resultados.

Informe del estado de la App con Monkop

Monkop es una herramienta para el test de Apps en Android (hay versiones pagas y una free). Se encuentra en “la nube” y sólo debe subirse el .apk de instalación de la app a testear. Luego se encarga de enviarnos un reporte con los resultados de las pruebas, donde brinda información muy útil al equipo de desarrollo porque sugiere oportunidades de mejora del orden de performance, uso de CPU, memoria y energía, entre otras.

Todas estas tareas del equipo de QA, sumadas al trabajo de los desarrolladores de aplicaciones y el área de producto explican, a mi criterio, porque la App de TN ¡anda bien!

¿A ustedes qué les parece? ¿Ya la probaron? Les dejo los enlaces al store de iOS y Android para que la descarguen.

 Post publicado originalmente en: http://blogs.tn.com.ar/dev/anda_bien_asi_probamos_la_actualizacion_de_la_aplicacion_de_tn_en_ios_y_android/