Life as a developer is hard; life as a tester is nearly impossible.

My very first job out of collage was that of a developer. I loved software and still do. So, I put my love to work. Pretty soon I was churning out thousands of lines of code upon code. The first application I developed was a bunch of property pages that would gather up some configuration values and stuff them somewhere in the Active Directory (AD). It was sort of an AD plug-in, very specialized, targeted at AD admins (who were supposed to know what they were doing, including Reading The Fucking Manual). So, I sat pretty and thought of all the ways in an admin could pump in garbage into the plug-in. I made sure that the plug-in would not spit out any garbage.

Or so I thought. My tester, at that time, was a serious looking chap (more serious than I am). For many days I wouldn't hear from him and I worried that he may not be testing the plug-in to the full depth and breadth that it deserved. However, almost to a regularity that you could set your watch to, he would start filing bugs on Friday afternoons. I am not talking about a bug or two. His bugs came like an avalanche, blanketing the functional space that I had meticulously cleared of bugs the entire week. He made, an inexperienced me, mad for many reasons.

1. First, why couldn't he file bugs every day? I felt overwhelmed by the avalanche and would have preferred to have the bugs trickle in at a constant rate. My work would have been more manageable.

2. Second, most (almost all) of his bugs were genuine and made my garbage-in handling logic look crappy. It hurt my big ego of that time.

3. Third, the big batch of bugs evaporated any euphoria I gathered over the week of clearing out the bug backlog. It made it look like I had not made any progress on the bug backlog. How could I claim that I had slain a horde of bugs when the bug-barometer barely budged at the end of the week!

The tester was having a ball. On the other hand, my life was hard. Very hard.

I actually asked my tester that time about the timing of the bugs. Why Friday, why not Monday or any other day. His answer was simple and logical. He was entrusted with testing five features. Being only human, he couldn't test them all together in parallel. So, he came up with a simple strategy of testing one feature a day. I mean, he was fully devoted to testing the feature that day to death. It just so happened that my feature's turn came on Friday. Another advantage he mentioned that testing a whole bunch of bug fixes per feature once a week was more productive than testing bugs across the board, as the fixes arrived. He had independently solved the setup/teardown optimization problem that plagued the manufacturing sector for a long time.

I have now been in a test role for over ten years. Love of my life has undergone a slight change over the years. I still love software and still write a fair bit of it in the form of automation. Writing software that tests software for correct functionality is even more thrilling but that is the topic of another conversation. I also do more than a fair bit of manual testing.

Now I am on the other side of the fence. The color of the grass on this side varies a lot, based on a lot of factors, but it is like the rains in the hot drought prone southern California. You see it once in a while and you yearn for more.

If I could don my test hat and time travel back to my early career days, I would have a some answers for myself.

First, testing (and by extension, testers) are no longer an after though in the software development process. There are, perhaps, companies out there that release software on the strength of developer unit tests, but I know none of them. In test driven software development model, testing comes first, development comes later. The gains are obvious. What is not so obvious is that testers are indispensable. Just like pair programming leads to fewer bugs, easy knowledge transfer, etc., so does having a formal tester.

I would tell my delusional younger self to rid of the delusion/ego surrounding "I don't write bugs, only code", and accept the fact that there will be bugs. The nature (severity, priority) of bugs will vary and some of them may very well be "desirable" rather than "must-have". There will be bugs. There is no escaping them. Love the tester that finds them before the customer finds them. Love the tester that finds an avalanche of bugs every Friday, even more.

Second, when I test a feature, I don't know what bugs lurk and where. I have some idea; my test experience, my test gut sometimes guides me; however, just like the police commissioner Berthier in the Frederick Forsyth's novel, "Day of the Jackal", more often, I don't know who the Jackal is, how he/she looks like, where he is and how to get him.

However, all is not lost. I have a QA process. I have the requirements, the test plan and the test cases. I have the power to test. I use that power to sweep the functionality, one test case at a time. Some tests take time to execute, some are much more pliant. On the whole, it is a slow, albeit methodical, process. Consequently, the bugs are slow to arrive. And sometimes they never do, before the release. I wish I could execute all my manual test cases in parallel, and thus find all the bugs at the same time, but the reality is that I have two hands. Bugs will arrive, just like babies, when they want to. It is labor intensive process, pun intended.

Third, filing bugs only to see them go into a backlog is heartbreaking. It brings the whole testing effort into question. Should I even file a severity 3 bug knowing fully well that it will not make the release bar (either this release or the next or the next...). I will file it still. Releasing a tested feature is more important to me than releasing an untested functionally rich feature. When customer run into the issues (and they will, sooner or later), I will be ready with the workaround, or the hot-fix or the fact that I am aware of the issue and have not neglected the feature.

My developer is having a ball.