This week I went to the beautiful city of Amsterdam to attend the European Testing Conference 2018. This conference hasn't been on my radar previously, but what caught my attention was the level of detail the organizers (most notably Franzi and Maaret put into creating an attendee-focused, inclusive and diverse event.
I initially had submitted an older talk if mine on testing REST-APIs using BDD which was not accepted, but the experience during the submission process made me want to go to this conference any way.
If you ever thought developers don't test or care for testing, you should hear out all the ones submitting for #EuroTestConf— Maaret Pyhäjärvi (@maaretp) August 24, 2017
Other than my usual conferences, the ticket price was notable (800 €) but given the fact the this conference offered free tickets to underrepresented groups, organized child care, and paid their speakers. This is (unfortunately) exceptional! I was happy to use the conference budget my employer Nordic Semiconductor grants us to support this!
I'm going to @EuroTestingConf with my son! A babysitter will take care of him, paid for the organization. Are you needing a babysitter for being able to assist to the conference? It's not a problem! Contact to me for more information. pic.twitter.com/5sAvxioSPw— @Adhara (@AdharaIT) January 30, 2018
What did I learn?
The two-day programme was a great mixture of up-front keynotes, talks, and workshops as well as interactive sessions. The keynotes were carefully selected to not be vendor-sales-pitches but focus on high level ideas about testing, communication and team-dynamics.
Gojko Adzic explained that we are seeing a revolution in the field of UI testing.
"This (visual difference testing and running the browser used to test in parallel) changes the economics of UI testing and makes them something we can now start looking into, because tests are now easy to maintain and extend." pic.twitter.com/AI7dKrxhis— Markus Tacker 🇳🇴 (@coderbyheart) February 19, 2018
This was very insightful since I grew up with the notion in mind:
It looks like it's time to rethink this paradigm. Tools like the one Gojko wrote (an open-source tool called Appraise) or payed tools like Applitools which i learned about from another participant during the networking session are greatly simplifying visual testing.
Lanette Creamer spoke about the importance of communication and how to better understand and improve the skills as a tester. Although this talk was mainly geared towards testers, I still enjoyed her insights into what it means to be a tester and improved my understanding of this role.
Good segment on communication in this talk between tester & developer: do not threaten, and find the language of the recipient. pic.twitter.com/rh4AmvWmUv— Markus Tacker 🇳🇴 (@coderbyheart) February 19, 2018
Zeger van Hese held a great keynote on being a sceptic. He stressed the point that it is important to (constantly) question information you have been given in order keep making the best decisions.
So, ask (context-free) questions in order to figure out the real thing: pic.twitter.com/X8p7yme2zx— Markus Tacker 🇳🇴 (@coderbyheart) February 20, 2018
He recommended a set of context-free questions to identify important aspects about a project in an unbiased way.
The closing keynote by Pamela Gay was meticulously executed and fascinating from beginning to end. It provided a great insight into the work of the Cosmoquest project, which uses crowd-sourced data to solve mission-critical problems in space-travel. One might think that it's a long stretch to testing but the learning of this talk for me was:
This was also a great reminder on how bad software is at detecting patterns.— Markus Tacker 🇳🇴 (@coderbyheart) February 20, 2018
It pays to build a really sophisticated collaboration platform, because the best algorithms in the world can't produce usable data.#EuroTestConf
Ergo, not all problems can be solved using software. A great reminder to stay humble.
There were four talk slots, each with four talks in parallel. I attended three of them, since I spent most of the fourth talk time talking with other attendees.
In this highly interesting talk Matthew Butt explained his way to enable testing in software that depends on services, which cannot be run locally. Since cloud-based services (like machine-learning) is becoming more and more coming, we have parts in our software which can not longer be run locally on a developer machine (e.g. for legal reasons). What to do if the provider does not provide a test-environment / stub for this service? Adapters, all the way. IMO this concept is getting to few attention. We are happily following the SOLID principle, but we are pulling interfaces from dependencies into our implementation. If we write adapters for them we can hide implementation detail of a service behind an easier (to mock) interface and can simplify testing of individual components. Matthew did a good job in illustrating this. You can find his slides here.
Once more than one team is working on a microservice architecture it gets important to coordinate tests between these teams. pic.twitter.com/klFtHHkS1C— Markus Tacker 🇳🇴 (@coderbyheart) February 19, 2018
The talk was a tester's perspective of working with microservices, which provided some value for me since Emily was concerned with orchestrating the collaboration between different teams working in with a microservice architecture. Most important takeaway from her talk: version your microservices so other teams or individuals can run integration tests and teams are responsible to run the integration tests with their latest code, otherwise there will be pain.
Albeit providing no new insights to me, Lynoure tried to take a new angle on explaining how to write tests: the mindset you put yourself in. Start from the most minimal example you can think of and then stop and go talk to your (business) stakeholders to actually figure out what the component you are about to write is actually supposed to do. Don't let yourself get drawn into the rabbit hole of writing too much, and too complete software. Because you can never know when you are done on your own, and the more code gets written, the more resistance to change is becoming ingrained.
There were five workshops which were repeated on both days. This reduced the FOMO significantly and I attended a workshop on BDD and one on Test Specification.
In Vernon Richard's workshop on Scripted vs. Exploratory testing we got to experience the pain of scripted testing first hand.
Experiencing the difference first hand in this workshop. pic.twitter.com/AtcJxPH3bg— Markus Tacker 🇳🇴 (@coderbyheart) February 19, 2018
We were given an outdated test script and tasked with testing a changed UI. This was no fun.
After 30 minutes we switched to persona based testing, where we used the persona to test a different website. Also we made significantly more progress here, and it was way less mind-numbing, it still had a flaw: the persona was lacking a clear goal, so it was not possible to evaluate whether the website under test passed or failed.
Obviously the workshop was meant to show us the difference in these testing methods through first hand experience and what would be needed to improved in order to make them a useful tool.
This workshop provided a great insight for me into the way testers work, and how we as developers can (and should) support them, as well as understanding the value especially of persona-based testing. It is way more flexible, does not need to be changed if implementation details are changed and provides customer-focused, easy to reason about framework for testers. On the other hand, it relies on testers understanding the domain and a lot of details about the test subject in order to execute tests. Which in the end will be to the benefit of the project.
The second workshop by Seb Rose and Gáspár Nagy gave us a very well executed tutorial on how to write better BDD scenarios. Working in groups on suboptimal scenarios we worked towards writing one great at the end of the workshop. Their insights and tips we easy to follow and execute.
From discussion with attendees one thing became clear though, too few teams are using this technique which enables discussion of features between stakeholders and developers and at the same time enforcing the implementation to follow these talking points. It seems that many teams start the implementation through Jira and other issue trackers instead of taking the time to formulate users stories. It might be because it is easy to write tickets like "Export list of products as CSV" in an issue, but hard to explain why a user needs this functionality in the first place.
Being an unconf fan I especially enjoyed this two-hour slot in the programme. It was hard to choose from from the roughly 25 sessions:
The first session was by someone working for a big oil company and they were looking for a lean way to develop an alternative-energy car. It was fun to toy around with that idea and imagine ways to enable this. Given the knowledge I have collected working at Nordic and as the son of an automobile industry veteran I could add some insights.
I was in a really interesting session on how to TDD a car.— Markus Tacker 🇳🇴 (@coderbyheart) February 20, 2018
Some things are similar: components, contracts between them, enable testing.
But the integration part is terribly expensive and complicated.#EuroTestConf
In the session on Continuous Deployment we talked about the do's and don'ts. Basically: you want your CI runners to be Phoenix Servers. Chris Dräger who hosted this session found LambdaCD to be his tool of choice. I would recommend Travis + Makefiles to solve this.
How to Kanban better started as a question on how to improve Kanban but this session quickly turned into a team clinic, where we tried to find ways for a team to improve their internal shortcomings, which were just being revealed by using Kanban:
Kanban as a process is pretty flawless, it shows you were the issues in *your* process are. You get rewarded for fixing your own issues, not by changing kanban.— Markus Tacker 🇳🇴 (@coderbyheart) February 20, 2018
The European Testing Conference was a fantastic experience for me, even being in the minority as a developer I felt very included and welcome. The atmosphere was always very friendly and never hostile or too opinionated. Amsterdam as a city did its best, we arrived a few days earlier and had awesome weather, great food and beer.
I would definitely recommend to follow @EuroTestingConf and sign up for their newsletter. We might see a new installment of this conference in 2019. Maybe in Finland, given that there were so many Finns among the attendees already?