Having been to several conferences these past two years, I noticed a pattern when choosing presentations/tutorials/workshops to go to: I have trouble picking just one when they happen simultaneously. This has been the case for almost all of the conferences I’ve been to. I have this notion that once I’ve chosen I have to stick with that session till the end or else I will not get the whole idea presented.
Luckily at this year’s Let’s Test choosing went a bit smoother than before. Although I still wanted to go to more than one overlapping session, (I heard the ones with Iain McCowatt and Michael Bolton were pretty awesome!) I chose presentations that either identified a particular problem I am currently facing (tricks to focus and de-focus, socializing with fellow testers), or ones that offered insights that I could somehow use in my day-to-day job (trends in testing, applying skills acquired from playing games).
What will follow will be a quick walk through of every tutorial/track I went to, aided by the sketchnotes I took during each session (a skill I learned at the second tutorial and was trying to exercise):
Tutorials (day 1)
When I first read Michael Bolton’s tutorial description I thought it was a very interesting topic to build a tutorial around (identifying and dealing with problems), and I was curious how he would achieve his proposed goals (testing of an application, mind-mapping, discussion, as well as a role-playing simulation).
The start of the tutorial seemed highly cerebral and abstract to me. We tried to tackle some rather difficult questions, like what the definition of a problem was, how would we spot one if it was there, how would we tell if a particular problem was fixed/went away, and what were some of the factors for finding problems.
We split into groups and tried to find our own explanations for these questions raised. Our group approached it by branching off of a definition given by Gerry Weinberg:
A problem is the difference between a current state and a desired state.
We then tried to identify the factors of a problem (e.g. “what are the things that make it more noticeable?”; “is it affecting the right people?”) then as a large group we tried to come up with possible ways in which we as testers, could help in the process of identifying and fixing problems.
My main takeaways from the tutorial was that problem solving is hard but worth investigating. I came away with some recommended reading, a book by Ross Ashby and a particularly expensive article about structuring problems.
I also tried to write down some of the interesting ideas people had during the talks, here’s a few that I think were insightful:
- trying to explain the distinction between “does not fulfill a desire” VS. “is not according to an expectation”
- a problem needs to be prominent in order to be noticed (there are ways of making the problem more prominent though)
- spec equals speculation and can also be viewed as a kind of wish list
- in order to comprehend and test a system, one must devise a “model” of the system that is more complex than the original one (we tried demonstrating this by doing exercises using the triangle example)
- Testing is a service that helps NOT to fool people, starting with yourself.
Next came Huib’s and Jean-Paul’s tutorial on how to work visually which I really enjoyed. It proved to be useful and very fun; we basically re-learned how to draw in a simple way by learning the basics of mind mapping and sketch note taking. I was never shy about drawing stuff (although like most activities, I find it a lot harder to do in a public setting than alone) so I guess sketchnote taking and presenting ideas through a combination of text and images comes more naturally to me than other forms of communication, although I still need to practice more..
They taught us that it was easy to start drawing arrows, and stick figures, it all came down to us actually practicing them. I can certainly understand the reluctance of some, since I sometimes find it hard to talk and tell stories and easily become embarrassed if I don’t succeed in getting my point through.
I tried to put in practice what I’ve learned so I sketched all of the talks I went to after this workshop.
Keynotes and sessions (day 2-3)
The opening keynote was inspiring and very “James Bach” if such a thing exists :). He talked about how identifying as context driven actually means three distinct things:
- having a model by which we understand, experience, value, and categorize good testing (this was taken directly from his slides, if I remember correctly 😀 )
- being active in the CD community by participating in debates, influencing and being influenced by people adhering to the same paradigm (a challenge to come up with our own seven tenets, or possibly find an eighth one)
- approaching and trying to solve a particular problem in a CD way (trying to apply different heuristics while testing)
This is the only talk I took regular notes of, and even though I noted plenty of cool/interesting ideas I barely wrote down anything, unfortunately :(.
The second day keynote from Johanna Rothman was all about what to do as a manager to improve the quality of the company’s testing force.
The main idea in her talk was to keep communication flowing between manager and tester through 1-on-1’s, giving feedback and offering help with career development, depending on the tester/situation of course; this was part of the People aspect of her talk.
The other part was about the Business aspect of managing a testing force, how to explain and report findings effectively (“defects prevent us from making money!”) and how to improve the quality of testing (“go to lunch with devs”; “no multitasking between 2 projects”)
Even though the keynote was mainly focused on managers (I mean it says so even in the title…) I feel I did learn quite a few things from it. For instance to always try finding ways to interact with my colleagues back home at Altom, being on a project that requires me to be in a different city sometimes takes its toll.
Those of us who attended Huib’s session split up in groups (again) and had to come up with skills, ideas, qualities that we need to improve on or acquire in order to cope with “the future of testing” – whatever that might be.
This was a fun exercise in explaining my ideas and to ask questions about other people’s.
One of our ideas that I found poignant was that testers should strive to have “T shaped skills”, as in to be a generalist thinker with one or two specialized fields; while another group tried to explain that in certain contexts testing the system was a vastly different than testing the software itself, as in testers would be wise to imagine how their software behaves outside of the test lab.
Jari’s talk was light and easy to follow (I think I structured my sketches of his session quite well). He talked about the different ways of being part of the community and supporting it in different ways (twitter, blogging, conferences, local community groups as well as online ones)
I think the conversation that came after was eyeopening (for me at least):
- Iain talked about the BBST courses and how that helped him interact with testers,
- the topic of certification was also mentioned (and the not-so-recent debate on what it means to be a certified tester)
- Scott Barber talked about a state he would like our small community to be in with a rather poignant exclamation: “Nobody picks on my little brother but me!” – the little brother being the CD school :D.
The next day, Madis talked about the many gaming skills you can use to get better at testing. Just as open world RPGs have many, many ways of completing them (doing side missions, crafting, and just plain old adventuring), testing is much the same way since there is an infinite number of tests you can run.
The key there is figuring out which tests are worthwhile, or in other words, what is the optimum
way to experience an open world RPG, depending on the player of course :).
Besides this, most group based games have very specific goals (winning) and the strategy
of achieving that goal needs to be adaptable to different situations.
Madis also talked about how even the best laid out plans can fail (due to human error or not), by giving an example from EVE online. Read more about it here. Finally we talked about the importance of coping with failure; Madis even recommended a game we could play to get used to the idea of failing.
The last track I went to was Zeger’s and I think I had more takeaways from that 20 minute session than from any other one. I guess I feel like that because he tried to address some of the things I’ve been struggling with as a tester, like limiting my time spent procrastinating and trying not to multitask needlessly (i.e. finish one assignment completely and only then begin a new one).
He had many helpful tips for both of these:
- reverse calendar – come up with a set of tasks for a project you would like to do, but start from the point where you are already finished with all tasks and going backwards from that;
- un-schedule – create your schedule for the next week/month/other arbitrary period, start by filling in your time with the things you would love to do, then move on the the things that you wouldn’t mind doing, then finish up by adding the things you keep postponing;
- mindful procrastination – choose a really daunting task to do, then get OTHER things done while you procrastinate doing it;
- do-NOT-do list – make a list of things you do not want to do (e.g. discarded solutions to different problems)
I opted to skip some tracks to either be alone or with a really small group, to recuperate, otherwise I think I would not have been able to keep up with the information barrage coming my way. As for the closing keynote, we unfortunately missed it, due to our flight back.
The thing that makes Let’s test so great is that even though the speakers, events, conversations are overwhelming, it still feels close-knit and familiar, I had a bunch of interesting conversations with a bunch of interesting testers I’ve met there. There were tons of other stuff to do at Let’s test besides the tutorials and sessions, like the Test lab, which was an AMAZING two day event (with some intermittent testing here and there) hosted by Martin and James, but that is a story for another day…