How to test an ATM in a distributed banking system

How would you test an ATM in a distributed banking system?

My initial thoughts:

  1. Basic functionalities: deposit, withdraw, check balance.
  2. Concurrency: Make an deposit at one ATM, at the same time withdraw some money from the other.
  3. Maximum amount of money
  4. Maximum user load

The first thing to do on this question is to clarify assumptions Ask the following questions:

  • Who is going to use the ATM? Answers might be “anyone”, or it might be “blind people” – or any number of other answers
  • What are they going to use it for? Answers might be “withdrawing money”, “transferring money”, “checking their balance”, or many other answers
  • What tools do we have to test? Do we have access to the code, or just the ATM machine?

Remember: a good tester makes sure she knows what she’s testing!
Here are a few test cases for how to test just the withdrawing functionality:

  • Withdrawing money less than the account balance
  • Withdrawing money greater than the account balance
  • Withdrawing money equal to the account balance
  • Withdrawing money from an ATM and from the internet at the same time
  • Withdrawing money when the connection to the bank’s network is lost
  • Withdrawing money from multiple ATMs simultaneously

How to test a pen

How would you test a pen?

My initial thoughts:

  1. Can it write? On papers made of different material?
  2. How long can it write? One week? One month?
  3. Is it easily broken?
  4. Can it be refilled?
  5. Can both lefty and righty use it?

This problem is largely about understand the constraints: what exactly is the pen? You should ask a lot of questions to understand what exactly you are trying to test To illustrate the technique in this problem, let us guide you through a mock-conversation.
Interviewer: How would you test a pen?
Candidate: Let me find out a bit about the pen Who is going to use the pen?
Interviewer: Probably children
Candidate: Ok, that’s interesting. What will they be doing with it? Will they be writing, drawing, or doing something else with it?
Interviewer: Drawing
Candidate: Ok, great. On what? Paper? Clothing? Walls?
Interviewer: On clothing
Candidate: Great. What kind of tip does the pen have? Felt? Ball point? Is it intended to wash off, or is it intended to be permanent?
Interviewer: It’s intended to wash off
… many questions later
Candidate: Ok, so as I understand it, we have a pen that is being targeted at 5—10 year olds. The pen has a felt tip and comes in red, green, blue and black. It’s intended to wash off clothing. Is that correct?

The candidate now has a problem that is significantly different from what it initially seemed to be. Thus, the candidate might now want to test:

  1. Does the pen wash off with warm water, cold water, and luke warm water?
  2. Does the pen wash off after staying on the clothing for several weeks? What happens if you wash the clothing while the pen is still wet?
  3. Is the pen safe (e.g. non-toxic) for children?

and so on…

Load test a webpage without any test tools

How would you load test a webpage without using any test tools?

My initial thoughts:
Write a script to create millions of virtual users to open the webpage at the same time. Then we measure the response time and see if the server would be down. We can increase the number of users to arbitrary large number to get the maximum load of the system.

Load testing helps to identify a web application’s maximum operating capacity, as well as any bottlenecks that may interfere with its performance. Similarly, it can check how an application responds to variations in load.
To perform load testing, we must first identify the performance-critical scenarios and the
metrics which fulfill our performance objectives. Typical criteria include:

  • response time
  • throughput
  • resource utilization
  • maximum load that the system can bear

Then, we design tests to simulate the load, taking care to measure each of these criteria. In the absence of formal testing tools, we can basically create our own. For example, we could simulate concurrent users by creating thousands of virtual users. We would write a multi-threaded program with thousands of threads, where each thread acts as a real-world user loading the page. For each user, we would programmatically measure response time, data I/O, etc.
We would then analyze the results based on the data gathered during the tests and compare it with the accepted values.

How to test a canMoveTo(int x, int y) method in a chess game

We have the following method used in a chess game: boolean canMoveTo(int x, int y) x and y are the coordinates of the chess board and it returns whether or not the piece can move to that position. Explain how you would test this method.

My initial thoughts:

  1. Error conditions: x, y are negative numbers; x, y are beyond the coordinates of the chess board. x, y are zero(s).
  2. If a piece can move to (x, y), test whether the method returns true. Similarly, if a piece cannot move to (x, y), test if the method returns false. That is, test if the method follows the rule of chess.

There are two primary types of testing we should do:

  1. Validation of input/output:
    We should validate both the input and output to make sure that each are valid. This might

    1. Checking whether input is within the board limit.
      • Attempt to pass in negative numbers
      • Attempt to pass in x which is larger than the width
      • Attempt to pass in y which is larger than the width

      Depending on the implementation, these should either return false or throw an exception.

    2. Checking if output is within the valid set of return values. (Not an issue in this case, since there are no “invalid” boolean values.)
  2. Functional testing:
    Ideally, we would like to test every possible board, but this is far too big. We can do a reasonable coverage of boards however. There are 6 pieces in chess, so we need to do something like this:

    foreach piece a:
    	for each other type of piece b (6 types + empty space)
    		foreach direction d
    			Create a board with piece a.
    			Place piece b in direction d.
    			Try to move – check return value.

Programming errors cause program crashes in different places every single time

You are given the source to an application which crashes when it is run. After running it ten times in a debugger, you find it never crashes in the same place. The application is single threaded, and uses only the C standard library. What programming errors could be causing this crash? How would you test each one?

My initial thoughts:
There are only two possible reasons that I can think of:

  1. The program involves with random number generation and it causes some error afterward.
  2. Some variables are not initialized hence causing further crashes.

The question largely depends on the type of application being diagnosed. However, we can give some general causes of random crashes.

  1. Random variable: The application uses some random number or variable component which may not be fixed for every execution of the program. Examples include: user input, a random number generated by the program, or the time of day.
  2. Memory Leak: The program may have run out of memory. Other culprits are totally random for each run since it depends on the number of processes running at that particular time. This also includes heap overflow or corruption of data on the stack.

It is also possible that the program depends on another application / external module that could lead to the crash. If our application, for example, depends on some system attributes and they are modified by another program, then this interference may lead to a crash. Programs which interact with hardware are more prone to these errors.
In an interview, we should ask about which kind of application is being run. This information may give you some idea about the kind of error the interviewer is looking for. For example, a web server is more prone to memory leakage, whereas a program that runs close to the system level is more prone to crashes due to system dependencies.

Find the mistake(s) in the following code

Find the mistake(s) in the following code:

unsigned int i;
for ( i = 100; i <= 0; --i)
	printf("%d\n", i);

My initial thoughts:
Because i is an unsigned integer, i cannot be negative. Hence the for loop should be:

for ( i = 100; i >= 0; --i)

As i is unsigned integer, when i == 0 and one does –i, i will be FFFF FFFF in hex. Then when you do printf with “%d”, i will be interpret as an signed integer. Hence -1 will be printed. Then it will print all the way to the smallest integer, which is -2^{31}. A piece of perfectly working code should be:

unsigned int i;
for ( i = 100; i > 0; --i)
	printf("%u\n", i);