Una vez más estuvimos presentes en la conferencia más importante que se celebra en España sobre testing y calidad de software, tras las últimas ediciones esta vez apostamos por patrocinar el evento y así disponer de un stand propio donde poder enseñar todos nuestros productos y servicios.
He de decir que tuvo bastante buena acogida y pasó por el stand muchísima gente con la que pudimos compartir momentos agradables y discusiones sobre testing, herramientas y situación del sector. ¡Muchas gracias a todos los que conocimos por vuestro interés! (y a los que no se acercaron, pues decirles que no sean tan tímidos la próxima vez ;-) )
Siempre me gusta tomar notas de todas las ponencias y presentaciones a las que acudo así que quería compartir con todos vosotros esas notas y titulares.
En global, nos tenemos que quedar con dos temas que son las tendencias actualmente en el mundo del testing:
- Mobility testing
- Automatización de tests
Resumen conferencias del día 28 de mayo (Día 1)
La keynote inaugural fue de Stuard Reid y este año se centro en introducir conceptos sobre los estándares internacionales, por qué se necesitan y como evolucionan. Esta keynote fue demasiado teórica y una vez introducidos todos los conceptos se explicó brevemente la norma ISO 29119 como estándar de testing.
Me resultó sorprendente que no se nombrase en ningún momento otra norma de referencia en calidad de software como es la ISO 25000, pero al terminar la conferencia entendí que una vez más los “testers” se olvidan del código y que solo se centran en la calidad externa. Desde el público se preguntó por qué no se incluía el testing estático dentro de la norma y la respuesta fue difusa... Quizás no quieren que se solucionen los bugs antes de llegar a la fase de testing :-P
La siguiente ponencia a la que acudí fue la de Mais Tawfik, sobre testing de rendimiento. Fue una de las que más me gustó. Me quedo con algunas frases, que aunque son de sentido común no viene mal recordar:
- El testing de rendimiento simula una acción y mide una reacción
- Hay tres objetivos a alcanzar: velocidad, escalabilidad y estabilidad
- Cada vez los tiempos son más pequeños para poner en producción los sistemas software, lo que provoca además que los usuarios estén impacientes, expectantes y que haya mayor competitividad
Terminó la ponencia con una frase que me gusto mucho: “the need for speed!”, algo fundamental en cualquier desarrollo.
La siguiente ponencia fue de Atsushi Nagata, que venía de Japón a contarnos como trabajan en Sony Corporation a la hora de analizar los problemas que surgen en los desarrollos.
Se hizo una introducción de la técnica de Análisis de Causa Raíz y después se “adaptó” para mejorarla aplicando técnicas ágiles (ARCA - Agile Root Cause Analysis).
Destacaría el siguiente contenido:
- Técnica necesaria no solo para arreglar problemas, sino también para prevenirlos
- Involucra totalmente a las personas, lo que puede ser estresante, ya que la técnica puede parecer que ataca al equipo de desarrollo al formular cinco “por qué” como preguntas claves, siendo el “por qué” la pregunta más fuerte para una persona.
- El modelo intenta cambiar las preguntas por debates, para aprender y perder el miedo.
Matt Heusser continuó después con una keynote de buenas prácticas de testing y nos contó los principales retos a los que se enfrenta tras doce años de testing ágil:
- Factores que participan en el modelo de defectos: incidente - defecto - causa raíz - amplificador - negligencia - trigger inductor
- El problema del flow en el testing: todos los desarrolladores sueltan sus historias el mismo día justo antes de la fecha de finalizar el sprint, mientras tanto los testeadores han estado sin hacer nada desde el principio.
- El efecto acordeón: trabajar en cualquier cosa en cualquier momento (multidisplicinar) es una de las peores consecuencias
- El problema del failure demand: no se puede hacer trabajo nuevo porque el antiguo está sin terminar
- Una posible solución es trabajar automatizando o haciendo scripts de tests cases hasta que haya otros casos manuales que poder probar
Cada uno que evalúe su situación personal y busque como puede mejorarla según sus consejos.
- Otra solución es que todo el equipo pueda testear (testing extreme programming)
Ya después Belén Bernardos nos presentó el reto principal al que nos enfrentamos hoy en día con la aparición de tantos navegadores. Una puesta en contexto del problema (antes todo era más fácil con dos navegadores) y una posible solución a través de una herramienta comercial.
Y por último para acabar el día, la que para mí fue la mejor ponencia, la de James Christie sobre la trampa binaria a la que nos enfrentamos con el testing (pass / fail).
Cito textualmente frases impactantes que resumen el buen rato que nos hizo pasar:
- Reality isn’t binary… we don’t know everything in advance. We should observe the software without a hypothesis to nullify (Rikard Edgren)
- Checklists are not auditing
- Tests scripts are not testing
- Testing is not meant to be easy, it’s meant to be valuable
- To know that we know what we know, and to know that we do not know what we do not know, that is true knowledge (Copernicus)
- Evidencia y opinión, ¿cómo podemos conocer todo? Pero más importante aún, ¿a quién le importa?
- Just doing the best we can!
- We might not know things with certainty, but we can make statements based on evidence & keep our opinion
- External auditors are watchdogs not bloodhounds
- you can’t bully good internal auditors, if you can bully them they don’t last long
- good auditors learn by listening bad auditors don’t listen. Their ticklist tells them the right answers.
- there are no right answers (probably)
- the ticklist is not the audit. it’s just a tool
Fue una gran charla sobre auditoría y todo lo que implica y acabo con las seis claves para ser un buen auditor:
- Auditors who need ticklists are unprefsionnal compliance monkeys. That demeans and deskills the profession.
- critical thinking
- communication skills
- risk management
- IT knowledge
- data mining & analytics
- accounting knowledge
- ¿Debe saber programar un tester?
- ¿Existe formación reglada al respecto de tester?
- ¿Cuál es el futuro del tester? ¿Desaparecerán?
Y a vosotros, ¿qué fue lo que más os gustó del primer día de conferencias?
Resumen conferencias del día 29 de mayo (Día 2)
El segundo día del congreso para mi gustó fue demasiado “estándar”, o al menos las ponencias a las que pude acudir.
Todo comenzó con la ponencia de Derk-Jan de Grood, que se centraba en el testing de aplicaciones móviles y su relación con los objetivos empresariales. Sentido común para gente que se inicia en el mundo del testing, charla enriquecedora pero quizás para otros con más experiencia no lo fue tanto, aunque nunca es malo recordar todos esos principios básicos.
Después tuve la suerte de poder acudir a la charla de John Stevenson (ingeniero de test de Cisco) sobre automatización de tests, con la que disfrute muchísimo y en la que se dijeron muchas cosas, pero que sobretodo se hizo hincapié en valorar el trabajo del tester por encima de la automatización.
Me quedo con las siguientes frases:
- Testing is an infinite process, how do you automate infinity?
- Not everything that can be counted counts, and not everything that counts can be counted
- Don't ask how many of your tests/checks CAN ben automated, but how many SHOULD be automated. Automation costs.
Y ya para finalizar la tarde tuvimos a Dorothy Graham que nos habló de errores inteligentes en la automatización de pruebas, con los siguientes titulares:
- Automation is a mechanism to run tests, not to find bugs. What finds bugs is the #testing activity
- Tools don't replace testers, they support them
- Testing tools aren't tools for testers.
- Do you run test or do you automate test?
- Automation that never changes is dying
- In testing effectiveness is more important than efficiency. There's not much point doing bad testing faster.
Además, Dorothy tiene una wiki muy interesante para ayudar a todos aquellos que se adentran en el mundo de la automatización de pruebas.
- Exploratory #testing finds more bugs than automation
Y ya no hubo mucho más tiempo de charlas para mí, dos días intensos muy muy centrados en testing y quizás menos en calidad de producto software a nivel de código, que parece la gran olvidada...
Nosotros seguiremos evangelizando la "calidad interna" para que poco a poco se va abriendo hueco en este tipo de eventos...
¡Hasta el año que viene!