A friend of mine (whoās looking for a junior tester role) got a question on how would he test an elevator.
Write one test case for:
Security testing - Iām assuming itās an elevator which gets accessed by a key card, so probably security test would be revolve around trying to bypass that perhaps?
Load testing - here I think we would need to find out the maximum supported weight by the elevator and gradually increase it up until itās almost at 100% limit to see if there is a performance degradation - is the elevator ascending slower if itās loaded with 599 KGs out of 600 KGs.
Stress testing - here maybe try to overload it beyond the allowed weight and see if it would move at all?
I still think although itās not a safe interview question, itās still a good example of a āhow would you explore a domain you know nothing aboutā interview question, which are all good ways to find out if people are comfortable being thrown into the deep end at times. These days elevators are altogether more complicated, they have maintenance interval counters, and a lot more going on than you might think. I, would be consulting the Cirrus Cybernetics Corporation elevator requirements incident, to point out how āshorter customer wait timesā, was perhaps a rather miss-guided metric to chase after.
Ughhā¦Iād groan if someone asked me this during an interview.
I also hated to be asked āhow to test a penā. Itās not software, itās not relatable. Just try if it writes, all the rest is bonus sheeeeeesh.
Sorry, Iām a bit grumpy today.
But for reals, I guess an approach for your friend could be āmodel the interactions of the elevatorā and see if you spot risks in there. Itās better than writing one test case (why one??!!) for those 3 testing areas, imo.
Also agree with Conrad, this is specialised hardware and has nothing to do with what most of us would test in our jobs. But yeah, that leads me back to the grumpy answer, this question is silly.
Thatās the question I meant! You need to answer āwhat do you want this pen to do?ā and then itās over
I get that itās annoying that people ask it because at the time you are not thinking about it at all.
I also heard some people get asked on how to test a fridge, I know that some companies are developing software for smart devices so in such a company that question might make sense (one company that I know of is making an app for smart beds) but this was at company that just makes regular old-school enterprise software, so Iām guessing the interviewer just tried to be original.
Itās just unfair to ask this elevator question a junior. It needlessly trips them up.
Iām now confident enough that Iād say: āI donāt know, an elevator seems like a very specialised thing and I donāt feel I could give a good answer. Could we scope it down to the software that drives the elevator?ā
But yeah, Iāve been in this crazy IT world for 10 years now, Iām not phased that easily during interviews.
Yeah, and I think thatās why the āelevatorā and āfridgeā questions are far too broad . And can waste time, which is another put-off for more advanced engineers. While the simple ones like ātest aā pen/digital-watch/chair are very good, but get overused.
I prefer if they throw a real-world issue into the interview. An actual issue they might hypothetically want solving.
For people whoāve used this type of question as the interviewer: how do you assess the response? Is it possible to objectively assess a response to this kind of question?
@blunderdome Exactly, unless you are an expert on elevators how can you determine the quality of the answer? Personally, Iād never ask that question and if I get asked the same thing Iād disregard it. They best job interviews Iāve had were the ones where the interviewer tailored the questions to the needs of their project, so Iād get a sense of what theyāre looking for. Itās not particularly impressive if you get asked just a common job question from the internet!
There are a couple of things you can test from a functional point of view. Is it possible for 2 floors to hog the lift to the exclusion of other floors? E.g. people on floors 3 and 4 keep pressing their buttons, and it bounces between those floors and never responds to button pressed for floor 7.
Thereās a standard elevator or lift algorithm, that makes the lift go as far as it can in one direction (because of button presses) before going in the opposite direction (for as far as it can). It would mean that e.g. floors 3 and 4 couldnāt exclude floor 7.
Also there are time of day features people might value. In the morning, most people are coming to work so having lifts available on the entrance floor to take them up is useful. So lifts returning to that floor as soon as possible is a good idea. Then, at the end of the day, empty lifts waiting on higher floors is more helpful.
In very big office blocks, lifts combine to be like a mini train network. E.g. lift A stops on even-numbered floors up to the 20th floor, lift B does odd floors up to 21. Lift C skips floors 1-20 and then does even floors above 20 etc. In this case testing that lifts can stop on the correct floors and canāt stop on the wrong floors.
In a posh hotel I visited once, a posh enough roomās keycard would activate the buttons for particular posh floors. So thereās the basic authentication and authorisation stuff around that.
I agree with comments others have already made about wanting to leave much of the testing to specialists in security, mechanical engineering, safety etc.
Thank you Weirdly, this (designing, not testing) came up in an interview I had for the job I started today!
Also, I forgot to mention earlier some grafitti someone had written in the lift in my universityās computer science department. There was a sign that said something like
I learned from a peer a few years back to ask āhow would you test a soda machineā. I think this is a bit more logical than an elevator and definitely a great question for interviews to see how the brain works to create different test scenarios.
Hello, hiring manager here who has asked this exact question, and directed it to juniors. Iāll explain my rationale:
Junior interviews are based on the assumption that the candidate has no prior test experience or knowledge of software testing. In this case, I try and translate question topics into concepts that may be more familiar, whilst still leaving opportunities to show me what Iām looking for in each question. (E.g. In my first testing interview as a candidate, I was asked how Iād estimate how long itād take me to make a hot drink for everyone in the office as I couldnāt draw parallels to software)
The elevator question to me, follows the same approach. Most people are aware of the intended functionality of an elevator, and itās rare youāll get a junior cutting the question short with a ālack of a requirements specā evasive answer. Most will try and have a go.
Iām not looking for someone who studies Health & Safety regs in their spare time, Iām merely looking for a logical breakdown of testing types, even if the candidate doesnāt mention any of them specifically.
The main thing for me is their approach:
Do they consider things logically or just scattergun scenarios?
How do they communicate the ideas they have to an audience?
Do they (expressly or innately) understand the critical paths and key risks (e.g. safety of passengers)?
Do they only assess the happy paths?
Are they considering things beyond standard functional testing - e.g. different types of users, failure states that donāt kill people, etc.
The above gives me better insight into soft skills which will be critical for their role (communicating ideas effectively and concisely, logical approach, critical thinking, etc.) and highlights areas that I may need to focus on. Learning testing techniques and types I can teach them, but having someone who already can think around a problem from multiple angles is of great benefit.
And Iāve been pleasantly surprised by the quality and forethought in some of the answers Iāve gotten from this question, junior or no!
Candidates often start by discussing the correct āfunctionalityā of the elevator, and some will take into account load and stress testing scenarios. Some of the more thoughtful answers took accessibility into account, or UX (clear signage, audible announcements, doors staying open long enough to let people on/off). Iām not expecting anyone to discuss elevator scheduling behaviours, but you do get the odd one that makes you smile!
Weirdly, this (designing, not testing) came up in an interview I had for the job I started today!