In Part 1 of this topic I wrote about the experiences that made me realize that Software Testing is not repetitive.  These are my experiences from over 7 years ago when I first started my career in Software Testing.

When I began to realize that skilled Software Testing was not a repetitive job, but one that required and made use of different types of skills & knowledge and was a thinking persons job – I immediately knew I wanted to become a skilled Software Tester.  I didn’t yet exactly know what that entailed, or how I would start my journey on becoming one, but that didn’t matter – I knew where I wanted to go so to speak and now I would work on getting there.

I saw two types of Testers (there are a lot more but for the scope of this post I’ll stick with two); those who wrote and ran the same test cases over and over & those who used different testing skills, knowledge, experience in their testing to find some great bugs and report valuable information.  The latter were the ones other individuals (testers, developers, product owners) would go to for input on how & what to test. They were the ones who would themselves go to ask developers for information, find information using different channels that were available to them.  They didn’t tell other testers what to do, but made themselves available to them as a good source of knowledge.

I was assigned to and chosen to test more “complex” projects – this is what led me to start working on testing different types of applications. By “complex” I mean testing applications for which there were no pre-existing test cases. Applications that nobody within the Testing Team knew much about in terms of functionality and technicality. I would talk to (ask questions) and work with developers and data analysts to determine what the application did, how it would be used and most importantly (and a learning experience for me) how I was going to test it.  I wasn’t just testing the application from the UI, I was now testing different components that made up the application.  I enjoyed being assigned and chosen for these projects.  Not only did I work hard to be the one the test manager chose for these projects but I showed that I wanted to learn and was both willing to and able to do so.

From this point on; about 7-8 months into my Testing career I knew that I wanted to learn more, get better at what I did and not just sit and execute the same tests over and over – a job that a robot would be able to do or even somebody with less knowledge & skill than me could do.

When I first started my career in Software Testing (about 7 and a half years ago now) one of the most common phrases I would hear is that “testing is a repetitive job”.  It wasn’t uncommon to read job descriptions with the statement “the candidate doesn’t mind doing repetitive work”.  At that time I didn’t know any better – I mean here were people with tons of experience and skills, who knew a lot more about the profession than me, so I believed it (at that point I didn’t have any real experience or knowledge about the profession).

This false belief/statement didn’t hold true in my mind for long.  At my second job (about 6-7 months into my career) I had picked up fast and started to work on many different types of applications.  I hadn’t yet read much content or books about Software Testing but I quickly realized that the uses of each type of application were different from each other and that the user would interact differently depending on the type of application, and that different applications may be subject to different rules and regulations. These were the applications I was now testing.  I was working at a company developing and distributing mobile content – games, ringtones, wallpapers, mobile web pages.  I was testing all of these applications and the features within them on the different projects I was working on and I realized it didn’t make sense to test the same test cases for each type of application because the use cases for one type of application wasn’t really applicable in a different type of application.  It didn’t even make sense for me to execute the same test cases repeatedly for the same application – while I understood the need for regression testing, I wasn’t sure how much and when it should be done and if spending numerous hours and days executing the same tests over and over was actually increasing the quality of the software.

At this point I wasn’t yet aware of the context-driven school of testing and that it was an extremely skilled approach to testing to which some great & knowledgable Software Testers have contributed and that there was community of skilled context-driven Software Testers. I was aware that while some testing may be repetitive (this may actually Checking and not Testing – I won’t go into this difference in this post); skilled testing that required one to think and use their brain to be creative and learn about the technology behind the application in order to better test software was anything but repetitive.

Even after I came to this realization I would still hear that “testing is repetitive” and would often see this statement in job offers. I was even asked in a few job interviews during those times if I was willing to do repetitive work – even though I knew I was a tester who did just more than execute tests over and over based on test scripts I wrote, I would still answer yes – at that time I didn’t yet have the confidence, skill set, experience and knowledge to say otherwise; to actually have a viewpoint of software testing that was different from somebody who had more experience than me who believed in that statement.

This was over 7 years ago now, a lot has changed – including my confidence level, skill set, experience and knowledge.  While I don’t read through as many job offer descriptions as I used to, I’ll still read over a select few from the ones I do receive – and one thing I don’t see often (if ever) is a statement along the lines of “repetitive work”.  I think a lot more people (although maybe not enough) within the Software/IT industry realize that Testing is actually a skilled & knowledgeable profession.

In Part 2 I’ll write about the things that made me realize early on in my career that I didn’t want to be a Tester that would execute test scrips over and over and define that as “Testing”.

Not too long ago while working on a project at a company a certain practice that was common and expected of testers caught my attention, not because it was interesting but because it made no sense to me.  This practice was Software Testers “signing off” on a project or fixes.  Why would I sign off on a product or fixes for defects? I’m not a Product Owner, I’m a Software Tester.  I test (explore, discover, investigate) in order to provide the product owners/stakeholders valuable information about the state of the product so that they can make informed decisions about how to proceed with product delivery.  A blog post I had read about a year ago by Michael Bolton immediately came to mind (http://www.developsense.com/blog/2010/05/testers-get-out-of-the-quality-assurance-business/)

As I dug deeper to understand why this was being done and where it all started, I had a few conversations with Michael and he was kind enough to help me out and lead me down the path to find some of the answers.  He suggested that instead of viewing and presenting the task of tester sign off to management as wrong, figure out the goal and alternatives will arise.

This is exactly what I did and soon discovered that what management believed in regards to software testing – its goal, purpose, and role was quite different from what I believed and practiced. Management believed that the QA Team (or Test Team as I prefer to call it) was responsible for assuring the quality of the product; that we were the gatekeepers of quality; that testers could and should assure the quality of work done by others.

At that moment I understood (understood being different from agreeing) why testers at the company were required and expected to sign off on product and defect fixes.  As Michael states in his post “it’s time for our craft to grow up.”

So here we are on this Christmas morning – I’m finally writing my first blog post.  The idea and motivation to set something up where I could post blogs and ideas had been there for months, maybe even close to a year – finally got started about a week ago at 2am. Couldn’t sleep and the mind was flowing with ideas – the perfect mind state to get started.  It was fun, learned a lot, and was productive, although the next morning was anything but.

As I did a bit each night to setup I thought about what the topic for my first post would be. Had tons of ideas but decided to go with an idea for my first post based on one of the first thing’s a Professional Software Tester ever said to me. It was over 7 years ago at my first job in Software Testing. I was a young kid happy to have found a job but not satisfied – I was eager to learn, develop testing skills and strategies, develop test cases, test plans and bug reports, I wanted to learn how to use the different software tools and applications the company used and learn more about the products I’d be testing.

I was part of the QA Team (the Test Team that is); as QA was an incorrect term for the work the team did and the purpose it served.  This is a difference I learned a few years ago reading content and descriptions written by Scott Barber and Michael Bolton.  The team was composed of the manager, a few test leads and the rest of the software testers. I was new (to the job and to the industry) and fell into the latter category.  The attitude towards testers and what we did was terrible, especially towards the testers who weren’t “leads”. We were seen as the scumbags who slowed things down, didn’t understand anything, and made life miserable for everybody else. The attitude towards testing in the company was terrible. As Gerald Weinberg once said when answering a question regarding what the biggest weakness is in the way companies test software; “To me, the biggest weakness is not considering software testing anything but a (barely) necessary evil. Testing is seen as something that could be done by a troop of monkeys, so serious testers are treated like third-class individuals.”

Anyhow I was in the kitchen one morning and this particular software tester (who happened to be one of the leads) walked in and asked me how I enjoyed the job so far and I replied that I was enjoying it and learning a lot (I was).  He said that was good and he offered his help anytime I needed it and said something to me that always stayed in my mind “There’s a lot of pride in testing”.  His behavior,  skills, effort to help others (new testers included) to get better and build their own skill sets, the respect he garnered (from testers, developers and project managers) all exemplified professionalism and the value he was able to bring to the team as a proud and skilled Software Tester.  I stayed at the company for 6 months, learned a lot and then moved on to better things – haven’t stop learning and getting better ever since.