Digital Soldiers, Job interviews and Software Testing…
What have Job interviews and Software Testing got in common? In both cases, it’s a GOOD thing to find out (and find out early!) that something is wrong…
Some years ago, I lectured in Software Testing (among other things) in Maynooth University. When I was preparing to take over the Software Testing course from another – far more technically capable – Lecturer who was on a one-year Sabbatical, I spent some time researching the various perspectives and approaches that are prevalent in the field of ‘Software Testing’ because it was a relatively new Academic field for me. Incidentally, it’s a surprisingly wider & more diverse field than you might think (and, in fact, is continuously evolving as systems and development techniques evolve).
In the end, since the Undergraduates were already doing practical, code-based testing (jUnit), I decided to focus the course content on more theoretical matters, evaluating & investigating the concepts and philosophies of Testing. It might seem strange to some readers – even those ‘in the business’ – that there ARE such things as ‘philosophy’ in Software Testing, but there are, and they differ quite a bit.
You’ll be pleased to know that I won’t be going into too much detail about that stuff here 🙂
One of the main things I wanted Students to get out of the Course – other than the basic ideas that inform our disparate approaches to Testing – is the idea that Testing is often as much an Art as it is a Skill. After all, Skills tend to be practical while Art tends to be more about creativity. I believe that, in many creative scenarios, if you understand the Art and have some Skill, then the Skill becomes transferable. With only the practical skills (the ‘how’) and no understanding of the art (the ‘why’), the skills eventually become obsolete. Similarly, with no understanding of the skills, the art is impossible to make practical use of. There is both a Skill and an Art in Software Testing. There is also both a Skill and an Art in conducting – and enduring – Job Interviews
Like most Business Analysis tasks,Testing should also start with the central question: “Why are we doing this?”. There is little point in wasting valuable time testing something without knowing why it is being tested. That’s not to say every individual test needs an individual reason, but the Testing phase and the type of Tests applied must serve a purpose. Otherwise it is a waste of time.
I think Testing needs a creative mindset as well as a practical mindset but I also think this may be best served by two different people, since some of us are just better at the practical stuff while others are better at the philosophical / conceptual. Of course, it’s not always feasible to have two different people available for this purpose so it helps if Business Analysts understand testing techniques just as much as it helps if Coders & Testers understand the factors that impact most noticeably on Businesses & end-users.
A common misconception, outside the discipline, is that the whole point of Testing is to show that some System is perfect. However, most people who are involved in Testing will accept that it is never possible to prove that a System is perfect. One (obvious) reason for this is that you can never prove a negative. How would you Test for the premise that “The system will never fail without automatically rebooting”..? It’s not possible to test for something ‘never’ happening since you would have to test repeatedly & continuously into infinity to prove it.
You can, however, have the right mindset to try to figure out what might go wrong, what might cause problems, what a User might unexpectedly do and what the system should do / does do in given scenarios… all things that will help you to figure out what – and how – to Test. The purpose of Testing, at its simplest, is to show that a system is suitable and appropriate for the task(s) it is intended for. There’s no point in testing a first-person shoot-em-up like ‘Call of Duty’ for realism because it’s not intended to be realistic. Testing to see whether digital soldiers exhibit the right sort of reaction to being shot would be a pointless waste of the main (valuable) resource we can never make any more of: time.
So, what has the ‘mindset’ of Testing got to do with Job Interviews (got to the point at last!)…? Well, in both cases, it’s a good thing if you find that something is unacceptable & ‘unfixable’, find it early and move on to something else. In fact, the whole point of Testing (and, in my view, of Job Interviews) is to find out what’s wrong before it is too late and, where possible, to do something about it. This is a mindset that doesn’t come easily to everyone but it CAN be learned for Job Interviews, just as it can for Testing.
The trick is to know what to look for before & during the Interview process, what questions to ask of the Employer and what answers (e.g. test results) are acceptable / unacceptable to you. When approaching a completely new scenario or system that you are going to test, it is advisable to get some background info on the scenario or system. This helps to ensure that valuable time is not wasted testing something irrelevant or running tests that won’t show anything useful. Similarly, when it comes to job interviews, we don’t simply agree to go to interviews for unsuitable / inappropriate jobs (assuming we are offered an interview for a role to which we are not suited – which unfortunately happens surprisingly often). When we are preparing for an interview, we can do some research to pre-answer some of the common / easy questions at our leisure (e.g. who they are, what the role is, what the duties are, how much salary is paid, where they are located… and so on). This means the actual interview can be treated with the same importance as the equivalent of User Acceptance Testing, as it is used to answer the final questions of acceptability before possibly committing to a decision.
Whereas job-hunters are probably more likely to go into an interview hoping that they can pass muster and get hired, it makes far more sense to go into the interview with the idea that it is never possible to find the perfect job (it has to be evolved) and what we are actually looking for is a job (or a candidate, if we’re on the other side of the desk) that is acceptable for the tasks and scenario intended and that could perhaps be ‘evolved’ into something better. In that way, we are more likely to deliberately look for things that are ‘deal breakers’ and, if they are ‘unfixable’, we are more likely to walk away from an unsuitable scenario. In Software Testing, there comes a time when it makes sense to ‘walk away’ (i.e. to throw something away and start again) but it can take a serious amount of personal courage and conviction to do that – just as it can when you’re offered a job but you believe it’s not the right job for you. However, walking away from something that has proven to be unsuitable is, in the long term, a ‘cheaper’ option – whether in Software testing or Job hunting.
So, what sort of ‘Testing’ should be practiced in a Job interview…? Questions, questions and more questions… The interviewers are there to ask questions and so, as it happens, is the Interviewee – even if it doesn’t always feel like it. The assumption of all the people present at an interview is that each of them has some purpose in being there. Similarly, the assumption about each question asked is that there is a purpose to it. Far too often, that is not the case. Have you ever asked yourself “what’s the point of that question?”. You would hope that each question you are asked – and your subsequent answer – offers some value to you and/or the interviewer. However, this assumes a lot and is not always borne out by reality. Asking a question that offers no value in and of itself or in the answers (or further discussion) it triggers, is like Testing for something irrelevant. Why bother..? If the outcome of a test serves no purpose, test something else. If a question serves no purpose (except filling silence, maybe?), replace it with a question that has some value. Since you don’t know everything about a candidate, or a role, there are literally an unknown number of unanswered questions.
As an example, many people think that Salary is one of the biggest (if not THE biggest) deciding factors in choosing a job. However, this isn’t always the case. If one position offers a salary of 100 (currency is irrelevant for this discussion) and another offers 101, there is little difference between them. Maybe at 110 or 120 the difference becomes important but there are other things that are often equally or more important – such as commute, workplace environment, opportunities to progress… a whole host of considerations. But we can’t consider them if we don’t know and we can’t know if we don’t ask! Many of these ‘parameters’ can (and should) be found out long before an Interview. In Software Testing, a technique called ‘Boundary Testing’ allows Testers to ensure that all acceptable values are (likely to be) processed correctly while all unacceptable values (are likely to) cause an error.
When it comes to Salary, for example, there may be some negotiation required to agree on a final figure but it is safe to assume that the Salary range on offer is acceptable to both the Interviewer and the Interviewee. Otherwise, they would not be there. Going to an interview without knowing what the Salary range is (or inviting someone to interview without them being aware of the range) just means that some valuable time is used to discuss something that should have actually been a pre-selection criteria and perhaps means that some, many or all of the Interviews could turn out to be completely unnecessary. Similarly, as an interviewer, it’s probably safe to assume that the candidate meets the minimum requirements. If not, your selection process needs work. This work should not be done in an Interview. So, why do many Interviewers waste time discussing minimum requirements at an actual interview? That’s like using the time set aside for actually Testing a system to figure out what (and if) you should be Testing. Why not discuss the other things (peripheral characteristics) that distinguish individuals – and jobs, for that matter – from each other? It would be a more valuable use of everyone’s time.
Importantly, when it comes your time as a job-hunter to ask questions (y’know that bit when they ask “do you have any questions for us?” at a time when most interviewees simply can’t wait to get out of the ordeal…?), you should not only have one or two questions ready, but they should be questions that add value and that help you decide if you still actually want the job. When you’re given the opportunity to ask, don’t let it go by and don’t worry about offending the interview panel. After all, if they’re going to get pissed off by you asking “Will I have my own desk / office / secretary / butler(!?) / Private Jet (?!?)”, aren’t you better off knowing this before you accept the job?
In the same way that Software Testing can never show that a system is perfect in all cases, but only that it handles known or expected scenarios in an acceptable manner, the same can be said for job interviews (sort of…!). No job interview (or even the most rigorous selection process) can ever guarantee that the candidate finally selected is the perfect one for the job and that nothing can go wrong. We’re people, after all, in a modern & complex world. There are literally millions of things that may prevent us being the perfect candidate (or prevent the job being the perfect catalyst for our career) but the interview or selection process didn’t – or couldn’t – test (and that’s not even including all those Twitter & FaceBook posts you don’t want discovered!). However, there is no excuse for missing something in a candidate’s background (or in a role) that should be obvious or that is crucial. For example, if the role is ‘Software Tester’, does that mean JAVA & jUnit or does it mean ‘User Acceptance Testing’? These are both Testing techniques but, boy do they require different skills!
Both the Interviewer and the Interviewee should be clear about what is being asked & required (‘boundaries’ or ‘minimum acceptable criteria’) and any vague or unclear criteria should be clarified as early as possible – well before the Interview if possible – so you can ensure that the only people who end up at the Interview are people who have some value to offer each other – even if it slightly irritates a Human Resources professional or Recruitment Consultant when you say “Thanks, but no thanks” **
In the same way that Testers actively expect to find problems and should be rewarded / applauded for finding them, so too should interviewers and interviewees. Finding out before you accept a job that it is unacceptable for you seems like it should be a good thing… right?
——————-
[Incidentally, for more on that particular subject see my post “In response to all the ‘advice’ from Recruiters…” here]
