Favorite Talks from Agile Testing Days 2016

One of the great ways to be updated with what’s happening in the testing community is to attend software testing conferences, talk to the speakers and attendees, and ask questions. But if you don’t have the budget to fly over to where the conference is (like me), the next best thing is to wait for the conference recordings to be uploaded online. That’s how I’ve kept up with the latest news in test automation, following both the Selenium Conference and Google’s Test Automation Conference. All these recordings on YouTube paints a picture of what experiences and opportunities are currently out there for software testers.

And recently, I decided to free some time to follow Agile Testing Days and see what went on over at Potsdam, Germany. It was my way of checking out what’s happening in the agile testing community someplace far away from where I am. And today I’d like to share some of my favorite talks from that event:

  • Designed to Learn (by Melissa Perri, about testing product ideas, experiments and safe spaces for them, and learning what customers want and need)
  • Snow White and the 777.777.777 Dwarfs (by Gojko Adzic, about factors that may likely change testing policies and practices in the coming years as a result of computing power getting cheaper, such as third party platforms, per-request payments, multi-versioning, machine learning, mutation and approval testing, testing after deployment and failure budgets)
  • Continuous Delivery Anti-Patterns (by Jeff ‘Cheezy’ Morgan, on eliminating branches, test data management, stable environments, and keeping code quality high)
  • NoEstimates (by Vasco Duarte, about leaving out estimation in software development projects)
  • From Waterfall to Agile, The Advantage Is Clear (by Michael ‘The Wanz’ Wansley, on software testers being gatekeepers of quality, growing up in a waterfall system, and the wonderful experience that is software testing)

Slowly Trying To Learn How To Write Automated Checks With Javascript

If I were to treat the experience like a game, the difficulty level I felt when learning how to write automated checks with Java is normal. At the time, the choice of programming language was obvious – I still remembered how to write C++ functions and if-else conditions and loops from back in college so I thought that maybe I could ease through the course materials that I took. By then I also had practical knowledge about Selenium using the Firefox record-and-play extension, or at least I understood how valid page element locators and Selenese commands are composed. What I focused more then was understanding how I could customize, update, and maintain checks in code rather than by updating all Selenium IDE tests via the browser extension, since the latter was a huge pain. Along the way the way I learned other stuff – object-oriented programming, version control, virtual machines, Selenium Grid, and parallel testing.

Then a year later I decided to rewrite the existing test code to a Ruby implementation, coupled with gem libraries like watir and page-object. There were no actual massive reason as to why I decided to try another programming language, except that I was curious. Ruby sounded cool, there were many who thought of the language as programmer-friendly, and when I found out about Jeff Morgan‘s Cucumber and Cheese book online I finally gave in and studied. And I realized, after writing test code in Ruby for a few months, that the difficulty level was easy. Perhaps because I’ve already absorbed a lot from programming in Java, or perhaps because I’ve found out (and was amazed) that Ruby code in general is more readable. The learning process was tons of fun – aside from spotting mistakes in my earlier style of writing code with Java and became more informed about refactoring, I also got knowledgeable about writing API tests, even HTTP requests, and understood that there are ways of testing web applications without directly interacting with the user interface.

Now I’m reading Enrique Amodeo’s Learning Behavior-Driven Development with Javascript book and studying how to write automated checks using Javascript. The difficulty level is hard, even with all the experience I’ve gained with previous programming languages, and I say that it’s all because of the language syntax. If I didn’t know any other programming language, I would probably come out and say that the difficulty level is insane. From what I’ve experienced so far, the abundance of braces, nested functions, callbacks, and promises makes it difficult for me to read and debug, and I feel that there’s a lot of room for making mistakes. Writing test code in Javascript is a bit overwhelming. So learning is slow, and a lot of the time I have to back-read and study how the code was written some more before going forward to the next lesson. But it’s all good practice for mastering the language and it’s quirks, which may prove useful someday.