Tag Archives: ministry of testing

It’s taken a while to write this. Not because I don’t have a head full of new ideas from TestBash but simply because it’s taken time to digest everything, put everything into a sensible order in my head, and come to come conclusions about the day.

If you hate long blog post then just read this bit 🙂

The Condensed Version

TestBash is great. It’s one of the friendliest conferences I’ve been to – people talk to each other, most people are really engaged in what they do, and it’s really easy to strike up a conversation with a complete stranger about something that you’ve seen or experienced. You should go if you haven’t already. Plus they video everything (and hopefully it’ll be online here soon).

The Long Version

Still here? Then read on….

I was lucky this year – I had the opportunity to speak again. Last time, in 2013, I was petrified. This time I’d spoken at a few more conferences and so I was altogether more calm and collected. From a personal point of view, one of the main reasons this was great was that it meant I focused more on the presentations that were on before mine. In 2013 I couldn’t tell you much about any of them. This time more of them went into my head 🙂

As usual I tried to write some mindmaps as the presentations took place. One great thing about TestBash is that there is only one track – and this means no difficult decisions about who to see, or annoying clashes. And from a presenters point of view it means you know how many people you will present to, i.e. everyone 🙂

So, here goes, my take on the day and what I saw.

Lean Coffee

If you come to TestBash and you don’t get up early and go to the Lean Coffee then you are really missing out. In fact more this time, there was also bacon 🙂 I love Lean Coffee, it’s a great way for people to get together and talk about what interests the group. We had some great discussion on a variety of testing topics and the whole event was really well attended this year, with lots of tables full of happy testers.

Then it was time to head on into the main auditorium for a day of talks.

The Rapid Software Testing Guide to What You Meant To Say – Michael Bolton

I started off trying to mindmap Michael’s presentation and then remembered why I don’t try and write mindmaps for Michael’s presentations 🙂 There’s so much information that it’s much better to sit back, watch, and then wait for slides or videos afterwards. In this presentation Michael took us through a whole bunch of statements on testing and software development, then dissected them, put them into Rapid Software Testing context, then reassembled them to show what should have been said. There was some great stuff in there – watch the video from the TestBash website when it is available. If you want to see a very small mindmap then here it is 🙂

Bug Detection – Iain McCowatt

Iain always gives a good presentation and in this one he took us through bug detection, from the perspective of tacit and explicit knowledge, the work of Harry Collins, and Dual Process Theory. Click on the thumbnail to get a full sized mindmap.

Re-running the ‘Are you a mac or a PC? battle … for iOS and Android – Sally Goble & Jon Hare-Winton

Sally and Jon from The Guardian took us through an entertaining presentation about the differences between iOS and Android, and how The Guardian approach mobile testing as a result. There were some interesting points in the presentation, and I really liked the gameification in the presentation as well, even if it did end up as a draw 🙂 Given more time then it would have been great to have seen some more detailed mobile testing information, but it was a fun presentation nonetheless.

I’d not met Martin before TestBash but got talking to him at the tester meetup the night before. His presentation was fascinating and explained how he had experimented with job titles and the effect that it had on how testing and testers were perceived. The results he presented were really interesting and certainly made me think more about what job titles and names really mean. I’m sure we’d all like to think that being called testers is great and people will always accept the value we know we bring, but perhaps that is not always the case.

I didn’t mindmap Martin’s presentation. It was before mine 🙂

Why I Lost My Job As a Test Manager and What I Learnt As a Result – Stephen Janaway

I spoke about my experiences of losing my job as a Test Manager. and shared my experiences of going through the transition. Being someone who now works in an organisation where there are no Test Managers meant that I was able to give my take on the future of Test Management, a future that I think does not, and probably will not, include the Test Management role in the way that it does today. I spoke about the changes that the organisation made in order to keep a focus on testing; things like test communities, a coaching role, and mentoring.

No mindmap obviously. I was busy 🙂 If you’d like to see the presentation then there will be a video on the TestBash website but why not come and see it live? I’ll be presenting a longer version at both Nordic Testing Days and EuroSTAR this year.

Myths and Legends of Software Testing – Vernon Richards

The legend that is TesterFromLeicester confronted some of the myths that we all experience as part of testing. With added tutu gags. Vernon gave us some great ways of confronting common myths and challenging those who share them. Watch the video – it’s great.

Quality doesn’t belong with the tester! – Maaret Pyhäjärvi

Maaret gave a really interesting presentation on how she has tested in a team with one tester. She gave some great hints and tips, and explained how her approach changed as a sole tester, and how the developers also approached quality as a result.

Getting Rid of Release Candidate Testing – Matthew Heusser

Matt’s presentation really interested me because we’d gone through the same transition in the past year and so I’d seen the arguments for and against. Primarily it was the testers who were more concerned about getting rid of release testing, and so it was interesting to see Matt’s take. I also liked his presentation style, using no prepared slides but drawing them on a iPad as he went. Really unique and it worked.

Click on the mindmap to get a larger version.

Automation in Testing – Richard Bradshaw

Richard took us all through his experiences in automation. I found it really interesting that he had first tried to ‘automate everything’ before understanding more about the differences between checking and testing, and how automation should be used to add value to software testing, not ‘be’ software testing. I didn’t get the chance to mindmap Richards presentation so take a look at the video when it’s available.

The Art of Asking Questions – Karen Johnson

We finished up the presentations with Karen, who sat on the stage and quietly and confidently gave us some great advice. She explained about how to ask questions, gave us a lot of really useful reading material, and explained in lots of details why asking questions in the right way is so important. You can find her slides on Slideshare and I’d really recommend reading them and following the links.

And the Rest

The 99 second talks were really great as usual. A real mix of topics, delivery styles and delivery. If you haven’t presented before then 99 second talks are a great way to get started and seeing so many new people up there and speaking was good to see.

Overall I love TestBash. It’s a conference that is so friendly. There’s lots of social events, it’s single track which means everyone sees the same presentations, and the lunch really helps to get people together. If you went this year then you’ll know how good it was. If you didn’t then why not? You should go next year. You won’t be disappointed.

You reached the bottom. Here’s your ‘prize’. TestBash makes people feel like this sometimes.

TestBash

I was fortunate enough to get the opportunity to speak at TestBash 2.0 recently. TestBash is one of the best software testing conferences, and this year it has a great line-up of speakers: James Bach, Seth Eliot, Matt Archer, Amy Phillips, me, Lisa Crispin, Huib Schoots, Bill Matthews and Tony Bruce.

Dan Ashby has written a great blog post about the presentations themselves, and I’ll leave it to Dan to explain what everything was about. I’ll do that for two reasons, one because he does a great job of explaining it, and two, because, as a presenter, I wasn’t always watching what was going on 🙂

My Presentation

I presented A Testers Hierarchy of Needs, which took ideas from Humanistic Psychology and the work of Abraham Maslow, and applied these to software testing, and the software testers. It stemmed from a blog post that I wrote last year, which seemed to be well received, and attracted a fair few comments.

TestBash 2.0 is less than 3 weeks away. I’ll be speaking on “A Testers Hierarchy of Needs”.

What motivates you to work and improve as a tester? Why do the testers in your team work well together? Or why don’t they? Have you ever wondered what motivates professional testers?

Maslow’s Theory of Needs seeks to describe the psychology of humans by way of a hierarchical model. From physiological needs up to self-actualization, it helps explain what motivates us and how we express that motivation. A Testers Hierarchy of Needs does the same for software testers.

If you manage testers and have a keen interest in ensuring that your team are motivated and work well together, or if you are a tester wondering what is needed to make your team great, then come along and discover more. I will present a framework which helps explain tester psychology, how internal and external factors can affect their motivations, and steps that can be taken to better motivate yourself and your team.

Why you may need to do some actual testing in the interview for your next testing role

When I was starting to think about writing some posts to help out those who are either recruiting testers (see here for my first post), or for testers looking for new roles, the obvious first post was going to be around interviews. Interviews are scary, interviews need preparation, etc.

But to be honest, there is already so much available on the web that’ll teach you the basics, that I’d be re-inventing the wheel.

This is the second post in a series on finding a job within testing – the first one is Starting a New Job In Testing which you can also read on this site.

Basic interviewing techniques

If you need some help on basic interviewing techniques then I’d recommend spending some time on Ministry of Testing, looking at the recruitment resource section. What I want to discuss in this post is an interviewing technique we are using where I work, in order to help us recruit testers. It’s not new but it’s also not typical, and so hopefully it helps you.

A typical interview

A typical interview has a set of questions, and sometimes a script to follow. While the questions may not be written down, an experienced interviewer typically has a number of questions in their head that they can tailor to the interview situation, and use to steer the conversation in a particular direction. There may be a formal test, or the interview may just be conducted verbally.

Simply asking someone questions about testing, and gauging their responses, is one way of understanding in more detail what they know. You can also find out more about who they are, and what they can bring to the company. While we are following this approach, we’re also doing things a little differently.

Persona based interviewing

In a persona based interview, each of the interviewers play out part of a task based story, which the candidate is also a part of. One of more scenario’s are played out, normally based around a task that the candidate would typically face if they were successful in joining the company. The interviewers take different persona’s, each playing the part of a role or person that the candidate would need to interact with, in order to successfully pass the task that they are set. In this way the interviewers can understand how the candidate approaches particular tasks, how they solve problems, and how they interact with others.

For our interviewers for mobile test positions we typically play out some scenario’s based around testing our applications on real hardware. I won’t go into too much detail, for obvious reasons, but the candidate receives a certain testing task, and then is expected to start testing and exploring the application in order to successfully find bugs within it.

We play the parts of other people in the story. These could be the Product Owner deciding on re-prioritisation, other testers being able to offer advice, a developer being difficult or helpful, or even a senior manager wanting to know the progress of a testing task. As we go through we throw in these sorts of requests, and other changes to the scenario, in order to see how the tester works when requirements change and the pressure mounts.

Attempting to complete the tasks without interacting with the other roles within the scenario is very difficult and we are looking as much towards how and when the candidate asks for help, as we are to the testing skills that they show.

After the scenario’s are complete then we discuss with the candidate how they think the scenario’s went, what they thought went well and what they would do differently if faced with them again.

Is persona based interviewing useful for test roles?

We think it is. Mainly because:

It gives us a better idea of how the candidate thinks, and how they approach a testing problem

I’m a firm believer in context-driven testing and Rapid Software Testing in particular, as is the company I work for. To me, being able to observe how someone approaches a testing task, who they communicate with, and what questions they ask is very important. Being able to get an understanding of how they change their approach based upon the context is also much easier within the scenarios. Using persona based interviewing I get to discover more about ‘how they tick’ rather than what testing terms they can remember, or how much of their career story they can tell.

We get to see a candidates real, practical skills

By giving the candidates tasks based around testing our live applications, usually on an iPhone or iPad, we give the candidates an opportunity to demonstrate the real, practical skills that they have. We encourage the candidates to talk us through what they are doing and give them the opportunity to demonstrate what they know. Being able to demonstrate ability also puts people more at ease and we get to see what they can really do.

It focuses on critical assessment and improvement

By having a de-brief or lessons learnt session after the scenario’s have played out, we also get to see how a candidate critically assesses themselves, and discover what they would do differently given another chance. Making mistakes is human but learning from them is the important thing, and I don’t expect testers in my teams to get everything right first time. However I do expect them to be able to recognise ways in which they can improve.

It’s more fun than just answering questions

It’s certainly more fun for the interviewers, and hopefully it’s also a bit more fun for the candidate (as much as interviews can be anyway). Asking questions isn’t much fun, and only being able to show your skills in simple answers, is not the best way to spend your time. Demonstration of skills tests how a candidate works not what they can remember.

So, why not try persona based interviewing next time you are recruiting for testers. It can be a great way of finding really good people who you can have confidence will do a good job.

The next post in the series will be about C.V.’s, and what you need to highlight in order to get noticed.

Some exciting news – I’ll be speaking about “A Tester’s Hierarchy of Needs” at TestBash 2.0 which is being held in Brighton, in the UK, on Friday 22nd March 2013. This will be the first time I’ve spoken at the event, and looking at the others speakers, then I’ll be certainly in very good company. James Bach will be giving the keynote.

You can find out a lot more about TestBash 2.0 at the event website, including how to get Super Early Bird tickets.

Caveat – this is not a list of exactly what happens in a Rapid Test Management class, nor is it a list of exercises and course material. You won’t become good at Rapid Test Management by reading this post. Sometimes I forget things. If you really want to know about Rapid Test Management then you need to sign up for the class. It will be money well spent and this post will tell you a little about what might happen if you do take the class.

Last week I had the opportunity to attend one of the first Rapid Test Management classes, and certainly the first one to have been run in the UK. It was a great experience and the beginning of a lot more learning. There were attendees from a number of different areas of software testing and together I think we formed a very effective group, learning from each other and sharing experiences.

Rapid Test Management follows on from the Rapid Software Testing class that James Bach and Michael Bolton teach. I’d attended James’ class in Cambridge at the beginning of March and so, with the class material and my ideas rolling around in my head, I pitched up at the Hilton hotel in leafy Kensington (well almost Shepherds Bush actually) for two days of intensive learning from Michael.

Rapid Software Testing is a context driven technique, intended to enable testers to excel at our chosen craft. Since it focuses on testing as a craft itself, instead of merely on the production of test cases and then their use for testing (or it could be argued merely for checking) then this does put some questions in mind when considering how best to manage it. By way of some preparation, I noted down some of the questions that I had:

How can I best manage each testers time when adopting a Rapid Testing based strategy.

How does estimation fit in with the Rapid Software Testing ethos?

How can I sell the idea of Rapid Software Testing not only to those within my team who may be sceptical, but more importantly to those who manage me, who are most likely not only sceptical but also less knowledgeable about software testing in general?

Day 1

The class was split into two days, the first morning focused mostly on refreshing understanding of Rapid Software Testing and ensuring that, as a group, we had effectively collected our own desired outcomes from the class. It was good to spend some time going back over the methodology itself even though I had learnt it very recently. It was great that Michael seemed happy to tailor the class to the audience in any way that was necessary, taking a lot of time to ensure that everyone’s opinion could be heard.

What I found great about this class, and the RST course, are the little nuggets of information, stories and quotes that James and Michael pass on. Looking back through my notes from this class I find that’s what I mostly write down, quotes like:

“Quality is value to someone who matters”

“Testers tell stories about products”

We also spoke in depth about the testers Elevator Pitch, that two minutes where you have to explain what testing is all about. Being able to explain and justify the role of testers and test teams is a critical skill and Rapid Software Testing gives you that skill.

When implementing any changes, such as introducing Rapid Test Management for example, then it’s critical to take into account the existing knowledge and processes that are already in use. Michael stressed the importance of ensuring that it’s not only the documented processes that are considered; in fact it’s the informal processes that are far more important to understand. He spoke about tacit vs explicit knowledge and how it is important for managers to be aware of the tacit knowledge in a test team and not merely the explicit knowledge.

We then took a look at how to put together a good team and how to train a new tester who was coming onto the team, through guidance and suitable heuristics. It was great to discuss with the others in the class about the issues they had faced when coming into a new team or bringing new team members in and also what had gone well. Ensuring that people are trained in a fault tolerant environment and gradually introduced to new tasks may seem fairly obvious stuff but it’s often over-looked, as is the need to ensure that feedback is both given and asked for from new team members.

Last week I had the pleasure of attending Rapid Software Testing training, organised by The Ministry of Testing. Rapid Software Testing is a technique popularised by James Bach and Michael Bolton and hopefully is not something new to you, but in case it is then I’d recommend looking at James Bach’s website. He explains it much better than me 🙂

The course was in Cambridge in the UK, and after a quick and easy train ride up then it was easy to find the hotel, dump the bags, and then go out to the Software Testing Club Meetup. This was a good start to the course, an initial networking event which James also attended, as well as a lot of local testers who were not attending the course. We had some great discussions and I met a lot of new people; you can see some photos from the event which have been posted up by Rosie, the organiser.

Day 1

Then to the first day of the course itself. From the moment the course started it was apparent that this was not your typical technical course. James’ style is well—known, just search YouTube if you want to see him in action, and he carried this into the course itself. He certainly knows his stuff, and presents in typical provocative style and is capable of causing many eureka moments. It’s very enjoyable, but initially tough, stuff.

We focused mostly in the first day on what Rapid Software Testing is, and the overall philosophy of the techniques. Rapid Software Testing is most useful to encourage testers to defend and think for themselves from a position of technical authority, especially useful in periods of uncertainty. Plenty of examples were given and James was able to draw upon his many years of experience in testing, both hardware and software. The time went by quickly and there was plenty of audience participation. James’ style is very much to put the audience members on the spot and ask some very difficult and blunt questions in order to replicate the pressures that testers can feel as part of project teams. To a few this comes naturally, but to most of the audience, this was a long way out of the comfort zone. We tried to help out whoever had been picked for a particular challenge, in order that the class as a whole could benefit.

The day concluded with an exercise on testing some everyday objects. Sounds simple, right? Well no. In case you will go on the course yourself then I will not give too much away, but suffice to say that there is much more to testing something which appears simple, than one at first thinks. It’s these sorts of exercises that open the mind and help learning.

Day 2

After a good dinner with some new software testing friends, and a decent night’s sleep, it was time for day 2. Here we went into more details of Rapid Software Testing and the relevant testing models. Again the examples given were general, intended to make you think like a tester irrespective of your background, and plenty of pressure was applied to those who James selected from the audience. We looked at the differences between scripted and un-scripted testing and exploded some myths about both areas. We also talked a lot about oracles and why they are essential in testing. As an example, I was surprised to find that a person can be considered as oracle.

We also discussed heuristics a lot. Rapid Software Testing has many heuristics, the fact that James can remember and explain them all straight from his head is somewhat impressive. As with a lot of the techniques and information, a fair amount of common sense thinking was clearly applied when inventing the heuristics, but it was good to get names put to techniques that I was using already, for consistency if nothing else. There is a danger of quoting too many heuristics of course, especially when dealing with other’s within project teams and management. James’ view seems to be that by bombarding those outside of testing with information and explanations, using the relevant heuristics, that testers gain legitimacy. I do not agree with his approach to the length that he presents it – clearly testers need to be able to explain themselves – but there is a danger of losing credibility if too many heuristics are invented and then explained, which merely represent ‘day-to-day’ work. Take a look at James’ slides and see if you agree.

By the end of the day we were questioning practically everything about testing and about the way we were working. There is a danger from this course that one starts to question too much but one needs to start small and work up I think. That’s certainly what I intend to do.

Day 3

The final day of the course started bright and early with more of the same. We focused on exploratory testing again, with more details, and talked a lot about documentation, metrics and information. The idea of focusing on a particular testing task, using some heuristics, but knowing when it is not working and de-focusing at this point, was a great learning for me. We also went into more detail on exploratory and session based techniques, something which I wish we had spent a bit more time on in previous days.

The main exercise for the day was based around finding a pattern for a system based upon dice. I won’t go into too many details on this (it’s explained pretty well at Better Testing) and also I do not want to give away a potential solution to anyone. But suffice to say it was a great opportunity to put into practice some of the techniques that we had learnt. Our group were not the quickest but neither were we the slowest, and it was certainly a good challenge.

The day then concluded with a wrap-up and overview of what we had learnt. Then some brief goodbyes and swapping of LinkedIn invites, and home to try and make sense of a busy three days and how what I had learnt could be applied to myself and the team members in my teams.

Overall

If you get the chance to go on Rapid Software Testing then go. Don’t think too hard about it, the course if very worthwhile and you will get a lot out of it. It is not easy, you will most likely feel uncomfortable at times with the training approach and some of the content may well seem obvious on first pass. But once you think more, and you start to question your own approach, with the techniques, tools, and even just the words, to back-up what you already know, then this course should make you a better tester. It would have been good to have seen a little more on session based techniques in detail and more about the tools that can be used, but I understand James does a separate course on this.

Thanks also go to Rosie Sherry, the course organiser. This was the first course that The Ministry of Testing have organised and if this first one is anything to go by then Ministry of Testing has a bright future. The venue and organisation was great, there was a really friendly, small company feel about things, and it was very easy to meet new people and learn together. Definitely three days well spent.

Tomorrow I’m leaving the safety of the South to journey far North* for something that I’ve been looking forward to for a long time. I’ve been fortunate enough to be able to sign-up for James Bach’s Rapid Software Testing course which has been arranged by The Ministry of Testing in Cambridge.

To say I’ve been looking forward to this for a while would be an understatement. Unfortunately due to budget constraints then it’s not been possible for me to get on courses like this in the past few years but ‘fortunately’ now that things are closing, then there’s a bit more money available for training and this will be money very well spent.

First stop is the Software Testing Club meetup tomorrow in Cambridge then on Wednesday the course starts. I don’t know what to expect but if it’s three days of hard but rewarding learning then I will be very happy. Having already taken a look at the course outline and slides then I’m sure it will be.

I’ll try and blog daily about my experiences, assuming I have the time and brain power left to do so 🙂

* (non-UK readers – we have a big North-South joke thing going on in the UK. If a place is north of Watford, which is a bit north of London, then us native southerners joke we’re out of the safety of the south and that it’s grim up north 🙂 Even though it isn’t and Cambridge is not even in really in the north anyway).