Best of the BSides - A friendly security conference in Manchester

Introduction

Today I attended a great little conference in Manchester called BSides Manchester. This was a free conference about security ran by members of the security community in a similar way to TestBash. In fact the whole event was a bit of a “SecurityBash” in so many respects, which is awesome and I recognised many familiar topics, concerns and ideas. Whether you're experienced with security or a newbie, I highly recommend this conference. I went along with no expectations, just hoping to learn as much as I could, expose my brain to new ideas and even if I didn’t pick it all up immediately, it could give my brain a place to start. Not only did I actually learn quite a bit but I also noticed that there was a great deal of similarities to testing so I thought I’d talk about the conference from that angle.

The similarities and parallels to testing

In no particular order:

• The security community seem to be very keen to promote leaner and more effective ways of improving security such as getting involved earlier and trying to be involved in discussions about new projects or approaches. This is exactly the same as with testing in general and both are frustrated when they are only asked for their opinion very late in projects. Perhaps this is the biggest area we share in common and maybe we could share our experiences and lessons with each other. Perhaps we can also be allies on this, for example where a tester has managed to get involved in the project early, we could be advocates for involving security professionals earlier too and vice versa.
• Carolyn Yates gave a great talk on the bowtie method which is very applicable to testing too and reminds me of how we look to use examples like mind-maps to effectively visualise our work. She also made the point that “not all tools need be programs, sometimes they can be visual aids” which I think as testers we can certainly appreciate too.
• There was a great talk by Collette Weston about echo chambers - in particular the difficulty for women and other industry minorities to break into the InfoSec industry and community and what can be done about it. I think we can all agree this is an issue across the software industry as a whole too and while I feel testing is a little bit better in this regard, it’s definitely not as good as it could be. This talk also prompted a great discussion about how some companies had started trying to diversify their security personnel (including hiring people with biology degrees) and I know in testing its well appreciated that we benefit greatly for our diverse backgrounds.
• In two separate talks by Ian Trump and Charl Van Der Walt there were discussions of what the future might hold and how artificial intelligence and the advance of technology will shape the industry and the work of security professionals. It seems obvious but I found it quite re-assuring to know that it’s not just testers who are wondering how these advances will affect their jobs. There was also discussion of the effects of automation and whether people were really considering these effects on the loss of jobs and how humans interact and use the automation. This echoes the concerns I’ve heard many testers raise and reminds me of my old blog post on this subject.
• Naturally there were several more technical talks focusing on particular types of hacks, attacks and penetration tests. This included discussions of how to defend against these attacks too. The mindsets and techniques that security professionals use to find and report these exploits is exactly the same as how testers find and report bugs. I think we have a lot in common on this subject (as, well, it is a form of testing) and I think we could do more to engage with the security community and share our experience - just as much as we can learn a lot from them too! All the things we talk about in testing were present here - such as trying to turn exploits into the most damaging problem they could find to justify and explain to companies why they need to fix it. I believe as testers we can also become more effective at general testing by learning about these exploits too - both in helping raise security issues earlier but also giving us more ideas for other kinds of testing. Perhaps we could share our knowledge, approaches and experience of exploratory testing with them.
• Another common theme of the conference was that security was not really a technological problem, but a people problem. This is of course not a new revelation, there are many historical quotes and philosophical discussions, for example, “a bad workman blames his tools”, “pick the right tool for the job” and so on. However, as humans we clearly find it difficult to keep these lessons in mind and it is easy with bias to miss that we are making assumptions about our problems. As testers I feel we should be very aware of this too and typically many challenges we face are nothing to do with the particular technologies involved. Many software bugs are caused by humans and machines are simply doing as they are told, the same applies for security exploits.

The differences

Of course, for all our similarities, there are also differences:

• As part of the discussion about diversity in the industry from Collette’s talk, there was also discussion about autism and how there was a general belief that many “black hats” may have struggled at school, dropped out and only picked up hacking because they had no other options. It was pointed out that because many companies require specific levels of education (such as GCSEs), it meant there was no way for these individuals to become security professionals. Why is this different to testing? Well in the testing industry I don’t feel we have such a specific concern with autism (though it will definitely also affect the testing industry and community too!), I feel our concerns are more about increasing awareness of testing as a possible career in the first place!
• I think this one is probably obvious but the security community is more naturally technically focused and capable, in tandem with the above point, most people seem to join the industry because of their interest in it and interest in technology. As such, while there is diversity, I get the general impression the diversity of backgrounds is a lot more acute as opposed to the very broad backgrounds of testers. As a result I feel testers tend to be less technically focused and more a balanced spread of soft skills to go with the technical subjects. That said, the conference did feature plenty of talks that were more about the soft skills, although probably a different balance compared to some testing conferences.
• I feel that the security community is even more aware of justifying their testing and explaining the effects of the exploits they find than the average tester because of both the ethical act of the testing and it’s very technical nature. Not only must they be very careful in not breaking laws or damaging a company but they also have to be very good at explaining why they think something is a significant problem and helping the company fix it. I think as testers we have a lot we can learn from this, not because we don’t do a good job of this, but our testing is a lot safer and doesn’t always require as much explanation. However, I think this will change over time if we get more involved with DevOps, challenging requirements and testing in production.

You should go to!

All in all, it was a great conference, I took a lot away and enjoyed myself. It was very reassuring to see so many similarities to testing and seeing ways in which we could work together. I hope to go to some other conferences in other areas around software development like Programming, Project Management, UX, Business Analysis, Operations and Systems Administration and continue learning from them. Maybe even to begin talking about testing at their meetups and conferences and see more sharing across our disciplines.

NWEWT #2 Growing Testers

Introduction

Last weekend I attended the second edition of the North West Exploratory Workshop on Testing (NWEWT). If you don’t know what an exploratory workshop is or want to know more about NWEWT, read my previous blog post here:

http://bestofthetest.blogspot.co.uk/2016/04/nwewt-1-regression-testing.html

Attendees

The attendees were as follows, the content of this blog post should be attributed to their input as much as mine, the thoughts I have here were brought together through collaboration:

Ady Stokes

Ash Winter

Callum Hough

Claire Reckless

Dan Ashby

Duncan Nisbet

Emma Preston

Gwen Diagram

Jit Gosai

Marc Muller

Vernon Richards

Vishnu Priya

Growing testers

This years theme was “growing testers”, looking to spark discussion on our own experiences as we’ve grown ourselves as testers and how we help other testers grow. We had a mix of new faces, some of whom it was their first time public speaking, and experienced people, which led to a nice mix of discussions exploring the topic from one end to the other.

I’m not going to go through all of the talks and everything that was discussed here, I’d just like to quickly blog about the discussions that really hit a chord for me and where my thoughts are on the subject.

Main takeaways

The major takeaway for me was Ash Winter’s ‘wheel of testing’, I really liked this idea and I think it struck a chord with me because I’m relatively new to managing testers and trying to guide them in their career progression. The more ideas I can try and explore to make my own ones, the better, I feel.

Ash explained that the wheel came from his dislike of competencey frameworks and the typical talk around growth being a linear path, whereas really it’s quite a chaotic and winding path. So he came up with a wheel to visualise the different areas a tester could focus on to improve. I’ll let Ash publish and explain his wheel himself, but effectively it contained different core areas of testing, with specialised or more focused subjects going outwards. The idea was not to tick off particular areas or focus people on any one path, but demonstrate what paths are available and engage testers in a discussion.

I also liked Marc Muller’s model which took 5 areas of testing skills and mapped them onto a radar chart. He asked testers to score themselves from 0 to 10 in each area and used this to get a picture of his team. I liked the simple visual nature of this chart and just as in Ash’s model it’s a useful tool to open up the conversation with testers on what the different skills mean to them and what they would like to improve.

Several people gave experience reports of what it was like for them to grow as a tester and I recognised so many familiar aspects to my career. It seems things have still not changed in that respect, people are still falling into it and accidentally happen across the testing community.

Naturally the topic of growing testers eventually led to the topic of “the future of testers”. While we didn’t go too far into this, as it’s a huge topic in itself, it was clear there was a fairly large difference in opinion and my takeaway from this is that I’d love to get into it more!

My talk

My interpretation of growing testers had two aspects to it, one was an introspective look at how I’ve grown as a tester and how I manage and attempt to help testers within my team grow. Another aspect was how to improve the growth of testers in the industry. The former I didn’t feel I was making any interesting points on, so in hindsight I wish I had dropped that part. But the latter point I’ve realised I’m quite interested in and curious about.

I argued that to help grow more and better testers in the software industry, we (society in general, not just the testing community) could be doing more to improve awareness about testing through education. I referred to the example of Scratch which is used to educate children on programming at school - could we be doing something similar for testing or somehow bringing elements of testing into those exercises?

I believe we can, I believe we could be improving how software development in general is taught (or not taught!) throughout education. I don’t mean testing degrees or testing qualifications though. How testing could be brought into education, how people could be made more aware could take many forms:

• The obvious option being degrees or qualifications like GCSEs.
• Supplemental modules or specialisms within existing computer science or software development or engineering courses.
• A change in the way programming is taught in existing modules or courses. Rather than focusing on pure coding problems, could we be focusing on delivery of software? We don’t have to call it “testing” but we could be changing programmers to be more used to understanding the wider challenges of software development and better advocates of testing. If a programmer recognises the need for a critical eye on their work, even if they don’t call that “testing”, aren’t they more likely to ask for it?
• A better promoted option in careers discussions. Career discussions generally are quite poor at university from my experience from 2010. We all wondered what the hell we could be other than programmers but had no idea. Simply having someone talk to use about the different roles in the real world would have made a difference.
• A one off talk from an experienced tester, maybe tied in with the career discussions.
• Including assignments for programmers to build software that other students will test and project manage. Maybe not very practical but maybe there is a way to make this work. The best way to demonstrate the effectiveness of testing is actually try and produce software for somebody else.
• Introducing ideas and techniques such as pairing, mobbing, code reviews, TDD, BDD, continuous delivery, logging and monitoring. These are not about testing but can be discussed quite easily in the context of testability. Through these subjects we could discuss testing. I also feel these ideas can be introduced even at a young age, at least to get people used to the people skills and communication challenges. If we could make people more aware of this before entering work would help I think.
• Sandwich courses, where students take a year out from their course to work in industry. If I had understood testing better I think I would definitely have taken this option because testing is a great way to learn about development just as much as it’s a career in itself.

After this conference I’m pretty damn motivated to conduct more research about how software development in general is being taught through the various levels of education. I’m well aware that it may be a large time sink and require some commitment but I’ve thought about pursuing this avenue for a while now. Having spent a majority of my life in education, I really enjoyed it and I believe it can be much better and much more inspiring. 

Through the Q&A session we had after my talk, it felt like there were mixed feelings on this subject. I think its fair to say some people felt that education isn't the best place to learn about testing. Also some people agreed with the sentiment around Scratch as a way to perhaps find more testers and spread awareness. I definitely feel there is more to research and discuss on this subject and there is something in helping academia improve.

TestBash Manchester 2016

Introduction

Last week was awesome! Why? Because it was time for TestBash again, but this time in my hometown of Manchester! I was really looking forward to seeing familiar faces again, meeting new ones and learning a ton about testing again, especially in very familiar surroundings (my current workplace is barely 10 minutes walk away from the main conference!).

Pre-TestBash meetup

If you’ve never been to a TestBash before, one of the best parts of it is the socialising before and after. Usually there is a meetup hosted on meetup.com by Software Testing Club on the night before the main conference day. This is your opportunity to meet fellow attendees, speakers and even say hi to the organisers Rosie and Richard. I fully recommend that you attend this and meet people you’ve never spoken to before, we’re a friendly bunch and have plenty of stories to share!

At Manchester, one of the major sponsors, RentalCars, hosted the meetup in their very impressive offices in the centre of Manchester. I’m definitely a little bit jealous of their very unique beach-themed cafeteria!

Main Conference day

The next day was the main conference day at the Lowry Theatre in Salford Quays, I was unfortunately a little late and just missed out on getting involved with one of the Lean Coffee sessions but in the end it was ok because I could meet the rest of my team from work (who had fortunately been given budget to come along too!).

The talks for this TestBash definitely had a common theme which I would summarise as “psychology and learning”. The first five talks definitely followed a theme of psychology, starting with James Bach’s talk on critical and social distance.

The talks

I was really looking forward to James’ talk partly because his previous talks inspired me to start this blog and get more involved with the community to begin with, but also because the topic is close to my heart as my career has been driven by it. When I started as a games tester, I was effectively working as an offshore QA with pretty poor and slow communication channels with developers. Since then I’ve been driven to reduce social distance and prove that I can maintain critical distance even if I become very intimate with the software I test. James’ talk pretty much covered this and provided some useful language and framing to explain it. As always I learn so much from observing James’ style of talking too!

Following on from James were two talks from opposite ends of conversations - Iain Bright on the psychology of asking questions and Stephen Mounsey on listening. I took plenty of notes for these talks because I know I’d like to improve in both of these areas. I was actually on a little bit of a personal mission try and hold back my excitement and listen carefully to other testers during the event because I’ve felt I’ve talked too much before. Trying to carefully think about the questions you want to ask, and why you’re asking them was the main takeaway I took from Iain’s talk and Stephen’s made me aware of how often I’m thinking about people’s words (and my own response) rather than actually listening to what they have to say before they’re finished. Personally there was plenty of food for thought here that I’d like to try and slow down and keep in mind in future.

Speaking of slowing down and keeping in mind, I loved Kim Knup’s talk on positivity! I think every tester out there has felt they are negative to some degree, simply due to the nature of reporting problems. I definitely catch myself complaining a lot when things aren’t going great so I’m going to try and take onboard her ideas such as making notes of 3 positive things each day, to try and train my brain to look out for them. I’ve already started trying to high-5 people in the office to put a smile on my face haha.

Just before lunch, Duncan Nisbet gave a talk on “shifting left” called “Testers be more Salmon!”. I was looking forward to this as I know Duncan from NWEWT and from the Liverpool Tester Gathering. The topic itself is something that I’ve also been trying to encourage at work and my colleague Greg Farrow has written about it before on this blog. Essentially the idea is to test earlier, asking questions about requirements, testability and gathering information to both save time and catch bugs when it’s cheapest to do so. Duncan made the great point too that shared documentation doesn’t mean shared understanding, simply because something is documented, it doesn’t mean everyone understands it the same way.

I feel the afternoon talks had a theme running through about learning, starting with Helena Jeret-Mäe and Joep Schuurkes’ talk on “the 4 hour tester experiment”. This was a little bit of an explanation of an experiment they’d like to try based on Tim Ferriss’ 4 hour chef book. The idea is to try and see if you can train a tester in 4 hours, focusing on just the basics. I’d definitely encourage you to have a go at this challenge on their website fourhourtester.net. They talked a little about their opinion that testing isn’t something you can just teach, that it is much better to learn through practice and I fully agree with this, especially the analogy about learning to drive a car!

Following Helena and Joep was Mark Winteringham’s talk on the deadly sins of acceptance criteria. To be honest, I was looking forward to Mark speaking because he gave a great talk at the Liverpool Tester Gathering on testing APIs but I think I’m a little bored of hearing about the pitfalls of BDD now (Behaviour Driven Development). That’s not to take anything away from Mark’s talk, he shared some pretty familiar examples on what not to do and had a great way with humour in his talks. But the negativity around BDD or acceptance scenarios feels like the negativity I’ve encountered around Microservices and I’d like to hear some well-thought out, positive experience reports. It feels like all of the balanced or thoughtful talks tend to be quite negative really and I don’t really see a great deal of value in using BDD over more straight-forward approaches such as TDD (Test Driven Development) and just trying to encourage collaboration without the reliance on process to force it. I want to really emphasise that Mark gave a great talk though and I’m sure others who actively use BDD took a lot away from it! I don’t mean to imply here that Mark’s talk wasn’t well-thought out or negative about BDD, just my own feelings on the subject make me want hear more on the benefits.

Next was Huib Schoots with his talk on the “path to awesomeness” which was effectively a series of lists of great attributes for testers, areas to focus on to improve and generally just what he feels makes a great tester. Echoing the sentiments of Helena and Joep’s talk, he really emphasised the need to practice, practice, practice! One particular line he gave that I really liked was “testing is a psychological and social problem as well as a technical one”.

Gwen Diagram followed Huib with her talk on “Is live causing your test problems?”. If Duncan’s talk was about “shifting left”, then Gwen’s talk was about “shifting right” - she gave lots of great advice and ideas on how to “test in live” such as caring about and learning from your production logs and monitoring or using feature flags. Her talk was very on point for me after I recently attended a meetup on Microservices and I’ve very much got DevOps on my mind at the moment, so I was very appreciative when she came along to chat about it at the Open Space the next day too!

Finishing the day was Beren Van Daele with his experience report on trying to make testing visible on a project that he was a test consultant on. Any talk that includes a slide which reads “My Mistakes” is always going to be very valuable, it’s important to share our mistakes and how we learnt from them and Beren shared a lot! I loved his idea of taking the step of actually creating a physical wall of bugs (out of insect pictures) to get people to recognise the bugs that needed fixing.

Overall the talks were excellent, I made lots of notes and ended the day with the now familiar headache from trying to stuff so much into my brain. My colleagues seemed to enjoy and learn a lot too so all in all I was very happy.

99 second talks

So at the end of the conference, they usually have a section for 99 second talks open for anyone attending to stand up on stage and talk about anything they like. I intentionally decided not to do one this time because I wanted to focus on the main talks and not worry about what I was going to say later as I did in Brighton. I also wanted to save the topic I had in my head for the following day at the Open Space.

Those that did do one though, were great, especially a developer looking for a tester hug and Gem Hill’s on meditation and mindfulness. Not many people broke the 99 second limit though!

Post-conference meetup

So as with the pre-conference meetup, there’s usually a meetup after the conference at a nearby bar or pub. For Manchester this was Craftbrew which was barely 30 seconds walk away from the Lowry. Again, I fully recommend attending these as it gives you more time to chat to other attendees, especially as many only attend the conference day. Everyone seemed to have enjoyed the day and were all bubbling with ideas from the talks.

Open Space

So for the first time TestBash held an “Open Space” day on the Saturday after the conference. This was held at LateRooms’ offices in the centre of Manchester (also very impressive offices that I’m jealous of, especially the number of great meeting rooms!). I had never been to one of these before and I was keen to try it out. If you’ve never been to one, it’s basically a conference where there is no formal plan, all of the attendees come up with talks, workshops or discussions they’d like to offer and everyone arranges a multi-track schedule that makes sense. I had no idea what to expect before I went but I knew I would get something useful out of it, and it definitely did!

To give you an idea, some of the things that were on the schedule were a workshop on security testing using Dan Billing’s insecure app called Ticket Magpie, a workshop on OWASP’s ZAP tool and in-depth discussions on BDD, automation and how to help new testers.

As I said before, I had a topic in mind that I wanted to discuss more with people so I ran a discussion on “Testing in DevOps”. I explained my feelings on the topic and openly asked what people felt about it and where they felt testing was going. I got a lot of great notes, ideas and thoughts out of this discussion and I’ll definitely be writing up a post about it in future! I’m very keen to talk about it at a DevOps meetup in future too.

I really enjoyed the Open Space, it gave me further chances to meet and chat to people I hadn’t met before and I really enjoy having focused, in-depth discussions on topics in a very similar way to a peer conference. I treated as an opportunity to learn from very experienced peers and have some of my own ideas or opinions challenged and improved. Hopefully I provided the same for others! I think I actually enjoyed this more than the main conference day in many respects, I guess because it gave more time to discuss ideas and challenge them, as opposed to simply listening the whole time.

I’m absolutely looking at attending the next one at Brighton!

Summary

Once again, TestBash has been one of the best experiences of my life, I really mean that. I absolutely adore the relaxed and friendly atmosphere, I used to consider myself quite shy and I’ve found it so easy to meet and chat to so many people. In just a short space of time I make so many new friends and pick up so many new ideas to think about. I’ve never looked forward to educational or social events like this, even though I’ve spent most of my life in education! But if you’re only ever going to try one testing conference experience, then absolutely to go to TestBash and try it out. I hope to see you at one.

Many thanks again to Rosie Sherry, Richard Bradshaw and everyone who helped organise, sponsor or make TestBash Manchester happen.

Neat ideas from some recent meetups

Introduction

The last few weeks I’ve been to quite a few testing meetups and there were some notable ideas that I really loved. Plus, I like promoting that these events exist and if you haven’t been to one, find one near you and go! (or if there isn’t one, start one!).

Challenges of testability

I had no idea about this one until I saw a tweet about free tickets from Ash Winter. It was a free 1-day, 2-track conference held in Leeds on the 20th September. I thoroughly enjoyed one of the workshops by Clem Pickering and Mike Grimwood. Their workshop was on testability and it involved designing a toaster (which reminded very much of this TED talk).

What I loved about this workshop was the visual demonstration of how people could take many different interpretations from vague requirements, the assumptions we make and how asking questions on testability helps drive out these assumptions. They used James Bach’s testability heuristics as a tool to help people explore different kinds of testability and generate some great discussion and ideas in the workshop. I loved this workshop so much in its simplicity and visual impact that I’d like to have a go running it at work when I can find a good time.

Using data to drive testing

The following week was the Liverpool Tester Gathering which featured my old manager from Sony, Gaz Tynan, talking about the visual methods they use to plan and review test coverage. This was another highlight for me as again I love the visual impact. Gaz talked through how they collect data from both exploratory tests and automation checks and map it onto a game map (similar to Google Maps). As you can imagine, many games at Sony have a 3D virtual world to explore and test, so they can represent their test data as a physical map too. He then demonstrated how they can then see where they test coverage is lacking or where they may want to explore more through examples like heat maps of framerate drop or where bugs were collecting together.

Seeing this visual representation of test coverage really got me thinking about how I could achieve similar results back at work. It was really inspiring and yet more evidence for me that visual representations of ideas, problems or reporting on data are so appealing and compelling.

Mob Programming with Woody Zuill

Introduction

Today I attended a 1-day workshop organised and run by Woody Zuill who, along with his colleagues at Hunter Industries, originally developed the idea of ‘mob programming’. This workshop was part of a major conference being held in Manchester called Agile Manchester and I heard about it after attending a meetup last month called Manchester Tech Nights. I had been invited to that meetup to represent testing with a 5 minute lightning talk. It was a great experience and even better that I found out about this workshop and conference from talking to people there! After finding out, I just had to book my ticket and attend, it seemed like a great opportunity to really understand what mob programming was all about without having to travel very far.

What on earth is ‘mob programming’?

Basically, it’s the idea of taking pair programming and applying it to the whole team. So the whole team works on a single piece of work at a time, with a driver and navigator rotating at timed intervals. The proposed benefits of this idea is that when we work separately, we deliver both the best and worst of our work whereas with the whole team present, we support each other and produce the best of our work at all times. You can read a much better written description by Woody himself here.

Why was I interested in this workshop?

Barely a year ago I only just started to explore the wider testing community and start reading and listening to different experiences and ideas on testing. Through that research I came across Maaret Pyhäjärvi’s blog and her talks from previous TestBash conferences on the Ministry of Testing’s Dojo. Some of the particular topics that caught my interest were on her recent experiences of working as the sole tester within a large group of developers and the challenges in managing this situation. Through her talks and blogs she mentioned the idea of mob programming (or mob testing) as a means to both learn very quickly but also cultivate understanding and respect across a cross-functional team. My curiosity was really piqued when I had an all too brief taste of pairing with Llewelyn Falco as well hearing his lightning talk on the benefits of mobbing at TestBash Brighton 2016.

I’ve started to experience the need to adapt testing to become more integrated in development processes in agile environments and mob programming struck me as a potentially useful way to encourage the spirit of not only developers and testers working together, but also the wider team, be that product owners, designers or scrum masters. The workshop presented a great (and well timed!) opportunity to observe how it might be done and get a better idea of why exactly Woody and his team back at Hunter Industries even came up with this approach.

The workshop and what I learned

The workshop itself was the kind of friendly, fun and relaxed workshop I’ve come to expect after the high standards set for me back at TestBash! Woody was very honest and open in explaining that he was only here to explain what mob programming is and how it has worked for him in the past. He didn’t claim that this approach would work for everybody. The workshop was split into two parts - the first part was where Woody explained the context of how he and his developed this idea and we took part in exercises to observe the benefits of working together as a team. The second part was where we actually wrote code as a mob!

The main reasons that led to mob programming as an approach being developed were:

• Originally Woody wanted to encourage his developers to recognise bad code. He wanted to achieve this by allowing people to figure things out and practice their craft together regularly - in the same way as any sports team.
• He also wanted to overcome the challenge of getting access to project managers to answer questions that blocked work - involving them in the mob helped provide immediate feedback to any questions the developers had.
• However, to achieve this, he didn’t force people to participate, everyone was invited but attending was not compulsory. This allowed people to get comfortable with the idea before they attended.
• Hence, the only reason the approach of mobbing worked was because the team decided to do it. It was not forced and was developed simply by trying ideas and trying to solve problems when they arose.

I really liked how open and honest this explanation was of the context and how this approach was developed. It was exactly what I was looking to learn by attending this workshop and considering how it might be useful (or might not be useful!) back at my workplace or in future.

Coding again!

Although I’ve been writing a fair bit of Python the last 3 years I haven’t really touched any more advanced programming than that for about 6 years (since my degree basically!). I was relishing attending this workshop and throwing myself in with a group of experienced programmers and trying to keep up. Having read and heard Maaret’s experiences with mob programming as a tester and how it was a great way to learn, I really wanted to experience this and see this benefit for myself. Not to mention, to hopefully contribute something with my skills as a tester. Having said that, I was reasonably confident that I could somewhat keep up due to my background in my degree and my recent Python experience.

It was a lot of fun! I didn’t feel too ashamed by my rustiness with Java and I started getting back into it pretty quickly. It was awesome to see how quickly we started interacting as teams, at first I was concerned that having less experienced programmers (or people who didn’t know any code at all!) would drag the team down. But I actually felt the less experienced programmers got up to speed remarkably quickly! It’s really quite impressive (and not at all surprising when you think about it!) how quickly people can pick things up when they’re thrown in the deep end but given the support to perform.

Woody was a great facilitator and I learned a fair few tips on how to conduct these sessions successfully - the main points being:

• The hardest part is to shut up and let everyone have an equal say! Treating everyone with consideration and respect was key, so that the whole team is on the same page.
• The key part that I think testers (and non-technical people) really bring a lot of value to mobs is focusing the team on considering each task in the language of plain english rather than in ‘coding language’. There was an emphasis on navigators giving instructions in english rather than specifying code. Although it may be necessary to support non-technical people to guide them through typing specific characters, it means as a tester you can easily navigate as you can focus on the objective at hand rather than technically how to solve a problem.

What does this all have to do with testing?

I believe that in agile environments and with ideas like continuous development it is generally no longer very effective to conduct all (note - perhaps some is still necessary) of your testing at the end of a development cycle or separately to development. Not only does this quickly lead to ‘testing bottlenecks’ but it just doesn’t make a lot of sense to be discovering basic flaws in logic or implementation only after development has finished. We could be bringing our skills as testers much earlier in the development cycle and discovering these flaws earlier and more cheaply. If we can challenge assumptions made before the code is even written, or even as the code is written, we will surely prevent some of the major re-factoring or re-writes that sometimes occur.

I personally see mob programming as a potential tool for encouraging much better collaboration between developers and testers as well as product owners and designers. The idea that ‘everyone is a developer’ who simply bring different skills is something that makes a lot of sense to me and I believe our testing can be become much more effective when we understand more about the code we test.

However, as always, maintaining critical distance and trying to always be an advocate for the customer is key to our work. But I strongly believe we can bring those values as well as learn and contribute more from a technical perspective without compromising those values.

What next?

Now that I’m armed with some better knowledge of the context of how mob programming came about and some experience of what it’s like to be a part of and facilitate, I’ll carefully consider it as a tool to suggest in future. I can see that if a team is already collaborating and working well together, pairing and mobbing in an informal sense, that this approach may not be necessary. However, I’m looking to build a healthy stock of ideas and tools to try when the time arises and if nothing else it’s always useful to try these ideas and see if there is anything we like about them.

In the scenario of rapidly sharing knowledge about a particular technology or language, I think this formal approach of mob programming could be very very effective and I will be looking out for opportunities to do this.

In summary, I highly recommend this workshop if you’re interested in the subject! As I’ve said a lot in this blog post, Woody is great and I got everything out of the workshop that I wanted to.