Let me give you some friendly advice to help you become the power tester you want to be. I’ll get the boot camp drill sergeant stuff out of the way first.

If you’re anything like the vast majority of new testers I’ve encountered, you’re full of questions. Probably a lot of questions that start with ‘what’s the best way to…‘ or ‘what is the best practice for…‘

Take that combination of words and remove it from your vocab. When I see questions like this, I cannot help but think that the person who asked it is incapable of free thought. That may not be the case, but those questions translate in my head as ‘Please spoonfeed me an answer so I don’t have to think. Please just tell me what to do. Give me a recipe that I can apply wholesale without consideration of any other factors whatsoever’.

Sounds fucking stupid, doesn’t it? Yes it does. Because it is.

Imagine if someone asked you ‘What’s the best way for solving conflict in the Middle East?’ That’s basically what’s happening. Hey, let me ask you for a simple answer to an incredibly complex question without giving you any context whatsoever as to how it applies to me.

Same thing goes for asking about pre-written test cases, answers to interview questions, what the best testing tool is. That’s sheer laziness. Don’t do it. You’ll see lots of other people doing it. Lots. If you do the same thing as everyone else, then you’re no different from anyone else. You’re a commodity and ultimately expendible.

Want to know how to distinguish yourself from the hordes of zombie testers out there? Don’t do what they do. Don’t be like them. If you want to be just another minimum-wage meatbot then fine, just find a different career.

If you want to be good at testing – hell, if you want to be even a competent tester, critical thinking is a skill you’re going to need to practice. I realize that might come as a shock if you thought testing is about following test cases (that’s not really testing btw, but that’s a discussion for another time). The habits you learned in grade school – memorization and subsequent regurgitation of the right answers – that’s not thinking. That stuff doesn’t work for testing.

Testing isn’t about pass or fail. It isn’t about getting the correct answer and turning it in to the teacher for a pat on the head. Testing is about asking questions about software and its artefacts and its people to find out information for the people that matter. It’s about maintaining your sense of uncertainty when everyone else is losing theirs. It’s about exploring issues of risk and the tradeoffs you make between making something better and the cost involved in doing so. It’s about seeing what’s in the gaps. What do people say they want? What do they actually want? What do they say they did? What did they actually do? What does this component connect to? What does it not connect to that it should (or vice versa) – are these the sorts of questions you ask when you test?

How do you know that a bug is a bug? (You might like to read up on oracles) How do you convince other people that a bug is a bug in a way that is tactful and persuasive? (You might like to read up on bug advocacy)

What else can you do to become an awesome tester? Want to know how other awesome testers do their testing? Do testing with them. Have you heard about Weekend Testing? (Yeah there are people who use their spare time to get better at testing, how crazy is that?) Even if you don’t decide to test with them, you can read the transcripts of the testing they did and their testing notes. You can learn from people of all sorts of experience levels.

There is no shortage of excellent testing blogs out there. There are ten times as many that are garbage, but if you’re here, then that’s a start. Any of the links in my blog roll and any of the links in theirs should have more than enough material to keep a new tester’s brain occupied for a very long time indeed.

Still reading? Well, if you haven’t been scared off yet then you might actually be serious about becoming a good tester. Read this stuff. Practice this stuff. Find anyone that knows software testing and learn from them – by which I mean question them. Don’t take anything that anyone tells you as gospel truth. Examine it. Turn it over. Poke holes in it. Good testers welcome challenge and criticism. It’s what helps them become better testers.

There are testers out there that will coach you. They’re good at it too. Contact them. Ask for their help, but understand that the onus is on you to do the hard work.

Becoming a skilled tester isn’t an easy path, but it is a very rewarding one. In the time I’ve been a tester, I’ve met amazing people from around the world and formed a network of peers I can go to when I have questions. I love the work that I do and I get to work with some amazing minds. I wouldn’t have had any of these opportunities had I not made the choice to make myself the best tester I could be.

If you’re a new tester and you want to be a good tester, then you have work to do. Best get to it.

If you’re keen to attend, then pricing details are here and you can sign up here. If you make it, be sure to say hi.

To me, effective test reporting is the glue that holds it all together. If you can’t (or don’t) report your findings effectively, in a way that your audience finds useful, then your testing is not effective.

It occurs to me that test reporting seems to fit within two categories. I call them Pull reporting and Push reporting.

Pull Reporting is where your audience comes to you for information. Generally they have questions that they want an answer to, such as ‘When will you be finished testing?’, ‘How stable is Product X?’, ‘Did you find any bugs in interface Y?’ and so on.

Setting aside for the moment the quality of these questions, let’s talk a bit about the sort of situations in which pull testing arises. Stand-up meetings, drive-by situation reports, weekly meetings are all examples of pull reporting. In each case you have an audience that (at least to some degree) has context in mind and is requesting specific information. In my experience it’s the drive-by sit-rep that can be the most challenging, often because I’m in the middle of working on something else and I need to context-switch in order to answer. I don’t know about you, but it takes me time to switch out of something I’m deeply focused on in order to answer something unrelated.

In this situation, there are a few things you can employ to buy yourself some time.

• Remember to breathe. If nothing else, oxygen is good for your brain and taking a deep breath gives you a few more seconds to switch over and consider the question posed.
• Ask your audience to repeat the question. If you were in the middle of something else, it’s possible you heard something akin to Charlie Brown’s teacher rather than a question. Ask them to repeat it.
• If you don’t feel like you can effectively answer the question right this second, ask for time. The question might seem urgent, but it’s rare that the situation is so mission critical that you can’t say ‘Give me 5 minutes, I’ll come to your desk (or call you back etc) with what you’re after.
• If you are ready to answer, go ahead and answer. If you are speculating about something, make sure that you identify that you are speculating. ‘I know x, y and z. It may be that a & b, but I’m not sure’
• Poll them to see if you have given them the info they’re after. It shows them you actually care about what they’re asking and it gives you immediate feedback as to whether your report was effective.

The drive-by report is also a great opportunity for an ambush. Knowing that someone is focused elsewhere and will need to context switch – that’s a great time to go on the offensive if you immediately want someone on the back foot. It’s a dick move, but it works. Hopefully you’re not on the receiving end, but should it happen, then remember that not all questions need to be answered. Beware ‘why’ – especially when it’s accompanied by a pronoun as the third word (why did you… why didn’t you… why aren’t you etc). You may find it more constructive to turn those sorts of why questions into ‘what’ questions. ‘What has happened that is concerning you?’ Answer that, and then you can decide whether the why is worth answering. Suggesting a different venue and time for the discussion is probably also a good idea also.

If you do find yourself in a position where you can reel off a report on request, you might like to consider using Michael Kelly’s MCOASTER heuristic. It’s a handy list of items that your audience may be interested in. You don’t have to report on every single item. Pick the ones you think your audience wants to know about (and check in after to see if they want more).

Push reporting is the opposite in terms of who has context in mind. Push reporting is when you have information that you believe your audience should know, but they are not aware of it. In order to effectively convey the information you have, you need to understand what is important to them, what they know already and how to frame your information in such a way that it is easily digestible and meaningful to your audience.

Examples of Push reporting are Bug reports, Reporting showstoppers or mission-critical issues, Risk reporting. Time is generally on your side (though not always). Take the time to make sure that your audience is properly framed. Brief them on your subject matter before you launch into your report. Even if you have an appointment with an agenda for your report, you can’t assume your audience will immediately be ready to hear what you have to say.

Push reporting is where your ability to tell a compelling testing story comes to the fore. Our job is to present meaningful information to people that matter. If all I do is present that information, then I really feel that I’m not living up to my potential as a tester. I would rather present that information in such a way that it presents a compelling call to action.

In my presentation at CAST I used an example from the movie Hunt for Red October. In this clip, the sonar operator aboard the USS Dallas (Jonsey) presents information to the captain about what he has discovered.

The Hunt for Red October: Jonsey Reports

Keep in mind that the raw information that Jonsey has is

• He knows he has heard a submarine that they don’t have previous records of.
• He lost the sub but picked up a sound the computer tells him his magma displacement
• He has done some testing and believes the sound is man made.
• He has picked up the sound on three separate occasions.

That’s it. That’s the raw info he had. Everything else he presented to the captain he has put together from what he thinks that information probably means.

He could have just presented that information alone. If he had, it’s possible that the captain would have extrapolated the rest. They tend not to put morons at the helm of nuclear powered, nuclear armed naval vessels. Still, if this is all the captain gets, then the onus is on him to do the legwork. What Jonsey has done is taken raw information and put it into a format that greatly helps the captain see the significance of the information. The only thing left for the captain to do is to decide whether he buys Jonsey’s version of events and then act accordingly.

This is about as close to the perfect push report as you’re likely to see. It may be that your own push reports aren’t as high-stakes as hunting a rogue Russian sub, but the principle remains. If you have information that your audience needs to hear, take the time to put it into a format that helps them see the significance of that information.

Ask yourself what you want from revealing your information. Do you think certain action should be taken? How does your information support taking that action? Do you want to highlight risks associated with your information? What are some credible issues that could arise as a result? How does your information support that? It may be that you have information that you simply wish to relay in case it is useful. Nothing wrong with that, but think about the information you are presenting and whether or not there is more to it than what you have.

Remember also that however compelling your case, the final decision is unlikely to be yours. Suggest a recommended course of action. Don’t demand. There may be other factors that you are not aware of that have some bearing on the situation. It’s your job to find and present the information. Let them take responsibility for what happens next. That’s why they get paid the big bucks.

Elicit feedback. Just as with pull reporting, you want to find out whether the information you gave was useful. If not, why not? You can take the response you get and feed his back into your testing.

I think that the distinction betwen pull and push reporting is a useful one. It provides me a framework to think about how to report and what to include. I’m curious to hear your thoughts or how you think about test reporting.

It turns out that the disk my VPS was hosted on crashed irrecoverably. Of course, it took my provider 5 days to get back to me with an explanation as to why my site was down. They eventually did give me an explanation, but not before I got sick of my requests for information going unanswered and transferred my site to a new host. I think there is money to be made in seeking out stocks of companies that have awesome customer service and buying that. I have yet to test whether the opposite is true, but if a company has shitty customer service, I just don’t have the patience to deal with it anymore. Moral of this story is – VPSland has shitty customer service, so they get no more of my money. Linode comes highly recommended by people I trust, so I have big expectations of them. Time will tell.

The site is not the only change in my life of late. I went back to Australia last month for final selections for the Australian national kendo team. Unfortunately I was not successful, so I won’t be going to Milan next year to compete. A pity really, I would have loved to have gone. It’s ironic that I came to Japan to do more kendo training, but if anything have ended up doing less over the last 3 years than if I’d stayed in Melbourne. I made a conscious decision to try and strike a better balance between my home life, my work and my passion for kendo. I did that, but it meant that I was not as sharp as I needed to be at selections. I didn’t fight badly, just not well enough. As it stands, I’ve made the Australian team twice. I would have loved to have gone a third time, but it is not to be. Other things in my life are calling. I will not be part of the squad for subsequent campaigns. I thought I’d be more upset about it than I am, but when it’s time, it’s time.

I’m looking forward to spending more time with friends and family. I’m looking forward to spending more time on my Japanese (which is still awful, for the amount of time I’ve spent in the country). I’m looking forward to being more active in the testing community. I’ll still be swinging sticks at people, but I no longer have to drive myself into the ground in order to get ready for competition.  It actually feels pretty good.

BK: I wasn’t sure about entering the testing competition. It looked like a bit of fun, but it was going to take up an entire evening of a 2 day conference. It’s difficult enough to catch up with all the people you want to see without taking up a bunch more time. I noticed that quite a few of the testers I wanted to talk to were also entering though and moreover, I’d not had the chance to test with Louise Perold before and this was a perfect opportunity.

LP: I was at CAST in 2007 in Seattle and entered the tester competition there as an individual. I had a lot of fun the first time, so I was quite keen on taking part again. It is a challenge though when you have been concentrating all day and your head is pretty full and then you have 4 hours that you know you are going to give some serious attention. So much of my job now is attending meetings and I get so little time to test anymore, that I definitely wanted to just break something again. The opportunity to do this with my good friend Ben, was something I could not pass up.

BK: The testing challenge was simple to explain; Install some software created by Dave Gilbert (who was attending the conference and on hand for the competition), then test said software for bugs, submit bug reports and tie things up with a test report at the end. Not so easy in practice, as it turned out. We faced a couple of challenges immediately. I have a thumb drive with testing tools I like to use – only I’d left it in Japan. The other challenge was that both Lou and I had left the power supply for our laptops back at the hotel. I left Lou to download the tool while I raced back to the hotel to pick up said power supplies.

BK: I got back to discover that the low bandwidth of the conference centre was causing problems with the download. We sourced a USB key that was floating around with the app on it and installed from there. It was here I discovered my first bug. Upon launch, the app crashed – didn’t handle non-US date format. Lou and I decided we should go talk to Dave and let him know this would probably affect other users with non-US settings. We also decided to interview him about the product.

BK: Having David at our table made life a lot easier. Being able to test and chat simultaneously with the guy who wrote what you’re testing is really the only way to fly (okay not the only way, but it works well for me). When you have built up a relationship with someone and see what makes them tick, you open up a much wider range of possible communication styles. You can always ask direct questions, but you can also make jokes, you also put a face (or faces) to the bug reports you send in. If something comes across as harsh in print, they may give you the benefit of the doubt if they have other references that show you’re not arbitrarily being a bastard.

Lou and I settled into testing our respective areas, logging bugs, consulting with one another about bug reproduction and logging. 4 hours is actually a really really short amount of time, especially since the app we were testing on was non-trivial. We chatted with Dave as well, not just talking shop, but also music and life in general, following where the conversation naturally went. It was good fun. Some of the bugs we found were cool and difficult to reproduce. The bug reporting mechanism itself left something to be desired, but we rolled with it. I went with a chartered exploratory testing style and here was where I made my first real error.

I took notes in a file as I do with most chartered ET that I do. What I didn’t do was take the time to make my mission explicit. I knew I was doing recon ET in order to find bugs related to handling of varying file types and extensions, but that may not have been clear to anyone trying to debrief me (or judge against my notes). The notes themselves were okay and gave a reasonably good indication as to what I was thinking, but I could have taken a few minutes and made them a lot better.

LP: I had wanted to use Rapid Reporter, and then couldn’t get it downloaded quickly so then decided just to use notepad. I realised once again how much of a skill taking good notes is. If it is not something that you continually practice, it is really easy to get out of the habit and miss things in your notes. I guess also, when you are trying to log bugs quickly (the first team to log an issue would get the credit for the bug), I felt pressure to focus on finding things and getting them logged. I should have also realised (as in real life) how important it is to recall and explain what you have and haven’t covered and exactly how you got to certain issues, why you focused in certain places.

BK: James Bach wandered by and asked about our test strategy. I thought our answer was a reasonably good one (more or less what I just outlined above). Since Dave was simultaneously the developer and product owner, we talked to him about where we could add the most value from his point of view, divided the work between us, got ourselves into a position where we could easily exchange information and got to it.

LP: I didn’t feel like I was able to give enough detail around the specifics of what I had been covering. Maybe because I had encountered a number of crashes that were not always quick to reproduce. Maybe because my notes were really bad. So I felt I was able to talk to our bigger plan, but not really exactly how we were implementing it or where we were in that implementation.

BK: When James wandered back again asking about the test report, it occurred to me we should have gone to him earlier and asked him what he wanted to see. No time like the present though, so we asked him there. Having gained what we thought was a good understanding of what the report should contain, I went about putting it together while Lou kept testing. In hindsight, we should have been building the test report as we went. No sooner had we started putting the test report together, we discovered we had about a half of a testing mission. Okay the competition was a little bit arbitrary and the mission was about finding and reporting bugs, but I was hard pressed to clearly define the specific mission that we had. We knew that we had a hard 4 hour limit, but that was the only stopping heuristic we had. If we’d started our report earlier, it might have occurred to us that there were other factors to consider when answering ‘When will you stop testing?’.

Because the bug logging mechanism essentially made the logged bugs invisible, backtracking to find the important bugs we logged took a lot of time. If we’d logged these in the test report as we went, it would have meant we had more time for other things. As it turned out, we barely had enough time to turn in the report as it was. Even when we did turn in the report it was missing a few things. We described the areas that we tested, but not a whole lot about the actual testing we did. We didn’t really have a clear statement of our overall mission (for reasons already explained). We listed the important bugs we found, both crash bugs and bugs we considered important to look at. We also listed the areas that we hadn’t covered.

We listed our conclusion up-front. I know that some people like to skim, so having the tl;dr (too long; didn’t read) stuff at the start would at least get the point across, with the larger details to follow. We also provided our testing notes – this was both a good thing and a bad thing.

LP: I also realised afterwards that we hadn’t really explained the subtleties of our mission and context. The fact that we were in a “competition” meant certain things – that we would focus on logging bugs as quickly as possible so that we could be credited has a impact on the way you test (and probably also the way you log the bugs). My notes when I looked back on them were just bad. I don’t think we should have included them. Even the mindmap – which I normally use to outline my strategy, was seriously lacking detail. I think again I learned that for me to really focus a lot better and do a better testing job, I should just spend a bit of extra time and energy on defining and outlining my strategy and then showing where I am on and off track of that. I also know that my bug logging was generally not very good.

Looking back at it now, it probably would have been a good idea to have a mini low tech dashboard, where we could have tracked exactly where we were against the chosen functional focus areas.

BK: A mini-dashboard, yeah nice one. Would have been really handy and really easy to do too.

Lou and I left the venue kinda down about our efforts. On the walk back to the hotel, we chatted about what else we could have done. I think about every second sentence started with ‘Ah shit, you know what else we could have done?’. We kinda figured that if there was a prize for tester/programmer relations we might be in the running. We assumed that there were a bunch of other teams well ahead of us for the overall prize.

BK: We’d like to send a big thank you to Dave Gilbert for putting his app up for testing and for being the focal point for a large number of testers, man I didn’t envy him that at all. Thanks also to James for putting up the cash (literally) from his own wallet as the prize. Thanks to everyone who had to wade through the list of bugs and test reports that all of the teams turned in. That wouldn’t have been a small task. The competition was a lot of fun.

LP: Ditto from me Dave was really an awesome developer to work with and test for.

BK: I have some suggestions for the CAST2012 competition (or really for anyone that wants to run one of these at a conference)

• Consider a competition that runs for the duration of the conference
  LP: Actually I kind of liked the 4 hour competition because I feel like it adds a unique pressure that makes for an excellent learning experience
  A longer comp has its pros and cons, but it allows different dynamics and I reckon it’d better mimic everyday testing situations.
  • Testers can split their time between attending sessions and doing actual testing – they might even put into practice something they’ve just learned.
  • Competition staff (developers, project manager, product owner etc) can selectively be on or off duty (just like in real life) – they may also not be so easy to find – also like in real life.
  • Given that testers are now likely to mob competition staff in order to max out the tester/programmer (or other) relationship thing, it allows said programmer (or other) to escape the love fest if it all becomes a bit much.
• Use a decent bug tracker.
  LP:I second this one.
  • Something simple like Mantis or Redmine would do the job. Set up separate projects for each testing team, or set up single users for each team so that it’s easier to keep track of who has done what
  • Said projects could be made invisible for non-members of that team (but team members would be able to check against each others’ work to avoid bug duplication)
• Don’t worry so much about the cash. It’s a nice little motivator to be sure and yet it’s probably less important than the fact you’re up against some of the more talented testers on the planet

For those that are planning to enter next year’s competition, here are some suggestions:

• Be prepared
  • Have your toolkit ready to go. You might be testing against a specific OS, a web app, mobile app, more than one of these or something different again.
  • Practice – If you’re not at the testing coalface every day, spend some time shaking the rust off your test-jutsu. Not just execution of testing, but information recon and reporting also.
• Talk to people
  • Find out who matters, and build a relationship with these people.
  • Find out what matters to them
  • Buying them beer probably doesn’t hurt.
• Use what you know to direct your testing
• Keep your feedback loops short (short being relative)
• Don’t overthink it. Plunge in and quit. Get some, go again – however you want to think about it, make sure you’re also doing it.
• It’s not going to be perfect. It doesn’t have to be. It just has to be useful (to someone that matters)

What I love about CAST is that there is a very collegial feel to the event. It feels like a safe place to air new thoughts and ideas (or old ones) and discuss them – even have them shot down, in an environment that promotes and supports learning and cooperation.

There were a number of firsts for me personally. I hadn’t presented at CAST before. My presentation went well, I thought. I had a much fuller room than I was expecting. People seemed to find it interesting and useful and there were a lot of good questions asked. It wasn’t perfect. The room’s air con was LOUD, so the set of speakers I brought to play a snippet of video were woefully inadequate. Along the same lines, I wasn’t using the mic to speak and a few people let me know I could have projected a little more. Strange. I don’t have a problem projecting in the dojo. Probably because I’m barking instructions at people. Presenting to a room of testers is a little different it seems. Something for me to work on, then.

Louise Perold and I entered the CAST testing competition – a 4 hour event to test the abilities and skills of the testers that entered. Louise and I walked back to the hotel lamenting what else we could have done if we’d just had a little longer. We had some awesome competition. People that I know by reputation if not personally and all of them excellent testers. When on the following day James Bach announced we’d won the award for best tester/programmer relations we were happy. That was something we thought we had done well. When he went on to tell us we’d won the overall competition, we were stunned and delighted in equal parts. Louise and I will blog more about this at some point soon.

Lastly, I got chatting to Michael Bolton about my thoughts on test framing and how I thought it related to audience framing (I have another post coming on this topic too). He invited me to present my point of view at his tutorial on Test Framing, which I did. I was grateful for the opportunity and a number of people said they got something out of it, so that was something else I was happy about.

The thing I love most about CAST is the interaction between people. Because I’m somewhat geographically challenged, I get to one testing conference per year. I choose CAST because of the people who attend. Because they challenge me and make me think and remind me of the power of diversity and having skilled, free-thinking people working together.

I was super happy to spend time with the Usual Suspects (the people I generally hang out with at CAST) – Henrik Andersson, Chris Blain, Tim Coulter, Carsten Feilberg, Johan Jonasson, and Lou Perold. I also met and got to know a bunch of other cool people (most of them Swedes – it was a real invasion on their part) Robert Bergqvist, Maria Kedomo, Mattius Gustavsson, Sigge Birgisson.

As always seems to happen, there were a great number of people I would love to have spent more time with. I met in person a number of people I’d only previously interacted with online. There are a number of people that I’d met before, but haven’t spent nearly as much time chatting to as I’d like and a few I wanted to meet, but didn’t get to. If I try and name everyone, I will undoubtedly forget someone. Suffice it to say there were a massive number of testers I’d have loved to spend more time with. I suspect that number will only be bigger this time next year.

I didn’t get to see all of the presentations I wanted to see. Some of them were captured on video (the emerging topics tracks and lightning talks among them, I believe). I plan on taking my camera next year to capture stuff I can’t make it to. If you didn’t make it to cast, I highly recommend you check them out.

The organizers are to be commended. Jon and James Bach were the most conspicuous of the organizers, but Paul Holland and his crew of facilitators and all the volunteers who ran around doing stuff behind the scenes are to be commended on a job well done. Volunteers are the unsung heroes of events like this. When things go well, you tend not to notice them. Without them though, this event would be near impossible.

There are a few improvements that could be made. I’d like to echo some of Michael Hunter’s sentiments. A lot of people are okay with a high-carb diet. I’m not one of them.

The distance between hotels made meeting people who weren’t at my hotel kinda difficult (though we managed to find pubs here and there that did the job).

As far as content goes, I got new ideas from the vast majority of the talks I attended. I must admit to being a little disappointed by the debate between James Bach and Doug Hoffman. I was hoping the format would be more of a formal debate arguing for and against a specific statement, but it turned out to be more of an argument/discussion with the interjections and interplay that tend to go hand-in-hand. I also thought Doug was more gentle with James than he deserved. I think this sort of event has potential. I’d like to see a change to a formal debating format, but having a relevant topic debated by some heavyweights in the industry would be very interesting.

I could create a list of questions and great quotes as Michael Hunter has done, but I think those people tweeting to the #CAST2011 hashtag took care of that most effectively (try searching on it). I’m glad they did, because I barely had time to tweet a thing for the whole event.

I’m hoping very much that I’ll be able to attend (and perhaps even present) at next year’s CAST, but that depends on a number of variables that are somewhat beyond my control. If you are considering attending next year, I recommend that you do in the strongest terms possible.

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 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.

It’s taken me longer than I thought to come up to speed. I’ve been scraping the rust off my unix-fu and with unfettered access to the codebase and the command line, I feel like a long-lost missing limb has been reattached. Between that and the whole ‘learning new stuff’ thing, I’ve not had much time for anything else. There seems to be light at the end of the tunnel though. I’m grokking more of the code base and starting to make some useful code contributions.

One of the things that I’m trying to do at the moment is put a little bit of structure in the way that the business group and the development group communicate. Right now there is lots and lots of communication, which is great. The confusion comes in where the lines blur between the business telling dev what they want and going to the extent of speccing out everything in such minute detail that there’s not much design work left to be done by the dev group. That might not really sound like a problem to some, but in practice I’ve found that it can make the dev guys feel micromanaged or like their opinion is not required/valued – especially when design-level decisions are architecturally difficult to implement. If non-tech design reaches too far and gets it wrong, it can mean wasted time and effort either for them when the developer rejects it, or for both if the developer codes it in order to prove the point. The thing I love about my current place is that there are no passengers, and this stuff tends to get worked out, but I think I can do more.

This is where I am hoping that Cucumber will help out. If I can put together a series of tests that step out the current behaviour with a DSL that both the business side and tech side can build their communication around, then I suspect we will find it a little easier to step through the desired behaviour in enough detail to be clear about functionality while leaving the dev guys to work out the implementation. It’s not the only reason I want to use Cucumber, but I do have high hopes in this area. It probably won’t hurt that people will be able to see this stuff turn into checks that can be executed automatically. The key is still in the communication. I’m looking to make the clarity of that communication easier.

Cucumber is new tech to me as well. Conceptually I get it, but it’s different when you start to get your hands dirty. After a lot of reading, I decided to go with Cucumber, Capybara and at this stage, I think a combination of Selenium and TestUnit (Ruby’s in-built unit testing framework). I’m a Capybara noob as well, so I’m up to my elbows in new stuff and loving it. Mostly. Sorta. Apart from the frustrating bits.

Almost the entirety of the literature I’ve found on this setup is for BDD – which is to be expected, given that’s what its for. All of the setup and how-to stuff is for building stuff that doesn’t exist yet. Great if you’re building from scratch, but not super helpful if you have an existing code base you want to fit tests to.

I had an utter bastard of a time getting Cucumber and Capybara to work at all. Granted that it’s probably because I’m working with code that does a few unusual things, but I didn’t expect quite as much screwing around as I had to do – so, I’m going to detail it here in case there are any other poor bastards out there who are trying something similar. Hopefully this will save you some frustration.

My setup is (as of writing) Ubuntu 10.4, using rails 2. I already have selenium installed, and the installation of that is not arduous, so I’m going to omit that part.

I installed the following gems:

libxml2 libxml2-dev libxslt1-dev
gherkin cucumber cucumber-rails nokogiri capybara database-cleaner

I’ve listed some that should be pulled in automatically by other gems’ dependencies. For instance, gherkin should be installed when installing cucumber, but for some reason I had to do it manually. YMMV.

After installing the requisite gems, it should be a simple matter of generating all of the cucumber goodness from the root of your rails project

(ruby) script/generate cucumber –capybara
(you can add other options if you want to have them built in)

If all your bits and pieces are installed correctly, you should see a bunch of files and directories get created.

Here are some things that tripped me up:
I thought I might do some work with rspec as well, so I pulled those down. If you’re thinking along the same lines, then Cucumber seems to barf if you install anything beyond rspec 1.3.3
I also had to mess around with the dependencies for the json gem in my project as cucumber seems quite particular about wanting 1.4.6

By default, cucumber will clean the database after each run (as is generally considered good automation practice). In my case however, I have enough stuff in the db that it doesn’t make sense right now to load from scratch or mock the bits I need. Maybe down the track but for the moment I’ve just switched this off in the environment file (more on this shortly).

Anyway, moving on. From root, there should now be a features directory. edit features/support/env.rb
You can either make your settings changes in here, or in another file and require it from here. This file is automatically generated, so if you plan on making a lot of changes here or you think you’ll have cause to regenerate this file, the latter might be a better option.

Here are the changes I put in

Capybara.default_selector = :css
Capybara.run_server = false
Capybara.app_host = <url of my testing area>
Capybara.javascript_driver = :selenium

One of the things that really screwed me around was not realising that Cucumber starts its own webserver and runs on that. I tried pointing it at the server instance that Rails kicks off, only to find that things were falling over and there was nothing in my logs to tell me why. I felt like a complete moron once I did find out, but then again, the docco in this area appears to be awfully light so I don’t feel too bad. Anyway – be warned. If you don’t want Cucumber to use its own webserver, you need to tell it so explicitly.

As I said, there’s bugger all out there right now on retrofitting scripts for an existing code base. It sounds like it’d be easy, right? The code and functionality is already there, so skip the red/green/refactor bit and go straight to green, right? Not really.

Rather than conceptually pre-fabricating your functionality, you get to look through your existing functionality, decide what is most important to test, work out where you need to retroactively install test hooks and build use cases that serve a business purpose, while not getting lost down a rabbit hole around functionality that currently exists, but perhaps doesn’t work quite how it should. Yay! Given that there is the potential for test to ‘just light up green’ when you write them, I’ve also found it a good idea to write checks that fail so you know they’re actually doing something, then correcting them – it sort of keeps the spirit of BDD/TDD even if you’re not driving any development just at this point.

Retrofitting Cucumber tests to your site is not as simple as it might sound. I am hopeful that it will be rewarding. It’s a little too early to tell just yet, but the signs are positive. If there’s any interest, I may follow up with a post about some more of the specifics of the actual hands-on retrofitting bit. If you have questions, fire away.

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.