Tests for a printer this is connected in a campus and need to identify the student using it to print his pages

Question

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.

Tests:

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

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.