Getting to know the limits of ‘outside the box’

I am working a bit too fast. Hopefully, I don’t miss anything out, though. I do test plans almost as quick as a ‘normal’ tester. On Friday, I was supposed to work on one test plan, but finished two and started a third one.

Third time did not lie and there were a lot of weird bugs written. Most of them were suggestions of previous testers and tiny tiny errors which would show up if you were very into details.

One of the test cases was about disable/enable the integration. There were two ways written to check: the button and the command line with a certain command. The test case passed. However, one of the comments reported a bug. A third way to disable the integration. I thought of it, too. Checked that bug out and it was correct. There was a tiny little bug living and prospering outside the test case. Outside the frames. However, it was marked green as fixed and written WAD. But it was not fixed!

Then, I got very confused. I tried to think whether it’s ‘fixed’ because the test case did not mention the third way… However, the confusing part is… isn’t our job to think outside the box? My colleague then explained that WAD means ‘Works As Designed’. It basically means, that there is a way to beat the system, but it’s supposed to be like that.

This is quite funny to realize that a profession which needs so much outside the box thinking, actually… may have limits. Some of the tricks may be a part of the software (that’s still a bit weird, isn’t it? but.. maybe the creators want to do a selection for new testers and will employ the ones who find that way out…). (:



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s