Ida introduced Tinder, an online service to meet people. It can be used to find someone to have a chat at an airport or meet a lifetime partner. She described how she applied her testing knowledge to search for a partner on Tinder. The compilation of acceptance criteria was hilarious already, including a good dozen aspects from handsome (but not weak) to strong enough so he could help with heavy luggage at airports. She presented the testing quadrant for identifying test approaches she applied and a testing pyramid to be used. To me, the topic of agile testing was very well presented, the talk was very funny and entertaining. Well done, Ida! I believe it would make a great keynote to introduce the topic of agile testing at a conference!
Gojko presented some aspects, that he believes will change the world of testing in dramatic ways. Two of the reasons for these changes are the ever decreasing cost of computation in general (e.g. by services such as AWS Lambda), and the decreasing time needed to fix issues after production defects are found.
When applying a micro service architecture, the single service can be tiny — Gojko talks about a few dozen lines of code. With so little code, finding the cause of a bug is typically easy. (At least a lot easier than in a code base containing hundreds or thousands of lines.)
Let me finish with just one tweet about this talk (there are many more on Twitter):
Due to Gojko’s presentation there was a whole new session dedicated to “Gojko’s Future” during the unconference day that followed this 3rd day of Agile Testing Days 2016. But since that’s another day, I will cover it in the next blog post.
Similar to the past few years, I participated in the opening session of the Agile Testing Days playing the role of Super Agile Person—only this year Super Agile Person represented the ghosts of testing past, present and future. Playing and singing along with the audience to the tunes of Jingle Bells was great fun. Thanks to Elad who posted a short video sequence of this on Twitter
The next two sessions rushed by in no time — I was thinking about my own session in the afternoon too much, I believe.
Since I had to prepare some Raspberry Pies, set up my own network for my workshop, I missed the 2nd keynote of the day. A huge “Thank You!” to Dragan Sekuloski for helping me setting up the workshop!
Sadly one thing went wrong: When presenting a topic as “Testing and the Internet of Things” two aspects are essential: The things and the internet. Alas, the internet wouldn’t work! So the story of Goblin King Jareth XLII and his labyrinthian world of connected rooms had to proceed without the prepared game. Sad but true.
Given how bad it started, the workshop then went pretty well: Thanks to understanding and wonderfully active participants we were able to collect a good number of topics the King was interested in. In particular the King wanted to learn about 3 topics:
What risks are we facing?
What interfaces are we dealing with in the Internet of Things (IoT)?
What should be tested (and what shouldn’t)?
Here is a list of what we listed during the session:
Cables can be pulled
No proper instructions
Loss of device
Some of these are not limited to the IoT, and in fact many can happen in other contexts as well. However some of the risks, when dealing with the IoT, are more, well, risky.
Here we did not precisely differentiate between interfaces and transport mechanism.
Skin (think of heart rate monitoring fitness trackers)
Sound, microphones, pressure changes (think about services like Siri)
RFID, NFC (card readers, new payment methods, theft prevention)
Not all of these are easy to measure or available everywhere. The point is that in the IoT we are dealing with a lot more interfaces and mechanisms to transport information than in ‘ordinary’ web apps or most other software systems. And each additional interface also provides a new way for attackers to get into the system.
What to Test
Replies of other systems
Bad conditions (e.g. when using light to communicate through air, what about fog?)
Distance (How far away from a card reader can a card be read?)
It gets really interesting when these topics are combined. Since the initial reading of RFID cards worked on the computers during the workshop, we discussed these questions as well:
Is it necessary to test the uniqueness of the IDs stored on the cards? When? Why?
What about testing the card readers?
An interesting observation: The card readers used in the workshop actually register as a USB keyboard when connected to a computer. This means that we could unplug the reader and still enter data using a real keyboard. Since the real IDs of the cards were also printed on the cards themselves, we even had IDs the system would recognise!
After my workshop I took a break from the conference and went for the next great offer right in front of the hotel: A conference private Christmas market! After enjoying some “Grünkohl mit Würstchen” it was already time for the next big thing: The “Ho-Ho-Ho-ly STWC & MIATPP Award Night”.
As in the previous years the 1st conference day ended with a great costume party and ceremonies for the award winners of the year. Congratulations to the Dutch team “Pan Galactic Gargle Blasters” for winning the “Software Testing World Championship” and to Maaret Pyhäjärvi for winning the well deserved “Most Influential Agile Testing Professional Person Award”!
Here’s a short reminder that I’ll be speaking at the Agile Testing Days 2016 this December. As the banner says: If you’re planning to attend the conference, ask me for a discount (it’s a coupon code) and I’ll be happy to send it out.