Well, it's my first time I've encoutered QA, the interview will consist of programming questions and QA questions for student Automation role(Programming automation programs that check other company's programs).

I've found some interested questions on the internet about QA, I'd love to get some help to prepare properly and in the right direction.

How would you approach this:

What tests would you write for a printer that is connected in a campus that needs to identify the user, and print the his pages only.


  • Get the id of the student

  • Get the files that were sent to the printer from the student's id

  • Request a payment card

  • Check card's balance, authenticate it..

  • Check for available paper in the printer

  • Check the print properties, and charge accordingly.

Question: This is what I've written so far, Is there some smart ways to attack these questions? For example, common questions I need to ask my self so I can provide efficient tests. Like: what are the things I need to check so the object will work, etc. Also, what other tests should I add to the one's I've written.

  • These actions which you propose testing happen on the printer rather than on a computer attached to the printer? Seems odd. Commented Aug 22, 2017 at 21:32
  • @JoeStrazzere I see. so would other tests do you propose to do sir.? Commented Aug 23, 2017 at 8:07
  • Well, what if these are the only details presented. How would you approach this with the tests? Imagine you're having an interview now. @JoeStrazzere Thanks for your time! Commented Aug 23, 2017 at 15:34
  • I would ask clarifying questions of the interviewer, before I proposed an answer. That's the same process I actually use when testing - understand the requirements first, then plan your tests. Commented Aug 23, 2017 at 15:37
  • 1
    And what sort of testing is this supposed to be? This all seems to be functional or possibly integration testing; are you also going to be doing load/stress, security, etc testing? Will any testing have been done already? What sort of scaffolding is available? You're missing a lot of basic information you need before putting a test plan together. Commented Aug 23, 2017 at 17:39

1 Answer 1


The first step is to understand the system and what it is supposed to do. Writing tests that exercise those features that are supposed to work in a way that should succeed is called Happy Path Testing. This is the bare minimum to test. if this doesn't work, either the Developer or the Tester didn't understand the requirements.

Next, think about ways the system might not work. If the printer performs a paper check and finds no paper, what happens? What if the paper sensor is broken and reports paper when there is none? What if the payment card presented has a zero balance? What if the number is valid, but inactive or expired? What if there's a power blink when the card is being charged? What about a power blink at any other time in the process? These are examples of negative tests that a robust system could be reasonably expected to handle. These may not be part of the functional requirement, but a robust system should deal with them gracefully.

Then there are the implicit requirements. The system should be dead-easy to use, even by a tired student. It should have rock-solid accounting practices, not making a single penny in error. It should complete its tasks in a reasonable amount of time, with 'reasonable' defined by current human expectation. If the time between debiting the charge card and the start of the print job is 30 minutes instead of 30 seconds, the functional requirement is met, but the implicit performance requirement may not be.

There are many other things to test. What your interviewer is looking for is not the specific list I provided here, they are looking for your creativity in identifying possible holes in the system and how to exercise and exploit those.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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