NWEWT #1 Regression Testing

Introduction

Last weekend I attended my first ever peer conference, which was the North West Exporatory Workshop on Testing (NWEWT). This conference was organised by Duncan Nisbet with help from the Association for Software Testing (AST). I’d met Duncan at the Liverpool meetup for the North West Tester Gathering after he had presented a great talk on ‘Testers! Be more salmon!’. Shortly after that meetup, he contacted me asking if I was interested in attending this brand new peer conference. After mulling it over, I accepted it for two reasons:

1. Why not? (pretty much the main reason I’ve done a lot of things!)
2. It sounded like an opportunity to learn by deep, critical thinking - I liked the challenge of presenting my ideas and having people really critically analyse how I think about testing. If nothing else I was going to get a lot out of it by forcing myself to think about a subject deeply in preparation!

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:

Ash Winter

Callum Hough

Christina Ohanian

Dan Ashby

Duncan Nisbet

Emma Preston

Gwen Diagram

Joep Schuurkes

Jean-Paul Varwijk

Liam Gough

Lim Sim

Richard Bradshaw

Simon Peter Schriver

Toby Sinclair

Tom Heald

Theme

The main theme for this conference was ‘Regression Testing’, specifically what we loved or loathed about it, whether we even do it, whether we should automate it and just generally what our experience and thoughts were.

What the hell is a ‘peer conference’?

I had no idea before I went! I researched around and I knew it was following a format whereby deep discussion and debate were encouraged between professionals, but as with many things, I didn’t really understand it until I started doing it.

Basically, there were 15 or so of us gathered, each bringing our own ‘experience report’ on the theme or topic for the conference. We each took turns in presenting our experience report through slides, flipchart or just simply talking. We then held a Q&A session where the real action started.

The Q&A session featured green, yellow and red cards. People were only allowed to talk when indicated to do so by the facilitator. If people wished to ask a question or contribute to the discussion, they held up one of the cards which had the following uses:

• The green card indicated to the facilitator that you would like to ask a new question or start a new thread based on the current discussion. So at the start, everyone would show green cards because there was no thread yet.
• The yellow card indicated to the facilitator that you would like to ask a further question or talk about the current thread. This is how the discussions got deeper and deeper into particular threads.
• The red card indicated to the facilitator that you felt the current discussion needed to stop or that you think a ‘fact’ being stated by another person was wrong. We didn’t see a lot of use for this card, only really once or twice for when particular threads went too long or something needed clarifying. Red cards can only be used for situations that the facilitator feels are genuine, so they can be taken off people if they are abused.

Typically, the discussions were mainly between the presenter of the experience report and the person asking the question. However, they could shift to a discussion between two other people - when you showed a yellow card you could directly challenge the person who had caused you to raise the card.

On a personal note

I actually think one of my biggest takeaways was cementing the feeling that meetups and conferences are not as scary as they might seem. What I mean by that is it's easy to feel like members of the community who are quite out-spoken or actively involved are not approachable. I’ve thought about this a lot recently and I think for me it comes from the assumption that because people are experienced, they know everything I know and have already come to the same conclusions. At the start of this year, I felt like I didn’t have anything new to add and more experienced people have taken their thoughts to a more advanced level. I guess I also felt that well-known people must get a lot of questions from their public position, so I naturally feel like leaving them alone, especially if I think my questions or thoughts are less developed than theirs.

So if you’re reading this and feel the same way about meeting testers and asking people questions, then fight those thoughts! My experience at all of the testing events I’ve attended so far is that everyone is more than happy to take the time to listen to you and help you! The key here is that you’re open to suggestions and ideas from other people and this is one element of my “oh god I don’t know anything” thought process I’d like to keep - I’d like to remain humble. But don’t be afraid to ask the questions and approach people!

Takeaways

Enough about my personal development, what about the content? Well I think the biggest takeaway that I think everyone agreed upon was that ‘regression testing’ is a phrase that is poorly defined and definitely not consistently used in our industry. I found myself agreeing a lot with Joep’s idea of not even talking about it. He suggested that instead of using ‘regression testing’ we could just talk about whatever we are doing, e.g. “I’m performing these tests to find out if these two systems are functioning as we desire”. However, that doesn’t mean we should never use the phrase, it may be that we feel within a particular circle of people or within a company, there is very clear understanding. The point is more about being aware that phrases such as this may not be as clearly understood as people might think and can even be used to not think about what you are doing. Again, Joep gave a funny example of it being a ‘jedi mind trick’ whereby managers are told “we’re regression testing!” to which they respond - “great” and walk away.

Several people also shared their different approaches to regression testing. Richard shared his F.A.R.T. Model which I had seen before and Ash also shared his own, similar model for exploring the large unknowns of systems. Toby took a different approach and discussed the idea of ‘regression in testing’ - the idea that your skills and knowledge regress and what we might do to try and combat that.  

One of the best parts of attending events like this is learning how exactly people conduct testing within their companies and the different situations and problems they are having to deal with. Christina, Simon and Tom all shared different situations that I think generated a lot of useful discussion and debate, they definitely gave me plenty to think about in terms of considering how I would approach those situations. Richard gave a particularly useful piece of advice that I really love - which I can only paraphrase as ‘don’t focus on the politics, make sure you’re still doing a good job first and foremost at all times’. This really struck a chord for me personally as I have experienced some very political situations that I haven’t agreed with, but I personally value my own professionalism to still deliver good work despite this.

Another idea that stuck in my head (unfortunately a lot of our notes were binned by the hotel staff on the second day so I’m stuck with just a few notes and my memories!) was Jean-Paul’s idea of using the phrase ‘continuous testing’ to help highlight the need to still perform manual testing throughout ‘continuous delivery’ pipelines - in other words combat the feeling that continuous delivery leads to people forgetting about testing. However, we did also discuss that potentially this could have the opposite effect where people treat testing as a separate concern because we are using a separate phrase for it.

In summary, there was a nice mix of ideas and approaches that I felt I could apply to my work or in future as well as a lot of food for thought. I feel like there are some threads that left me with even more questions - I’m guessing this is normal for these things! Unfortunately, I think a lot of the attendees had a lot of similar points of view, so we ended up agreeing on a lot of topics without much debate. However, I think I still learnt a great deal and it was useful to find a lot of validation in my current line of thought on this topic.

My experience report

Not everyone got a chance to share their experience report but I was lucky enough to be one of the chosen! I’ve written up my views on regression testing here:

What do we mean by regression testing?

Summary

I really enjoyed my first experience of a peer conference a lot and it left me wanting more. I really liked the chance to start digging deep into a topic. It was also nice to find a lot of validation of my own ideas on regression testing and to learn new ideas and approaches from other people.

What do we mean by regression testing?

Introduction

I recently attended a peer conference where I presented my experience report on regression testing. I’m going to go into the detail of what I talked about in this post - if you’d like to read more about the peer conference and what on earth a ‘peer conference’ even is, read here:
NWEWT #1 Regression Testing

Disclaimer

I have no data to back this up, before I go any further I’d like to highlight that. What I state here is my opinion based on observations and my interpretation of people’s words and actions. I’ve not really thought about how I might go about measuring and collecting data to back up my words here, but I’m going to bear it in mind for future topics!

Feelings of mis-use

For the last 6 years of my testing career I’ve never been formally trained on testing. I don’t have an ISTQB qualification and a lot of what I know about testing I have either been informally trained or I have learnt myself from observing others. I therefore have a definition of ‘regression testing’ that I have learnt from how others use it.

Before I go into what I personally define this phrase to mean, I’ve noticed ‘regression testing’ referred to as:

“The testing we perform at the end of projects, where we re-run all of our tests and make sure the code hasn’t broken anything.”

This kind of understanding also seemed to crop up and become twisted with statements like:

“I’d like to press a button and run all of the regression tests automatically.”

“Why didn’t your regression tests find this?”

After being invited to the peer conference, I decided to look up the wikipedia definition of ‘regression testing’. I went with wikipedia simply because it’s likely to be a commonly used source. I actually found that wikipedia’s definition fits my own definition fairly well:

“Regression testing is a type of software testing that verifies that software that was previously developed and tested still performs correctly after it was changed or interfaced with other software.”

Combining this definition with my recent understanding that ‘testing’ is about learning, I think this fits with my own take on ‘regression testing’ which would be:

“Regression testing is considering the risk of change”.

Comparing my own definition with how people seem to use the phrase, I realised people seemed to define regression testing with the attributes of:

• Repeating tests and therefore being highly automated.
• Being performed late in a project, at the end of a sprint or a waterfall. Usually it seemed like it was considered an activity to be performed after development activities.

This seemed totally wrong to me, and I started thinking about why I felt that.

Why does this matter?

Well the first question I felt I needed to answer is - why does it matter people have these differing definitions? Well, this is what I could think of:

• If regression testing is only performed at ‘the end’, does that mean we only consider the risk of change at the end?
• If regression testing is an activity to be carried out after development activities, how invested are non-testers in the results?
• If we are only performing regression testing at the end, and therefore only considering it later, how do we effectively identify risks?
• Assumptions are being made about how valuable it is to repeat tests and the cost of executing them.

In Practice

In my opinion, everyone involved with software development is considering the risk of change all of the time even if only subconsciously. Typically, we’re nearly always changing the software and hence discussing what the desired behaviour is. However, for me the danger of the phrase ‘regression testing’ and how it seems to be commonly used is that we’re leaving the bulk of this kind of critical thinking to the end of projects. Not to mention over-estimating the value of simply repeating tests over and over.

Could we be finding problems with change earlier? When it’s cheaper to both identify and act upon?

What if we are developing a component that is part of a larger system, are we not considering the risk of change as we develop it in isolation? As we start integrating it? Is it wise to only to consider the greater implications of a change later on?

What if we’re developing a change to the red component, are we only going to consider its integration with the blue component later? What about the effects of this change to the components that are not directly connected like the green one?

With git branching, where do you perform ‘regression testing’ here? Who performs the testing? How do they identify when and what to test? When is ‘at the end’? What tests would you run ‘at the end’? Are you only repeating tests? Or running new tests?

These questions are hard to answer when you don’t have all of the information available to you, with these git branches you may not know what was changed as part of each branch - you may not even know how many branches there are and when they were merged. The developer who is writing each change and merging it knows this, but do they identify the risks? Or do they ‘leave it for regression testing’?

My conclusions

I’m concerned that ‘regression testing’ is being referred to as a standard testing phase, different to the testing carried out as part of development activities. This seems wrong to me because it encourages the ‘over the fence’ mentality of ‘coders code, testers test’. If we are to effectively identify the risks of change, we need to work together as a team, not as separate roles.

I believe regression testing is a continuous activity that should be performed as soon as possible. The reason it may have to be performed ‘at the end’ is not because it should be, but because that is the earliest possible point. I currently work in an environment which desires a ‘lean agile’ approach (speed) at the same time as developing a microservices architecture (decoupled). Both of these require us to become smarter with our testing, we don’t have time to run large numbers of repeated tests just before releasing only to find out a flaw in our work that could have been realised with some greater collaboration earlier on.
Finally, regression testing is not an automatable activity - it is the process of consideration and analysis, not repetition. Repeating a test may be useful to help us evaluate risk, but sometimes we may want to try a totally new test. Regression testing isn’t just repeating all of the tests that were run before - as the risk changes, so do your tests. Your testing needs to be continuously adapted to this changing risk.

TestBash 2016 Day 5 - Main Conference

Introduction

This week I’ve felt a sense of momentum as more and more testers started arriving for the main conference day. Over the course of the week, the numbers of testers appearing at the meetups has multiplied to the point where on Thursday night there were hundred testers enjoying free drinks at a great bar on the beach called Ohso Social! The awesome thing was that it never felt any less friendly and open, the vibe we had at the little meetup at Wagamama on Monday was still felt on Thursday night! With that in mind, I was really looking forward to the conference day

Lean Coffee

Where do I start? I had a lot of great takeways from today, starting with listening to some great advice from Andrew Morton during a ‘Lean Coffee’ before the start of the conference. The topic of working more closely with developers was discussed and he suggested learning unit testing. I can’t really find the right words to describe this, but I felt kind of amazed at myself for never having considered doing this before. I can certainly see the value in certain situations being able to feedback and assist developers in writing unit tests! It was also cool to observe the ‘Lean Coffee’ setup - effectively where you discuss topics for 5 minutes and vote on whether you want to continue on the subject for a further 3 minutes.

We then all filed into the Corn Exchange hall at Brighton Dome, by far the biggest room of testers I’ve ever been in! Fortunately for me, I had plenty of faces I now knew fairly well ranging from my fellow RST class alumni - Tracy, Kirstin, Tammy, Mark, Markus and Dan as well as people I had met during the week such as Anna and Andrew. Not to mention people I knew from back home like Paul and Leigh. So I had plenty of people to bounce off discussing the talks through the day!

Main Talks

I won’t go through each and every talk in huge detail (sign up to the Ministry of Testing’s Dojo and you can watch video recordings of the talks!). But I will try and summarise some of the parts of each talk there were notable for me!

The first talk was by Lisa Crispin and Emma Armstrong on “Building the Right Thing: How Testers Can Help”. There were quite a few points made in this talk which reflected a lot of what we are currently trying to achieve at work with Lean Agile. Even though I’ve very recently read and heard a lot about some of the points before, I still find it helpful to listen to them again. I can never be reminded enough about asking great questions like ‘What will it deliver to end users or the business?’ and ‘How will we know its successful?’. Recent experience has really brought home the value of these questions!

The second talk was by Dan Billing on “Testing or Hacking? Real Advice on Effective Security Testing Strategies”. I had briefly spoken to Dan earlier in the week (I so need to talk to him more!) so I already expected his slide on disliking the term NFR (Non Functional Requirement) haha! He had lots of great suggestions of tools to get started with security testing and also tips from the OWASP guidelines like ‘Evil User Stories’ to help make the case for security testing.

After a short break we had a talk by Katrina Clokie on “A Pairing Experiment” which was one I was really looking forward to ahead of the conference and it didn’t disappoint! I’ve been looking to encourage pairing where I can because I can see the huge value it can bring and I was lucky enough to experience it with Llewelyn this week! I made a lot of notes from this talk and took away a very strong desire to play my part in championing pairing! Her talk covered her experiments in encouraging pairing among her test team, what did work, what didn’t work and what value they found from doing it.

Following on from Katrina was John Stevenson talking about “Model Fatigue and How to Break It” and boy did he make an entrance! There were several people who could be described as ‘stealing the show’ but I think I’d have to give it to John. He definitely took an RST approach to presentations! A lot of John’s advice really hit home along with the learning I took from RST - which was a strong encouragement to keep your models fresh and don’t just apply them the same way every time to different situations.

The last talk before lunch was by Patrick Prill on “Accepting Ignorance - The Force of a Good Tester”. Patrick made the point that ignorance based on the Oxford Dictionary definition is the “lack of knowledge or information”. In other words, as testers we are all ignorant and we should be aware of it and use it! He also talked about representing our knowledge in terms water droplets and how really our knowledge is really only a ‘drop in the ocean’ so to speak!

The first talk straight after lunch was by Michael Wansley and it was definitely another good nomination for ‘stealing the show’! A guy who has toured the world in a music career and been a software tester for Microsoft? His message was definitely controversial with a lot of the audience but I really liked that the conference had included someone who was saying something completely different to everyone else. It’s good to have a voice speak for those who don’t necessarily agree with everything from the context-driven testing world and I really respect Michael for standing up on stage and speaking for his take on tester’s responsibilities. Especially considering it was the first time he had ever spoken at a testing conference!

The seventh talk was about “Having all your Testers Code: It Doesn’t Have to be a Big Deal” by Andrew Morton and Anna Baik. In a way I’m a little jealous of them doing this talk as a lot of what they had to share was very similar to some of the work me and Greg Farrow had done over the past two years. But it was nice to hear someone else share the same tips and frustrations at attempting to set up their first automated regression suite. I’m very supportive of talks like this that share experiences because I know there are people out there that are in this position right now and it can be invaluable advice and tips. One such tip that I liked was making sure you set up just one automated test with your CI (Continuous Integration) first, as this is the fastest way to deliver value from your automated tests. Rather than trying to create all of your tests first before hooking it up to your delivery pipeline.

Next was Nicola Sedgwick’s talk on “Do Testers Need a Thick Skin? Or Should We Admit We’re Simply Human?”. I liked this talk because it covered a topic I’m acutely aware of and keen to keep an eye out for. We are asked to care for our work as employees and as testers, but at some level we have to be able to let go and not let problems get into our heads too much. Its very easy for a bug to be found in live and for testers to feel very guilty about ‘missing’ it. We know that we can’t find all of them, and sometimes we couldn’t have done anything to have found it but it is very easy to feel the pressure.

We then had another short break before Bill Matthews’ talk on “Smart Algorithms - Are We Ready For This?”. This was a fascinating talk discussing the challenges in trying to test programs that perform extremely complex tasks, such as AI (Artificial Intelligence) projects like Google’s self-driving cars. I think at some point in future I’d like to tackle testing a project like that, it sounds like a great challenge, especially with budget and time constraints I imagine!

The final talk of the day was by Nicola Owen on “Nowhere to Hide: Adjusting to Being a Team’s Sole Tester”. Nicola discussed her experience going from starting writing and running test cases with a big team of testers to using mind maps and working directly with developers. I definitely recognise a lot from my own career in this talk and one particular comment I liked was - “I found once Developers started reading my mind maps it felt more like a shared responsibility to test the work”.

99 second talks

Finishing off the conference was the 99 second talks. This was where anyone attending the conference could get up on stage and say whatever they like for 99 seconds (or less). As I’ve mentioned in earlier blog posts, I was encouraged by Rosie and Vernon to do one so up I got on stage!

There were at least twenty of us on stage and the way it worked was we would line up in a queue and pass the microphone to the next person when we were done. If we went over 99 seconds, Vernon would blow an airhorn to end a talk.

There was a nice mix of short tips and advice, rants, raps and fun! I particularly liked Emma’s rap! There were also several people (I’m really sorry, I forgot names already! Please comment if you read this!) who talked about how great TestBash was for them, how it’s encouraged them and built their confidence up. I saw several nice moments like this over the week and I was happy to see people such as that get up on stage!

Getting up on stage…

It’s funny how brains work, having done my lightning talk at the North West Tester Gathering in Liverpool last month, I felt relatively confident about speaking again. However, here I would be in front of hundreds of people instead of eighty! But the funny thing is, I actually found it easier and I think it was because I stood on stage in the queue for a while which let me get used to standing in front of so many eyes.

I talked about my recent experience re-learning the value of using diagrams to explain yourself, rather than always referring to words. I think I delivered it ok and people said it was good but I just hope it was useful to someone! This was all on camera too, so I’m not looking forward to seeing myself on video!

I think now I’ve done this though, I’ve not got any excuses left about submitting a talk to TestBash Manchester so...here I go!

Social stuff

After the conference we headed to a pub called The Mesmerist. Unfortunately by this point a few people had to go home, so for those I didn’t get to say farewell to - I hope to see you all again next year or at a meetup some place! I got chatting to even more people I hadn’t met before such as Olly and Steve (who had heard of and knew about ResponseTap!) so I successfully completed my personal mission to talk to at least one new face every day!

My final night of TestBash also contained a final nice moment where a certain well known speaker came over to speak to one of my fellow RST classmates. I think that moment summed up the whole week and the vibe of all of the events - all of the organisers, speakers and regular attendees were so happy to speak to new people and not just stick to their own groups. If there is one takeaway I would like to keep forever, it would be that - to always seek out new people to talk to and encourage new people to ask questions and get involved. I had gone to TestBash with my own personal mission do that, but it was very heart-warming to see very well known speakers doing the same.

Looking forward

I’m now home and catching up on my sleep but I’ve got a lot to look forward to! First on my list is catching back up with work and then starting on introducing the ideas and lessons I learned! Leigh has challenged me to do another Lightning Talk at Liverpool which I’ll gladly take up! I’m also attending my first ever peer conference next month!

Finally, I can’t wait for TestBash Manchester! I’m excited to see how Richard gets on putting a northern spin on TestBash.

I hope you have found my posts a useful insight into TestBash and I hope I’ve conveyed how friendly and positive the whole event is! See you there next year!

TestBash 2016 Day 4 - Distributed Teams Workshop

Introduction

Today I attended a workshop being run by Lisa Crispin and Abby Bangser called ‘Building Quality in with distributed teams’. I hadn’t expected to be going to this workshop until Rosie alerted me to a company giving away a free ticket to attend. So once again thank you Rosie and Inviqa for letting me know and sorting out the ticket for me!

I’ve not got a lot of experience working in distributed teams (that is, teams that are separated by location typically, such as in separate countries). But I was looking forward to learning a lot about it and speaking to other testers who clearly were already dealing with this challenge.

My main takeaways today

The workshop was just run in the morning, so it felt like a more condensed style compared to the 3-day RST course I had just finished. However, I was once again taking a ton of notes as I was eager to learn from the vast experience present that I could talk to about this subject!

The workshop began with people sharing their experiences and challenges with distributed teams before we were split up for a task. The task took up the bulk of the workshop and was an interesting little experiment with communication! I don’t want to give away too much about it, but the idea was we would split up into groups and try to carry out tasks in a simulation of ‘onshore’ and ‘offshore’ teams having to work together to satisfy a tricky product owner. This was a really fun task and there were so, so many behaviours and problems that came to the surface. I think even if you don’t work with distributed teams, this workshop can be very useful because the ‘us & them’ mentality can be seen even within the same office!

I’m really forward to talking about this workshop when I get back to work because there were so many funny similarities that I think we will recognise in our own work.

It was also nice to meet some new people whose background was naturally more from a distributed orgaisation, so I could really probe them for information and understand their challenges, I’m sure one day the information and tips will come in useful! It was also nice to attend as a novice in the field, it stops me from talking too much about my experience and forces me to listen better to people.

Oh and also, I also got do a little pairing work with Llewellyn Falco who I recognised from a talk he did with Maaret Pyhäjärvi on developer-tester collaboration. He was very quick to jump straight into finding ways to pair up on the task, which was a learning experience all in itself for me!

All in all, it was a fun workshop and I was surprised (I should really expect it!) how much I learnt from it, even how much I could recognise and tips that I could apply even at my current workplace. I would love to have a go at running the same task again one day!

Social stuff

Today we’re headed to the beach to a bar called Ohso Social. I’m expecting a lot more people and a lot more new faces at this meetup as it’s the night before the main conference. I’m keen to find out the details of how the various other workshops went for other people, I would have loved to attend Richard Bradshaw’s workshop on Lego Automation or Martin Hynie’s on TestOps which I believe includes exciting technologies such as Docker for setting up test environments quickly!

Looking forward

Tomorrow is the main conference day with a ton of speakers to listen to. The conference runs all day from 9am till 6pm so I'm making sure I take a nice big empty notebook to fill! I’ve also allowed myself to get talked into doing a 99 second talk in front all of these people so I’m more than a little nervous about that! I’ll be spending the rest of today thinking about what the hell I’m going to say! Wish me luck!

TestBash 2016 Day 3 - RST Last Day

Introduction

Today was a sad day, the last day of my Rapid Software Testing training course! I’m sad because it’s been so much fun and so much to learn. I think I would summarily describe it as ‘the best university lecture I never had’ - as in many ways it’s what I had expected from university. I think I’ve been hungry for a dedicated educational format for a while and I really enjoyed it. I’ve also met some great people and learned a lot from their different approaches and techniques.

My main takeaways today

The main topics for today were centred around managing exploratory testing sessions, how to report on them (if you need to) and some food for thought on how you measure the value of your testing sessions. We also talked through tips for taking better notes and how to use ‘safety’ language to improve our communication. We continued to use more mind maps and spent a lengthy amount of time collaborating and comparing each others, which still threw up surprises in how different people were approaching tasks and articulating themselves.

Michael also gave us the opportunity to ask about any topics we would like to talk about and we raised the topics of Regression Testing and “When do I stop testing?”.

I think out of the three days so far, this was the one where I felt I got a huge amount of value, I took plenty of notes and I’ve got quite a few ideas that I’d like to try out and discuss when I get back to work!

What do I think of RST? Do I recommend it?

I loved the course, my mind is swimming with ideas and I got answers to some burning questions that I’d had for a while. The format of the course is very friendly and accessible and really encourages collaboration and sharing which are values I really hold dear. If you have read a lot about RST already and are unsure whether to take the course - do it! I’m sure you have questions about what you might have seen or read, take the course and challenge Michael or James! If you have no idea about RST or are new to testing, this is hands down the best introduction to both testing and the community you can possibly get. It’s been a pleasure to share a room with bunch of great people and bounce ideas around about testing. Best of all, it’s fun! And it really demonstrates that testing can be fun!

Thank you to Michael for answering so many of my questions and being so approachable. Thank you to for all of your charm too! It really makes a massive difference to the mood of the class and people’s engagement! I learned a lot just from observing your teaching techniques and methods too!

Thank you to Dan Billing for being a great facilitator! Not only was he acting scribe for Michael and making sure all of the refreshments and lunch was sorted, but he was also taking the class himself too and dealing with various other issues. All three days went smoothly and not once were people left bored or waiting around, we were always engaged in the class!

Social stuff

Today we went back to The Eagle pub to play testing games with Michael and John Stevenson and also to meet all of the people arriving for the workshops tomorrow (Thursday). I caught up with a few familiar faces and met a few people that I wanted to thank for ideas they’ve shared such as Martin Hynie (who we have taken a lot of inspiration from at work). I also met even more new people of course such as Anna who I had a very long chat about interviews and what qualities we look for in testers!

Unfortunately we never got around to playing the ‘Dice Game’ in class because we had so much to talk about and we still didn’t get a chance in the pub. However, I did get to observe a game being played by Michael involving playing cards and an 'art collector'. I’m definitely going to be having a go at playing this with anyone I can when I get back!

Looking forward

Tomorrow I get to attend a workshop on distributed teams held by Lisa Crispin and Abby Bangser. I’ve definitely not got a lot of experience with this, so I think I’m going to be soaking up a lot like a sponge!

TestBash 2016 Day 2 - RST

Introduction

Today I continued my 3-day training course on Rapid Software Testing (RST) with Michael Bolton. My goal for this week was to try and share my experience of RST and TestBash so that you can get a feel for what it’s like to attend. So far I can definitely say it hasn’t been one of those boring corporate training courses you might get sent on!

My main takeaways today

Today felt like we really got to start practicing RST and learn about ourselves. Whereas yesterday we were blown away by new ideas and approaches, today we got to ask questions, try performing RST techniques ourselves and discuss how our views differed either with Michael or with each other.

The morning for me (and I suspect many others) was very humbling. Before taking the course I had a read a good deal about RST and about the ideas James and Michael share. I admittedly started the course with a sense of confidence that I understood and could practice a lot of it already. In reflection, I think this is the very thing I wanted to be challenged on, I think I subconsciously felt that simply reading about it wasn’t enough. Well, I got what I came here for!

The main morning task I eagerly jumped into and in hindsight I think it was a lesson worth learning. I won’t go into details as I think you should go into this course relatively un-prepared to get most out of it. But let’s just say that the course is definitely not as easy as it might seem at the time. This may all sound a little negative, but it’s not! In the afternoon I felt a little more at ease I realised:

1. I was definitely not the only one who felt like this!
2. It was an opportunity to learn from my approach and identify the differences that Michael was speaking about.

The afternoon session provided an opportunity to practice mind maps and Michael encouraged us all to share ideas and look at each other’s approaches to tasks. I had used mind maps before but not quite got the value out of them, so I really enjoyed this and I saw so much value in this very visual representation of test ideas. It was amazing to see how varied the approaches and ideas were.

Social stuff

After today’s session a bunch of us all met up at a pub called The Eagle (which is where we are meeting up tomorrow for the first of main TestBash meetups). A few people from the RST course came and also a few people I haven’t met before turned up from other workshops. I ended up talking a lot about the sprint structure at my current workplace and it was nice to try and explain it to other people and try and justify (and therefore reason) why it worked. I like doing this because it forces me to really think about my reasoning and whether it really makes sense! I always find a few holes in my line of thinking! It was also great to meet Vernon Richards again who I’ve met before from the Liverpool tester meetup and talk about some topics I’m interested in at the moment like speaking at universities!

Looking forward

Tomorrow is my last day of RST and I’ve been warned by a couple of people it’s the hardest day! I’m looking forward to it though but I’m sad it’s almost over, I’ve been loving the discussions, the challenges and the great things I’ve learned so far. I know a few people on the course are leaving right after too, so I’m sad that I’ve only got one more day to bounce ideas off some great testers! However, there are some people sticking around and plenty more new faces to meet, especially on Friday for the main conference, so I’m looking forward to all of that!

Bonus!

One more thing! Right at the end of yesterday, I was discussing the TestBash week with people and I was asked if I was attending any workshops on Thursday. After I said no, Rosie asked if I knew a company was offering a free ticket because one of their people had fallen ill and couldn’t attend. She gave me the details, I asked and now I can definitely say I’m attending a workshop on Thursday morning - "Building quality in with distributed teams" by Lisa Crispin and Abby Bangser. I’m over the moon about being able to attend even more and maximise my week! And I really can’t thank Rosie and the company Inviqa enough for letting me know about this and giving me the ticket!

TestBash 2016 Day 1 - RST Intro

Introduction

So today I started a 3-day training course on Rapid Software Testing (RST) with Michael Bolton. Wow. What a day, I’m excited to share this experience and I hope it encourages you too to take this course!

What is Rapid Software Testing?

Rapid Software Testing (as explained in the link above) is a training course designed by James Bach and Michael Bolton which aims to introduce methods and skills to testers that can help them become much better at what they do. I was keen to take this course having come across James and Michael’s content before for several reasons:

1. To become a better tester of course!
2. To challenge my own beliefs and understandings of testing.
3. To learn from other testers approaches to the challenges presented in the class.
4. To meet and discuss testing with like-minded testers and learn from their various backgrounds and experiences.

My main takeaways today

I wanted to try and keep up posting to this blog each day because I feel it helps me consolidate my feelings and thoughts and also because I’d like to share some of my experience with people interested or considering taking this course.

The bulk of the morning we were challenged in a task that I felt really engaged the whole class and I can only really summarise as the following line of thought:

“This is an important problem! And this is how testing should be done!..........oh wait, can I really justify that this is an important problem? Do I even know how to test properly?"

As you can imagine, there were some good debates and discussions that Michael really encouraged and I think we all were left feeling suitably challenged come the lunch break! I think everyone felt a little bit like what they thought they knew about testing was almost completely wrong!

In the afternoon, we continued on with further discussions which re-assured us all, that, yes we do know how test properly, and yes, those are important problems - but there are better ways of practicing testing and communicating our work. By the end of the day, I think we all felt exhausted but satisfied that we were learning a huge deal and not so concerned that we didn't know anything about testing!

Throughout the day there were lots of fantastic tips, guides and advice from both Michael and also from other class attendees! I think one of the biggest values of this course is learning not just from Michael but also from the other testers in your class, learning how their approaches differ to yours and the different ways of communicating and reasoning!

I was also glad to share some of my own tips for people, such as highly recommending Python as a potential programming language for interested testers along with the other recommendations such as Perl and Ruby. Apparently there are some very entertaining and effective kids books on Ruby and “I am a bug”!

Social stuff

I made the most of the opportunity to talk to all of these great testers and I’ll try to do a little roll call here of the names I’ve remembered (apologies to anyone I’ve forgot the names, spelt wrong or didn’t get chance to ask for! reprimand me tomorrow!):

Lisa, Aaron, Clare, Mark, Gemma, Martha, Dan and Tammy - thanks for sharing and chatting to me! I look forward to more! Sorry to anyone who I didn’t catch names, but thank you too for sharing a chinwag on all things testing!

I was also glad to pose a couple of questions I’ve been itching to ask Michael specifically about, and I’m looking forward to the answers over the coming days!

Finally, it was great to finally meet Rosie and thank her for helping me get to TestBash in the first place. The organisation of the event so far has been fantastic and atmosphere really open and friendly and I really appreciate the hard work she puts in to make it happen!

After ending the class today, I took the opportunity to chat with Rosie and ended up somehow signing myself up for a 99 second talk on Friday. We then headed to Wagamama with the rest of the class to eat food and be merry!

Looking forward

I can’t wait for tomorrow, to continue my journey learning how to test better and meeting all of these friendly people again! The main aim tomorrow is to learn (and remember!) more names and to keep challenging my views on testing!