Years ago, in the group discussion round of my first campus interview, my group was given the topic "The role of testing in the career of a software professional". I went first, making a strong case for testing professionals. I spoke about the inevitability of bugs, the economic cost, user impact and how testing was essential to maintain software sanity. I think I made a good case, becuase I was eventually hired for the job, but I knew I didn't believe a single word of what I'd said. In fact, days after the interviews, I was scared by the thought that my passionate case for testing might actually convince the company to put me in a testing role!
Over the years, I've understood the importance of sound testing. I've also realized how much of an intellectual challenge testing really is. Here you are given a piece of software - sometimes you know the code, and sometimes you don't. Sometimes it has a spec, sometimes you create the spec as you go. The software you are testing might be new or it might be tens of years old, will typically have millions of paths through the code and hundreds of thousands of states (with many thousands that could be wrong). How can you figure out how to make the software fail? How can you unearth the hidden assumptions the developer made? How can you write software so that it can be tested easily? How much of your testing effort can you automate? How do you measure the quality of your testing? How do you know you are done?
I was once the member of an interview panel, and we rejected a candidate for the developer's post. One of the managers in the company turned around and asked us "Is s(he) at least good for testing?". I didn't see how ludicrous this statement was then, but I see it now.
We live and learn.
No comments:
Post a Comment