What if you don’t have the skills a manager is looking for?

What do you do when hiring managers are looking for a set of skills you don’t have but you sorely want? You learn.

I see this situation played over and over again. The market is shifting and a new tool or technique is the next biggest standout skill or experience hiring managers are looking for, yet you don’t have that skill. What’s worse is that you can’t get an opportunity to learn that skill in a workplace because you don’t already have it…..a Catch 22 situation.

Read More

You’re brand new

“I’m new to testing – where do I start?”

I get asked the above questions A LOT. It’s a very common question for those who are brand new to testing, those who are shifting from another business function and those who are returning to testing after many years away.

I repeat roughly the same answers quite often so I’m writing a blog post to point people at.

Of course, a little self promotion – if you do nothing else then buy my own remaining relevant book – it is packed with ideas on how to learn, how to network and hints and tips on how to rock an interview 🙂 You could consider it a much longer form version of this blog post.

Join the Software Testing Club. Period.

Check out the AST training courses and learn as much as possible.

Follow the big bad list of test bloggers being curated by the Software Testing Club – there are a lot of them – mostly good – pick and choose carefully though.

Download and read my Blazingly Simple Guide To Web Testing – all of the hints and tips were created from bugs I’ve found in the past.

Join twitter and follow the #softwaretesting #testing hashtags – find interesting people and follow them.

As part of the above question I also often get asked what the day to day activities of a tester are.

It’s tricky to say what the day to day activities of a tester commonly are as the role is so incredibly varied. You might be following pre-defined scripts and checking that the software matches the test case.

You might be exploring the product to discover what it does. You might be analyzing specs, writing user stories, writing automated tests, performance testing, security testing, doing customer visits, studying usability and a whole host of other stuff. You might do some of these things during one working week at some companies, you might do nothing but following scripts at others.

The industry is so varied that I would suggest, if you can, that you take the time to carefully chose the testing role you want. I would always suggest seeking out companies that put exploration and learning above scripted testing, but not everyone has the luxury of holding out for such companies.

Some companies will insist on a certification. It’s your choice as to whether you want to get one. I’m not a fan – but I’m a realist – some companies require them – and if you need a job then go for it. But take the certification for what it is – a certification that you sat the course and got a favorable result. It is NOT a marker of excellence and shouldn’t be your single point of learning.

If you follow some of the above you’ll encounter people and communities that will help you find the resources you need, the people you need to know and hopefully the sources that can help you skill up in the right way. You might even land a job through your networks and community.

Getting Hired – At Conferences

One of the things that I have observed from a number of testing conferences is that none of them have any sustained focus on hiring or getting hired *.

There have been one or two sessions about the topic of hiring but nothing sustained.

The occasional tracks that I have seen have been mostly focused around the hiring strategies of big corporates where bums on seats is sometimes more important than cultural team fit.

Most testers don’t know how to get hired – I wrote a book to help bridge that gap. Those that do know how to get hired are truly in the minority and appear, at least on the surface, to be overall better testers. Mostly this is not true – they are good, but they are often no better at testing than others, it’s just they are much better at getting hired. Getting hired is a skill.

Hiring and getting hired is a vast topic and one which is fraught with contextual challenges, but I believe that a dedicated set of talks from hiring managers from a wide variety of contexts, and maybe some sessions and tutorials on writing CVs, interviewing etc would go down well at most testing conferences. It’s great being good at testing but how do you then go on and get hired…

There are supporting topics such as social profiles, writing clear CVs, networking, self education and interpersonal communication that might also make interesting tracks. Or maybe they wouldn’t. Maybe people go to testing conferences to learn about testing and not the other stuff that comes with our working world…

What are your thoughts?

* The conferences that I have been to

Career Paths And Testing

When you’re advancing your career in testing it’s easy to get sucked in to the lure of big titles like Test Manager, Programmer Manager etc, especially if your using some of the mainstream “career path” guidance tools. The offer of a test manager role might seem like an attractive offer compared to a “test engineer” or something like that. However, apply caution, in my experience most test managers I’ve known have done little other than manage artifacts (test cases). A role title does not accurately reflect the role.

Use your own judgment when you’re applying for roles with big titles. Someone I know is a Test Manager….of himself (and some test cases).

I know a Director of Test who manages a team of 2 testers (and lots of regression test cases).

I know someone who works for a test manager. This test manager manages a team of 45 testers doing nothing but regression testing. The team keeps growing but the testing is not changing. By all accounts he’s hiring people and getting them to manage a load of test cases. Is this test management – I guess so.

After fulfilling your basic needs like salary, location and any other contextual needs I’d suggest to try to find a job that challenges you, not a job that gives you a so called “career path” title.

Find a job that challenges everything you thought you knew about testing. Find a job that provides you with an environment you’ll thrive in. Try to find a job that is modern and relevant. Try to find a job that let’s you think…and gives you room to breathe.

Try to find a job that blows your socks off. And don’t worry too much about what you’ll be called.

Oh yeah – Did I mention I was hiring for a solid tester who likes a monumental challenge?

Oh yeah – I also write a book called Remaining Relevant about how to find those great jobs, get the skills you need and then rock an interview. You can buy it here on LeanPub

Communication and Testing

In yesterday’s test team meeting we did an interactive sessions around communication. Stickies, pens and a whiteboard were all we needed to have a fun session talking around communication.

We started by brainstorming what communication is. Then what factors affect communication. We talked about feedback.

And of course we talked about PAC – Purpose, Audience and Context.

(Those who’ve known me for many years might remember that PAC Testing was my very first testing blog all those years ago in 2009. It’s still running and getting traffic! The links are all wrong on it and the images are no longer there but the site is still up! http://pac-testing.blogspot.co.uk/)

We also talked around some specific examples of communication failure. It was a fun session thrown in at the last minute. It’s always good to throw in some soft skills sessions.

By the way – I’m recruiting for testers!

http://www.newvoicemedia.com/about-newvoicemedia/careers/

If you’re interested in coming to work at NewVoiceMedia then drop me an email, or even better – connect with me on Twitter (@rob_lambert) and DM me.

certification of awesomeness

Could not having a certificate make you stand out?

Many years ago when I sat the foundation certificate it made very little difference (if anything at all) to my day to day work. I remarked to a colleague though that the certification would make us all “more employable”. I was right.

certification of awesomeness
Certification of Awesomeness

Back then not many people had the certification so when you saw it listed on a CV (complete with required logo) it made that CV and candidate stand out. Had they taken their learning more seriously? Were they prepared to see what this certification lark was all about? What was this certification thing?

Soon though, everyone had a certification and you no longer stood out from the crowd.

Thankfully though – along came more higher rated (and presumably higher valued) certifications. Great. You could stand out again. Until of course – most people started to get these too.

Now you need something more to stand out. I wrote a whole book to help you work out what I think you need to do. But one thing came to mind* the other day that I realised I missed from the book.

What if your CV was the only one that DIDN’T have a certification?

That would make you stand out.

And any good hiring manager might start to ask “I wonder why they felt the need not to get certified, or list it on their CV?”. And that is an excellent starting point for a good conversation about you, software testing, certifications and your learning.

Note: Although this blog post is a flippant approach to the challenges hiring managers have of finding good candidates – it could actually be a useful approach to standing out.

* I recall some Twitter banter around certifications and why you don’t need them but can’t recall (or find) who actually made a statement along the same lines as I have. If you know who it was please let me know.

– I’ve since been informed that it was Michael Bolton via Twitter who said to leave the cert off the CV – sage advice indeed.

Ha ha – told you so

Quite often I hear presentations and discussions from testers who talk about those moments when they feel it appropriate to say “Ha Ha, Told You So”.

You know? Those moments when the testers advice was ignored and it all went pear shaped. Or the time a tester said the company should be testing earlier, only to find a boat load of bugs too late in the day.

Over the years I’ve heard loads of people saying “ha ha – told you so”.

Sure it’s gone pear shaped, but it’s often at these times that you are needed the most; when your skills and ability are required by the business to get software out of the door.

If all you have to say at times like this is “ha ha, told you so” then you will appear petty, annoying and arrogant.

We shouldn’t be offending people and making them resentful because a decision was made that frustrated us. We need to step up and take ownership. Step up and contribute. Step up and make a difference.

At a conference a few years back a tester was presenting on how happy she felt when the project crashed and burned because they had ignored her advice. The crowd were joining in talking about “wiping the smug look off the developer’s face” and saying things like “at their peril will they ignore the tester”. It’s poisonous, unhelpful and downright ridiculous to think like that. (I was in the minority in the room btw – I walked out with a few others who found that session just too much).

So when you hear a tester shout “ha ha told you so” as a project takes a downward spiral, offer them some constructive feedback and ask for their support. Motivate them to act, not gloat in the destruction. How is that negativity going to help the business release good software.

Releasing software is a team effort. And tester’s are a part of that team.

Let’s say I gave you a giant box to explore

Let’s say I gave you a giant box to explore.

In the box was a machine that did a number of different functions along with an instruction manual. The functions that the machine can perform are complicated but ultimately observable and open to identifying more thoroughly than we currently have done in our user guide.

The machine however has lots of unknowns when it comes to putting spurious data in and connecting with a wide array of third party apps. The results of your actions are outputted to a simple user interface. It’s not pretty but it does the job. The above was a test that a company I worked for would give during a job interview.

box Image from subsetsum on Flickr.

They provided a laptop with this “test machine” running on it (a Java application) and they provided the instructions (a simple two page html document).

When I sat the test I hated it.

I didn’t feel it dug deep enough around some of the diverse skills I, and others, could offer.

In hindsight though I think this type of test was actually very insightful – although maybe the insights weren’t always used appropriately.

I got the job and soon found myself on the other side of the process giving this test to other testers hoping to come and work with us.

When I was interviewing I was handed a checklist to accompany the test. This checklist was used to measure the candidate and their success at meeting a pre-defined expected set of measures.

It was a “checklist” that told the hiring manager whether or not to hire someone.

The checklist contained a list of known bugs in the “test machine”. There were about 25 “expected” bugs followed by a list of about 15 “bonus” bugs. There were two columns next to these bug lists, one headed junior and one headed senior.

If we were interviewing a ‘junior’ (i.e. less than 3 years experience) then the company expected this person to find all of “expected” bugs.

If we were interviewing a ‘senior’ (i.e. more than 3 years experience) then the company expected this person to find all of “expected” bugs AND all/some of the “bonus” bugs.

There was also space to record other “observations” like comments about usability, fit for purpose etc

This interview test was aimed at flushing out those who were not very good in both junior and senior categories.

I’m assuming many of my readers are jumping up and down in fits of rage about how fundamentally flawed this process is…right?

I immediately spotted the fundamental flaws with interviewing like this, so I questioned the use of the checklists (not necessarily the test itself) and I stumbled across two interesting points.

Firstly, there were some hiring managers that stuck to this list religiously (like a tester might to a test case). If someone didn’t find the bugs they were expected to then they didn’t get the job. Simple as that.

Other hiring managers were more pragmatic and instead balanced the performance across the whole exercise. For example – I didn’t find some of the things I was expected to find, but I still got the job. (It turns out a few managers were ticking the boxes next to the bugs people didn’t find to “prove” to senior management (auditors) that candidates were finding the bugs they should have).

Secondly, this test was remarkably good at exploring the activities, approach and thinking that most testers go through when they test.

Whether someone got any or all of the bugs they were expected to was beside the point for me. I was more interested by the thinking and process the tester went through to find those bugs and assess the “test machine”.

It just so happened that most hiring managers were not measuring/observing/using this rich data (i.e. the testers approach, thoughts, ideas, paths, etc) to form their opinion.

Junior or Senior – it made little difference

It was clear from doing these interviews that it made little difference how many years of experience a candidate had and their ability to find the bugs they were expected to.

I actually spotted a very prevalent trend when doing these interviews.

Those that followed the user manual found most of the “expected” bugs no matter what their perceived experience level; juniors, seniors, guru grade – it made no difference.

If they followed the user guide (and often wrote test cases based on the guide) then they found these “expected” bugs.

Those that skimmed the user guide but went off exploring the system typically (although not always) found most of the expected bugs AND some/all of the “bonus” bugs – again, irrelevant of their experience (or perceived experience).

This second point highlighted to me that the approach a tester took to testing influenced the types of bugs they found, but also, in this interview case, it challenged our assumptions about experience and bug count. It also made a few people think whether they had categorised the known bugs correctly – were the bonus bugs too easy to find?

I observed very junior testers finding the “bonus” bugs and senior testers missing them purely because of their approach and mindset. (although not a scientific finding it did give me enough insights to set me on my journey towards exploration and discovery).

It wasn’t even as simple that all seniors did a more exploratory approach and that juniors did a more scripted approach. That simply didn’t happen.

It seemed to run deeper than that. It seemed to focus more around a curious mindset than years of experience.

Obsessed with finding out more

Those that took an exploration and discovery approach appeared to develop an obsession with exploring the “machine”.

They seemed more compelled to discover interesting information about the “test machine” than those who followed a script based on a partial user guide.

Following the guide simply wasn’t enough. They needed to find out the information for themselves. In a sense, they needed “primary” information. Information they had obtained themselves straight from the source (the product). Other testers were happy with using a “secondary” source of information (the user guide) to formulate conclusions. It obviously wasn’t as clear cut as that, as many straddled the middle ground, but the trends did show an interesting difference in approach.

Note Taking & Story Telling

Another dimension to this process, which was what kick started my obsession with note taking, was that those who went off exploring appeared to tell more compelling stories about their testing, often through detailed and interesting notes.

The notes they took enabled them to recite their exploration and discovery story back to others with an astounding level of detail – something most people who followed a script didn’t do ( I can’t say whether they “could” do it though).

As these people got stuck in and delved around in the product they started to tell a really interesting story of their progress. Through narration of their approach and interesting notes they got me and the other hiring managers interested, even though we’d seen dozens of people perform this very same test.

They started to pull us along with them as they explored and journeyed through the product. They wrote notes, they drew pictures, they made doodles and wrote keywords (to trigger memory) as they went.

They built up a story. They built up a story of the product using the user guide as a basis, but using their own discoveries to fill in the gaps, or to even challenge the statements made in the user guide (of course…the user guide had bugs in it too).

They wrote the story of their exploration as it developed and they embraced the discovery of new information. They kept notes of other interesting areas to explore if they were given more time.

They told stories (and asked lots of questions) about how users might use the product, or some of the issues users may encounter that warranted further investigation.

They involved others in this testing process also; they described their approach and they made sure they could report back on this compelling story once they’d finished the task.

What intrigued me the most though was that each tester would tell a different story. They would see many of the same things, but also very different things within the product and the user guide.

They built up different stories and different insights.

They built their testing stories in different orders and through different paths but actually they all fundamentally concluded very similar things. The endings of the stories were similar but the plot was different so to speak.

What they explored and what they found also said a lot about themselves and their outlook on testing.

Their actions and outputs told stories of who they were and what their contribution to our company/team would be. They let their interview guard/nerves down and they showed the real them.

Everyone who sat that test told us something about themselves and their testing, however, we (the hiring managers) were pulled along more with those who built their testing stories as they went rather than those who had pre-defined the story and stuck to it.

The explorers appeared to tell more insightful and compelling stories and they also revealed deeper insights about themselves and the product.

As our hiring improved (better job adverts, better phone screens, better recruitment consultants) we started to interview more people who would explore the product and tell us these compelling stories; these were the people we wanted to seek out.

As a result even those hiring managers who were obsessed with their checklist would find themselves being pulled along with the exploration. They found themselves ignoring their precious checklists and focusing on the wider picture.

It didn’t take long for senior management to see the problems with measuring people against lists too.

Did I learn anything?

Oh yes indeed.

We should never hire purely on binary results (i.e. found this, didn’t find this, is this type of person, is that type of person, isn’t this).

Only by testing the system do we find out the real truth about the product (specs are useful, but they are not the system). In a choice between primary information or secondary information I will gravitate to primary.

When we explore we have the opportunity to tell compelling stories about our exploration, the product, the testing and more importantly, ourselves <– not everyone has these skills though.

All testers will conclude different insights, sometimes they may find the same bugs as others, sometimes very different ones. Therefore it’s good to pair testers and to share learnings often.

The hiring approach should be consistent across all those with the power to hire and should focus on the person, not the checklist.

Good exploratory testing relies on the ability to explain the testing, insights and findings both during the testing session and after (and often relies on exceptional note taking and other memory aids).

If you’re hiring a tester, observe them doing some testing before making an offer.

I believe an obsession to learn more (and be curious) is one of the most observable traits I can see. Exploration and curiosity does not always come naturally to people. Not everyone is curious about the world around them or the products they test, but for testers I believe this trait alone will send them down the many paths of learning. (and this is a good thing)

Someone with 10 years of experience is not always better than someone with 2 years – especially so if they have had 10 of the same year.

Dividing people in to junior and senior camps is not helpful. Where is the cut-off mark (years of experience? – see point above)? We are all on a journey and our skills will change and develop over time – the person is what you are hiring, not the years that they have worked.

The big question I now ask is “Does this person want to be on a journey to mastery? If they don’t, it’s very hard to encourage them to improve.

 

Note: This post may come across as me suggesting exploratory testing approaches (and therefore exploratory testers) are better than scripted testing approaches (and hence testers who follow scripts). That’s not my intention. How you perceive this post will depend very heavily on how you perceive the role of testing and the role of the tester to be in your organisation. You know your organisation and the needs that you and your team have. Some organisations desire people to follow scripts, some organisations desire people to explore the product, some desire something in between and some desire other things all together.

 

What can you do with a brick?

Last week one of our team, Simon, ran a really fun session with the whole test team on our Exploratory Testing process.

We started by discussing some of the thinking that we’ve identified happens when we plan exploratory testing sessions. We talked through a diagram we created a few years back, and although it’s pretty accurate in identifying some high level ideas of our Exploratory Testing process, it’s by no means complete, but it served it’s purpose as an aid to explaining.

Once we’d been through the diagram Simon introduced the team to one of my favourite games that explores creative thinking.

It’s a common game where people are asked to come up with as many uses they can find for an item.

It’s a really good way of understanding how people think up ideas, how diverse the thinking is within our group and it’s also a good way of injecting some discussions and banter in to our session.

Simon gave the group 5 minutes to write their ideas on post-it notes. The item of choice today was a “brick”.

We then affinity mapped them in to rough categories on the white board and discussed a little around each category as a group.

3

 

We then discussed the process of how people came up with their ideas.

It’s always tricky analyzing your own thinking, especially so in retrospect, but we did spot a couple of patterns emerging.

Firstly, whether consciously or not, we all envisioned a brick and started from this image we’d constructed. As it turned out we’d all thought of a standard house brick; some people saw in their minds the one with holes in it, others the bricks with a recess. Either way we started with the standard form of a typical house brick (here in England).

1

 

Here’s where we appeared to head off in slightly different thinking ways. After writing down all of the basic ideas that a brick is used for (building stuff, throwing at things, weighing things down) we started to head off in the following three directions:

  1. Thinking of other sizes, shapes and forms that a brick could take
  2. Thinking of different contexts and locations that a brick could be used in it’s original form (outside of those we naturally thought of straight away)
  3. Thinking of everyday objects that we could replace with a brick.

For example:

  • We could grinding the brick down to create sand
  • Use the brick as book ends
  • Take the brick to a philosopher (and/or someone who had never seen a brick before) and try to explain what it was used for
  • Use the brick as a house for small animals, insects and little people
  • Use the holes in the brick as a spaghetti measurer
  • Putting the brick in a toilet cistern to save water
  • Projectile missile and other weapons
  • Use it to draw right angles
  • Use it as a paperweight
  • Use it as a booster seat in a car
  • Use it as a holder for fireworks
  • Use it as a bird bath.

And many, many more.

2

As you can see we explored a number of uses and we created a decent amount of categories in which a brick would fit.

What was most important though was that we all took time to reflect on where our ideas were coming from.

We also noted that not all of clearly think in the same fashion. Some people remained true to the form and shape of a brick but explored different contexts.

Others ignored the standard shape of a brick and explored different elements and uses of the materials within a brick.

This realisation that we all think differently about something as simple as a brick triggered some further discussions about how we come up with ideas for testing our new features.

It ultimately lead to us to concluding that it would make sense to pair with others during and after our story kick off meeting. It might generate a broader and deeper set of test ideas. It might not. We’ll have to experiment.

For now though we’re running with two testers attending story chats followed by a brainstorming and ideas exchange meeting. We decided it would make sense to not do the brainstorming in the story chat as that will sidetrack the purpose of that meeting, but we will be sharing our wider test ideas with the team as well as writing acceptance tests in SpecFlow for static checks.

Let’s see how it goes.

It was a really good session and we took away a direct change we could try. It’s good to get the team together every week to chat through the ways we are working, thinking and solving tricky testing problems.

Opposite Views

At EuroSTAR 2012 I got talking to someone who had polar opposite views to mine on Testing and Agile implementation.

Despite his opposite views and the fact I could counter almost anything he said from my own experience I knew deep down inside that he knew he was right.

His solution, albeit not something I would label agile, worked for his clients. He was passionate about the work he does and the people he helps. He held different views, but was contributing goodness to others in the industry and more importantly, he was getting results for his clients.

He was helping people succeed.

No matter what my opinions are there will always be people who hold different opinions, ideas and experiences to me.

In software development there are very few process level ideas and actions that are black and white. It’s difficult to quantify, measure and then compare two different approaches as there are so many variables…like budget, people, product, customers, skills and experience etc.

One approach that works over here, might fail over there.

A lot of people avoid talking to people who think differently to them but I believe that only by opening our dialogue with others who think differently will we truly learn about ourselves and alternative ways of doing things.

Isn’t it in this collision of ideas where true innovation and learning comes from?

I had a lot in common with the tester I met at EuroSTAR 2012. We’ve kept in touch since and despite his continued promotion of ideas at odds with mine we’ve become good friends.

At EuroSTAR he told me that he had found his calling in life.

Who am I to say his calling is worse than mine?

T-Shaped Testers and their role in a team

Stick with it….it’s a rambling long essay post.. and I may be way off the mark.

I’ve never been comfortable with the concept of a separate test team and associated “phases” of testing. I spent about 8 years working in these environments and kept struggling to answer questions like:

  • “Why are we involved so late in the project?”
  • “Why are there so many obvious bugs or flaws?”
  • “Why does the product not meet the spec?”
  • “Why do we always follow these scripts and assume the product is good?”
  • “Why don’t we use the questioning skills of tester’s earlier in the process?”
  • “Why are the tester’s skills in design, organisation and critical thinking not valued at the end of the cycle?”
  • “Why do we have some specialist testers, like performance testers, but a load of other testers who just do ‘any old functional script’?”
  • “Why does everyone keep complaining about this way of working, but do nothing about it?”

And a whole load more questions along the same lines.

These questions are common in the industry, check out any forum or conference and you will find many similar questions being asked, and a plethora of tools, services and consultants willing and able to solve these problems.

It’s taken me many years and much analysis to come to an idea about testing that I feel more comfortable with, and in truth, it wasn’t even my idea, but I’ll get to that bit.

The more people I speak to about this, the more I realise that others feel comfortable with it to. Comfortable because they are operating in these contexts, or, more crucially, would love to operate in a context like this. Of course, some don’t agree and many simply don’t care…but that’s another post.

I believe that finding bugs is just one aspect of a testers role.

I don’t think finding bugs is just the responsibility of the tester either.

I also believe that testers should use their skills in other parts of the project cycle, whether that cycle is two weeks or two months or two years.

The idea I am presenting here is the T-Shaped people idea. It’s not mine, I believe Tim Brown (CEO of IDEO) coined it in the 1990s to describe the new breed of worker.

If you imagine the letter T being a representation of a person’s skills (or as a role as I like to use it). The vertical part of the T represents the core skill or expertise. In testing I would naturally suggest this is the core skill of testing (of which there are many variations, and sub-skills). The horizontal part of the T represents the persons ability to work across multiple disciplines and bring in skills and expertise outside of the core skills.

The more I talk to people about T-shaped testers the more I hit a nerve with people. It really does seem to sum up the growing number of testers in the community. Those who are skilled testers, yet are skilled in a number of supporting domains.

Many of my peers in the community are T-shaped testers. They excel at their specific element of testing yet they bring in skills from other areas, or they use their skills to fulfill other roles within the business.

In start-ups or fast moving companies the ability to work across multiple disciplines has some obvious benefits.

One person capable of fulfilling a few roles reasonable well seems like good value and a good asset to delivering value. Even in traditional environments with more structured roles T-shaped people can be found serving multiple roles.

However, a lot of the time people don’t see themselves as contributing to something outside of testing (i.e. fulfilling other roles), or bringing other skills they have to the role. Some simply don’t have the opportunity.

Some great testers in the community fulfill other roles within their business. For example, without naming names:

  • There is a great test manager I know who is also a support manager.
  • There is a great tester I know who is also a product owner.
  • There is a great tester I know who is also a scrum master.
  • There is a great tester I know who is also responsible for market research for the company.
  • There is a great tester I know who also does all of the hiring interviews for **every** role.
  • There is a great tester I know who also runs conferences, sells advertising, builds his own product, markets his own product and consults to big clients. (how many different skills do you need to achieve that?)

These are just some examples. There are countless others.

Then there are those who are testers but have supreme skills out of work that aren’t utilised in their main role. We have musicians, artists, designers, writers, mechanics, engineers, carpenters, social media advocates, printers, net-workers and anything else you can think of that someone might do out of work. Could a company not utilise and encourage the use of these skills to help solve business problems? Of course they could.

Sadly, many people (not just testers) are pigeon holed in to their role, despite having a lot more to offer.

As a short side story I was ready to leave testing a few years back, mainly due to being unable to answer the questions I posed earlier. I was thinking “Is This It?”. What about the skills I had and the passions outside of work? Why can’t I use these? What job could I get that does use them? Would I have to re-train? Why are my other skills ignored in the work place? Then I found blogging, consulting, agile coaching, systems thinking and ultimately people management and it all fell in to place…..Anyway – I digress.

I believe that testers, actually – anyone, can contribute a lot more to the business than their standard role traditionally dictates. The tester’s critical and skeptical thinking can be used earlier in the process. Their other skills can be used to solve other problems within the business. Their role can stretch to include other aspects that intrigue them and keep them interested.

With Acceptance Test Driven Development, Test Driven Development and a whole host of other automation approaches comes the need for testers to be involved earlier but crucially, not so tied down later in the cycle running confirmation checks. Exploration, curiosity and intrigue are what drives testers in these environments. The checks are taken care of, what remains is to understand what the product actually does and provide insights in to risk, uncertainty, user experience and the markets (customer, end user, competition, industry) expectations of the product, plus the stuff we might not have thought about earlier.

They can help to discover what the product is meant to be, not just give judgment on whether it meets the requirements or not.

Finding bugs is what we do, but I don’t believe that this should be an end goal. Bugs are a side effect of discovering more about the product…maybe.

I believe everyone has the capacity to do a lot more towards the goal of shipping great products outside of their stereotype role. It’s something we’ve embraced here at NewVoiceMedia.

We have testers who write product documentation, are scrum masters, are building infrastructure to support rapid release, are taking ownership for security and compliance to standards, are presenting the development process to customers, are visiting customer sites to research how people are using the product, are writing social media content, are devising internal communication strategies, are doing agile coaching, are creating personas and are using their natural skills and abilities where they are best suited to help move the business forward.

We’re still working on the balance between roles and expectations, and the balance shifts, typically in response to the market.

Don’t get me wrong. Many people don’t have this opportunity but if you’re in a position to make changes then utilising your wider skills and the skills of those in your team could be a great approach to solving problems.

This is clearly not restricted to testers either. Programmers, product owners, support, sales, accounts etc etc – everyone is a T-Shaped person, or at least has the potential to be T-Shaped.

I think the future of testing is going to be a future of both specialists and generalists. There is always a need to have specialists in security, performance, accessibility etc, but there is also a need to have generalists; testers who can fulfil a number of different roles across the organisation whilst still maintaining a core skill of testing.

Being a T-Shaped person means having skills that can be useful across other domains. Having T-Shaped tester roles means encouraging testers to fulfil a number of roles. Learning the skills needed, or already having the skills in place (i.e. already being a T-Shaped person) means people can either slip straight in to the role, or they may have to seek out learnings, coaching and mentoring. And that’s where good management, teams and community engagement can come in.

I’m exploring around this idea right now, but I know already that T-Shaped people gives me a really good model to describe the testing and testers I feel comfortable with. The testing that I feel suits me, the companies I seek out and the markets I work in.

I believe testing is more than finding bugs; it’s about exploring the product, discovering what the product needs to be, discovering the market needs (i.e. A/B Testing), discovering what the product actually does, working out whether the product is suitable for the context of use, questioning the process, improving the process, helping to design the product, improving the product, helping to support it, helping to promote it and ultimately working with the team to deliver value.

And all of the above might explain why myself (and those peers who appreciate or demonstrate the T-Shaped model) find it so hard to recruit great testers (for our contexts), yet other managers I speak to can find “good” candidates at every street corner.

We demand more than just testing skills. We demand many other skills that complement a testing mindset. Skills that help us deliver value.

Of course, these are just my thoughts based on testing in my context. You’ll work in another context and appreciate other skills. At the moment this is just an idea, and like all ideas, it might be wrong. But I thought I would share it anyway.

 

Image courtesy of : http://www.flickr.com/photos/chrisinplymouth

We are all on a journey

At some time or another we all lose sight of the fact that each and every single one of us is on a journey.

Life is a journey. Your careers and jobs are just one part of that bigger journey.

 

 

  • Some people take more control of this journey than others.
  • Some people have more opportunities to take control than others.
  • Some people are further along their journeys than others.

There are many factors that affect the journey you are on.

These could include some of the following:

  • Your personality
  • Your location
  • Your cultural background
  • Your mindset
  • Your boss
  • Your company
  • Your family
  • Your desires and needs
  • Your passion for the job
  • Your peers
  • Your awareness of the industry
  • Your mentors
  • Your heros
  • Yada yada

The list goes on, and on, and on.

Some people are more open to new ideas, new challenges and new opportunities. This often gives them a wider choice of potential paths.

 

This opens up great opportunities, but it can also open up choices which are hard to make.

Some people are further behind on their journey than others. That doesn’t make them “rubbish” or “stupid” or “not part of our group”. It just means they are on a different path, are in a different place on a path and maybe they haven’t yet reached a similar path choice that you have gone down.

10 years ago I was on a path of scripted testing, no exploration and all of this in a waterfall death march environment. I’ve heard people say recently, that testers in these environments are “rubbish”…….really? Why?

I’m a better tester now for sure, but I’ve never considered myself “rubbish” – I’ve just gained wider insights and more experience from the paths I have chosen (or been forced down) in my career and life.

Some people choose alternative paths for a variety of reasons. That’s their choice, not ours. They may want different things from their careers. They may want different outcomes. They will have different personalities than we have.

Some people follow career paths that don’t seem logical, that wind and dip and move backwards.

 

In the end though, they too are on a journey. And that messiness and sporadic direction of travel may suit them well.

In the testing (and wider development community) we are all too quick to assume that someone is rubbish, or inferior, simply because they are on a different path, have not had access to the opportunities we may, may not show any interested in progressing beyond “enough” and may not even be aware of alternative routes they could take.

The work someone did a few years back is often still deeply associated with that person, even though their current work may actually be very good. Work some people do now may be of the same standard that we ourselves may have been doing 4 or 5 years ago.

We’ve grown and taken paths which lead us to now, they may do the same too. In 4 years time they may be doing the same standard of work as we are doing now.

Don’t get me wrong. There are testers who are better than others in certain environments. Or achieve higher marks using whatever yardsticks for measure you are using. There are testers I would hire and who I wouldn’t. But there are also good testers who are right for one context and not for another.

There are testers who, with the right help and support, could become outstanding testers. There are good testers who may not get that help and support…..

There are many routes and paths through our testing careers. The path you choose will not be the one I choose. And that’s ok.

It’s easy to point at someone else and say they are rubbish because they work in X way, or don’t have X skills.

It’s harder to acknowledge the reasons why they are at a certain point on their career journey, to establish whether there really is a problem with them being there (or even if it’s any of your business) and then to support, help and share to guide them down a path they want to go on.

Are certifications relevant?

I know many readers of my blog would suggest I’m a hater of certifications for Testers.

That’s simply not true. Despite my ardent fight against them I am pragmatic enough to realise that getting a job often requires getting a certification. And putting a roof over your head often trumps principles and ideals.

I also believe that a certification course, delivered by a competent tutor who has bucket loads of skills and experience, can be very valuable.

I just don’t like what they have come to symbolise in the market place. I don’t like how you DO NEED A CERTIFICATE to get a job (in most cases).

Where did it all go wrong?

I’m not here to bash Certification schemes. Use your own judgment and experience on whether you think they give you insights and learnings or not.

Instead I’m going to ask you a question:

Are certifications still relevant?

  • I don’t believe they have succeeded in making people competent Testers. This is evident from the number of certified people on forums and LinkedIn asking “What is Testing?” or “Tell me how many Tests I should have for X feature!” or “why is testing so boring”.
  • I don’t believe they have succeeded in creating a universal language with which to talk about Testing. This is evident from the fact most Testers don’t know what “action word driven testing” is or what a “Software Failure Mode and Effect Analysis” is OR the fact that I call it a Test Case you call it a Test Script. The big question here is “Do most Testers care outside of their own company and context?”.
  • I don’t believe they have succeeded in promoting the value of software testing to organisations and business. I still come in to contact with a vast array of companies who don’t test, don’t appreciate testing and don’t understand what value testing can bring.

So are they still relevant?

There was a time before the Internet when you had very few places to go to obtain Testing knowledge, training or awareness. When I started out I went to the British Computer Society, a few well known books and the ISEB foundation. The ISEB crowd certified me. I still kept Testing as I had before. I just felt slightly more hire-able.

Only when I reached out to the wider community online did I find a place to soak up information and ideas about testing. I started sharing ideas. I started to meet people who thought the same way that I did. I started to feel like Testing was actually interesting. I started to find people who didn’t talk about standards, didn’t speak in platitudes and marketing pitches and didn’t push certifications at me from all angles.

When access to information is restricted or impossible those that hold the information have the power. If you wanted that information you had to pay. If you wanted to see what the “industry” thought was a good standard, you had to pay to find out, and then pay even more to be accepted.

Social networks and the “digital revolution” has made that information (and a much broader selection of ideas too) available to the masses. Having to pay for access to information is becoming rare.

Yet we still continue to pay for certifications.

We’re no longer paying for the content; almost all of that is available online, for free.

We are no longer paying for the training as it’s possible to sit the course and pass without in person training. (There are also a vast selection of excellent paid and free courses available online and in person outside of the certification schemes.)

I believe the masses* are paying for the right to say “I have a certificate!!!!!”

In a sea of people all shouting “I have a certificate!!!!!” why would anyone pick you?

 

* There are some people I meet who sit the certification courses as just one part of their continued learning…not the only part of their learning.

Social Media alone will not get you a job

Judging by the swarm of testers trying to connect with me on LinkedIn recently it seems no-where is now safe from those who want a job.

99.9% of those who try to connect with me have never had a conversation with me (in the real world or digital). I see the same thing on Twitter, where I have less control over who follows me and also on this blog, where I delete a huge number of comments from people wanting a job.

It seems many testers are falling in to the simplistic trap of believing that social media will get them a job. It’s not surprising when there are a number of companies, individuals and organisations who are pushing social media (in the Testing world) as the way to land a job.

It’s easy to see why people would sign up for Twitter, follow some people in testing and then directly ask them for a job.

Social Media alone will not get you a job. Social Media, in a simplistic sense, is a communication (and publishing) platform/channel. It’s a way of networking, communicating and distributing content. Social Media may get you connected to people with jobs, or put you in front of people who are hiring, but you’ll still need the skills to see the application through (unless of course the hiring manager is not assessing you on anything). You still need your thoughts, ideas and the ability to articulate these clearly. Social Media alone won’t help you there.

(Note: I do know of some examples where simply turning up to the interview would get you a testing job, but I don’t really consider that testing, or a proper job.)

Here’s some thoughts on why I believe the message is too simplistic.

  • Some companies may see an active social media user as a drain on resource. After all, you should be working instead of tweeting…right?
  • Some companies may see an active social media user as a risk. “What are they going to say that could get us in trouble?”
  • Some companies may see active social media users as a boon. After all, their business may benefit from the thought leadership, experience or free marketing. They may even be working in the social space and demand people who understand and “get” social media.
  • Some testers wield their social presence with great skill and attention, yet aren’t great testers, but great marketeers.
  • Some testers wield their social presence with great skill and attention and are amazing testers, and great marketeers.
  • Some testers don’t wield their social presence well, and are bad marketeers.
  • Some testers sign up to social channels because they think they should and do nothing spam others.
  • Some testers sign up to social channels because they think they should and have no interactions, followers or conversations.
  • Some testers use social media as a platform to sell services and goods.
  • Some testers use social media to communicate ideas and further their skills and thinking.
  • Some testers use social media to build communities.
  • Some testers use social media to destroy communities.
  • Some testers just don’t get it and stay away.
  • Some testers are afraid of social media. Their personalities don’t gel with the public display of thoughts and ideas, yet they can be incredibly talented.
  • Some companies hire very well without social media.
  • Some companies go straight to their social channels for hiring.

I probably know someone who fits all of these, and a whole load more categories too.

I know a great tester who recently landed an amazing job and she isn’t on any social networks. Not even LinkedIn.

I know testers who are on social networks and actively connecting, but they can’t get jobs. They lose out to better candidates.

I know of some testers who have been offered a job directly through Linkedin without even being interviewed.

 

It’s too simplistic to say that getting a job requires you to be on a social channel and it’s too simplistic to say that being on a social channel will get you a job. It’s clearly not true in either case.

What get’s you a job (apart from “jobs for the boys” mentality) is proving to yourself, your peers and the hiring manager that you can do the job.

Social Media is no different to networking in person at Testing events, presenting at conferences and offering training services to build a wider network.

 

Getting in front of the hiring manager is easier with more connections, but these don’t have to be online through social channels. Many testers operate very well indeed and that’s purely from the old fashioned face to face networking.

Networking has been the key to getting a job (especially in hard times) for years, and it’s true that Social Media makes that’s easier now for the masses. But any hiring manager worth their salary should be recruiting for the person and their mind, not the number of social channels they are on.

Social channels and social media can help you amplify your thoughts, build your network, generate content and communicate with those who can get you jobs, but your skills and experience will be what ultimately separates you from others.

http://www.forbes.com/sites/lisaquast/2012/05/21/recruiting-reinvented-how-companies-are-using-social-media-in-the-hiring-process/ http://www.forbes.com/sites/lisaquast/2012/05/21/recruiting-reinvented-how-companies-are-using-social-media-in-the-hiring-process/ http://www.smartcompany.com.au/hiring/048837-the-legal-dangers-of-hiring-through-social-media-2.html http://www.chicagotribune.com/features/tribu/ct-tribu-facebook-job-dangers-20120117,0,1257938.column http://www.therecruiterslounge.com/2011/09/26/be-careful-when-using-social-media-in-hiring-decisions/ http://www.quarles.com/employee_social_networking_dangers_2010/ http://www.inc.com/guides/2010/04/social-media-recruiting.html http://mashable.com/2012/02/11/social-media-recruiting-tips/ http://steveradick.com/2012/05/27/seven-real-ways-you-can-use-social-media-to-find-your-next-job/ http://socialmediatoday.com/fixcourse/564760/3-social-media-mistakes-you-dont-know-youre-making