Tag Archives: experiences

"ministry of testing", "rapid software testing", blog, Experiences, Exploratory Testing, practices, Testing

Experiences of Rapid Software Testing

3 Comments

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.

Experiences, Testing

My First STC Meetup

Leave a comment

Meeting New People

Last night I went to my first Software Testing Club Meetup in Guildford, Surrey.

What’s A Software Testing Club Meetup?

A Software Testing Club Meetup is simply a meeting of like-minded people. Mostly testers 🙂 It’s an opportunity to talk testing and normally have a beer or two. And in this case it was pie night in The Keystone so there was some great food as well.

So What Happened?

It was a very enjoyable evening. There were a great bunch of people there. ‘Hello’ everyone at IDBS, and all the other people that I met, talked testing and ate pies with. This was the first meetup that’s been done in this area, and also the first time I’ve gone on my own to anything like this, but it was really easy to settle in and get chatting. We had some good discussions about Selenium, software testing certification, and I got some great tips on freelancing from Alan at StoryIQ.

If you’ve never been to an event like this then you really should go. People are friendly, and it’s a great place outside of work to talk, and to find out experiences from other parts of the industry and from testers working in other companies.

Rather stupidly I forgot my camera, but fortunately other’s didn’t so there’s some pictures here.

Thanks to Lynda for organising, and I hope there’s another one soon.

blog, Experiences, management, practices, team, Testing

!(Certification) = !(New Job)

16 Comments

There’s a lot said in the testing press and blogs about certification. There’s some well known haters of ISTQB and a few, albeit quieter, exponents. There is of course the training providers shouting loudly about their guarenteed pass rates, how their courses are faster than all the others, and how you won’t survive in testing without the qualifications that you can get from them. Is certification as important as they say? I’m beginning to think that maybe it is, but not for the reasons their sales people present.

Firstly some background. I’m ISEB Foundation and Practitioner certified. I enjoyed the courses which I did with the excellent Grove Consultants a few years ago. OK, the exams were not fun but the courses were. I felt like I learned something and I went along because I wanted to learn. The qualification was good, but secondary. I felt it wasn’t essential. I still feel this way, I’m not an out-and-out ISTQB basher but I feel things are beginning to go too far.

Once I became a team leader, and then a test manager I continued to send people on the courses. Some didn’t want to go, but I felt it was important for them to learn something new, and more importantly to learn the same way, and using the same information, that the rest of the team had already learnt. It gave some consistency. That was useful.

Fast forward a few years. I now have a team of testers and delivery ops people. Times have been hard and training has been hard to come by, by the time these people joined the team there was no training available that would lead to the ISTQB/ ISEB certifications. Has the quality of what we do decreased? Well, no. If anything, we’ve gone out and trained ourselves, trained ourselves, and updated our ways-of-working in even better ways. We are still consistent in our approach, and as a bonus, some people can now train others. Also a good skill. Not getting the ISTQB training has annoyed some, whilst others weren’t bothered at all.

Now my team and I find ourselves in a new situation. Soon we will all lose our jobs as R&D is moved overseas. Suddenly the issue of certification slams itself forward again. Most of the job ads scream ISTQB certified, for recruiters it’s almost the first question asked “Are you ISTQB certified?”. How have we come to this?

I think a lot of the testing community is stuck in a vicious circle. If we get lazy with our recruitment then we quickly fall into a trap of just putting “ISTQB certified” in the “Essential Requirements” section of our job ads. We are the ones who caused the recruiters to ask “Are you ISTQB certified?” Certification within the industry becomes self fulfilling. And those of us recruiting testers don’t necessarily get better testers.

So what’s the solution? More certification? I think all those of us who recruit for software testers need to re-visit what we look for in a tester, to adjust our outlook and our requirements so that we are trying to find those who are good at what they do, not what they have studied. A few years ago I used to run a written interview test for candidates which was based on the ISTQB syllabus. Many of those with the qualification failed.

And to my team, without certification and needing to find new jobs? I’ve sent them on ISTQB courses. It’s only fair, they need the best start they can get in their job searches. But if I find myself in this situation again then I hope that it’s not this way….

* For those of you without any programming knowldge – ! in the title means “Not” 🙂

Image: jscreationzs / FreeDigitalPhotos.net

blog, Experiences, Exploratory Testing, Testing

Some Brief Words On ET for Mobiles

Leave a comment

No not the short, funny coloured alien guy….

Yesterday I attended a exploratory testing session for the latest change that my team are testing, on new feature phones. So we’re talking mass market devices, ones where a bug let out into the field can wipe out your profit and destroy your reputation. So we like to get our QA right, you could say.

Overall the session went well. We found some bugs even though the feature under test is pretty close to release maturity now. There was a great mix of developers, testers and some of the release ops team (aka the CI guys). We like to use these sessions to bring the team together. Using Agile sdlc’s helps here anyway, but having everyone testing together and helping each other is great for the team spirit and the togetherness. It was good fun.

So here’s what went well and what to try differently next time:

* Make sure you do not limit your sessions to just the testers in your company. Get everyone together, it’s fun.
* The leader of the session is important to keep things flowing. Our test lead brought ready flashed phones. And food. That helped.
* Make sure you have a structure to the session. We used charters.

And some areas to learn from and change:

* Getting results and statistics from the session wasn’t easy. Next time we will try session based (as I’ve used in other teams).
* Get some commitment from participants and make sure they come on time. People who drift in and out break the focus of those testing.
* Make sure there are chargers and SIMs with relevant features available.

Overall it was most enjoyable. I can’t wait for the next one.

*and in the true spirit of mobile, I’ve written this whole post on a Nokia E7 using cutepress. Yep, I’m still a Nokia user, and still mobile obsessed 🙂