Category Archives: management

My Experiences of WeTest 2016

tl:dr;

I really loved being a part of WeTest 2016. I gave the opening keynote at both conferences, as well as a couple of other talks at sponsor events. If you came to any of them then this post contains some useful links you may want to read. It was great to meet so many engaged and knowledgeable testers in New Zealand.

The Opening

I was thrilled when I was offered the opportunity to travel over to New Zealand and talk at the WeTest 2016 conferences in Auckland and Wellington. I mentioned my conference speaking goal as part of my presentation at both events – this was that one day someone would invite me to speak in New Zealand. And Katrina Clokie, on behalf of WeTest did just that earlier in the year. It didn’t take long for me to agree to be a part of the conference and being offered the opening keynote was a real privilege.

Now there is one thing that’s clear and that is that it is a long way to New Zealand (28 hours to be precise from the UK). So I wanted to ensure that I made the most out of my short time there and to give a presentation that fitted in with the conference theme of “Influence and Inspire”. Given that I have made a move out of a pure test role over the last few years then this seemed like a logical theme for the presentation, and an opportunity for me to give my views, gained from outside of testing, on how testing is perceived. I also wanted to show the audiences that there’s important leadership roles within testing to be taken and made the most of.

Preparation and Arrival For WeTest

I can say without a doubt that WeTest was the best organised conference that I have spoken at and it’s testament to the effort put in by Katrina, Aaron, Shirley and Dan. All too often presenters at conferences aren’t treated brilliantly by organisers – either by having a lack of support leading up to the event, being expected to pay their own way or by needing to foot the bill for travel and accommodation then claim back. WeTest was different – they organised and paid for all travel up front and sent detailed itineraries for each speaker, plans on how the conference rooms were to be setup, as well as ensuring that the simple things like a taxi to pick you up off a long haul flight was pre-arranged. It made the whole experience easy and it made us speakers feel valued. Other conferences should take note.

A really appreciated gift at checkin. WeTest was a great example of how to run a conference
A really appreciated gift from the organisers, handed out at hotel check in. WeTest was a great example of how to run a conference.

Up and Away?

My presentation focused on my views of testing from outside of just testing and how I made a move into software management and why. It was part of a clearly well thought out programme and the other presentations, whether focused on more technical aspects such as mobile testing, or other leadership presentation, fitted together really well. You can see the programme here to get a feel.

Great sketch notes of my presentation from Yvonne Tse
Great sketch notes of my presentation from Yvonne Tse

Highlights

People arriving for WeTest in Auckland
People arriving for WeTest in Auckland

I thought all the presentations were good but a particular highlight for me was Adam Howard’s “Exploratory Testing Live” where Adam took the really brave step of doing live exploratory testing on the Trade Me website in front of a conference audience. Fair to say it went a bit better in Wellington than Auckland, where he found a bug early on that blocked a lot of the rest of the session but he coped really well and there was value in both sessions. We don’t see enough live testing at testing conferences, it’s common to get live coding at development ones but hasn’t seemed to catch on. Based upon Adam’s session then it should.

Also I really enjoyed Joshua Raine’s really personal story about “Conservation of Spoons” which he did as a noslides presentation. Deeply personal at times and spell binding. I won’t give you the details because I’m sure he’ll do this one again and to know the story would spoil it.

A New Approach to Q&A

As part of my presentation I thought I’d try out the new Q&A feature in Google Slides. It turned out that this was a good move because it enabled me to get questions from the audience as I talked and also to keep a record of all of them for later. If you speak at conferences I’d really recommend it.

For those of you who attended then here’s the questions asked, my responses, and a little more information.

What do you most miss about your testing focused roles?

I guess I miss being the expert with the safety of many years of experience of testing. I also make sure I keep connected to the testing community because it’s great and if I didn’t then that would be the biggest thing that I’d miss.

It’s hard to find a balance between adapting and burning out when trying keep up with new trends and technologies. Do you have suggestions on how to manage that balance?

I make sure I do one thing well; that together with Jerry Weinberg’s Lump Law – “If we want to learn anything, we mustn’t try to learn everything” help me to maintain a balance. Trying to find the one thing to focus on is sometimes hard, but by discussing with your stakeholders and your team then you can usually come to find out what is the most important.

Do you have any resources/suggestions for learning to speak ‘Dev’?

There’s not one clear answer to this – it depends on your context, languages and architecture that you are dealing with. When I started then I tended to use google a lot and base my searches on discussions I’d had with the dev’s in my team. I’d also ask them what they thought I should be learning and why. I’ve also found sites like Hacker News and Stack Overflow to be great for keeping up with what’s happening. Talking Code also comes recommended.

Was your career path in the same company or different? Would you suggest to change companies or progress in one?

It was in the same company and I think it’s much easier to make a change from one path to another when you are in the same company. You have that reputation to use and you are a known quantity. It’s also likely that you’d been working towards such a change as part of your personal development anyway so the company will be confident in your plans.

Since we are talking about change, at any given point during those career changes did you resist the change? How did you over come that? Were you specifically looking for change?

I talked about how it can be scary to make changes but trying something new for 6 months is key. You need to understand that you will go through a change curve just like anyone else and things will feel extremely uncertain as a result at the beginning. I knew what to expect since I’ve been through other changes.

In this case I wasn’t specifically looking for change, more for an opportunity.

Thank you for the nice talk If you had to recommend doing ONE PRACTICAL exercise to raise awareness with the team that WE ALL own quality – what would it be?

I like the idea of whole team testing and bug bashes are a great way of starting.

What do you think testing will be like in 10 years time?

I think we’ll see less traditional testing roles and the focus on automated checking will become more of a development activity. This may mean that there are less testing roles in total but good, exploratory, coaching testers will always have a place in teams. I think the biggest change will affect Test Managers, with far less of a need for them and a transition to coaching roles.

How do you avoid being typecast as just being a tester and overlooked for other career opportunities?

Show that you have an interest to others in your company. Work with your manager to map out your path to a new role and start to show that you are learning the skills that will be required in order to be successful at it.

In short – you own the responsibility for your own career.

A lot of people in this company are transitioning from Waterfall to Agile. Some of the people in the room might gain from you talking to how you see that transition working from the experience you bring, especially if they’re concerned about career development and management.

It does depend a lot on how the management structure adapts. In agile transitions that I have been a part of we’ve changed to autonomous, cross-functional teams with single managers, who have been supported by coaches for both agile, testing and development. This support network is key, as is the establishment of discipline based communities. A strong testing community for example, allows testers whose roles are changing to adapt.

I’ve spoken before about the effect of removing Test Managers from an organisation and the biggest takeaway for me was the need for a strong support network for testers afterwards.

Support from coaches allows not only testers to be supported but also means that someone with testing experience becomes responsible for establishing career paths, competency expectations, etc that can then be used by other managers who are not experienced in managing testers. It also helps maintain a ‘voice of testing’ towards senior management and to enable activities that help testers grow within an organisation.

And Repeat…

Parimala Hariprasad is full flow!
Parimala Hariprasad in full flow!

The first conference was in Auckland and we repeated the experience again in Wellington three days afterwards. This meant that the whole WeTest circus upped sticks and set off for Wellington for a repeat performance. I also did an “Understand Your Mobile Users” presentation at a sponsor the night before, plus the same WeTest presentation at a sponsors internal conference the day afterwards. Four presentations in one week was something new to me and actually pretty interesting to do as I got into the speed of things. It almost felt like being in a band on tour 🙂

Closing Thoughts

WeTest was great. I met some great people and learnt some new things. It was extremely well run by a passionate bunch of volunteers who knew how to treat their speakers well and how to organise a great programme for the conferences. The testing community in New Zealand is really engaged and it’s clear that there’s some really forward looking testers pushing the boundaries here. If you get yourself over to New Zealand then I’d certainly recommend it. It’s not that far. Really 🙂

Agile In The City 2016

I’ve just got back from Agile In The City, which is a relatively new agile conference held in London. It’s in its second year and this was the first time it had been extended to two days. I had a great time; there was a good mix of talks, tutorials and workshops, a decent venue and even some good food as well.

IMG_20160616_095642140

As usual I did some mind maps of the sessions I attended. My favourite session was Managing For Happiness from Jurgen Appelo, a really inspiring keynote about how to manage better, with some great tips.

My mind maps from all the sessions I attended are below.

Keynotes

Managing For Happiness by Jurgen Appelo
Managing For Happiness by Jurgen Appelo
How To Derail Agile Rollouts - Katherine Kirk
How To Derail Agile Rollouts – Katherine Kirk

Track Sessions

IMG_20160618_140329446
Scaling agile development at the Government Digital Service by Adam Maddison

 

IMG_20160618_140338606
Punishment driven development by Louise Elliott

 

Develop The Product Not The Software - David Leach

Develop The Product Not The Software – David Leach (with free water pistol 🙂

 

Value by Andrea Provaglio
Value by Andrea Provaglio

 

From Oil Tankers To Speedboats - Jonathan Smart
From Oil Tankers To Speedboats – Jonathan Smart

 

#NoProjects - beyond projects - why projects are wrong and what to do instead - Allan Kelly
#NoProjects – beyond projects – why projects are wrong and what to do instead – Allan Kelly

The End Of The Road For Test Managers?

I’ve been reading a lot about test management recently. There’s some excellent posts out there, in particular I’d recommend you look at this one from Katrina Clokie, explaining the changes that are required for test management to remain relevant in the world of Agile software development and continuous delivery.

She also links some other articles which I would definitely recommend you read, if you are interested in the subject.

My Interest

So why am I interested? Well for starter I’m a Test Manager. Over the last couple of years I have seen my role change, from one of leading a separate, large test department, to one of managing testers across a number of project teams. It’s about to change again.

I’ve seen the challenges being a Test Manager in an Agile environment brings, in particular the difficulty in remaining relevant in the eyes of product and development managers, and the challenges of understanding enough about multiple areas in order to be able to support your team members. Being a Test Manager in a Agile environment can be isolating at times, particularly when the department is big, and the number of agile teams is large. It requires an ability to balance a lot of information, priorities, and tasks, across a number of areas. Stakeholder management and influence become key. Context switching comes as standard. Often it’s not much fun.

Through discussions with others, and looking at my own situation, I’m increasingly coming to the conclusion that the new ‘Agile Test Manager’ positions that Test Managers are moving/ falling into just don’t fit with the ways that teams want to work anymore. The team is more important than the manager, and, for example, choosing to keep discipline based management because it means testers are managed by testing ‘experts’ isn’t enough to justify it. Managers are not able to effectively support their people if they do not have the time and energy to keep fully in the loop with the team. As Test Managers get split across multiple teams, (primarily because having one Test Manager per Agile team is massive waste),  then it becomes nearly impossible.

Continuous Delivery

Moving to Continuous Delivery complicates matters further. Giving a team complete autonomy to design, build and release it’s own code is an extremely motivating way of working. Do Test Managers fit in with this ? I’m not sure they do. Where independence and autonomy are key, management from someone from outside of the team just doesn’t fit, particularly when that management is only part-time.

Change Is Coming

So how do we change? Do Test Managers merely become people managers, desperately trying to understand what their people, spread across multiple teams, are up to? Are they there to help manage testing but not people?? What about the coaching and mentoring, the sharing of knowledge and expertise, and the personal development of testers?

As I see it I think we’re going to see a lot more of this sort of setup:

  • Engineering Managers, who line manage an entire team. They understand the people best because they work with them day-to-day. No need for handovers, no need for performance feedback requests to other managers at review time, and no need to waste time and effort with coordination. Engineering Managers manage the whole delivery process and people involved. They may have come from a background of expertise is a particular discipline, but now they need to be able to represent all. But crucially they are focused on the management of a team who own a particular product or component and so share a single focus with their team.
  • Test Project Managers, who manage larger testing projects/ programme’s and dedicated testing phases such as UAT and customer acceptance. No people to manage, just deliverables. This role is very dependant on the nature of the software/ hardware solution being delivered. It’s most likely not needed in a lot of companies.
  • Test Coaches, who help organisations deliver the optimum testing possible. This means through coaching, mentoring, advising and working with engineering managers and whole teams in order to help them optimise their testing effort. Similar to James Bach’s idea of Test Jumpers, but with more focus on providing advice, guidance and strategy. In smaller companies they are much more likely to be exactly like the idea of Test Jumpers. Call them Test Jumpers, Test Managers, Heads of Testing or whatever, but the key point is that they are test experts who have the mandate to support testers in multiple teams but do not manage them. They can assist with recruitment and personal development if required, but are not a particular person’s official manager, and may get involved more with recruitment and personal development process, rather than people.

What Next?

The dedicated Test Manager, who manages testers and testing is not a role I can see continuing for too much longer. It is a hangover from the past, when large, dedicated test teams needed management, and it simply does not fit with how a lot of teams work anymore.

But, and this is a big but, I work in web, web services and mobile. I’ve seen the push for Agile and the push for Continuous Delivery because it fits the nature of the projects and technology used in these areas. Team’s are lean and projects are short. Almost certainly this makes me biased.

I would be interested to know what you think. Do you think the traditional Test Management role is reaching the end of the road?  Or is it alive and well, and relevant in the area that you work? Why not leave a comment below and get the conversation started.

Incentivising Community Engagement?

I firmly believe that in order to be as effective as possible, testers need to engage with the software testing community. Learning from others, particularly outside of the companies where we work, makes us more rounded and better informed individuals. It enables us to inspire ourselves and our colleagues in ways that we could not otherwise.

Recently I’ve been wondering why more people do not engage with the community. What is stopping them, and how can we all help change this? We can explain how brilliant the wider community is, and we can give examples from our experience. We can send people to conferences and email round blog posts. What is that does not work?

What do we do about those within a team who do not want to interact? Those who do not see it as a good use of their time, and are not willing to spend time on community matters, even if that time is given to them by the company. Should we incentivise people to do so? At least in order to push them in the direction of the wider testing community, where hopefully they will get hooked? Or should we do the opposite? Is it a valid idea to make community engagement a part of people’s role description, and therefore penalise those who hold such positions and do not exhibit such engagement?

Or is there another way of persuading everyone that the software testing community is key to their personal development? I’d be interested to know what you think.

Less Than Three Weeks Until TestBash 2.0

TestBash-Speaker-300x125

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.

It would be great to see you there.

Persona Based Interviewing

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

Interview

 

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.

Image courtesy of Ambro / FreeDigitalPhotos.net

 

Starting a New Job in Testing

Image

Thing have been a bit quiet around here. Maybe you’ve noticed it. Maybe you’ve only came to this blog for the first time, from a link from Google or Bing, in which case welcome, and do note the gap in posts. I’ve been busy.

Primarily this has been because I’ve been searching for, and then settling into, a new job in a new company. Starting a new job isn’t easy, be it in testing or any other field, and it’s what you do in the first few months in a new company that can really affect how the rest of your time there goes. Those relationships you make early on, and how you are seen by others matter. It matters a lot.

So, while things are fresh in my mind, here’s some handy hints on what you should consider when starting somewhere new. I’ll be sharing further articles about recruitment, job searching and C.V.’s over the forthcoming months.

All presented with a software testing view.

Talk to people

Probably the most important thing you can do when you start, especially in a testing role. Being a good communicator, with the ability to get on with as many people as possible is very important as a tester. Spend your time searching out the important people, introduce yourself, and find out more about them. Ask them about the company, ask them about how you can work together, and find out what they think about how the company does testing. Those relationships you make early on affect how people see you for a long time. Sure, you won’t be able to remember all their names, but make sure they remember yours. And yes, this does mean talking to more than just testers 🙂

 

Ask Questions. A lot of questions

Testing is all about questioning a product in order to evaluate it, right? Take the same approach when you start a new job. Ask everything you can think of, no question is too stupid to ask if you don’t know the answer. Often, so much information in a company, is un-documented, and you want to make sure that you can understand the bigger picture, as well as just knowing enough to do your role. As testers we need as broad a view as possible in order to work effectively so make sure that you learn by questioning, and continue to do so. It takes time to settle into a new job but the more questions you ask then the quicker you should be able to feel like you understand company and your role within it. Don’t sit there, feeling blocked because you don’t feel like you can ask something.

 

Be nice

First impressions count. When you first start you meet a lot of people. Every time you meet someone new then that’s a new first impression. Always remember to be nice. Even if you are really an evil tester 🙂

 

Consider what you are bring to the company

They decided to employ you, there must be a reason, right? 🙂 Remember that you have good, and relevant, experience that you can bring. It’s easy when you first start, to just spend your time learning the company and your new role. But do not forget that your experience from outside the company could be really useful. Maybe your old company did it’s test automation a particular way or maybe you can see the new company works in a way you helped improve in an old role. It’s often new starters who are in the best position to see improvement areas. Don’t just accept that ‘this is the way its done round here’, and don’t feel afraid to speak up.

 

Ask for feedback

It can be really easy when you start somewhere new to just go into things head down and try and pick everything up at once. Remember that you need to pause and ask for feedback. Make sure that you question your own understanding of things, as you learn them, and regularly ask for feedback from those you work with.

 

Don’t forget to continue focusing outwards as well

When you start at a new company it can be really easy to spend all your time learning your new role. After all, there is a lot to pick up and a lot to learn. It is tiring, but don’t forget what you did before. Since you are reading this then I assume you read software testing blogs at least. Keep active in the testing community and keep learning. That way you can bring not only new ideas from your previous job, but also new ideas from the whole testing community.

 

Enjoy it

It takes a lot of effort when you start a new job. There is a lot to learn and a lot of people to meet. Focus on what attracted you to the new job and don’t forget to enjoy it 🙂

 

I’ll Be a Panelist at the Next Generation Testing Conference on 6th December

I’m excited to be able to announce that I’ll be a panelist at the Next Generation Testing Conference which is on Thursday 6th December in London.

The conference is in its seventh year and is continuing with the  format that was trialed at the last conference in May, with more emphasis on panels and discussions, together with case studies. This should hopefully mean that there’s some great audience participation and discussion on software testing.

I’ll be on two different panels during the day – “Retrospective on 2012” and “Looking Forward to 2013” We’ll be debating various topics including:

  • What have we learned in 2012?
  • TestDevOps – what does it mean to you?
  • Continuous Integration and Continuous Delivery – lessons learned
  • Mind Map techniques that work with Agile
  • Advances in risk-based testing
  • Changes in approach for testing cloud based solutions and mobile applications
  • The rise of TestOps
  • Innovation/renovation
  • What is the next big thing?
  • “Prespective” of 2013

Others presenting or as panelists at the event include Paul Gerrard, Julian Harty, Steve Tulk and Niels Malotaux.

It’s sure to be a great event, as the last one was. Hope to see you there. You can find out more about the event at http://next-generation-testing.com/

A Testers Hierarchy of Needs

As part of my role I manage testers and also those involved in delivery operations. This means thinking not only about testing and test techniques, but also about person management, and the tools and techniques that a good manager uses in order to have a happy and productive team. These two areas should not, of course, be treated in isolation since, in order to have a successful test team, it’s the managers job to ensure that the two areas fit well together. If this can be done in as seamless as possible a way, maybe even without the team members even being aware of it, then my experience tells me that you can hit that sweet spot where the team is technically excellent as well as being the sort of team that testers want to work in, and are proud to work in.

I’ve studied a lot of theories of management in the past but the one that I keep coming back to again and again is Maslow’s Hierarchy of Needs. At it’s simplest it seeks to explain the needs of human’s in their most basic form, expressed hierarchically in order of those needs.

So, for example, the theory puts forward the hypothesis that it is most important (and therefore at the bottom of the pyramid) that human’s experience a need for food, water, etc. Safety needs come next, followed by a need for belonging, and so on.

As a manager, keeping this simple theory in mind can really help. I’ve found numerous occasions in the past where it has helped me understand team members actions, and to help ensure the team is working effectively together.

But it has also got my thinking about how one might go about applying Maslow’s Theory of Needs to Testing. More specifically, how a tester in a team or project might experience and visualise those needs, as reflected by their status within the team. This lead me to produce this:

Testers Hierarchy of Needs

Test Mastery is a place I see the respected, happy tester sitting. Probably people like you, who interact and are involved with the software testing community, who self-learn and who are able to articulate the need for testing effectively.

This is just the start of the theory. I’m sure, as a community we can add more to this. What would you add to the different levels and why? Leave a comment below.

 

 

More Experiences of Rapid Test Management

If you remember from the last post, I recently attended Rapid Test Management, taught by Michael Bolton in London. For a general overview and what happened in the first day then take a look at the previous post. As before, the following caveat applies:

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.

We started day two talking about test strategy and how one might incorporate Rapid Software Testing into a test strategy. The Heuristic Test Strategy model was introduced and we studied this in some detail, and followed it up with an exercise to define a strategy for a smartphone. I was happy with the choice of product under test, given my background then it made it easier to take into account my domain knowledge, and so our group could come up with a large number of options to consider. Equally interesting was what other groups had come up with and it was very interesting to see how each group had approached the problem differently and come up with different solutions. This goes to show that diversity in teams and experience is very important in testing.

Back on day 1 we had produced a list of areas that we, as a group, wanted the class to be focused upon and the major areas that so far had not been covered were risk and test coverage. As usual, Michael had some great experiences to share and course material to cover the risk areas and the details of risk based testing. In fact, the amount of class material was another one of the great things about this class – you get a lot, far more than you can look at or can be taught in the class itself. Together with some useful testing tools and also some more exercises and demo’s, this gives a great set of material to use afterwards. Continual learning is important and so to gain access to all the notes, examples and slides is just the start.

Day 2 was concluded with a look at test coverage and ways to visualise test coverage. Rapid Software Testing provides you with some great ways to do this, from the simple to the more complex. It got me thinking about how I might incorporate this into the Kanban project management processes that my own team use to manage our work.

So, should you sign-up for the class? You bet’cha. Rapid Test Management is a class that you should attend. If you want it to, and you take the time to study all the information and material that you receive, then it will make you a better tester and it will make you a better test manager. I’m on the way; I’m just beginning to take on-board all I’ve learnt and to read through the material we didn’t cover in class, but with everything I read I’m confident that it’s improving my skills.