2

I have an interview coming up soon a software engineer in test role, I've worked as a dev/support/QA and though technically skilled, I've had little chance to code in my current role, only outside work. I'm concerned about this upcoming interview as its very different in style to anything I've come across and was looking for advice.

Apparently they give me a brief/scenario, I work on my own for a bit then present a test plan to them. Of key importance is what I'm going to automate and why.

I've never faced this kind of scenario -> test plan style, has anyone faced this before and could anyone recommend resources to see something like they might produce? Obviously it may be completely different but I feel it'd give me more confidence knowing what is around the corner

3

I've done it and basically I find these sorts of interviews come down to two main points.

  1. How well do you understand Test Plans, Strategies and documentation? Can you break down a project so that it communicates what you intend to do in a document that is handed to either someone outside your group or someone unfamiliar with your task.
  2. Can you communicate within a document to your manager, colleague or outside person what your steps are? Can this be handed off to someone else to handle, in your absence or when you add people to a project, for them to know what to do.

Most of these sort of scenarios are about showing your process, your methods and how you test. In many ways it doesn't matter what the actual details are, unless a company really gets that precise but in an interview I have seen that rarely, it's about what you know and how you apply it that is really being checked here. Presentation also is checked here, how you communicate on a person-to-person level and how you handle questions.

  • Hi MichaelF, thank you very much for your response. Could you tell me a bit about the brief/scenarios you faced, was it a simple system i.e. a holiday system or a random object, say a toaster? From what you've said I think I should be fine. When you mention breaking down a project, do you normally do this by features/components or by how you're going to test i.e. performance testing certain areas, automating certain areas, manually testing certain areas etc? Thank you again for your response – shicky Dec 4 '14 at 11:14
  • @shicky I've done the toaster thing, I have also asked the toaster, and I have been given a project I needed to create plans for at home and present during the interview. Don't worry so much about what I or others may do, work with what YOU know because you need to explain how you did it or would do it. Think of it as an example where you have the perfect set up to plan or test as you see fit, and speak to that. – MichaelF Dec 4 '14 at 12:52
  • Hi MichaelF, thanks again for the response. I understand what you're saying but presumably if you asked the toaster question or were given a project for people to write a test plan overnight, you were looking for certain things. Someone could easily rhyme off a number of things they would do or ask certain question, but if its completely in the wrong ballpark or rubbish, then I'm sure you weren't interested in the candidate. I'm interested in a 'good' way to break things down, I'm not sure I would know how to do this currently – shicky Dec 4 '14 at 14:20
  • @shicky Certainly someone could do that, but if they can do it and back it up with examples and a rational method, then its fine. If its rubbish, its rubbish that is hard to defend. I don't know about good, but if you are not clear on how to break out projects I'd suggest reading up on how to generate functional, regression and other types of tests that is far too expansive to go into an answer here. Remember its about explaining how YOU do it and being able to show/explain your method and process that's what these are really about. – MichaelF Dec 4 '14 at 16:14
  • Thank you Michael, I appreciate you taking the time to write your original answer as well as the follow-ups. You're certainly correct and I think I'll follow my usual method of breaking things up into testing 'types' as it were, for example security, usability etc – shicky Dec 4 '14 at 17:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.