Pages

Thursday, November 11, 2010

Difference between testing and trying out

On days like this it can be really hard to find out whether the functionality you just have implemented really works, and really does what your customer want, isn’t it?

Well, actually, no it isn’t.

One of the things that are just frequently ignored, is that testing really is a structured process.

What do you need for a test?
  1. Create a test plan; The test plan includes all tests that should be executed. Try to write the test as simple as possible. Everybody on the project should be able to execute a test. Rule-of-thumb here: It should sound like its being written by a child. Each test consists of:
    1. A subject
    2. Steps to execute the test
    3. A description what condition have to be met for this test to be successful
  2. Involve your customer; Talk to your customer, include his input, and get his commitment to these test.
  3. Implement
  4. Execute the test; Be careful when executing tests. One of the goal in testing is also to have an environment where errors are reproducible.
    1. Read the execution steps carefully
    2. Execute the steps one-by-one
    3. Do not leave out steps or reinterpret certain steps because “it should lead to the same result”, someone trying to fix the bug you have filed will be grateful, when he is able to reproduce it.

If you do not follow these steps, you are not testing, you are trying out your software. In this case you also might be able to find bugs, but it will be harder for you and anyone else to reproduce bugs.

You also will not be able to guarantee the same high quality of your product.

What should be tested?

You should test your business process, your use cases or user stories, no matter how you call it.

Most important is that you test from a users perspective in order to make your product work for your user.

Also make sure you test corner cases, exceptions in business process. Eg you handle orders in your system, what happens when the order is canceled within the minute it has been ordered?

Normally you do not have to test cases that should not work, but there might be exceptions to that, eg when implementing a credit card validation, only for VISA, you might also want to test, that it gives an error for American Express.

In these cases you have to evaluate carefully.

Who should write test cases?

This should be a responsibility of everybody in the project. The customer is just as well a good source as is the developer.

You have to make sure that the person responsible for the product, eg the Product Owner in a Scrum project knows that these tests exist, so he can coordinate them with the customer.

Also make sure that you have a fixed set of test cases before starting to develop.

If you add test cases during development you will most likely need longer to implement than you have estimated.

No comments:

Post a Comment