It's been awhile. Again. Even though I'm working on three assignments and haven't got the time to write down all the ideas that are swarming in my mind, things are pretty awsome right now. Namely all of these assignments offer intellectual challenges I've been yearning for so long now; Quality management with some of the most brilliant developers I've ever worked with, testing center of excellence handyman activities in super friendly and responsive environment and a pretty sweet exploratory testing gig for even sweeter product...
Plus I'm getting married soon! Exciting times! \o/
Nordic Testing Days 2012 roundup, which unfortunately has been delayed due to the before mentioned reasons. I'm tackling these lightning style i.e. a very short summary about the subjects that touched my heart and mind, divided in two days as the conference itself. This lightning style is of course because of the latency, which have made me to forget things. Very familiar situation in software testing too... ;)
So, time to get tackling (click the headlines for presentation material)!
|Mr. Galvans in action|
Ainars gave us a very memorable presentation about his personal growth to understanding the reality of defect management and how some people might use bugs as a tool. Bugs are often handled only as numbers and thus misinterpreted, they can be used to assign tasks, they can be used to wrongly boost or weaken confidence when reported in masses, a lot of time is spent on managing them instead of fixing then, and eventually, when they are too hard, costly or time consuming to fix, they become features. "Njet problem, normal catastrof", as our Eastern neighbours have eloquently put it... ;)
Ainars presented also a cure for this; A bug triage i.e. it is decided what bugs should be reported and what should not. As such this is however and extremely dangerous cure. How can anyone really decide what should be told and what not, and what are the implications of this decision? You never know what information is vital or what are the causes of even the tiniest root cause. By finding and reporting bugs that may seem irrelevant may reveal a root cause which might cause the worst problems. Bugs and info related to them can however be wrapped. Actually one of the most brilliant things about exploratory testing that when you discover something, you explore it further and once you've gained as much info and confidence about the bug as possible, preferably even it's root cause, you report it. Perhaps Ainars meant just this, but the message didn't reach me.
The most memorable moment was when Ainards told that his wife corrected all the errors from his presentation, but still said that it sucks. Something for all of us to think about... ;)
|Mr. Pavlov in action|
Nikolai led a workshop that actually wasn't a workshop because we didn't get to do anything. He however managed to explain somewhat technical presentation in terms which even us non-cyborgs could follow. He emphasized the importance of non-functional testing and it's synergy with functional testing. Nikolai is on top of his game as he quite sovereignly listed the non-functionalities they have mapped to be tested at Skype. Not ISO/IEC 9126, but quite impressive still. What always stikes my nerve is the lightweight approach on non-functionalities. Repeatedly people seem to pull non-functional requirements out from thin air, and every time I wonder what are they based on. Non-functionalities are actually the thing that makes testing so darn complicated, and perhaps because of that is often so overlooked. Sometimes they are off-loaded to quality management, sometimes to vendors, but only rarely people seem to really take responsibility over them. Laziness?
Some say that non-functionalities are what makes quality. That is something worth thinking about.
|Mr. Ryber in action|
I'm ashamed to say that I didn't know "Tobbe" before this keynote, but now I consider him to be one of the greats. He has an extensive career in testing, speaking routine from numerous conferences, values to die for and he even wrote a book! And now he was guiding us about how to become really great testers.
Firstly, the literature. Even though he has written a quite nice book about testing (from which I will steal a lot of ideas, yoink! :) and recommends some books about testing to be read, he encourages people to read about other things that support testing, among other things of course. Thought provoking stuff like "Tools of Critical Thinking" by Dr. David Levy and "Lateral Thinking" by Edward De Bono. Ok, I have started to read this stuff before and I have a book-wise workload of my own, but to hear this kind of encouragement from someone obviously more successful and a brilliant tester reinforces my path and makes it more robust against ignorance.
Secondly, the plan. Not so much as guidance for a tester per se, but to map and control your upcoming endeavours as a person and professional, he presented an idea about a plan with a few well placed pointers. Few upcoming years, your goals, how to achieve them and details. And you have you to set them and pursue them yourself! No one else will create your goals for you. So make a list, or better yet a mind map about the things you want to do and achieve withing the next few years; Skills to learn, books to read/write, conferences to visit as a participant or speaker, etc. And if something goes wrong, create a plan to fix it. "Tobbe" pointed out also some very important things to remember when doing and following the plan like try to make testing fun (more in the slides). This is simple stuff, but quite often people tend to forget that when we do something and don't have fun while doing it, it will be done badly.
Even though I consider myself to be somewhat experienced and prepared person with strings attached to right directions, the childish wonder of learning new stuff still catches me off-guard from time to time. E.g. James Bach and Michael Bolton have constantly this effect on me. And now "Tobbe" has joined the club!
Now I have a plan. But unfortunately I have to keep it a secret, or others might prevent it. Stealth mechanics learned from James Lindsay... ;)
|Mr. Söderblom in action|
It's hard to judge your own presentation so I'll leave it to my friend Peksi. ;)
I can however mention that this was my first conference appearance ever. I've trained a ton of people and have stage experience, but this was by far the most imporant one for me. And the excitement was set accordingly. The crowd consisted of about a hunderd brave souls, including superstars like Rex Black. The very distant thought of freezing up crossed my mind, but as one of the organizers, Harles Paesüld, came to chat with me and even told a joke before the show, I was completely relaxed. And the show started.
I started with ET basics as I see them, and progressed with some simple examples about how to do and manage ET. I enjoyed myself, and the adrendaline rushed me. I don't even remember everything I told there, I was in the zone. :) Those who haven't had the pleasure of teaching and presenting to crowds don't know how tiring it can be. But nothing is more fun!
I stumbled the most when I wasn't able to clearly state out the difference between verification and testing. They are completely different activities, with different people with different mindsets doing them, and it's a massive understatement towards both to combine them. I should've talked about the differences between algorithmic and heuristic thinking, but perhaps next time.
All and all, I think it wen't well. Even the grilling from Rex Black was fun, and put my expertise to the test. Actually I dodged some bullets because of the like-minded crowd who helped me with the trickiest of questions. So, thank you all! For everything!
After "Tobbe's" keynote we had dinner and some festivities, which actually caused me to miss the beginning of the day 2, but more about that in my next post... ;)
Never leave home without a quote. As Mr. Torbjörn Ryber made the biggest impact, he'll have the honor to say something smart to the end of this post:
"Make testing FUN!" -Torbjörn RyberYours truly,
Sami "Adventuring Monkey" Söderblom