Category Archives: management

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.

I’m Speaking At the Next Generation Testing Conference on 23rd May

I’m excited to be able to announce that I’ll be speaking, and sitting on a panel, at the Next Generation Testing Conference which is on Wednesday 23rd May in London.

The conference is in its seventh year and is trying out a new format this year, 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 Panel 1: Testing Today – What are the main challenges? It’ll be moderated by Dr Richard Sykes and they’ll be a group of us representing various areas of software testing, including Tony Bruce of London Tester Gathering fame. We’ll be debating various topics including:

  • Testing in the cloud
  • Testing mobile applications
  • Testing Big Data migrations
  • Games Testing
  • Non-software systems testing

I’m then be presenting a case study: Mobile Testing – That’s Just a Smaller Screen, Right? This will go into the background behind mobile device testing, how it differs from the desktop world, and giving some pointers towards areas to consider when formulating a mobile device strategy.

Hope to see you there. You can find out more about the event at http://next-generation-testing.com/

 

Test Leadership vs. Test Management – Is the Balance Right?

As I’ve blogged about recently, I’ve been recently studying for the Level 5 Certificate in Management and Leadership from the Chartered Management Institute. I’m now three sessions into the four session course, and it’s getting really interesting to see and think about how one might apply general management principles more specifically to the software testing area.

The most recent session was all about Management and Leadership. As part of this we did an exercise where we had to sort out a number of different phrases into groups that either apply to ‘Management’ or ‘Leadership’. No sitting on the fence, no spending hours deciding which to put where, but a quick exercise to make you think. There  were right and wrong answers (although primarily to seed further discussion).

The list, as I saw it, is below. What do you think? Do you agree?

Leadership Management
Enables others Implements and maintains
Inspires vision Focus on systems and structures
Encourages head and heart Adopt short term view
Acts authentically Completes transactions
Asks what and why Asks how and when
Has long range perspective Brings order and coordination
Focuses on doing the right thing Focuses on doing things right
Inspires trust Accomplishes tasks through others
Acts as an innovator Focuses on performance
Challenges Provides stability
Transforms Controls
Committed to the cause Imitates
Gives purpose and meaning Complies
Focus on people

After the exercise I got thinking about how I might apply this more generally to software testing. Specifically to Test Managements vs. Test Leadership, i.e. what separates those who run testing projects, probably as part of the design and delivery of a specific product, vs. those who lead groups and provide inspiration both inside those groups, and to the wider testing community. Are the skills needed in those situations different?

We clearly need within our community those who can challenge and innovate. Right now this is coming mostly from the context-driven community as I see it, where also the vision and long range perspective is clearly evident. These people are driving things along nicely in my opinion. As someone who has recently attending Rapid Software Testing with James Bach then I can say first hand that he’s certainly encouraging head and heart. I don’t need to mention challenging, right?

The question then comes, who is taking things further? Leaders need managers to take their vision and turn it into practice. They need someone who can focus on the short term view, give the control and ensure completion. They need people who implement. As a community do we currently have enough of the managers listening and implementing the vision that our leaders are sharing?