Hiring Testers – a view from the other side of the table
It’s been a while since I’ve needed to hire another tester, but that time has once again arrived. Hiring has generally been a lengthy and painful experience and this time appears to be not much different from the last. I generally put the call out to people I know that might be able to help out. If that fails then it’s time to put the word out in the Internets that I’m looking. This invariably results in a flood of CVs of which 99% are TERRIBLE. I resent this as it is a huge waste of my time – the only finite resource I have.
I might get one in twenty resumes that I don’t immediately bin. Out of those I keep, I’ll probably end up interviewing one in five.
For the sake of my own sanity I’m going to list all the things that will get your resume binned (by me at least) and some things you can do to increase the chance that not only will you be interviewed, but that you will be hired.
I don’t care how well you’ve copied that stock standard resume you googled. Most of the stuff online is fucking awful anyway. Here’s how your standard crappy resume goes:
Name and particulars
Some sort of generic mission statement about how you want to do your best for <insert company name here>
Description of tertiary education
Description of previous positions held describing your responsibilities in bullet points
There are variants which include
a bullet point list of skills with some context-free rating of competence
a list of desired positions that doesn’t include ‘software tester’ (note – if you want to be a project manager when you grow up, I don’t care, but if you’re applying for a software tester role and the ‘desired role’ field doesn’t have ‘software tester’ in it then you get binned)
These painfully generic resumes make my eyes bleed and contain absolutely nothing that tells me whether or not you might be a good fit for the role.
Moreover, these resumes are often riddled with spelling and grammatical errors. If I see these, you get binned. I consider your resume your first work product. I’m looking for people who are detail oriented and have pride in their work. If you can’t be bothered to get this right, then the job I’m offering is not for you.
Don’t tell me about how you know you’re a perfect fit for the role. That’s not for you to decide. There’s being confident and then there’s being a knob. If you’re a knob, you go in the bin.
If you’re going to go to the trouble of making a resume – something that you are hoping will make you stand out from every other person that applies for the role, why would you go out of your way to make your resume as close as you can to every other resume you’ve seen? I recommend in the strongest possible terms that you buy and read a book called ‘Rites of Passage’ by John Lucht. Read it all and pay special attention to the section on putting a resume together.
As for what I want to see in your resume, I don’t want to know what you did, I want to know what you achieved. What did you do that made a difference to the company?
Tell me what skills you have and tell me which ones you regularly use. Even better, point me at examples of your work, blog posts discussing your skills, posts to stack exchange where you’ve helped people out with the skills you’ve listed. The less work you make me do to convince me you’re worth hiring, the better. If you don’t have a lot of experience, be up-front about it (and show me what you’re doing about it. Tell me about an open source project you’re working on to improve your skills, or a software testing conference you attended recently). If you haven’t done anything to make yourself appealing you shouldn’t be surprised when you’re passed over.
Okay, let’s pretend you’ve sent me a resume that offers me the faintest glimmer that you’re someone I might be able to spend 40-60 hours a week with. The next thing I’m going to do is give you a questionnaire that shows me how you think. It used to surprise me the number of people that plagiarised their answers. Don’t do this. I know how to use the internets too and I will find out. When that happens, I will tell everyone I know and like not to hire a person called <your name here> because s/he is dishonest. Which also sucks for anyone that shares your name. I’ve considered posting a wall of shame on my blog for would be testers who are dishonest and stupid, but I’m not that much of a bastard yet.
So – answer the questions in your own words. Say what you think, not what you think I want to hear. If you think a question makes no sense or is not relevant, say so or ask for qualification. I’ve been known to ask stupid questions on purpose to see if a candidate will call me on it. Almost no one does. Don’t play buzzword bingo and don’t use nebulous, meaningless phrases unless you’re prepared to define what they mean to you.
Okay then. So assuming you’re not a plagiarist and you can think for yourself, we might get to spend some time chatting face-to-face or over the phone. I’m going to ask you a bunch more questions. I’m still looking to make sure you know how to think, and have an aptitude for the kind of testing that I will want you to do. I’m also looking to make sure you’re not a psycho and that you’ll be a good cultural fit for the team. If you’re a dick, I don’t care how mad your skillz are; we won’t be working together. If I like you and the people I work with like you then you’ll probably get an offer. There’s a lot of work in between an application and an offer though. Perhaps I should know better by now, but I live in hope that the next resume across my desk will be from someone that takes this stuff to heart. I won’t be holding my breath though.
EDIT:
Here’s what some other people have to say about hiring testers
Paul Carvalho
I’m sorry, but I’m not allowed to argue with you unless you’ve paid
in Everything, Software Testing
as certification, rex black, Software Testing, Testing
I like to engage in good healthy discussion. I don’t mind taking a contrary position or having an argument. I want my friends and colleagues to challenge me. It helps me learn and think in different ways. I’m not a zealot about it. I’m okay with people being wrong on the internet, but every now and again there is the invitation for dialogue that I find difficult to pass up. It can be tough though when the person who has requested said dialogue is reluctant to engage.
I had just such an experience recently over on UTest’s blog where Rex Black of ISTQB fame was interviewed for ‘Testing the Limits’. Mr Black was hopeful of conversation between himself and readers of the UTest blog. Being a reader and having a number of questions I was happy to oblige.
Unfortunately the dialogue has, at least thus far, not been what I was hoping for. Now I don’t want to be unfair. Mr Black is a busy man. He did go into quite some detail on a number of the questions I asked. He indicated his lack of time a number of times during his replies. I had a number of other questions and made several statements though that I was hoping would prompt further dialogue. I’d like to think he will at some point he will take a well earned breather and spare a few minutes to come back and continue.
He was kind enough to point me in the direction of their psychographic analysts. I did put in an a request to them for more information, but have thus far received no response. Should that change, I will be sure to amend this paragraph. (Mr. Black, if you are reading this, perhaps you would be so kind as to have a word on my behalf and have them forward the relevant materials)
In the event that the conversation moves over here, let me list the areas where I would like to continue discussion:
What do you think the value is (to the certificate holder) of a certificate that pretty much anyone can achieve after a multiple choice exam that involves no practical examination of testing?
Would the testing industry not be better served by an examination process that rigorously tests the candidate’s ability to apply in pratice the theory and techniques they have learned, even if such a process was time consuming, difficult and did not scale well?
Wouldn’t the ISTQB serve the industry better by helping busineses realise that excellent testing is difficult to do well and that not everyone is cut out to be a professional tester?
There were a couple of other questions that I was waiting to ask. I wanted to get the current set squared away before I continued, but since I am not sure when this discussion will continue, let me state them here.
You say that ISTQB’s competitors have obvious commercial interests. Is the ISTQB a not-for-profit organisation? If that is the case, what happens with the $100 or so that examinees pay for their certification. 160,000 x $100 is not a small sum of money, even over 10 years.
I should say that these last couple of questions are not only for Mr. Black, but are open to anyone from the ISTQB who can authoratively answer them.
Once again, I’d like to invite you to read through this PDF, at least slides 8 to 14, but the rest is very worthwhile also. There are questions and assertions there that I think you really need to answer, for the sake of your credibility if nothing else.
The floor is yours.
The Software Tester’s Dictionary
in Everything, Software Testing
as AST Dictionary, Software Testing
For those of you who weren’t at CAST2010 and maybe aren’t so acquainted with some of the things the Association for Software Testers is up to, you might be interested to learn that Cem Kaner is heading up a special interest group to create a dictionary of terms relevant to software testing.
For those people who are passionate about their testing terminology, why not give them a hand?
I would love to see this proliferated far and wide. I’d much prefer a wealth of definitions to choose from and a place to point people than a cult of money grubbers peddling their one true way.
I haven’t seen the dictionary get much airplay yet and granted it’s in its early stages, but my google-fu failed me the other day when I did an idle search and then I stumbled across it here. I figured I’d do my bit and get the word out. If you don’t have time to volunteer, pass the link on to someone that might.
Life is too short to do a job you loathe
in Everything, Software Testing
as life, sanity, Software Testing
I’ve been busy lately. In a good way, at long last.
I recently started at a new company and have been flat out getting acquainted with how the new place is put together. I have to say – I am loving the new role. I know when I turn up that before the day is done I will have learned something new or I will have made a positive difference somewhere – usually both.
Which brings me to the topic of this post. I’m not a big fan of bitching about ex-employers (and doing so is not the point of this post), but I feel compelled to point out some of the things that have struck me as I shift into this new role.
I did not enjoy working at my previous place of engagement. It’s a shame to say, because some of the people I worked with were very smart andvery talented. Unfortunately the company seemed designed to make any change a herculean effort. I’d be hard pressed to purposely design a more inefficient way of working. I’m not going to give you a laundry list of specifics (though I could). Suffice it to say that there were uphill battles to be fought on pretty much any front you turned to.
I should have seen the writing on the wall. I remember thinking two weeks in ‘Can I really bring myself to care about this company enough to stay and do what needs to be done?’ Still, I was optimistic. I had come from a job where I’d been more successful than I could have hoped and like Alexander before me, I was going to cut through bureaucratic Giordian knots and lead the way to a shining future of efficient development, clean code, strong inter-team relationships excellent configuration and change management, not to mention a kick-arse testing group.
Sadly I acheived none of that. I decided I’d stick it out for 2 years and see how much change I could make. Maybe it was like turning an ocean liner around. Once you got past the momentum built in one direction, surely change would come more quickly. Nope. Didn’t happen. What’s worse is I found myself conforming. Keeping my head down. Not saying anything when I should have made a stand.
As the two-year mark rapidly approached, I had what some substance abusers call a moment of clarity. I was ashamed at my behaviour. If my peers saw me behaving like this, they would not be proud. Far from me making that place better, I had allowed myself to become worse. I decided it was time to leave.
No sooner had I made the decision, an email came out of the blue. A guy emailed me, said he’d read my blog and wanted to have a chat about testing over lunch. He worked a few train stations away and hey, I’ll talk about testing all day if you buy me lunch so I was all for it. I happened to mention during the meal that my current contract was almost up. One thing led to another and I found myself with an offer from a company that looked to me very much like it was doing things that I wanted to be a part of.
Long story short, I’m now working at said company with a bunch of super smart people doing work that I think makes a positive difference in the world. I like the work that I do and perhaps the most importantly I am myself again. I work and think and act from a place of integrity and I can see that the people I work with do the same.
I guess what I’m trying to get at is life is just too bloody short to work in a job that makes you miserable. Not only is it time you will regret never being able to get back, but you may not like the person you become. No amount of money is worth that.
If you find yourself looking at the clock wishing it would tick faster, if you wonder why you’re doing what you do when nothing seems to change, if late on Sunday afternoon when the prospect of work tomorrow makes you die a little bit inside – your place is no longer there (if it ever was).
I’m not saying ‘quit your job tomorrow’, but if you’re stuck in a work situation like this, do everything in your power to find something that is more you. There is something better out there. Go find it. Please.
Borrowing Japanese as a teaching aid
Adam Goucher’s post on New things to steal from the Japanese is the impetus for this one. At CAST I gave a lightning talk on borrowing Japanese language as a teaching aid.
Using foreign loanwords is probably harmless enough if you’re using them to jazz up a story, but if you’re going to use them as teaching concepts especially in the sense of you being the teacher and having enough understanding to relay these concepts to others then more care is warranted.
There were a couple of points that I wanted to make in my talk (though I’m not sure how well I did in the five minutes that I had). Firstly, there seems to be some sort of mystic profundity attached to the Japanese language. Pick a common concept and use the Japanese word for it and all of a sudden it’s full of ancient wisdom.
When I first started learning Japanese, everything seemed terribly profound to me too – probably a combination of kanji seeming unintelligible and me watching far too many samurai movies. Being a little older and a little bit more experienced, I can safely say that, like western teenagers, Japanese teenagers can talk for a half hour solid and say ABSOLUTELY NOTHING.
Japanese language is not necessarily any more profound than your native language. English has some wonderful, seldom-used words that you could choose to bring back into common parlance.
The other thing is that Japanese language is not necessarily as straight forward as it seems. There are many words that do not have a one-to-one translation and many words that have more than one meaning based on the context you use them in. That cool word you borrowed to spice up your new teaching material may have other meanings, than the one you intended, or deeper meanings that you don’t quite understand.
Shu-Ha-Ri is a particular favourite of mine when it comes to borrowed terminology. On the surface, it describes the progression of learning from the novice stage (shu), where you follow an instructor’s directions over and over again without necessarily understanding why (wax on, wax off, Daniel-san); then an intermediate stage (ha) where you begin to explore what your new-found skills mean and how to apply them in practical situations; to an advanced stage (ri) where your learning becomes self-directed and you no longer require a teacher in order to evolve your skills.
Sounds simple enough in concept, right?
Okay, so let’s take a closer look at the three kanji used.
守 – Shu – means to obey, but also to protect or defend.
破 – Ha – means to rip, tear, break or destroy
離 – Ri – means to detach, separate or release
Armed with this knowledge it becomes a little tougher to reconcile each of them into the neat little definition above. To add to this, allow me to make a gross generalisation about Japanese culture compared with Western culture.
I have observed that westerners tend to have a mindset of ‘make me understand, then I will do’
In Japan there is frequently a pattern of ‘do and eventually you will understand’
The ‘do’ part may take several years before understanding arrives. Case in point, I have done kendo for around 18 years. I felt that I had a solid understanding of the basics maybe 6 years ago. Some of my peers would probably tell you I’m still not there yet.
I’m not saying that one way of thinking is right and one is wrong, or that one is better than the other, but that you should understand that these difference is there. They are part of the culture and it has a direct bearing on language and the understanding of concepts such as Shu Ha Ri
Ri may not come to you without many years of effort. It is unlikely that a several week or even several month course will take you from Shu, through Ha to Ri. Not in the most simplistic sense of the term. Got someone telling you that you can be a black-belt from scratch in six weeks? Run far, far away from that person.
As far as teachers go, I would suggest that if you are tempted to borrow from the Japanese, or another language that you don’t speak for that matter, that you spend some time studying the culture and the people and at the very least be aware that your understanding of the term may well be incomplete before you have your students start calling you sensei.
The Know Thy Enemy Paradox
in Everything
as CAST, educating management about testing, heuristics of software testing, know thy enemy paradox, Software Testing
I started this post a few times before I realised I was actually dealing with two subjects rather than one. At CAST2010 I took Fiona Charles‘ workshop on Speaking Truth to Power. It turned out that this was one of the subjects that I was writing about and hadn’t managed to articulate at all (Thanks again, Fiona).
The other subject is the situation where you know that a particular subject, product, action etc is not a good one (at least in your context), but don’t necessarily have the familiarity with it to explain why. In order to do so, you’re going to have to learn at least enough that you can speak from your own experience why such a thing is not good.
I call this the ‘know thy enemy paradox‘ – In order to explain why you shouldn’t need to know/use/do something, you need to learn enough about it so that you can coherently explain why.
It would be nice if we could simply take the advice of our learned peers or mentors. No one I respect in the testing industry is going to pan someone or something without a valid reason. If my interest does not lie in that direction, I am happy to take them at their word. As far as directing our own learning goes, this is entirely possible. It becomes another matter however when your line manager proposes that you use one of these things (say, an expensive testing tool or certification or even an inappropriate testing methodology), especially if its use is to be tied to some KPI. This is where speaking truth to power comes into play.
Let us take a hypothetical situation. Your manager tells you that the company will pay for you to go and get certified as it is something that will help you in your career (now say thank you and get out of my office). You haven’t been testing long, but you’re a keen reader of testing blogs and you’ve read on some of them that some testing certifications may not be all they’re cracked up to be. Of course, you don’t have any direct experience (positive or negative) with the particular certification proposed.
You can find online a lot of information spruiking this certification method. There are also vocal groups saying ‘no, don’t do it!’.
If you need to argue with your manager about the pros and cons of certification, then it is not going to be enough to point at online info and say ‘Read this’. It will come down to ‘pointy haired manager’s glossy whitepaper from salesguy trumps your bit of paper from the internets’. As far as your manager is concerned, it’s just stuff that some dude said. It’s not your own experience (and by extension, not your own argument).
If you find yourself in this situation there are a few things you can do. If you are being pressed for an answer, an effective response is ‘Let me get back to you on that’. This will give you time to put together the information you need to argue your case.
Take the time you need. Study the material and the alternatives (I’ll come back to this). Put it into language they understand (probably money, but this is not always the case). Have whatever facts and figures you need prepared before you present your case.
When you present, use newspaper style. Your first sentence is your conclusion. Your first paragraph is a summary of your story and anything that comes after is as much detail as is required. If you see a room of nodding dogs (I mean agreement, not falling asleep), stop selling.
There’s a danger in the ‘know thy enemy paradox’ for the more experienced tester also, as there seems to be no shortage of stupid trying to pass itself off as smart and taking the time to find out enough to refute the never-ending streams of stupid can leave you less time than you want for learning to be a better tester.
There are a few things that I have found that help. If I’m not gearing up to take them down, I only need to know enough that I can say ‘I disagree, and here’s why’. That’s probably not going to take you long (I’m talking minutes, not hours or longer).If you find yourself spending longer, ask yourself ‘Do I need to be reading this, or am I just getting off on outrage porn?’
If I need to convince someone else, I’ll look for ways to construct a cost/benefit analysis. If you can show you’d get more benefit from a preferred alternative and put that into dollar figures along with a compelling story, then your going to stand a much stronger chance of your voice being heard. If you can, speak to someone with direct experience with the subject in question. If your manager has mistaken beliefs, you may need to spend a bit of time refuting them. Maybe have those in your back pocket in case you need to pull them out.
If you are gearing up for a longer conflict well, that’s probably a topic big enough for a separate post (probably by someone with more battle scars than me).
CAST2010 was awesome
in Everything
as CAST, Software Testing, Testing
I spent the last week in Grand Rapids, Michigan, attending CAST2010 (Conference of the Association for Software Testing). It is difficult to describe the value of a conference like this. It is a collection of some of the most respected minds in software testing, of my peers and of people full of passion for the craft.
I attended an awesome workshop by Fiona Charles on ‘Speaking Truth to Power’. There were some fantastic presentations by testers from all over the globe. There were a series of lightning talks (I made one on the use of Japanese language as a learning mechanism). If that wasn’t enough, there were some excellent hallway conversations and exchange of ideas and the opportunity to meet some very talented minds. I met old friends, and many people with whom I had exchanged emails, but never met. It was all over far too soon and I am very much looking forward to the next one.
If you only attend one testing conference in 2011, I urge you in the strongest possible terms to make it CAST2011.
Here is what some other attendees had to say about CAST2010
Michael Hunter
Selena Delesie
Mark Vasco
Carsten Feilberg
Edit:
For those that want a small taste of what CAST is like, the keynote speeches are available online
What I learned from my puzzle exercise
in Software Testing
as cryptography, puzzle, Software Testing, Testing
I’d like to say thank you to everyone who participated in this little puzzle exercise and most especially to everyone who provided feedback. I hope you had fun with it. Well done again to Rushmila Islam who was the first to work out the puzzle.
I have posted .the solution at the bottom of this post. YOU HAVE BEEN WARNED.
I learned a lot more than I thought I was going to. Firstly and probably the most obviously, I learned a lot about cryptography that I didn’t previously know. Thanks to James Bach for the collection of links.
Braingle was probably the best of the bunch. Thanks also for the link to Sebi’s puzzle.
I found Jürgen Plasser‘s answer fascinating. I hadn’t encountered measuring entropy of text as a way to inform possible encryption techniques. It’s something I’d like to look into further.
It was interesting to see how close people got with their responses. Many people had several correct pieces of the puzzle, but not quite enough to solve it completely.
I think most people gave me way too much credit for the amount of crypto knowledge I’d have had as a high-school student. I didn’t have access to teh intarwebs back then, and time that I could have spent in the library was more likely to be spent playing role-playing games or painting miniatures or similar valuable life skills.
One of the things that this puzzle made abundantly clear to me was the value of information before and after it becomes known. Without the key information, it was a real puzzle. Far more so than I had originally anticipated. Having all the information at hand, the puzzle seems obvious and simple in hindsight.
It drove home for me just how difficult it is to convey the value of a tester to those who don’t understand what good testers do. Even the distinction that testers are a source of information (so is a book. so what?) doesn’t necessarily convey the effort that is involved at producing this information.
Some people went to a great deal of effort; tried some very cool things. That was the most gratifying thing for me. The answer was ultimately irrelevant. I got to see how you guys think. As testers, we are often showing others the fruits of our effort, but not the beauty of the effort itself. Having been able to do that here, at least in part, I think is pretty cool. Thank you again to everyone who shared.
SPOILER ALERT – Explanation of the cipher follows.
The message was encoded with direct character substitution with a few added extras. The message reads top-down, right to left. The first two characters provide the character offset – character 1 – character 2 = offset.
The spaces themselves mean nothing, but exist primarily for obfuscation though I did put them in diagonally in the first puzzle to give a clue to the direction of the word flow. Spaces in the actual message are represented by vowels, so in this sense, vowels do double duty in that they can represent their offset character or a space.
Data driven Selenium in JUnit via @Parameters
in Software Testing
as automated testing, junit, selenium, Software Testing, test automation
I played around a bit with iteration using JUnit today. I have some generic tests that behave differently depending on the values fed to them. I don’t want to have iteration code living alongside each test (maintenance nightmare), so I wanted to use JUnit’s @Parameters tag to pull in my test data via a Preferences file and do the iteration for me.
It took me longer than I expected to get right, mostly because static methods annoy me and trip me up a bit. (Your parameters method must be static in order for it to work).
However, get it working I did. On the off chance that it saves someone else some time, here’s how it works:
import java.io.InputStream;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Enumeration;
import java.util.Properties;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;
@RunWith(Parameterized.class)
public class paramTest
{
final static String dataFile = "/dataDriver.txt";
private String words;
public paramTest(String words)
{
this.words = words;
}
@Test
public void verifyThing() throws Exception
{
System.out.println("key: " + words);
}
@Parameters
public static Collection<Object[]> data()
{
Collection<Object[]> returnList = new ArrayList<Object []>();
InputStream dataStream = paramTest.class.getResourceAsStream(paramTest.dataFile);
Properties dataProperties = new Properties();
try{
dataProperties.load(dataStream);
} catch(Exception e)
{ System.out.println(e);}
Enumeration<?> e = dataProperties.propertyNames();
while (e.hasMoreElements())
{
returnList.add(new Object[]{dataProperties.getProperty((String) e.nextElement())});
}
System.out.println(returnList.toString());
return returnList;
}
}
Interestingly enough, the data comes back in the reverse order that it exists in the preferences file. Something to keep in mind if you want your tests to run in a certain order.