Tag Archives: leadership

Presenting at TestBash – A Testers Hierarchy of Needs

TestBash

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

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

My Presentation

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

I’ve published the slides on this site so do take a look  – A Testers Hierarchy of Needs.

I’m also writing a further post, which will go into a bit more detail about my presentation, and the links between humanistic psychology, Maslow, and software testing so do look out for that.

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.

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.

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?