Ministry of Testing: Autumn 2014 events review
I've just returned from a 10-day trip to Brighton, where (among other things) I participated in five of the Ministry of Testing's Autumn 2014 events series. There was such an interesting array of courses on offer, that it was difficult to narrow it down to just five!
I have a huge pile of notes and sketches which I need to write-up this weekend, but (in loosely chronological order) here's a rough outline of my experiences during the last fortnight.
OK, I'm not going to dwell on this one. I needed a hotel which wasn't so cheap as to be unpleasant, but not so expensive as to bankrupt me during a nine-night stay. On that front, mission accomplished, and its modern, sleek interior was pleasant enough for the most part. However, as with most budget city-centre hotels, on Friday and Saturday night it transformed into the party hotel from hell, with people loudly roaming the corridors after late-night clubbing exertions. Front desk service was also a mixed bag, which mostly seemed to be due to understaffing, and the odd decision to share staff between reception and the bar (meaning that one or the other was almost always unattended).
I'd recommend the hotel if you're looking for a cheap short stay on a weekday, but don't expect much rest at weekends.
There were many pre- and post-course activities, many of which started in The Hop Poles and eventually led us to other pubs/restaurants in Brighton. With attendees coming and going each day, depending on what courses were taking place, there was naturally a real variety of different characters and personalities on show; each night had its own unique flavour.
Bill presented a massively hands-on exploration of the issues surrounding application security. The course was based around a custom-built web application, Ace Encounters which had been deliberately constructed to contain a whole host of vulnerabilities. Some of these were apparent on the surface after some initial exploration, as we began the session by trying to identify the potential attack surfaces, and (with some background knowledge about the application's customer base) to determine what the biggest risks and repercussions could be.
Once we'd gained familiarity with the application, we spent much of the day exploring the OWASP Zed Attack Proxy tool, and (with ZAP configured to act as a man-in-the-middle between our browser and the application server's responses/requests) how we could utilise ZAP to exploit the website and introduce unexpected or undesirable behaviour.
In some cases, this was really scary stuff. One such example can be seen in the photo above: After uncovering a simple SQL injection vulnerability, we took Havij and used this to blindly brute-force a structural outline of the database, including all of the data within previously-unknown tables.
After the class, Bill provided attendees with a copy of the vulnerable web application, so that we could create local replicas (in an isolated environment) to continue honing our security testing skills. This is something that I've already begun doing, and I've been furthering my security testing knowhow by completing two excellent Pluralsight courses from Troy Hunt, Hack Yourself First and Hack Your API First.
I'd already dabbled with Python a fair bit, having taken some formal classes on Coursera and Codecademy earlier in the year, during which I'd learned enough syntax and structure to provide a technical review of Paul Gerrard's recent (excellent) Lean Python book. However, I'd failed to translate that knowledge into practical everyday usage, and Kristoffer's recent blog post Collect and Share Test Artifacts with Python suggested that was just what I would find on this course. I was certainly not disappointed!
The class consisted of several sections, each themed around a concluding practical exercise. In each section, we learned a few disconnected sections of the Python programming language, and then brought them together to complete a seemingly-complex task from scratch. By combining everything we'd learned to that point, and with just the right level of hints in the workbook, the pieces fell into place, allowing us to (for instance) generate a random sequence of connected GPS coordinates and plot them onto a map.
Kristoffer showed a real flair for both delivering material and keeping the class flowing without leaving anybody behind (for instance, moving participants around at various points, so that beginners could pair with more experienced partners). I was amazed (particularly given the number of previous Python primers that I had taken) that I was still discovering new modules and functions which I hadn't previously encountered.
For me personally, the biggest revelation from the class was how much better I've become at debugging Python code. When a runtime error occurred, I was able to determine and fix the problem within a matter of seconds, reminding me that I actually have a pretty refined set of diagnostic abilities.
For another perspective on the same session, check out Kim Knup's blog post: Review: Python for Testers.
Whereas my previous two courses had been heavily hands-on, Matt's course began a three-day series of discussion-led and theory-based topics. Attendees compared their own experiences with agile development, and how testing fitted into this structure.
We participated in several interesting whiteboard exercises, including a "What is Agile?" brainstorm. I found myself heavily referencing a couple of recent blog posts on the subject, 'Agile Is...' (John Stevenson) and 'What problem is agile solving?' (Rob Lambert). My group's diagram, embedded below was heavily based on the desired outcomes/effects of working in an agile fashion, which contrasted heavily with several of the other groups, who seemed to focus more on the scrum process (e.g. sprint planning, demonstrations and retrospectives). The process doesn't exist because we want a process - it exists to give us a beneficial outcome!
*What is Agile?*
Among the other practical activities, we looked at how so-called "manual testing" (that is, everything which is not a soulless automated check) can be made more efficient, and how wasteful scripted processes can be trimmed, and giving less information allows the tester to engage their brain. It's a topic which is close to my heart, and formed the basis of my recent blog post for The Testing Planet, Light at the End of the Regression Testing Tunnel.
We also participated in a really revealing practical exercise, which I don't want to spoil here (not least because I hope we can re-use it in an upcoming Weekend Testing session!) but suffice to say, it allowed us to visualise (with the benefit of some secretly-gathered metrics) how we split our time between reviewing requirements, performing testing, and documenting the outcome of that testing (and how frequently we context-switch between those activities).
Wow! This was a seriously intense (yet engaging and fun-filled) day of activities, designed to stimulate our creativity and visual thinking. I took twelve A5 pages of notes, and sketched another ten A4 pages in my Wipebook, but I didn't feel overworked in the slightest - I could take part in Andy's exercises every day and never become bored.
Partly this was because of the way that the class was structured. The slides were interspersed with a variety of creative thinking exercises, including lateral thinking teasers, group discussions, and solo/group sketching activities. Much of this was framed around the types of questions that we face in our daily work ("Who/What...", "How many / How much...", "Where" etc) and how we can provide visual responses to these questions which can simultaneously simplify and clarify.
I had several major takeaways from the session, which I've been able to quickly retrieve from my notes, thanks to the visual communication techniques that I picked up from Andy!
- You can learn to be more creative, it's not merely an innate ability. As Picasso once said: "Every child is an artist. The problem is how to remain an artist when we grow up."
- Creativity is sometimes frowned-upon by companies as being unstructured and inefficient; yet we are knowledge workers, who seek to solve problems through divergent thinking. If we're not creative, our users will be - and they could break our software in ways which we were unwilling to consider. (I was reminded of James Bach's TestBash 2013 talk, A-Galumphing We Go.)
- Although working in teams can be great for generating ideas, so can solitude. Taking time to think for yourself can help you to achieve greater inner focus.
"Only" nine pages of notes from this session, but almost every word was a new discovery to me. Whereas many of the other attendees were already working for organisations who were practicing BDD, or who had recently joined teams which already had a large collection of Cucumber tests, I was in the minority who were approaching the class from the perspective of "I'm hearing lots of buzz about BDD, but I've not had any experience of it so far".
With that in mind, this class gave me perhaps the biggest leap in knowledge of any that I attended (given that I had some degree of pre-existing knowledge on the other subjects). Most of my previous limited encounters with BDD were through commonly-held misconceptions, such as "BDD is a form of automated testing" and "Now our BAs can write all of our tests". Alan dispelled these myths, and took us through a series of exercises where we had a chance to see BDD in action.
At the end of the class, I had a much better understanding of how BDD scenarios are created and structured, and we got into a surprising level of detail regarding the structure of Cucumber feature files. It's given me a valuable grounding in the subject, and (perhaps more than the other classes) has allowed me to build my own personal learning plan; my personal kanban board is now full of tasks relating to Cucumber and SpecFlow tutorials!
With rain and no fanfare, it's buh-bye Brighton! See you again and thanks for your hospitality; blogging at weekend. pic.twitter.com/Amfmc9veJv— Neil Studd (@neilstudd) November 7, 2014
Congratulations if you made it this far :) These are just my abbreviated notes, but simply writing these 2500 words has reminded me what a pleasurable, engaging and exhausting experience I've had during the past couple of weeks!
Thanks to Rosie and Graham for their hospitality and organisation, to Tess and Grace at the venue 68 Middle Street for providing us with tea, coffee and towels throughout the inclement weather, to Simon and Amy for getting the evening meetups started, and to all the speakers and attendees with whom I interacted - there are far too many of you to mention!
I'm not sure when I'll next find myself in Brighton, though the next bumper crop of Ministry Of Testing events will revolve around TestBash 2015, when I'll be presenting a workshop myself! The Autumn 2014 classes have set a very high standard, and I'm going to have to work hard if I want to provide the same level of learning experience for my attendees. It's going to be an exciting challenge.