MC Ramirez Reading time ~9 minutes

Bueno bueno, os vengo a contar la última aventurilla de conferencias que hemos tenido. Esta vez hemos ido a TestBash, ni más ni menos que a San Francisco, California.

Aquí estamos, Juan, Jokin y yo con el Golden Gate de fondo… no se puede pedir más 😁

Para mí ha sido la segunda experiencia internacional en conferencias y bueno, tengo mis conclusiones… al final os cuento 😉

Antes de nada voy a dejar por aquí algunos tweets, referencias a los ponentes y alguna idea o libro que me pareció interesante para que indaguéis vosotros también si lo veis conveniente:

Influence Authority - Elisahbeth Hendrickson

Su twitter @testobsessed, la f* ama que escribió Explore it! (vais viendo el nivel no?) Nos comentó cómo el feedback positivo es mucho más potente para incentivar el cambio que ser sólo críticos. Deberíamos ser “kind” no “nice”, simplemente honestos, directos y constructivos. Nos dejó una nota al libro Radical candor de Kim Scott

Going Undercover in the Mob - Jasmin Smith

Su twitter @jasmintestcode, nos habló sobre la eficiencia de los mob con grupos diversos donde se fomenta el aprendizaje y la innovación y ¡oye! los meetings decrecen… (algo que algunos no querrán 🤣)

How to defuse a bomb… wait, I mean a bug - Michele Campbell

Tester at the table and the tester in my head, Adrian Dunston

Su twitter @bitcapulet

“Quality is optimism plus skepticism, repeat yourself, make a deal, argue correctly and promote yourself.”

Climbing to the top of the mobile testing pyramid - Rick Clymer

Su twitter @clymerrm

“You never get a second chance to make a first impression”

Extra! Extra! Automation Declared Software! - Paul Grizzaffi

Su twitter @pgrizzaffi

“Be sure the tests are still valuable because otherwise you are maintaining non valuable ones” (es esfuerzo para nada)

Create a culture of quality assurance - Angela Riggs

Su twitter @angelariggs_

How to test serverless cloud apps - Glenn Buckholz

Su twitter @darkseer2010

Power of models - Richard Bradshaw and Dan Ashby

Sus twitters (twitters, espanglish a tope) @FriendlyTester y @DanAshby04

Indagad aquí, esto es cremita fina 👌🏼

Stories from testing voice first devices, such as Alexa - Kim Knup

Su twitter @Punkmik

AI means centralized testing is inevitable - Jason Arbon

Su twitter @jarbon

Techniques for generating and managing test data - Omose Ogala

Su twitter @omoseisreal

How I learned to stop worrying and test in production - Amber Race

Su twitter @ambertests

Quality Assurance in an AB/Test driven company - Antonia Landi

Su twitter @landi_antonia

Testing the front-end, back-end and everything in between - Bria Gangard

Su twitter @Bria_Grangard

Getting under the skin of a react application, an intro to subcutaneous testing - Melissa Eaden and Avalon McRae

Manual regression Testing Manifesto - Brendan Conolly

Su twitter @theBConnolly

Recordar que todas estas conferencias se graban y se pueden volver a ver desde el dojo de Ministry of Testing . Siempre podéis pedir a vuestra empresa que os suscriba una cuenta al dojo para poder tener acceso a este contenido (que es brutal).

En fin… yo estos días he tenido la oportunidad de saludar en persona a Richard Bardshow, gracias a que él hizo un concurso para ganar un ticket, pude ir el año pasado a la European Testing Conference de Helsinki.

Bien, en cuanto al formato, la TestBash para mí ha sido menos propensa a conocer gente que la European Testing Conference pero igualmente se han hecho juegos como el Family Feud con el que pasamos un buen rato de risas, 99 second talks y lean coffes para empezar las mañanas. En la European se fomentó mucho más porque se hicieron rondas de speed-dating, las tablas redondas por grupos para hablar de los temas propuestos (donde todo el mundo se dedicaba ese rato a lo mismo, no sólo “los más atrevidos” para que me entendáis) y se hicieron workshops en grupo también.

Y las charlas sí que han sido más potentes bajo mi punto de vista.

Y como os contaba al principio, lo que tengo claro es que en un ciclo de conferencias a este nivel: ves el futuro, te das cuenta de si lo que estás aplicando en tu empresa está bien, si va por el buen camino o qué nuevos horizontes se están abriendo en nuestro campo de trabajo. (Echar un ojo a los conceptos del modern testing )

Sin embargo en conferencias nacionales he visto más bien experiencias de trabajadores que intentan luchar contra el sistema para aplicar lo mínimo necesario para implantar calidad, quiero decir, en las conferencias internacionales ya se da por sentado que el tester debe estar integrado en todo el ciclo de desarrollo, que se hace pairing, que se investigan nuevas maneras de dar valor al producto a la hora de testearlo (no por tener más cantidad de tests estás ayudando más a tu negocio…) etc

Además el ambiente es de “teaching” and “learning” no de “destroying you because I’m better and wiser” 🤣

Simplemente quiero dar un toque desde aquí a los trabajadores que como QAs/Testers estén en una empresa que no tenga asumido que la calidad es así, de todos y desde el primer momento. Hay que salir de la teoría cerrada y poner en práctica las metodologías que creamos que aportan valor, metodologías que no tienen por qué estar escritas en un libro por alguien muy importante sino que nos funcionen, ¿me explico?

Ah! Y un punto más, la presencia de mujeres en estas conferencias es real, nada de fomentarlo, hacer un llamamiento etc… simplemente ya lo es, así de natural, y así debería ser en todas las demás conferencias. Habrá más o menos mujeres… pero ya las hay. Fliparíais con la de mujeres que llevan 30 años o más trabajando como testers… sin embargo en españa parece un trabajo muy nuevo.

Creo que estoy muy intensa hoy escribiendo jajaja.

En fin, no quiero cerrar sin dar las gracias a Flywire, Flywire twitter Flywire instagram. Por ello puedo vivir estas experiencias y aprender tanto. No todas las empresas apuestan así por sus trabajadores y esto es algo que se debe saber y propagar a las demás.

Espero que os haya gustado y que hayáis conocido nuevas ideas y ponentes.

A cuidarse!

MC Ramirez Reading time ~1 minute

JMeter Testnight

Thanks to all for coming

MC Ramirez Reading time ~16 minutes

¿En serio? ¿Otro año? El tiempo vuela y creo que si está volando así de rápido es porque las cosas van muy bien 😄

La verdad es que quisiera haber publicado muchísimas cosas este año pero oye, parece que tengo que darle un toque a mi agenda para poder escribir nuevos posts. Este año he ido a conferencias súper interesantes como a la Test Academy de Barcelona y la European testing conference de Helsinki 😱

En fin, mientras me animo a contar esas vivencias, os cuento qué tal de nuevo en el VLC Testing, que esto para mi ya es un must.

Bien esta vez, comenzamos con una charla introductoria bastante relevante para el resto de las conferencias puesto que Javier LLacer nos introduce “Antes de pollo fui Gallo” en la que nos cuenta como, metido en el mundo del desarrollo y al principio de los tiempos, él creía que la calidad no tenía una importancia clara.

Le parecía raro tener a un tester desde el principio del desarrollo. Comenta que nacemos gallos con respeto a la calidad, porque pensamos que somos lo suficientemente buenos para llevarla innata con nosotros, pero eso es precisamente porque no la entendemos. Además es muy difícil implantar la calidad en una empresa que nunca ha tenido cuidado de ella.

Debemos acabar con los vicios que obvian la calidad y tomar buenos hábitos, metodologías, organización y desarrollo para que ni el producto ni el equipo tengan mala imagen. Hay que tener muy en cuenta que para tener calidad, ante todo debe haber buen ambiente en el equipo y fomentarlo.

Nos hizo recordar la diferencia que existe entre un jefe y un líder.

Además nos dio un toque con respecto al departamento comercial, que son los grandes olvidados y deberíamos sin embargo estar muy en contacto con ellos puesto que son los que establecen las expectativas del producto con los clientes. Al final, la cohesión es la que permite que el engranaje de la organización esté perfectamente engrasado.

Charlas (miércoles)

Control de la calidad del software en la Generalitat Valenciana (Amparo Belmont y Juan Carlos Egido)

No podemos ser inflexibles con la calidad. Ellos recorrieron todas las consellerías para ver qué métodos de trabajo se seguían, estructura etc. Vieron que todo era muy dispar, no había control de versiones y era muy difícil mantener la trazabilidad de las aplicaciones desplegadas. Además la gestión de esos proyectos se hace inmantenible puesto que existen grandes volúmenes de datos y aplicaciones.

Para implantar una metodología común crearon gvLOGOS. De esta manera se regula toda la problemática.

Finalmente concluyen afirmando que es muy difícil el cambio porque existe resistencia pero mientras se encuentren alineados con los usuarios, la calidad estará presente.

Ágil por necesidad (Silvia Jiménez)

Nos cuenta la experiencia de su equipo con uno de sus clientes. Les pidieron crear una factoría donde crear componentes y por otro lado se certificaran los productos. En el pasado lo que manejaban en su empresa era el típico modelo “creo” > “certifico” > “despliego” hasta que se les presentó la posibilidad de hacer un cambio.

El cambio se basó en fijarse en el modelo del Lean Manufacturing, de tal manera que, en el mundo del software (Lean software development https://en.wikipedia.org/wiki/Lean_software_development), llegues a estructurar proyectos de desarrollo de un modo ágil.

Fue así como pasaron de tener una factoría con el antiguo modelo, a tener dos en las que todo el proceso de desarrollo, test y despliegue estaban totalmente engrasados.

Lecciones aprendidas:

Estrategia de test guiada por contexto (Tomislav)

Nos compara el testing con los caballos, ¿qué tendrá que ver? Pues mucho, porque nos comenta que su coach de equitación le ha enseñado lecciones que encajan perfectamente con el mundo del testing.

“Sabes montar ese día, a esa hora y con ese caballo en particular”

Y es que todo depende del contexto, no podemos decir que ya sabemos testear algo simplemente porque ya hicimos algo parecido alguna vez.

Por eso debemos en nuestra estrategia de testeo debemos pensar en:

  1. Para quién estamos testando
  2. Qué aspectos de calidad tenemos que tener en cuenta
  3. Dónde lo vamos a testear
  4. Cómo lo vamos a testear

Y basar todo ello en estas tres máximas: experimentar, aprender y compartir.

Muy buena compañero

Orquestación y calidad en el ciclo de vida de los microservicios (Aurelio Pérez)

Nos presenta el problema y la solución en su arquitectura. Nos introduce la diferencia entre la arquitectura monolítica y la orientada a microservicios.

Ellos implantaron un orquestador de aplicaciones que se pone por encima de los Jenkins y tiene su propio ciclo de estados. Teniendo esto, el resto de aplicaciones mapean su estado actual con los estados de este orquestador para que sepa en qué momento la aplicación en cuestión podría ser desplegada.

Además siguen ciertas reglas como:

  1. Cada equipo es quien decide y define las dependencias de su microservicio

  2. La descripción de los pipelines debe ser para todos la misma

  3. No es facil que todos los micro servicios tengan las mismas fases y por eso cada uno tiene su propio .json que mapea sus fases con las del orquestador

Aplicación profesional del esquema de certificación ISTQB (Aurelio Gandarillas)

Ya todos conocemos esta certificación. Este año apuestan por difundir este conocimiento a todos los profesionales informáticos desde que se estudia la carrera.

Tropezar con la misma piedra vale, pero hacerte amigo de la piedra nunca (Domingo Gaitero)

Nos muestra de nuevo la realidad de que la calidad y el testeo caen una y otra vez en los mismos errores y hay que luchar por lo contrario para evitar la tristeza y desmotivación de los trabajadores.

  • Testear al final del ciclo de vida del software
  • El testeo no lleva tiempo
  • No se tiene en cuenta que el testing es rigurosidad
  • El testeo está subestimado

Hacia el testing ágil: 5 errores que vas a cometer y podrías evitar (Pedro Sebastián)

Nos cuenta qué problemas podemos encontrarnos en agile:

  1. Ver el testing como algo aislado y no un trabajo en equipo
  2. Ultradetallar la actividad de testeo
  3. Automatizar todo y no tener una estrategia
  4. Sobrevalorar las capacidades técnicas, hay que saber que el conocimiento suma pero que la actitud multiplica
  5. Adaptar agile desde el modelo waterfall

Agile testing en Goldcar (Juan Antonio Ruzafa)

Esta empresa de alquiler de coches tiene un equipo técnico detrás muy interesante. Desde el principio han defendido la idea de “todos somos testers” y “una historia no está terminada sino está probada”.

Me gusta la idea de que piensan para cada User Story, si debe llevar su correspondiente sub tarea de testing exploratorio y/o automatización.

Tienen además un DSL desarrollado para comunicarse con negocio a nivel de tests.

Además han desarrollado métricas que les permiten ver el estado del negocio y su trabajo como son la diferencia entre bugs reportados por clientes vs bugs encontrados en user stories, recuento de tests etc

Para finalizar, apuntan que su siguiente paso es meterse con docker.

Testing de API para alcanzar la calidad (Jesús Heras)

Nos cuenta cómo testea API con rest-assured y valida los servicios api rest en Java y siguiendo la filosofía BDD.

Los test siguen el esquema Given When Then y sus aserciones los matchers de hamcrest.

No pruebes, simula. Cómo Cabify usa IA en su proceso de testing (Juan Enrique Sanchez)

Nos comenta cómo aproximaron el testing de varias maneras puesto que, en Cabify, se tiene la app del conductor y la del pasajero.

Un primer approach fue utilizar appium a bajo nivel para tener tanto iOS como Android sincronizados contra un mismo test, tras esto probaron con microservicios algo que acabó siendo poco determinista y muy inseguro y finalmente han probado a simular utilizando la inteligencia artificial.

Con esta aproximación ya no se hacen tests sino que se le indica al agente qué tareas debe realizar (programadas de antemano) y el resultado no es binario, sino que una tarea puede no ejecutarse, puede aparecer un error, un fallo etc

Muy interesante todo lo que nos comenta.

Cierre

La jornada cerró con premios como suele ocurrir y la verdad es que me gusta mucho la organización y que promuevan este tipo eventos.

Noche

Por la noche alojamos el evento de Trobatest en nuestra oficina de Flywire y ¡tela la de gente que vino!

Unimos a unos y otros profesionales que buscaban testers y jugamos para que todo el mundo tuviera la oportunidad de conocer al resto.

Nada más que añadir, una comunidad espectacular ;)

Talleres (jueves)

A los que yo he asistido:

Introducción al testing exploratorio, Heurísticas de testing y Pensamiento lateral (Claudia Badell)

Claudia nos explica súper bien el testing exploratorio.

La estrategia de pruebas a seguir aquí sería la suma del aprendizaje, diseño y ejecución de pruebas. Tienes libertad personal de qué probar pero la responsabilidad de administrar tu tiempo para que la búsqueda de información sea productiva.

El testing exploratorio es útil para obtener resultados rápidamente, detectar defectos en lugares que no esperábamos y aprender más del producto.

No es improvisar.

El testing exploratorio basado en sesiones te permite organizar el trabajo. Esto es, establecer una misión para la sesión (general o específica), ver el área de cobertura, analizar las tareas, dejar traza de los datos utilizados, mindmaps y notas y elegir una buena herramienta de reporting.

Claudia nos recomienda leer el libro “Explore it!” Porque contiene muchas heurísticas de testing que pueden ayudarnos en la tarea del testing exploratorio.

Docker y Docker compose, caso práctico (Vicente Pons Martinez)

Mi compañero de Flywire, Vicente, nos cuenta todos los secretos de docker compose. Este taller ha sido sobre todo práctico.

No estaría mal que vinierais por la oficina a una hacknight o testnight para pillarlo por banda y preguntarle más 😉

Servicios Rest y Gherkin y cómo combinarlos (Auxi Carlos Alberola)

Ella nos cuenta como empezaron en un proyecto con una máquina de estados, con muchos roles. Lo primero que hizo para ver cómo probarlo de una manera óptima, estudió bien el proyecto, la arquitectura, analizó las herramientas disponibles para hacer esas pruebas y finalmente priorizó las pruebas que debía hacer.

Con relación a las herramientas: SOAPUI, Gherkin y REST ASSURED (más orientada a BDD)

  • El lenguaje Gherkin es para definir los requisitos que después probarás. Defines a alto nivel y por debajo cucumber te hace esa traducción a un lenguaje de programación. Así roles como los analistas que están más en contacto con el cliente pueden diseñar pruebas.

  • SoapUI sirve para simular código de servicios web de forma rápida, sirve tanto para REST como para SOAP. Además te permite hacer pruebas de carga. (Y nos muestra cómo funciona la herramienta, cosa que me hace volver a 2 años atrás en mis inicios como tester… las ventanas siguen siendo independientes y estando sueltas por el escritorio… qué loco todo… xD) es una herramienta potente, eso sí.

  • Rest Assured sirve para simplificar la construcción de los test sobre una API REST.

Parece que utilizar REST ASSURED + Gherkin es una buena apuesta.

Performance is happiness (Almudena Vivanco)

Vamos a medir la satisfacción del usuario. Y con ello vamos a optimizar reduciendo el número de recursos críticos para acortar el critical path de nuestro producto.

A tener en cuenta: tiempo de respuesta, animation, idle y load.

Importante, conocer WebPagetest.org, que es free, no es una herramienta de carga, es para ver si tú como cliente te frustras o no con el producto. (Libro recomendado: WebPageTest) No es un Jmeter, no nos permite conocer el estado del servicio ni una auditoría de código. Es una herramienta de rendimiento a nivel de browser para analizar los tiempos de visualización y renderización para comprobar cuál es la experiencia de los usuarios.

Nos permite hacer emulación de dispositivos móviles y simulación de red. Hay que tener en cuenta la latencia a la hora de hacer las pruebas y así saber si tenemos que evitar la frustración miedos y estrés ciertos usuarios. Hacemos la prueba con nuestra web, flywire.com Desde Korea y China Te devuelve la “nota” de la prueba que ha hecho. Debemos intentar comprimir al máximo las imágenes que servimos, contenidos que sean estáticos etc (como comentan en el libro las 40 golden rules for performance)

Para nuestro test: Hace dos ejecuciones, una sin cache y otra con. El primer tiempo de carga del primer byte son 3 segundos. Estamos usando el keep alive, nos chiva que usamos gzip en los recursos, nos dice en qué podemos mejorar, sobre todo en esos dominios que no son nuestros, te genera un video de cómo se ha visto la web desde allí… vamos que está genial.

Tips:

  • Tenemos que tener en cuenta el front-end porque se ve muy afectado según el dispositivo que lo cargue.
  • Siempre hay que hacer el peor caso, el de todos los usuarios son nuevos
  • Hacer más veces el mismo test para comparar (con y sin cache)
  • Document complete vs onLoad
  • Evitar muchas conexiones porque consume recursos en el cliente, para evitar tener un SPOF (single point of failure, cuando dependemos de un tercero y lo tenemos en medio de nuestra carga, por lo que hay que ponerlos al final, puedes forzar un dominio a dar timeout) y bloqueos
  • Revisar cuánto tarda el código impuesto por analytics, clicks, hot jack…
  • Mirar en el waterfall del test cuántos Kb tiene el html inicial, en qué segundo comienza el evento render, cuántos socket connections hay hacia un host concreto…

Ahora entramos nosotros como testers para ver qué tenemos que medir. Podemos hacer comparaciones con la competencia y utilizar otras herramientas para ver qué podemos mejorar:

  • sitespeed.io
  • cssanalyzer.com
  • jscompress.com
  • compressor.io
  • unused-css.com

Conclusión

Estoy viendo que, a nivel local, la comunidad relacionada con el testing y con la calidad está creciendo y se hace eco cada vez más, eso sí, todavía veo que se cuentan historias que podrían haber sucedido hace perfectamente 10 años, vamos, que quedan empresas que no apuestan mucho por ella o que directamente se niegan e impiden que sus trabajadores la implanten como es debido.

Me gusta cómo ha crecido este ciclo de conferencias pero me gustaría aún más empezar a escuchar menos sobre esa lucha para implantar la calidad y más temas de nuevas prácticas y mecánicas de trabajo que nos hagan mejorar como profesionales.

En fin, no prometo volver pronto, pero sí prometo que lo intentaré 😂 ¡a cuidarse!

MC Ramirez Reading time ~9 minutes

Parece mentira que haya pasado un año…

La verdad este VLCTesting me ha parecido muy bueno. Es la segunda vez que asisto y quién me iba a decir a mi que este año estaría viviendo en Valencia :)

Como la otra vez, quiero recoger un resumen de las ponencias y los seminarios por si esta información os parece interesante.

En relación a las ponencias:

Software testing… ¡Hay que echarle valor!

por Maximiliano Mannise

Siempre abre camino con tono divertido y esta vez con las distintas acepciones para la palabra valor en testing:

  • Valor como valentía y coraje para poder llevar un proyecto adelante.
  • Valor como satisfacer una necesidad del usuario.
  • Valor que las personas aportan en todo el proceso, nuestras skills, no sólo por los testers sino por todos y el trabajo en equipo.

Además nos comentó que aunque sabemos que nuestra misión principal es encontrar esos bugs, eso no es entregar valor, debemos aportar mucho más, dar más información para así poder defender la calidad del producto. Igualmente debemos dar visibilidad al tiempo que se debe dedicar al testing en los proyectos.

Esta ponencia me hizo recordar este vídeo de James Bach sobre la aplicación del pensamiento crítico.

También hizo hincapié en el análisis de la causa raíz y los 5 porqués que facilita averiguar la causa de un determinado problema. Si no la conocéis podéis echar un ojo a este post. (aunque no debemos olvidar que esto nos puede llevar equivocadamente a encontrar una única causa y normalmente la realidad incluye más variables y por tanto más causas).

Devops Mythbusters

por Salvador Folgado y Jordi Borja

Comentaron los mitos que han detectado a la hora de implantar la figura del DevOps en las empresas. Anteriormente al ciclo de conferencias nos enviaron un correo con una encuesta sobre esto y aquí los han expuesto y comentado.

En resumen es recordar que quienes trabajan en operaciones lo hace para dar información y preparar la infraestructura según la demanda y dar valor al negocio.

¿Cómo hemos potenciado nuestro desarrollo ágil con testing BDD?

por Jorge López Mateo

Ya que el cerebro humano no entiende las abstracciones de primera mano, cuantos más ejemplos tenemos de algo, mejor entendemos los conceptos. Por ello en BDD se hace un boceto de las pruebas en lenguaje natural (precondiciones, evento y postcondiciones), se escriben ejemplos y después se hacen ejecutables.

Es muy buena excusa para juntar al analista, el tester y el desarrollador para crear esos ejemplos concretos que sirven de referencia para los planes de pruebas y para aportar el valor que el usuario final demanda.

Contaron que en su empres han mejorado con BDD la mantenibilidad de los tests unitarios. Con ello se han dado cuenta de que se suavizan las fases por las que pasa el producto y se fomenta el mundo agile.

Además nombró frameworks como cucumber que ayudan a facilitar esta implantación de BDD.

Mejorando testesrs, de 0 a 100

por Tomislav Delalic y Jokin Aspiazu

Nos contaron su propio aprendizaje y crecimiento como testers. Una de sus reflexiones es que resulta difícil encontrar testers y cuando los encuentras, se hace difícil también reclutarlos. La clave está en dar oportunidad a la gente que empieza desde 0 e invertir en mejorarlos y aportarles. Hace falta tiempo y dinero. ¡Hay que invertir en formación!

Según la compañía, se puede organizar más o menos a los testers, con planes a corto, medio y largo plazo. Por ejemplo, emplear 5 semanas de formación para asentar las bases del testing, principios agile y técnicas de automatización. Además permitir al candidato estudiar algún curso enfocado al testeo.

Otro punto muy importante es volcarse en eventos que invitan a aprender y hacer comunidad.

Grande, pequeño, ancho y largo. ¡Vamos a poner a prueba la responsiveness!

por Eduardo Luna

Tuvo que estudiar cómo plantear una estrategia para tener un diseño web responsive. Además qué recursos emplear para defender por qué no sacar a producción un producto que no consideraba de calidad debido a no ser responsive. ¡El diseño web debe ser adaptativo!

Hay que considerar temas como el público al que va dirigido el producto, mirar todas las plataformas en que será utilizado, cuales son las versiones más utilizadas, navegadores de más uso, la conectividad con la que cuentan esos dispositivos,
el método de entrada de datos, las resoluciones y orientación de las pantallas, el ámbito geográfico de los usuarios…

Destacó también la importancia de realizar bocetos desde el primer momento que, de un simple vistazo, se pueda observar cuál es la intención del producto.

Finalmente ver cómo será el test plan, que tenga un reporting muy visual y que nos de la visión general muy rápida.

Es imposible testear todo en todos los dispositivos. Utilizar frameworks como BrowserStack, Galen etc es una gran idea pero si se puede utilizar el movil físico mejor.

Nunca hay que olvidar las 5 condiciones de test: navegación, rendimiento, condiciones del usuario, cobertura de plataforma y testing visual.

Amenazas en el internet de las cosas

por Josep Albors

Divertido a la par que escalofriante. El internet de las cosas tiene ahora el poder y debemos ser conscientes de que no esta securizado. Prueba de ello es el reciente ataque DDoS del que hemos sido testigos y que podemos leer en esta noticia.

A partir de ahora, simplemente desconfiad de vuestra cafetera y vuestra nevera. Ahí queda.

Cómo probamos SW en idealista

por Raúl Hernández

Nos comentó que tienen equipos según las distintas disciplinas y dan soporte en todos los proyectos donde haga falta. La calidad es responsabilidad de todos. Ponen el foco en el usuario final (sobre todo realizando pruebas exploratorias y de aceptación).

Además ponen mucho énfasis en la automatización de las pruebas sin olvidar nunca las manuales. Siempre tendremos que probar manualmente para que sea útil el feedback. Su proporción de pruebas es básicamente 50/50 (manuales vs automatizadas).

También, en cuanto a detalles técnicos, nos informó de que en los tests automáticos utilizan PageObject (si queréis más detalles sobre este patrón podéis pasar por uno de mis antiguos posts ).

La evolución del QA. Del mono al QA

por Jorge Barroso

Nos propuso un inteligente símil entre la evolución humana y el QA. De esta manera nos proporcionó un resumen para poder ver en qué estado de la evolución nos encontramos con determinado equipo y proyecto y ver hacia adonde avanzar.

El software escondido

por Francesc Pastor

Relacionado con el testing en sistemas embebidos, esos grandes desconocidos. Este software también necesitamos testearlo. Para llevar a cabo esto, se crea una interfaz y así se consigue captar la información del sistema dejando todo preparado para el posterior testeo. Por ejemplo AUTOSAR para automóviles, nos proporciona una abstracción del microprocesador o hardware, así tenemos la funcionalidad que quiere el cliente lista para probar. Tampoco hay que dejar de lado la seguridad funcional (que tiene en cuenta la oportunidad, el impacto legal, la independencia y la aplicación hw y sw). Y algo súper importante es que centran su atención en los posibles fallos que impliquen un riesgo para las personas (dandoles prioridad frente a los posibles fallos del sistema).

En relación a los seminarios:

Testing y DevOps

por José Carlos López Ayala

Basado en la importancia de generar un pipeline para tener un despliegue automatizado. Conocí la herramienta XLRELEASE que es la que ellos utilizan para los despliegues.

UX para Apps

por Yolanda Tomás

Me gustó muchísimo puesto que toda la parte de experiencia de usuario y de diseño me encanta. Nos hizo ver la diferencia entre usabilidad (algo es fácil de usar) y experiencia de usario (donde hasta entran en juego los sentimientos de los mismos).

También dio un repaso por todas las técnicas que se siguen para asegurar la calidad del producto:

  • Técnicas de investigación de los usuarios: como idear unas proto personas, inventando su perfil, que tendrán unas características específicas y tenerlas presentes durante todo el desarrollo de la aplicación. También la generación de story boards como escenarios en los que los usuarios se pueden ver envueltos.
  • Técnicas de diseño: como el cardsorting que permite escribir todas las funcionalidades de la app en papelitos y pedirle a los usuarios que las ordenen y categoricen según crean (algo que puede ayudar en la disposición de los elementos del menú de la aplicación).
  • Técnicas de prototipado: como determinar qué contenidos son obligatorios y seguir guías de estilo.
  • Técnicas de evaluación: hacer tests como el de los 5 segundos, tests A/B y tests de guerrilla (en los cuales te ayudas de amigos, familiares etc para que prueben la app).

Probar en dispositivos móviles y no morir en el intento

por Víctor Gómez

A la hora de asegurar la calidad de los dispositivos móviles tenemos que tener en cuenta la naturaleza de las aplicaciones (si estas son nativas, Web App o híbridas) y tener un buen conocimiento de las funcionalidades. Estas funcionalidades se encuentran tanto a nivel de la aplicación como del dispositivo, por ello hay que fijarse en puntos como:

  • Si existe una galería de productos
  • Notificaciones push
  • Carrito de compra
  • Tarjeta de fidelidad (códigos de barrras etc)
  • Geolocalización
  • Pasarelas de pago
  • Compartir en redes sociales

Para ayudarnos en este sentido existen diferentes herramientas como MonkeyTalk, Frank, Xamain test cloud, Selendroid, Calaba.sh o EarlyGrey. Así como granjas de dispositivos (como PerfectoMobile QC Lab) que podemos utilizar.

Víctor nos comentó que tiene publicados varios libros sobre calidad que podemos encontrar aquí y con ellos colabora con distintas fundaciones. Es una maravilla que alguien aporte este valor a la comunidad de la calidad del software.

Mejora tus habilidades como tester… ¡Jugando!

Seguro que la recordáis de mi antiguo post, ahora somos compañeras de trabajo junto con Jokin :)

Este año se ha currado un seminario con juegos para enseñarnos que nuestras habilidades se pueden entrenar. No es sólo la genética la que influye en aquellos aspectos en los que somos buenos.

Teniendo identificadas las habilidades que un tester debería tener, podemos entrenarlas jugando:

Esto se pudo llevar a cabo con la ayuda de @homoludicus Valencia que nos prestó todos los juegos.

¡Y hasta aquí puedo leer! Espero que toméis alguna idea ;)

MC Ramirez Reading time ~1 minute

Está claro que a veces es difícil recordar el nombre del autor de un libro que leíste, el ponente de una charla que te gustó, alguna regla mnemotécnica o simplemente la traducción de una palabra.

Existe un estudio que afirma que es mejor recordar algo por repetición que por haberlo estudiado de memoria. Esto es, forzarte a recordar cosas de manera activa para evitar olvidarlas.

En estos momentos intento ganar una entrada para ir a la European Testing Conference de Helsinki y por ello he grabado este video para Whiteboard Testing. En él recojo esta idea del recuerdo activo y explico cómo funciona.

Básicamente consiste en tener tarjetas organizadas en mazos. Cada mazo contiene las tarjetas relacionadas con un tema en concreto. Imaginemos un mazo llamado “Libros” que contiene tarjetas con el título del libro y su autor. En cada tarjeta el título del libro estará escrito en una de las caras y el autor en la otra. Cada día iremos cogiendo una tarjeta para preguntarnos a nosotros mismos si recordamos lo que hay escrito en la parte posterior. Así, cada vez que cojamos una tarjeta, leeremos el título e intentaremos recordar cuál es el autor, si no lo recordamos muy bien, lo volveremos a intentar lo antes posible y si lo recordamos perfectamente, lo repasaremos unos días más tarde.

De esta manera nos forzamos a recordar esos datos y nos aseguramos no olvidarlos. El tema es poder jugar a repasar conceptos en cualquier tiempo muerto o rato que tengamos libre.

Existen aplicaciones móviles y de escritorio como ANKI que te facilitan esta tarea y autoajustan qué día es conveniente volver a repasar cierto concepto.

Espero que os sirva ;)