Our application suite supports a number of access levels. Each user is assigned one of five access levels. Each level has a uniquely defined behavior in the application. In general, the higher the level, the more you can do. But higher levels do not always have the ability to do everything a lower level user can do.
There are a number of times when people believe the application is not behaving correctly. Frequently this is due to an ignorance of what each access level is allowed to do. Normally this happens with the newer developers or testers. It usually takes a senior developer to sort out the problem and trace it back to an access level issue.
I have been working with a new tester recently. He is testing out the application that I am responsible for. He has found some weird problems in my application. There is a lot of interaction between us since I often need to know exactly how to reproduce a problem, or what specific data the tester is using to validate the application.
The other day I asked the tester to reproduce the problem he had documented. He had to do a lot of work to reset the application access levels to the ones used when he encountered the problem. He told me that he was doing a lot of testing in the application at each of the access levels. This was recommended to him by a senior tester. This encouraged me. I have to admit that, while conducting my own unit tests, I did not test all the functionality at each of the access levels.
This emphasizes the differences between developers and testers conducting verification. A developer may be quick to declare success once one test passes. Or sometimes a developer will assume that some tests will pass based on the results of one other test. A tester may also have this opinion. But they will actually perform the tests to verify the hypothesis. However a developer may be quick to skip steps that seem repetitive and boring.
It is a good thing that we have an internal test team to keep development honest. Their absence would not be a total loss. Our customer has their own system acceptance test team. And since we are migrating to all new development tools this year, the users themselves have scheduled a functionality test of our upgraded application. I have the feeling that I am going to be researching a lot of trouble tickets this year. Since I like fixing bugs, this is a good thing.
