I have a Junior QA interview coming up, and I was asked to learn the basics of Selenium. I have done this through free tutorials. I am fine with the Selenium concepts, but I was told I would be asked how I would test real-world objects at a conceptual level. I may be asked to test any random object in the world but it will probably be a simple one - bicycle, can opener, etc. I will not have to write code but explain it orally. I am not sure how to approach studying for this and how I should relate it to Selenium testing with Java. I can't find any resources that are similar to this, so I am asking here to be pointed in the right direction, or for a conceptual example for a real-world object.

The person in HR didn't really give me much info other than that I would be asked to explain how I would test real world objects without writing any code.

For example, let's say I'm asked how I would test a bicycle. The way I would answer this now not knowing what they're really looking for is this:

I would ask what the function of the bicycle is and how the various parts work together to achieve this functionality. I would deduce that the bicycle has 3 primary functions; be driven by a drive train through the rotation of the peddles by the user, and a braking mechanism operated by the user, and the swivel of the front wheel to turn.

Now that I have determined the primary functionality I would break these down into smaller problems to test. For the sake of this post, I will just go into the drive train. I would determine when the user pedals it will turn the chaining which it would pull the chain forward. This chain is connected to a chaining on the rear wheel which turns the wheel through the transfer of energy given from the chain. I would then ask is this the only way the user can use the bicycle? Is pedaling the only function that the client has access to? If, so I would test to make sure this function properly catches any invalid input or uses.

I would need to test each individual piece so as to build a larger test. I would check to see how the Pedal class calls the Chaining class. How do they interact? What would happen if I passed the argument "pedal_backwards" to the chaining? What kind of constraints with pedaling does the Chaining enforce? Next, I would check to see how the Chaining calls the Chain class. What constraints are there in this invocation? I would do the same for the rear chaining.

Basically I would break the object down into smaller problems and test how they interact with each other. This way changes to the code base will still be testable with my tests and will continue to work autonomously.

Am I on the right track? I wasn't really given much information just that an engineer would pick a real-world object and ask me to test it.


  • There are already some answers that cover thinking about test cases/scenarios for the object but when I've asked or been asked similar questions the first thing I always ask is "what's the object meant to do?". An answer below mentions a coffee cup, but what if I designed the cup as a pencil holder for my desk? The test cases should be relevant to the intent for the product, not to any possible thing the object could be used for. – Cherree Jul 9 '19 at 19:56

Testing real world objects comes up in interviews quite often. Interviews usually pick an object that everyone has seen and used before. Mostly, I've gotten "how to test a coffee mug or travel mug" question. Testing an ink pen is also common. While a bicycle might be the object, you are typically given something simple due to time constraints of the interview, which is why a coffee mug is quite common. It's also common to not get clarifying answers from the interviewer to questions you may have about the real world object.

So far, your answer is in line with functional testing at a unit level with some integration testing -- all important things test. Keep in mind that unit tests are usually the realm of developers and integration testing is for QA.

There is no "right or correct" answer to testing real world objects in an interview. What the interviewer is looking for is your process, your approach to testing, how detailed and thorough you are. This question helps the interviewer compare you to other candidates, so the more thorough and detailed you can be, the better your chances.

For a detailed answer, considering incorporating other types of testing: performance, load, user experience, end-to-end, security, accessibility, etc. Think of edge cases. Think of any government regulations that might apply (important for some industries like finance, health/medical, automotive, aerospace, etc). How would you break the item?

Given your bicycle example, what are the government regulations for it? What happens if you run over the bicycle with a car/truck? What happens if the chain comes off while riding? What happens if you get a flat tire while riding? What's the user experience like for the seat? Seat and steering adjustments? What about fixing a flat tire? What if you leave the bicycle outside in harsh weather conditions? Who is the primary, secondary, tertiary user personas for this product and how do they use the product differently? I can think of a lot more questions and considerations -- this should help get your ideas flowing in other areas.

When it comes to QA and testing, happy path/positive testing is usually easy -- this is how software or a real world object is supposed to work. What's harder is the sad path/negative testing. Find ways to break it. Keep in mind short term quality and long term quality.

Your answers should also reflect common testing fundamentals like Boundary Verification, Equivalence Partitions, All-Pairs testing.

Real world testing is done by Consumer Reports and Underwriter Laboratories (for anything electronic). You can read some of their reports for ideas. The same QA and testing approaches work for non-software products.

| improve this answer | |

I think you have covered testing on different 'levels' in great detail however testing also includes on different 'types' as well.

One may think about security, performance, reliability & safety etc as important quality parameters to test an object on. I think you may easily relate it to an 'Bicycle' and come up with additional scenarios which may showcase to the interviewer how you look at it from different angels and covers all aspects of testing , not just the most obvious one('functionality') which might set you apart from other candidates.

| improve this answer | |

In software testing it is important to have same vocabulary. I would start your interview by asking information questions about your assignment. In the case of bike, I would ask:

  1. What type of bike? Mountain, electric, with gears, children ...

Point is that you should ask for clarification.

Testing ideas.

You can start with testing tours. Kelly has great article on that topic: Taking A Tour Through Test Country,

The goal of tours is to get to know with the bike.

For example in feature tour you can do exploration of all features, e.g. battery life, gears, breaks. Here you do not look for bugs, you just get to know with the bike.

Other tours are: data tour, variability tour, structure tour, user tour, scenario tour, configuration tour, interoberability tour, testability tour.

Than you should start looking for bugs. For that you can use consistency heuristics. FEW HICCUPPS gives the idea.

For example, if you have a mountain bike, you can compare it with other producer mountain bike.

This is a start, but with those two resources, you can test for hours in your interview.

| improve this answer | |

It may not about automation and programming. As I saw the question, I would consider the attributes of the object. What makes it useful? What capabilities it could bring? Start from here.

| improve this answer | |

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.