Team Tourism! It's a thing!

In the last few months of my life, there has been a lot of change. I started my own testing consultancy and most of my days have consisted of meeting people and trying to figure out my elevator pitch. I have been feeling like I am spending most of my time in the Chaos zone.

After receiving our Team Tourism passports at the Driven Alliance Unconference, I realised that there may just be a moment of escape and perhaps a transforming idea or two. Travel does this for me… .and now I could do some ‘travelling’ right here in my own town! :)

I emailed Oz and asked If I could come and visit the Keyblade Team at Firstrand as my first destination. I arrived just after 9 so I could be in time for an intro before their standup.

When I walked into the Keyblade team room these are the things I noticed -

• The room felt like a calm space - I felt good energy
• There were 2 MASSIVE awesome TV screens with multiple keyboards in front of them
• There was a monitor with 3 red blocks on it
• Some blue balls around the room (to sit on)
• An interesting looking scrum board with not that many stickies on it

I was introduced to the team (many of whom I already knew) and we went on a coffee mission. They have really good coffee… and an amazing coffee machine.

Oz talked me through the board and explained how they run the standup.

Standup happened and people spoke about the work…  and there was some nice banter in between. They have a format for their standup which I liked a lot -

1. What’s broken and why?
2. Anything we’ve learned and would like to share?
3. Walk the board (talk to the actual work)
4. What’s not on the board?
5. Can we deploy?
6. What’s the next most important thing we’ll be working on today?

The team then picked the first problem for the mob and we got going. I was IN the mob. Listening and trying to ask questions where I thought it might be useful. I was able to get a feel for the problem and the troubleshooting of it. So many good things about a mob.. That is a whole other post.

I spent a day with the team and the things I saw, make me think that this team is biasing themselves for greatness. They have created an environment where they are constantly thinking about how they can -

• Respond to the business
• Experiment and fail fast
• Write solid maintainable code paying attention to testability
• Share their knowledge
• Have fun
• Self organise
• Use time effectively
• Respect everyone’s contribution to the team

I think that context matter. The more I can study the principles that are important across contexts and the context specific practices that people use to address these principles, the better chance I have to notice when things are not optimal. I also want to have a box of experiments to pull from to try and make them different. I think this is what everyone can get from a bit of tourism. Also, the more we can share our ideas and experiences, the better chance I think we have of moving the craft forward.

So find a team today and start getting some stamps in that passport and ideas in the toolbox!

Get inspired, join a community, work on your technical skills, play games, write a book!! Let's Test has something for everyone!

Being a tester is not always easy. It sometimes feels like we are swimming upstream and it is a lot more fun swimming with friends. There is a difference between trying to learn things from reading and adapting, and having these things brought to life by people who have tried things and had experience and are super excited to share.

About 6 years into my testing career I managed to convince my boss to send me to CAST (Conference for the Association of Software Testing). I am an introvert. While the thought of talking to a bunch of strangers and being in large groups of people, was incredibly daunting, the chance of meeting and learning from great minds in testing, forced me to get out my comfort zone. My first day was a tutorial session with James Bach. Someone whose work I had studied, and pored over, and attempted to use and adapt on a daily basis in my testing. James was teaching heuristics and we were encouraged to write our own. A scary task when you know you will need to share your thoughts with all those strangers!!!! A heuristic that eventually came to mind was 'Slowly, slowly, catch monkey'. I described what I meant, and it resonated. In the painful moment of feeling alone and overwhelmed, I got to meet testers from all over the world who were in a very similar position to me. That was the beginning. We bonded. They became my friends and part of my testing community. They introduced me to other testers. We formed a 'gang'. We talked over Skype and supported each other and sat talking testing until all hours of the morning. I realised that there were people with a similar passion. We could discuss our experiences and debate our thinking and move our craft forward. It was an experience that would change my career forever.

This is what we want to bring a lot closer to home for all testers in SA. We want you all to know that you are not alone, that there are people right here who share your passion and want to move the craft forward. They will be at Let's Test. You should be there too!

What I really meant by Slowly Slowly catch Monkey...

I'm busy reading Patterns of Quality - How Software is built by Jerry Weinberg. I came across this paragraph in Chapter 4 -

"When trying to introduce change in software engineering practices (or any practices, for that matter) it’s often better to work by addition, rather than subtraction. Instead of continually emphasizing what people are doing wrong, emphasize what they are doing right so that they will do more of it. Also, you can point out that there are things missing, but not too many at one time. You may need to say something about state B in order to motivate them to change at all, but don’t overwhelm them with their sins. It only makes them feel powerless and unable to make any creative changes."

It was at CAST 2007 that I first attended a tutorial led by James Bach and learned about Heuristics. In writing my own (Slowly slowly catch Monkey) the above describes what I meant (and didn't articulate nearly as well :)).

Presenting at CAST 2010

In early August, I will be presenting a paper at CAST 2010 in Grand Rapids, Michigan with Carsten Feilberg entitled "Nice words are not enough". The paper describes our experiences with introducing session-based and exploratory testing approaches in organisations that are more accustomed to detailed scripted tests. Projects where tests are designed upfront and progress is measured in numbers of tests passed. It also looks at some ways we used our skills to face the challenge.

I met Carsten at CAST in Toronto - in 2008. One of the many benefits of attending CAST is that you end up building a network of people that you can call on, debate things with. People who are just generally fun to hang out with. Carsten is one of those people and he has encouraged me to do this with him. Although it is a scary thing for me, I am also glad that I am finally stretching myself in this way.

Putting the paper together has been an interesting process. Although we are on opposite sides of the planet, in terms of our experiences with using session based testing as as approach we faced very similar challenges. It was also interesting to collaborate with someone that you are not in the same room with. There is a level of trust and understanding required when communicating in this way. I think we had that down.

So why did we write the paper? Well, Carsten thought that we might have something interesting to share... and I agree :)
I am hoping that people will take away some ideas they can experiment with on their own projects. I am also hoping that we have some cool debate and discussion around the "numbers game". Finally, I am hoping that people get a sense that they are not alone. That there are lots of us all over the world struggling with these same kinds of projects and project managers. :) All trying to figure out how we can communicate better and add the most value possible.

CAST is a really special kind of conference. One where you end up meeting people that inspire you. One where debate and discussion is not only encouraged, but where the environment, facilitation and organisation supports it. There is also an opportunity to meet and debate with some of the most thoughtful and thought-provoking super testers around - Cem Kaner, Scott Barber, Karen N. Johnson, Doug Hoffman. And my friends who will also be presenting, Carsten Feilberg, Henrik Andersson and Johan Jonasson.

I'm excited. Hope I see you there!

Back to blogging...

I have just completed an extremely exhilarating project that was supposed to be a quick 6 week testing assignment for 6 people. It ended up lasting a year and at its peak, the project test team was at 19. On this project I was able to really get my hands dirty and do a lot of testing myself. Something which I hadn't done for awhile. I had almost forgotten just how much I love it. The thrill of finding juicy bugs and coming up with new and exciting ways to break something. It was great to put into practice some of the things I learned on the BBST Bug Advocacy course and also to refine my approach to Session based testing.

Although the project implementation was the hardest I have worked in a long time (and possibly the most stressful implementation I have ever been on) I learned a lot and am really grateful for the experience. The project also presented the opportunity to work with a fantastic bunch of people. I felt like I truly collaborated with the developers on the project. We formed a great team and it was a pleasure to work with such professional and dedicated people.

And now its time to move on to new things... and some old... and I am looking forward to hopefully having a bit more time for research and blogging and mentoring. Before I start the new project however, I am off to an extremely exciting course in Albuquerque, New Mexico - PSL I first heard about PSL from my CAST buddies. A couple of them attended last year and could not say enough about it, so I decided I had to see for myself. I am looking forward to learning and growing from the experience. Hopefully I can bring that back into the next project and use the skills to cope with whatever new challenges come my way. I'll be blogging about it as soon as I am back....

Fieldstones ... an experiment

I came across the concept of "fieldstones" when attending the BBST Online Instructors course after CAST last year.

This snippet is from the BBST instructors website:

'''What is the Fieldstone Method?''' In ''Weinberg on Writing'', author Gerry Weinberg describes how he collects ideas for small chunks of writing for later use. If you're interested, we invite you to read more about Gerry's ''Fieldstone Method'' at:

• Gerry's writing blog
• Gerry's website
• One of many reviews of his work

Last year, I was doing quite a lot of mentoring of testers and found that in evolving my approach to this, I wanted to develop something that I could refer back to so that I wouldn't forget to talk about the important stuff. I decided to start collecting my thoughts during sessions and then putting these into Mindmaps. Each time I had another session, I could use the map as a guideline for talking about the topic and during the session refine it. I guess you could also call these mindmaps heuristics. The initial thoughts that I collected came from research into and experience of a specific testing task. Although the ideas are not all my own, they are all things that I know I have applied and have worked for me and I'm confident I can explain and teach. I am looking to share these over a period of time and would like to ask for feedback and questions in terms of how useful you think they may be as well as any questions on the content.

CAST 2009

I am very excited to once again be attending CAST this year. Even though times are tough and I am going to be totally self sponsored this year, I decided that I just couldn't miss it.

What makes it even more exciting is that two of my friends (Tim Coulter and Henrik Andersson) that I met at previous CAST conferences are giving presentations. I can't wait to hear them speak.

I had a seriously difficult task picking the tutorial I was going to attend and in the end have selected Jerry Weinberg's entitled "Ensuring Testing's Proper Place in the Organisation", however I am hoping that some of the other tutorials may just get repeated after the conference so that I can also attend something else. (James Bach, Scott Barber and Michael Bolton are ALL giving tutorials!!)

Once again, for those that haven't heard about or read about CAST it truly is one of the most inspiring things you can attend as a tester. The things I have learned and the people I have met over the last 2 conferences I attended have really helped to shape my views and also my career in testing. The value extends beyond just the material. I have without fail come back with new inspiration and ideas that I can try out and reinvent for myself. Not to mention the network of people all over the world that I now call my friends and am able to rely on for advice and discussion.

If you are thinking of attending a conference this year (or ever) make it CAST!

Mentoring fieldstone 1 - Requirements analysis

Much of my testing experience has been in regulated financial institutions (yes, there are such things - we have rather tightly regulated banks here in SA) and so we spend quite a lot of our testing time analysing and raising issues against, specifications. I have evolved a Mindmap to help me when mentoring people in this process and would like to put it out there for comment or maybe it helps you in some way. I realise that since this is a Mindmap, much of it may be rather cryptic, so please also feel free to ask me questions.


Please note that the reference items for this Mindmap are:

• Specification-based testing by Cem Kaner
• Exploring requirements by Jerry Weinberg and Donald Gause

Ranting...

James has just written a thought provoking blog outlining a hypothesis that Quality is dead. Having seen the things going on around me lately I tend to both agree and slightly disagree… and then end up firmly on the agree side.

At our previously major client (a large financial institution) they are now firmly in the trenches of their shiny new outsource deal with large outsource company.

A couple of reasons why I think that on the surface it may appear to have been a fantastic idea (and supportive of quality):

Millions have been spent on an end to end test environment – they have made a significant investment in testing

There has been a concentrated effort to get an end to end environment in place that can be accessed from Chennai. The outsource company will in the end have full control over the environment. We were testing most of our mainframe code along with the developers making their changes as and when they liked and with absolutely zero control over what they were doing. Sometimes if they were nice, they would let you know. But I guess if you are going to be spending that much on the total testing effort, then another few million is worth it to make sure that your testing is happening in a proper environment.

People are having to pay attention to their project plans and project planning – and so in theory, planning will improve and more time can be allowed for testing

The deal is fixed price based on a budgeted number of hours that need to be decided on, a quarter in advance. The ways things worked (when we were still around) is that when projects ran late, testing always “made a plan”. There was no fixed number of hours so we reallocated resources, cut our scope, worked silly amounts of overtime, analysed incomplete specifications and basically did everything possible to be “part of the team”. These guys don’t have to. I suppose that neither did we. Maybe the difference goes back to a perception of value. Since the Financial institution is now paying significant amounts more than they were previously paying per hour, people seem to listen more. Everyone has to sit up and take notice because if they budget for hours and the rest of the project is late…. well it’s tough. They need to repay for the new testing hours that will now be required in the following quarter OR pay a premium to have an amendment to the contracted hours. So should we have played the same game? Does it result in better quality? I don’t really think so… but I don’t have any proof yet. I do know that the perception when projects run late is no longer that it is a “testing problem”. The blame is now sitting firmly back in the Project Manager’s court.

Reason why I think it sucks

“The skills argument”

One of the primary reasons given for the outsource deal (or the way that it was sold to the trade union) was that the skill required to test the types of applications key to the future strategy was not available in South Africa.

I was copied on an email the other day where the new team were required to test a change control and so instead of analysing the change to determine what needed testing, they simply asked the developers, “which of the list of abc do you suggest we test?”. And then that was what they went with. Is that skill? Is that evidence of skill? I suppose they can always blame someone else if there are bugs in the part that they didn’t test. I guess they have a different view of quality.

How was our skill judged I wonder? Was it the fact that we didn’t put our foot down hard enough? Would we have been adjudged to have more skill if we were more expensive? Perhaps, if we had big fancy certifications…?

Even IF it was the case that we had no skill or not enough skill, and this is the part that kills me, why not invest all those chunks of money in upskilling local people? In a country where there is over 30% unemployment! Why not work with people who are trying their utmost to develop the skill within the sector that needs it the most?

Instead they have chosen to spend millions in someone else’s economy. Our industry is now over 400 jobs short with around 300 of those people searching the market – just from this company’s decision - with less and less jobs available as more and more financial institutions head in the same direction. And this from a company that claims it is committed to black empowerment. I just don’t get it.

It all makes me tired and depressed and feeling unappreciated. Tomorrow I’ll be inspired again to change that… for now I had to rant.

p.s. See also Ben’s thoughts after reading James’ blog.