Getting Started

If I’m going to start a blog category on software testing, it seems that I should begin with a simple, “What is Testing?” entry to make sure we’re all on the same page.  There have been countless blog entries, books, etc, written on this topic, but here is my two cents to throw to the world.

Gretchen and Zoe wrote a great post on what a SDET is. You should definitely read it before continuing to read here, so you get a better understanding where I’m coming from.

What Is Software Testing?

I have an uncle who loves to ask me questions about things I do at work; however, my answers have to be in the form of a simple non-technical one sentence response. Since I know my uncle at one point in time will read this blog entry, let me answer his question now in the acceptable manner,

“Testing is finding bugs in the software product.”

There are so many different aspects of software testing, but at the end of the day, our job is to find bugs. There is the automation testing aspect, the regression testing aspect, the buddy-testing aspect, specification testing aspect, but all of these aspects still lead to the same result: finding bugs, whether we’re finding them ourselves, developing tools for others to find the bugs, or finding them before they are ever introduced into the product.

How to test software is where this area gets interesting and where all of us SDETs spend the majority of our time. It is in the how to test software that we start to see all of the different aspects come into play.

I remember getting ready for my campus interview (instead of a phone screen, I was interviewed on my college’s campus) and I was reading the job descriptions of a SDET, SDE, and PM. There might have been a STE position, I’m not sure. What is interesting is that I put down SDET has my last choice. I wanted to be a developer (SDE). During my interview, the interviewer asked me which aspect of the software development cycle did I find to be most critical during my work experience with WebTOP. Without even thinking about what my response was going to be, I passionately said, “Testing! By far,” and continued to describe why it was so important to test our modules before the students got them. It wasn’t until I got a callback to come to campus for an interview for an SDET position that I realized the significance of my response to the recruiter.

Knowing what I know now about what it means to be an SDET, it definitely would have been my first choice all those years ago. After reading the job description, I just had this misconception that testing was this monotonic motion of hitting the same keystrokes over and over and over again or writing those boring test plans from the CS courses. If I could tell myself 3 years ago what software testing really is, or if there is someone else in a similar situation, this is what I would have to say,

Finding bugs is the best job ever. It is a position like none I’ve ever encountered where it is your job to be super-critical (of the product you’re testing). The job never ends and you will never catch all of the bugs. It’s an extremely interesting problem space where you have this black box (or white box) staring at you, and you have to test for a certain number of scenarios (usually in the 100s for 1 given tester) times a certain number of machine configurations, setup configurations, operating system, languages, and so forth, and you will never have enough time to do this manually, let alone test everything through automation. How do you ensure a high-quality product for your users?

Although I just made up the last paragraph as I typed, I’m sure someone out there is asking some variation of this as an interview question. It is in this problem-space where SDETs get to use their creativity, development skills, and testing skills to come up with more efficient ways to test to find the most number of bugs in the shortest amount of time.