“How do you test a vacuum?” Interview question

Question

I have a question regarding an interview question that was asked to me recently. How are you suppose to answer if someone ask you “How do you test a vacuum”? Seems like too vague like there is so many ways to test a vacuum. How does the interview expect me to answer this question? Like what type of test methodologies I will use to test it?

Answer 1

Such open-ended questions are trying to uncover if you have real-life experience tracking down misunderstanding and unsaid assumptions (which are always the source of the biggest problems in QA), if you have experience of quickly learning about new problem area.

They are not concerned about right and wrong answers. If interviewer has a preconceived "right" answer: run!

So, to answer this question, don't start talking about what you think they mean by "testing vacuum", but ask probing questions to learn more:

• How is vacuum defined (empty space vs appliance vs outer space vs vacuum tube vs ...)?
• What are unsaid assumptions? What else I need to know?
• What are the requirements for vacuum?
• What are the goals/intended use? Who is the audience: users? production line?
• What process needs to be tested? Are they defined, or they need to be established and/or adjusted?
• What metrics we use to evaluate success/progress?
• What are corner/edge cases of definition? Lifecycle? Special unusual use cases?

Then, adjust answer accordingly to what you just learned. Use some related previous experience to illustrate how you solved any similar problem in the past.

They do not expect you to solve on the spot the technical problems they have and spend months and years trying to solve. They are interested to find out how you think, learn, solve problems and communicate with peers, especially under a pressure.

Answer 2

Whenever I get the "how do you test x' questions I fall back to the tried and true:

• How should it initially appear - smoke test
• How should it work - happy path
• How should it fail - sad paths. This is usually most of the response to the interview question
• How should optional components work correctly - happy optional path
• How should optional components fail - sad optional paths

I also think about what I should do in terms of the traditional agile testing quadrants, at least those that apply and so I would consider things like:

• Unit tests - Does the vacuum suck correctly ? Does each wheel work well ?
• Integrated tests - Do the power plant, suction model and collection bag work together ?
• User Acceptance - Does it clean sufficiently ? Is the handle suitable for pushing and pulling ?
• Performance - Is the noise level acceptable? Does it get too hot ? Is the power cable safe ?

Once this is done I've identified tests to start with.

Next I would look at the test pyramid to help guide me about how many I should be writing in each area

                       manual tests
                 a few automated UI tests
               quite a few integrated tests
             lots and lots of very fast unit tests

Answer 3

I disagree with other answers.

There is a joke

A code tester walks into a bar. Orders a beer. Orders ten beers. Orders 2.15 billion beers. Orders -1 beers. Orders a nothing. Orders a cat. Tries to leave without paying.

Basically, tester's main job is to break things. It is job of coming up with edge cases that no one came up with before. Anyone can tell you how to test a vacuum's happy-path. Just put some dirt on a carpet and vacuum it up.

So this question is all about figuring out if you can come up with "weird" edge cases, that people normally don't think of.

On top of my head:

• What happens when plug is pulled when it is running?
• What happens when it is dropped from first floor while running?
• What happens when you suck up bucket of water?

It is exercise in brainstorming all kinds of crazy things that people can do with their vacuum.

Answer 4

For any engineering problem, there are classroom answers and real world answers. We need to know enough to provide a solution. What failure meay mean is important, as hysterisis may impact your solution.

(You) "Describe the application"

Yesyou are entitled to ask for more informstion. But start by getting them to tell their "story". This may be part of the game. Do not insult them by not playing along. There are options that depend upon requirements, constraints, budget.

Manometer probably a keyword, not naming this might fail you. Strain guage Reiief valve Diaphragm switch Spring tube gauge Electron beam

You should also ask along the way.....

• What is the desired state and purpose (life support ? Spacecraft ?)
• What is my budget?
• Are mutiple redundant tests required?
• How accurate does the test need to be? Tolerances, pass/fail.
• How am I constrained ? A swimming pool full of Hg is OK then ?
• Is reporting required ? Of an academic standard ?

So a pattern of requirement determination is in place. I'm seious about the keywords, your education level may be on trial.