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…). (:



Official start of testing (with smokes) or trying to catch some bugs

I was so excited about the start of testing! It turned out to be even better than I expected.

This week I am supposed to be the size of a half real tester (!). I think I was more than that! Instead of 3 full tester’s hours, I actually did 4 hours of a full tester and even had time off before my train (going to visit my parents in another part of the country for Christmas).

My tutor got a bit irritated by the fact that the smoke test was not as flawless as it had to be (my manager explained it well: the name for smoke test comes from electricity where the first test to do was to connect the wires and see whether the smoke comes). I got very happy and interested in that test. So great that it had difficulties. I even fixed several test cases and ran the test on not run before test cases. So lovely.

And, some test cases I repeated for like 5 times. Especially the one with a fixed bug. Sometimes there are problems to “recreate” the bug… Some test cases come from one each other and if we do a workaround for one of them, to get another one may not be easy. It’s like a house of cards: if one card is standing on a slippery surface, another one which is on top gets affected, too.

However, with a lot of tries, I managed to see that the bug itself was fixed. Everything would be fine if it did not require so much time. Life is ironic and bugs like to make homes in test cases with huge files which take forever to compile even without a bug. But… I made it!

Later on, I got to know what kind of status a relationship between tester and developer there is… Our developer contacted me, being all friendly and introducing himself. Then he asked whether I have anything to say to him. I replied no. He replied: “Very good :-)))))))))))))))))”. No wonder my fellow colleague said that developers on her team were so happy when she was absent for a month – they all were thinking that their builds are bug-free. 🙂

144 Moral Support