Author Archives: admin

Negative Test Cases

Posted on by
Reply

What are negative test cases?

If you get faced by this software testing question during an interview, first define positive and negative test cases, and then give a few examples.

Positive test cases test that the application does what it should.

Negative test cases test that the application doesn’t do what it shouldn’t do.

Huh? Not too clear?

Basically, positive test cases means feeding in valid input into the application, and checking that the app computes the right result, or otherwise behaves in the correct way.

Negative test cases, on the other hand, feed the application invalid input, and generally try to trick the app in different ways. The point is that the app should not do the “correct” thing – the thing that it would do in the positive case.

Examples?

Negative Test CasesImagine a basic login screen. The login screen should only allow you to log in when you’ve supplied the right username and password.

The positive test case would check that the application allows you to log in when you give it a valid username and password.

A negative test case would check that the app doesn’t allow you to log in when you give an invalid username and password, or when you don’t supply any password, or when you supply a password containing characters that the system doesn’t accept as password characters.

Example 2:

Imagine a function written in a dynamically typed language that computes the square of a number.

The positive test cases would feed a number to the function, and check that the result is indeed the square of that number.

The negative test cases would depend on the specifications for how the function should behave for all input other than integers. Should the app throw an exception, return the input value, try to compute the square using operator overloading, return some constant, or is the behavior undefined? The specifications have to tell us this. However, at the least, we can test whether the function will crash or throw a fault or otherwise do something that is clearly undesirable. So the negative test case might feed the function a string, an object reference, a list, or any other non-number value.

How Do You Know When To Stop Testing?

Posted on by
Reply

How Do You Know When To Stop TestingHow do you know when to stop testing?

Here’s how you should answer in case you are faced with this software testing question during an interview.

It’s one of the basics of theoretical computer science that there is no algorithm for predicting how an arbitrary program will behave with a given input (aside from running that program with the input).

What does that mean for the above software testing question?

It means that there is no hard answer to the question for when you should stop testing. The answer will depend on the application you are testing, and probably, on a lot of other factors not directly having to do with the application. Basically, there might be heuristics (ways to approximate) for the right amount of testing, but there’s no way to know the true answer, except for very small toy programs.

What are some of these heuristics?

First of all, if the application comes with clearly specified requirements, we cannot stop testing until those requirements have been validated.

Secondly, a more complex application will always require more testing than a simple application. This means that even when the functionality has been validated on the surface, we should push to break the complex application harder, because the chances of it containing bugs are greater.

Third, we should consider what the application does. A guidance system for the space shuttle should be tested much more thoroughly than a new blogging platform. Can you imagine the catastrophic, horrifying failure that a bug in the space shuttle could cause?

Fourth, if there are additional, non-functional, requirements, such as performance or security, we cannot stop before validating those requirements also.

Fifth, if the application will run in an environment that is different from the development environment, we cannot stop testing before we have run the app in the deployment environment.

What about some business realities?

We should stop testing if tester and developer time can be used more productively elsewhere (new development, or testing of another company product that takes priority for some reason).

We should stop testing if the testing deadline has passed, and it’s time to deliver the product.

We should stop testing if the testing budget has been depleted.

In conclusion, if you are asked how you know when to stop testing, you should say that the answer depends on the application you are testing, and the business environment you are in. Both will dictate when you have found the application to be satisfactory.

How Would You Test a Vending Machine?

Posted on by
Reply

How Would You Test a Vending MachineHow would you test a vending machine? This is a classic example of a software testing in the wild interview question, where you are supposed to show off both your formal knowledge of testing techniques as well as your creative and technical side in inventing test cases.

So, how would you answer this question?

The absolute first thing is that you should talk about the specifications  for a vending machine. Without this, it’s impossible to test anything. You can either ask your interviewers to give you specifications for the exact kind of vending machine you should test, or you can invent some specifications on your own and present that (see the example below).

You should then explain that that there are lots of different kinds of tests that we might want to apply to a vending machine for. First of all, there’s the functionality – does the vending machine do what it’s supposed to do? Then there’s performance – can the vending machine handle lots of subsequent requests; or, how much electricity does it spend for a typical request? We might also be interested in security – is it possible to break into the vending machine easily and steal the candy or the money?

Finally, you can work your way through an example, given specifications for a vending machine, and a kind of test.

Let’s focus on testing the functionality of a typical vending machine that takes in an arbitrary amount of money, and sells several products (like the usual soda vending machines).

Here is a list of possible specifications:

  1. The vending machine will only dispense the product if enough money was put in
  2. The vending machine will return the correct change in case too much money was put in
  3. The vending machine will correctly dispense the selected product (and not something else)
  4. If the user doesn’t select anything within 30 seconds, the vending machine will return the user’s money

And here is a list of possible test cases:

  1. Select a product, put in exact change. The selected product should be dispensed.
  2. Select a different product, and do the same test as above.
  3. Select a product, put in too much money. The correct change should be returned.
  4. Select a product, put in insufficient change. The product should not be dispensed, but the change should be returned.
  5. Put in change, but don’t select a product. Wait 30 seconds. The change should be returned.
  6. Select a product, but don’t put in any money. The product should not be dispensed.
  7. Enter in an invalid product number. Nothing should happen.
  8. Put in foreign money. It should be returned and the product should not be dispensed.
  9. Put in a metal disc of the same size as a coin. It should be returned and the product should not be dispensed.
  10. Put in the correct change, then turn off the power. What happens then? Consult the specification.
There are lots of other possible tests you could come up with – vending machines get pretty complicated after all. However, the point here is not to come up with a perfect test suite for a vending machine, but to display your overall knowledge and skill with software testing. The interviewers want to see how you would handle a complex problem.
In summary, when asked how you would test a vending machine, first talk about the necessary specifications for the vending machine. Second, talk about the different kinds of testing that could be done. Finally, walk through some sample test cases to illustrate how you think about testing.