Its all about people.

This might sound really obvious, but not much can get done without human involvement somewhere along the line. Therefore people are important, and that is the same whatever industry you happen to be in.

Working in technology, we can be forgiven for believing that technology is king, and people are somewhat incidental. We are focussed on delivering changes to products and using technology to do so. Code is written, tested and released in regular cycles, to deliver benefits to an end-user – a person. But what about the people who are not those referred to in a User Story? Those actually involved in gathering requirements, writing the code, testing it, releasing it? Are they not important too?

Yes, I believe they are, and I also believe that too few companies genuinely believe this to be true. Thankfully the company I work for is very people focussed and personal and professional development is not just something we pay lip service to. Failure to invest in people just means that they will leave. A new study on how millennials see the world indicates that they are happy to just jump ship on regular intervals to get ahead. That contrasts with my belief in loyalty and that moving too often looks as though you lack staying power, but there is a generation gap here, so maybe the difference in outlook is not so surprising! In any case, it’s not just about Generation X, Y and millennials, but people in general. We all need to feel valued, that we are doing something worthwhile and appreciated, stretched so that we have learning opportunities, and trusted to do a good job. No-one wants to feel bored and undervalued, whatever year they were born in.

The problem is that managing people is hard work. Everyone is an individual, with different motivators and needs, and a good manager has to keep track of each person and deal with them in the way that works for them as individuals. When I first started managing, I believed in treating people the same – that’s fair isn’t it? And treating people how I would like to be treated. Both admirable ideas, but fundamentally flawed. Firstly I assumed everyone was motivated by the same thing, and that isn’t the case. And secondly, my preferences are not the same as others. So by trying to do the right thing, I missed out on looking at people as individuals.

Roll forward a number of years and as I matured into my role, attended training courses and benefitted from coaching by my line manager, I came to realise and appreciate the differences between each of my team members. I manage 9 testers now, all unique in their own ways, and I absolutely celebrate those differences. I love being able to find out what motivates someone, and give them opportunities in those areas. It’s great to see how they respond, and the passion with which they do their work when truly trusted and motivated. There is so much to be gained as their manager, as I get to celebrate their successes with them, and see them fired up and ready to tackle new things.

Whilst writing this, it strikes me just how much of a mind-shift I have had to make over the past 5 years, but it has been totally worth it. I would like to think that I am a good manager – not perfect, and still with a lot to learn – but no longer taking a lazy approach to managing people, and instead considering them as individuals, and treating them as such. I mentioned earlier about treating people fairly, and I can still do that by giving them all different opportunities, and not leaving anyone out. It isn’t about treating everyone as though they were clones of each other, and it isn’t about assuming that everyone is motivated by the same thing or has the same dreams and aspirations.

Yes, it takes effort and time to get to know every individual, but then if it isn’t about the people, what’s the point?

My first Webinar!

A week ago I delivered my first Webinar, courtesy of Unicom Seminars (www.unicom.co.uk). They had approached me to see if I was interested, and after blogging, writing a few magazine articles and speaking at conferences, this was something I had not done before.

The theme was around learning and it worked well for me as I have been on a bit of a mission to help my team to do some tester pairing and Thought Leadership to stretch themselves, and I felt I could deliver something of value to others.

As I was writing the slides (and notes), I noticed just how much we focus as an industry on the purely technical skills that we want testers to have. It struck me that we are ignoring the analytical skills and soft skills that we want as well, which are the three areas I feel a good tester needs to work on. There’s no point in hiring a good technical tester who lacks analytical skills as they wont be able to plan the tests to actually automate. There’s also little point in hiring someone with little or no soft skills. Good communication skills are vital.

I managed to get the point across in a 30 minute slot, with 40 ‘live’ attendees listening in, and I was very pleased to have around 10 questions to answer as well.

Doing something like this has helped me to give something back to the wider testing community in a different way, and I am grateful for that opportunity. My next magazine article will be in Jan 2017 Tester magazine on this very topic so you will be able to read more there. Unicom have also asked me to do a conference session in Manchester in February on this topic, as they felt it would come across well.

I would encourage anyone reading this to have a think about stepping out and giving something back. The Ministry of testing offer the chance to do 99 second talks on a test related subject which can be put on a website, and this is a great first step towards doing a conference talk, webinar or writing a blog or article. It’s worth it, believe me.

Routes into testing

I’m going to make a guess that you (as a reader of this blog entry) never dreamt of becoming a Software Tester when you were at school or college. You may have had dreams of being a doctor, lawyer, train driver, astronaut or a whole host of other things, but Software Tester was not something you would necessarily have even heard of.

For decades, anyone wanting to get into the field of IT would aspire to a Development (or Programmer) role, as these were the main roles that we heard about. Even today, whilst Computer Science graduates have heard of testing, by virtue of the fact that A levels (in the UK) and degree courses now do something akin to a nod towards the fact that software testing is actually something important, and there are people who choose not to write code but to test it for a living. As an example, Oxford university offer a course on Software Testing as part of a Software Engineering degree, which is something that didnt happen in the 1990’s or 2000’s!

There are many graduate schemes which bring people into IT, but even today primarily this is Development, Security and Operations type roles. There are Testing Services companies that will train testers as graduates, but I wonder what the ratio is of graduate testers compared to other roles in IT?

I fell into a testing role for my second job, moving from one bank to another, from a non IT role into a role that I had never heard of. There were no training courses and I learned on the job. It took me a while to understand what the role actually was, and even now there are many people with differing opinions as to what Testing actually is – but that’s not for this post!

Over the past few weeks there have been some interesting Twitter posts about whether Testing is a role that anyone can get into or not. My view is that we are all testers anyway, without realising it. We test the temperature of bath water before bathing our small children. We test the fastest route from A to B and try different ways. We test boundaries of behaviour and acceptability. We test how much we can eat in a ‘eat all you can’ buffet before we feel full. We test just how much longer we can wear our old trainers before they fall to bits! We test all the time.

It seems to me that just about anyone could in theory become a tester, no matter their career background, but not everyone would be good at it. To be a good tester requires having the right attitude as well as technical ability and the right mindset. Technical skills can be learned, how to approach testing can also be learned, but attitude and the right mindset cannot be learned.

It’s interesting therefore to look at how current Testers (at all levels) actually got into software testing as a career. A common story is where projects have required assistance from business units with User Acceptance Testing, and those who helped out became involved that way, staying in Testing and bringing their business knowledge. I’d love to hear your stories as I’m sure there must be some very unusual routes into Testing out there so please share your story and how you found the transition.

Another great day at work!

Ok, I am a few days late, as the day was actually Tuesday 13th September, but I haven’t had time until today to get blogging.

Back in May, I blogged about taking TestBash to work – well we did it again this week! With my colleage Bhagya  we ran our second ‘Building Quality with Distributed teams’ workshop for over 20 people from four different teams within our organisation.

We had learned a lot from the first workshop, namely to have a timekeeper as well as two observers, which really helped, plus we extended the timings of the tasks a little to see how that worked.

We managed to keep it to 3 hours, and with 100% positive feedback from participants that they all found it useful, but almost unanimously suggesting that we add a little more time as it felt rushed as we wrapped up. So, our next one will be 3 1/2 hours long! Each time we will try to take on board feedback and make improvements, so as to maximise the benefits that the participants gain from the time invested – and it looks like we are in demand. Our parent organisation has asked us to perhaps run a session as a pilot to see how that works, and we may we asked to run externally as well.

All of this arose from attending a workshop at a conference, and proactively taking it from there and implementing it ourselves. So thanks again to Lisa Crispin and Abby Bangser  for sharing the resources and supporting us with this. They could so easily have kept it to themselves, but that isn’t what we as testers do. We share our expertise and knowledge with others for the benefit of everyone in the industry, and that’s what I love about the testing community, so long may it continue.

Here’s a challenge. What have you read about, seen at a conference or experienced that you could share with others?

Good testing – luck or judgement?

I get to talk to a lot of testers, not just those in my team, but other teams in my organisation, testers at conferences and those I interview, and it struck me the other day that there is no real way to tell from a person’s background whether they are going to be a good tester or not. Wouldn’t it be great if we could apply a formula – it would make life so much simpler, but I don’t believe it comes down to training or background – it’s either in-built or not. What I mean by that is that in my opinion, good testing cannot be just left to luck (although it can be I suppose if you just happen to find that critical bug without looking for it!), for me it is all about attitude and mindset. Technical ability and the focus on automation seems to be the overriding requirements for many testing roles, and whilst they are important, they are not the ‘be all and end all’.

If we define a good tester as someone who can write automated tests, then we are essentially defining a developer. So why do we need a tester to focus on writing code if developers can do that?

Good testing comes from understanding the application, understanding the requirements (usually from a User Story if we are following Agile), and determining whether the requirement is testable, whether there are any omissions, clashes with other stories, potential impacts on other applications, and what types of testing are needed in order to prove to the Business Owner that the team have delivered what was requested. Good testing is found in how a tester approaches their job, and I know I have mentioned this before, but it is where a tester adds value to a team. Having another individual who can just automate the acceptance criteria that a Business Analyst wrote adds no additional value – and the team have employed a developer essentially.

A good tester needs to think about the application, and consider it as an end user, ask the questions that no-one else thinks of and be inquisitive. A good tester has to exercise good judgement in determining what to test and how to test it, and whilst this can be learned (to a degree), much of this will come from a person’s character.

If you are a good tester, then luck will play second fiddle to judgement, every time.

The danger of words

Ok, so here I am back on the theme of recruitment. Why? because I am trying to fill two roles in my team, and it has been a struggle.

There is a fundamental problem with CV’s. There are many different ways in which a CV can be laid out, many different words used to describe experiences, but no hard and fast industry rules or best practices governing them.

Every CV is a personal statement, therefore should reflect the individuality of the author. Layouts do not need to be the same, although the type of useful information should be uniform. A good example is where candidates will list a job role, and the first bullet point isnt about their experience or responsibility – its about the company or product, lifted from a web page somewhere. I’m interested to a degree what type of application they work on, but I dont need a company history! Or there are many fonts used (refer to previous posts for that one), or messy tables that make it hard to read.

So, what should a candidate cover?

Thats easy – it’s the skills, direct experience and responsibilities that they are doing/have done in each role – e.g.

  • Writing a Test Strategy for Project X.
  • Working as part of an Agile scrum team, attending Planning, Retrospective and Demo meetings and Daily Stand-Ups.
  • Estimating user stories.
  • Writing tests based on User Story acceptance criteria.
  • Writing automation tests using xyz, in K* language.
  • Executing manual and automated tests, and raising defects in ppp.
  • Performing non-functional tests – Performance using nnn, load using zzz.

And so on.

One of the biggest issue however is how candidates justify the use of certain words, expecting those reading the CV’s to know what they mean.

I’m referring to ‘Experience in‘ and ‘Knowledge of. Both in my opinion are dangerous!

I spoke to a candidate on the phone who had used both of the above all over the CV, including for a tool that I needed the candidate to have used, in order to fit into the team and hit the ground running. Unfortunately we don’t have time to train someone from scratch due to looming deadlines, so I had reviewed a batch of CV’s to narrow down to 3 candidates. This candidate gave me a run through of the skills and tools that they used, but missed out this one. I picked up on this and asked about it – and the reply was that they were aware of the tool but had never used it. I asked why it was on the CV – to which the response was “That’s why I used the phrase Knowledge of”. Wow! Priceless answer……except for the fact that I am in no way a psychic, therefore have no idea what the candidate was thinking when writing the CV! The candidate proceeded to argue with me (never a good idea in a phone interview) until I pointed out that to include it was dishonest and that only skills or tools that they have practical experience should be covered. I also asked how I was supposed to know the difference between their statements! Needless to say the call was ended shortly afterwards.

I then experienced the flip side of this in the next phone interview where someone HAD used the tool on a personal project at home, but decided not to list it. It’s interesting how people’s minds think. My view is that even if you have used something for a short while, or as a home project, it is fine to list it within its context. This shows that although it is not a skill that would be useful if the role requires someone experienced, it could be if there was time to train someone up with basic knowledge already, and it shows initiative and a willingness to learn.

Another issue is repetition. Do candidates realise how many people search through CV’s using the Find function in Word?. If I need a set of technical skills, that’s what I’ll do to see if they are listed in the body of the CV, and not just in the agency cover sheet (believe me, it happens far too often). The problem is that candidates will have performed a number of similar roles, and copied bits and put them under each role. Why? I understand that a candidate will have estimated, tested, attended Agile meetings etc in 3 companies, but surely there is a way of rewording a little in each one – to not do so looks very lazy. If a candidate can’t be bothered to show that each job differed a bit, then a) why move in the first place, and b) does that show a lazy attitude to work, or are they trying to reuse phrases and show me something? Its hard to know, but the decision to phone or face to face interview hangs off the information that is presented in the CV. As a manager, I cant afford to waste time finding out.

Not everyone will agree with me, but I am speaking for myself as a recruiting manager. I want the basics. I have a number of CV’s to review and not a lot of time to do so. Poor layout, waffle or repetition is wearing, annoying and wastes my time, and will not get the candidate through the door.

The best CV’s cut the waffle, tell me what I need to know, don’t contain lies, and are not craftily worded to try to get the CV past me to try to gain an interview. Lies or discrepancies will come out in an interview where everyone will have just wasted a lot of valuable effort, and the candidate will not get the job anyway, so why bother?

My advice to anyone writing a CV is this – read it as someone who has only 5 minutes to screen it. In an ideal world every manager would have longer but that doesn’t happen. What are the standout items that you want them to read? Do you have to put all those bullet points in from a job you did 3, 4, 5 years ago? The most important roles are the most recent 1-2 years, so focus on those. Remove any duplication – the fact that you have used Selenium Webdriver doesn’t need repeating 14 times! And use words carefully! Words can be dangerous – they can mislead and they can give a false or negative impression of you if not used with care. What does ‘Experience in’ really mean. Contextualize it. Help the person reviewing your CV to find the real you. And get someone else to proof read it.

The fact that I mention that I am recruiting is NOT an invitation for recruitment agencies or candidates to make direct contact. You can however find details of roles that we have open in my organisation here: https://reedelsevier.taleo.net/careersection/13/moresearch.ftl – direct candidate applications only.

Thanks for reading.

Oh – before I forget, the above ‘Curriculum Vitae’ image is from a site http://www.ssworkclub.co.uk/ who are a group who have set up a website aimed at helping people on a local estate in the north of England to write good CV’s and help them find work. What a great thing to do – well done guys!

Maintenance

Blogging is something that I do sporadically – there are people who seem to have an awful lot of time during the working day to post updates, but I am too busy to do that, and in the evenings I want to unwind and let my brain relax a bit. I find that during the weekend where I am winding down a little is when some of my better ideas pop into my mind.

Like this morning. I went out into the garden to put the Guinea Pig into the outdoor run, where I noticed just how quickly the grass had grown since it was cut only 8 days ago. Looking around, things are growing at a fast pace – shrubs, grass, weeds and the vegetables in the greenhouse. In fact the grass verges were a metre high before the council cut them last week!

I sat with a cup of tea and started thinking about the maintenance jobs I need to do later on today – onions and lettuces to plant out, weeds to pull, some shrubs to trim a little. You may wonder where I am going with this, and what it could possibly have to do with testing, but here’s the thing – it’s all about maintenance. Oddly as I was thinking about gardening, the idea for this blog came to me.

As testers, we need to perform maintenance around our testing artifacts in the same way that gardeners need to do in their gardens.

We have many test artifacts – in my organisation there are testing notes for each application, so that if a tester is new to that team, they will have reference notes about the application, what it does, where environments are, the test data needed, where the automation pack is etc, and of course we will have our test automation suites as well.

Having this information to hand is a good thing – but only if it is maintained and kept up to date. Applications are ever changing and we should ensure that we perform maintenance as part of our core testing approach, rather than leaving it.

The grass outside our houses and on the green up the road was left to grow to a metre tall, and as a consequence children couldn’t kick footballs around until it was cut by the council. It is the same with testing – things become unusable. If we do not maintain our automated tests, they either do not run at all, or a number of them fail, giving a false indication to the development team as to the state of the build. It then become necessary to waste time investigating why some failed, and determining if they are genuine failures or not. And if links are not updated, or test data suites are ignored, they become useless and the time originally invested becomes worthless.

Planning to include maintenance as part of our testing day jobs is a must – but it is a challenge. We haven’t got there yet with all teams, due to pressures for delivery, so this is something that I also need to work on with my team. It isn’t easy, as we have to persuade others that the time spent doing the maintenance is valuable and gives us some pay-back.

I’d be interested in hearing from anyone who has managed to pull this off, as I would be willing to bet it may only be a reality for a minority of testers.

My first challenge today is getting the garden in order – who knows, I might have some more bright ideas whilst pulling out some weeds later (it is very therapeutic!!).