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.
The last conference day started with a very personal & inspiring (and slideless!) keynote from Antony Marcano, entitled “Don’t Put Me in a Box”. He made a good point about how people have many ‘labels’ outside their job such as mother or father, friend, cook, helpful neighbour etc., while in a job there’s often only one label: The job title. In fact, he asked as few listeners in the audience about what they do and everyone answered with a role or a job title.
He explained how this may be an impediment for agile teams. If (or when) we stay in the box of our job title, we might not get a chance to help in an area that’s outside the main focus of our job description.
The following talk “Pull Requests and Testing Can Be Friends” by Alan Parkinson presented some very interesting points. One of them was this: While it may not be necessary for testers to be able to write code, it may be very useful to be able to read code.
His presentation was mainly how his company uses pull requests in Git. I found it interesting that they use pull requests for a lot of things, including reporting and tracking bugs found when testing the change that implemented the pull request. The reason they do so is simple: The context in which that bug was found is that pull request, therefore these two should be kept close together. They implemented this by having a discussion for each of their pull requests. To me this makes a lot of sense for a development team.
After that I attended Chris George’s talk “Easing the Pain of Legacy Tests” (Be sure to watch the slides, they’re great!). He explained how his team started with a long running (as in: 16 hours) test suite that reported about 20% of the tests as failed; and not always the same 20%. After some iterations of working on the problems they had significantly faster as well as much more stable tests. So, for his team it was well worth the effort.
In the afternoon, I attended Selena Delesie‘s workshop “The Best Agile Managers Thrive When Teams Do”. An introductory exercise showed how stressful it can be for both the manager and the team, if the manager tries to control the progress, instead of allowing the team to solve the problem at hand.
Often it’s better to make the goal visible to (and understood by) everyone, and then let the team work out the solution. One thing I found particularly interesting was this: In a more controlled environment people sometimes have to wait (or at least feel they have to wait) for the next task given to them by the manager. This waiting is not always necessary, but happens anyway. In a more team oriented environment the waiting is more often caused by the work itself, for example when one can only continue testing after some serious bug is fixed. To me this ‘work constrain’ related waiting is a lot easier, because one understands the reason for waiting. The ‘management constrain’ related waiting often seems to be unnecessary and therefore can be more annoying.
At the end of the workshop we, the participants, were asked to answer the question: “What does senior management value?”. For the answers, see the photo below.
I believe that our (the workshop participants) overall model of senior management is far too simple (or simplistic).
The last keynote was Alan “The Evil Tester” Richardson’s “Helping Testers Add Value to Agile Projects“. His story was full of insights and entertaining and I like how he explained that he doesn’t want to be called a ‘QA’:
As a final note: I had a lot of fun talking to some of the other contributors to Lisa & Janet’s new book “More Agile Testing“. I wholeheartedly recommend this book — but may be I’m biased, since I’m a contributor. 😉 As I had the book with me, I got some signatures, not only from Janet & Lisa, but also from other contributors I met at the conference.
Thank you everyone at the conference! I’m already looking forward to seeing you again next year.
If you’ve read my previous post about the tutorial day, you may wonder why there’s another ‘Day 1’. — Well, the official conference program mentions the 11th of November as the 1st day, so I stick with that.
For me the day started with a Lean Coffee, a format where people meet, gather topics everyone can bring, vote on these topics and then discuss the topics based on that voting (see the link to the site for more information). I like this format, because it allows to get to introduce a topic and discuss it without spending much time. That way one can see whether at least some other people are interested in a particular topic.
Afterwards, Lisa Crispin & Janet Gregory gave the inspiring first keynote, titled “WELCOME TO THE FUTURE – Preparing For Your Agile Testing Journeys”. They presented their view of how software testing may be in the future and also shared the slides. I liked the Star Trek theme presentation, which also nicely matched the topic.
Next, I attended George Dinwiddie‘s talk “A Poet’s Guide To Automated Testing”. He demonstrated how important a good choice of words is, when writing automated tests. By questioning every single word in a rather typical test, he showed how the tests can be improved. For example a typical test often reads: “When I log in to the system…”.
Who is the ‘I’ mentioned in that line? A customer? A system administrator? The ‘I’ who wrote the test, whatever his or her role was? — After a while, sometimes a rather short while, this knowledge gets lost. So it’s usually better to make this knowledge explicit in the automated test.
The following presentation by Carlos Sanchez was titled “Continuous Delivery, the Next Frontier”. I found it very interesting to see him talking about Docker a lot. Also interesting was so see that, while many people know about Docker and also use it, not many people do use it in a production environment, at least none of the people attending the talk.
Also he provided a funny explanation about where Docker works:
In the the early afternoon I attended Jeff “Cheezy” Morgan‘s workshop “Patterns of Automation”. There was an enormous amount of interest in the workshop and the room filled up quickly. He gave a good number of patterns and even (successfully!) live coded his examples. Super interesting, entertaining and funny!
At the end of the conference part of the day Bob “The Flowchain Sensei” Marshall gave his keynote “The Antimatter Principle” (explained on his blog), a very inspiring, thought-provoking and slideless presentation.
The conference day ended with the now traditional Halloween and costume party, excellent food, super interesting conversations and Matt Heusser receiving the “Most Influential Agile Testing Professional Person” award. Congratulations!
Just like the years before I enjoyed the Agile Testing Days a lot. A fun theme throughout many of the talks were… unicorns and I think Gojko Adzic started it. This affected my brain so much, I said ‘Look, a unicorn!’ to my dog, when I took him for a walk for the first time after I came back from the conference. Actually, the animal crossing our path was a squirrel.
Here’s a short summary of my favourite parts. In order to stay in sync. with the printed & online conference program I’ll start counting the conference days at 0.
Just as the full title “Software Testing Reloaded – So you wanna actually DO something? We’ve got just the workshop for you. Now with even less PowerPoint!” promised, there was only very little PowerPoint and a whole lot of testing & questioning.
I especially liked the way Pete & Matt presented the examples & exercises as well as the reasoning behind them.
There were a lot of games and actual testing. All was very hands on, well explained and debriefed at the end. To give just one example: We tested electronic dice, in order to give an estimation about how long testing would take and to come up with a recommendation whether these dice were ready to be used.
Questions like “Can we ship it now?”, “Is there a pattern/problem there?” and “What actually are the requirements?” were covered.
I also won a price, so my point of view might be biased. 😉
Get them in(volved) by Arie van Bennekum
I found it super interesting to listen to one of the creators of the Agile Manifesto, especially since he pointed out that many of the principles and values have been around before the manifesto was written.
Myths About Agile Testing, De-Bunked byJanet Gregory & Lisa Crispin
Lisa & Janet debunked myths as ‘Testing is dead’, ‘Testers must be able to code’ and ‘Agile = Faster’. Excellent story and fun presentation.
Consensus Talks – 7 10-minute-talks (including mine)
The format of 10-minute talks, all back-to-back and no break included was the one I missed in the previous Agile Testing Days. This way a whole lot of ground is covered in a short time and it’s a great opportunity to explore new techniques in presenting without doing too much harm and/or presenting on conferences for the first time.
Self Coaching by Lasse Koskela
Lasse explained how to coach yourself. After explaining how the human brain works he talked about how to step ‘out of the box’ (your personal point of view) in order to better understand what others actually say and to stay honest to yourself at the same time. Deep knowledge, very well explained indeed.
The MIATPP Award Night 2012 Lisa Crispin won the MIATPP Award. Congratulations!
Test Lab by James Lyndsay & Bart Knaack
This year I went to the “Test Lab” and tested a small LEGO Mindstorm robot, that could move around on a coloured sheet of paper and react, depending which colour its camera would detect. The task: Find out what the specification of the robot is and find defects in its implementation.
Very interesting: We had to come up with a hypothesis of how the robot was supposed to work as well as finding defects. I really enjoyed the way Bart & James gave feedback and asked the right questions.
“Reinventing software quality” – Gojko Adzic
Gojko made the point that in agile testing we might (still) not focus on the right thing: To build the right software. Instead we concentrate on finding bugs and building the software in the right way. He illustrated this with one of his books: He found a defect and then spent a while searching & listing more problems and ended up with a good number of them, definitely enough to make you worry about the quality of the book. However, the publisher explained that essentially all reviews were very positive! So: When people keep paying for your product or service, worrying about defects may not be that important.
“Fast Feedback Teams” – Ola Ellnestam
explained the importance and value of fast feedback. And he’s right: In many projects feedback could be gathered a lot earlier and be used to improve what features are built (as well as how they’re built). Other talks at least touched this topic as well. And while I wholeheartedly agree about this, I’m also a bit worried that we (as software creators) might forget about (or even ignore) slow changing aspects (for more about this see my previous post ‘Slow Feedback Cycles‘).
“Exceptions, Assumptions and Ambiguity: Finding the truth behind the Story” by David Evans
David explained how natural language is ambiguous, unclear and sometimes hard to understand. His examples included part of Jabberwocky (in several natural languages), music lyrics and last but not least programming. Also, I like his short introduction of the Cotswolds.
“It’s the Economy, Stupid! Learn the fundamentals about the one and only argument which will drag your management into agile practices” by Lucius Bobikiewicz
Lucius talked about economic reasons of letting teams focus on 1 (one!) project/product, as opposed to working on multiple projects/products at the same time. It didn’t surprise me much, that letting teams finish one thing and then progress with the next is economically favourable. But I was very surprised how much of a difference it made in the example he presented. These are the main advantages of the 1-project-only team Lucius presented:
The time between the 1st project start and the first paid project (usually at the end of the project) is much smaller, meaning that significantly less money is needed to fund the upfront costs.
Given the limited period of time in which a software can be sold, the product can likely be launched at the optimal time, whereas multi-product-teams may enter the market later and therefore always lag in selling.
Since the overhead of context switching is minimised, the team can work on more projects/products per time unit. This advantage depends on the amount of time needed per context switch and the time the projects take .
The economic point of view Lucius presented was a surprising and welcome detour form the other sessions which were much more focused about technology and/or ‘doing the right thing and doing it right’.
Every morning of the conference days 1-3 Lisa Crispin organised a Lean Coffee in one of the hotel bars. In small groups we discussed topics people were interested in. In order to cover some topics we limited the time for each topic to an initial 8 minutes and then added another 4 minutes depending on a quick vote. I find this is a very fun way to find and discuss topics. Thank you Lisa for organising them!
As a leaving thought: The chair persons were given (foldable) chairs as a present — ‘chairs for the chairs’. Super funny, if a tad bit unpractical to get home via train or airplane.
A big “Thank you!” to José, Uwe and Madelaine as well as the other organisers that made the Agile Testing Days such a great and enjoyable conference.