My Earlier Days as a Programmer and How I Became a Software Tester

Software Tester
Many people do not think about Software Testing as a career. In fact many do not even know the field exists nor how rewarding and challenging it is to be a Software Tester. There is not a degree in Software Testing so many people applying for the job are not really sure what we do. It does make me contemplate how I learned to test. In my earlier days I was trained as a Cobol programmer. As part of my training I learned how to create flowcharts; test my own code (negative, positive, boundary testing); validate the records returned at each data set; and review the raw data to ensure it was processed correctly at each step. The assignments were difficult and our documentation was expected to be perfect. If you made one mistake in your flowchart you lost a grade level. At the time it seemed very harsh to me, but I now understand the discipline was necessary to help us work through a problem. In those days we worked through the assignment by creating a flowchart. From there I worked as a programmer in different capacities that included finance, human resources, and securities. Sometimes we received written requirements, but most times we needed to work with the requestor to understand what s/he needed. Other times we wrote code for production systems or consolidated programs for efficiency that often required reading in a dozen or more files. We needed to understand the file layouts, the data, and how to merge the files to ensure we did not duplicate records. Basically we gathered our requirements, wrote the code, and tested it. We did not have a testing department – sometimes you could get another programmer or a business user to help with the testing.

I was often the liaison with the Information Technology department on the behalf of the business community. I could speak both languages. This afforded me opportunities to test the output of the IT department projects such as an employee change form that automatically filled in data based upon pre-defined information. While working in Human Resources we implemented an application tracking system to handle the large amount of resumes received for opened positions. This afforded opportunities to help define the requirements and “test” the commercial-off-the-shelf products to determine if they met our needs. As object-oriented programming became more popular or perhaps better known, we were hearing more about Java, Oracle, and data warehousing. During that time I started a new job to start a software development department and we did it all. We wrote requirements, developed the code, and tested it. Over time I moved into a role to start a Software Testing department. And we performed a lot of different roles including business analysis, software testing, training, and implementation.

I will always value my days as a programmer because it helped shaped my career. Plus when I talk to the developers I have an appreciation for their struggles and can visualize what they are trying to achieve. I find myself translating what they say to how I would code the solution. Through all this, I realized I was a born tester as I view my world through my testing eyes. It can be difficult to explain to those who are not passionate about testing. As an example, when something does not work in our house I automatically think about the business requirements, how it might have been developed, and tested. Immediately I want to study and test the problem to find any patterns to the failures. When there is an upgrade to our DVD, I start to “test” the new features. What happens if I try this, or try that? What is the logical flow and how can I take what I know about software standards to learn more about the upgrade. I tend to not read manuals – I jump in and start with exploratory testing. I start with learning at a high-level or the surface. How does it work? Then I will go deeper to understand the functionality. I tend to be a button-pusher; what happens when I click this button. As an example, when we moved into our house, we got a new stove. It had an electronic clock. While the delivery guy was still in the house, I went to the stove and started to push buttons to figure out how to set the time. The delivery guy was stunned. He asked how I knew that because they have customers calling them to find out how to set the time. Honestly, I do not know how I knew – I just did. And that is how it is with software testing. Some of us are born testers and some may not know – yet. There are just times when we know what to do when others are scratching their heads asking, “how did you know to do that?”

So what is your story on how you became a Software Tester? I would love to hear it.

4 responses

  1. Like you, I started as a COBOL developer and carried out a lot of unit testing, which I enjoyed as I wanted to see how the programme worked and I didn’t really consider it to be testing. When the independent testing team got round to testing my code I was very defensive and resented them poking around in something they didn’t understand. That attitude prevailed for a long time and I refused to help testers at all!

    It was only when studying for my masters that I took a module on testing as I was curious about the field and thought it would be an easy module but after a day on the course I was quite fascinated by the science behind it: test coverage etc. and I quite enjoyed it and it all seemed logical. At the time I had moved from development to a production support role and was fed up of supporting/fixing buggy code. After shouting “who tested this?” in the middle of the night one too many times, I decided that I would be the one to test it! I would be the saviour of support technicians everywhere!

    So within months I became a tester.

    I really enjoy the work and find it a very challenging job. I do find it frustrating at times as testing is squeezed or rushed and I’m glad to see a large professional network including blogs like yours that look to address these challenges: after development I think testing has one of the largest support communities. I’ve attended conferences and been in awe of the passion for testing.

    I don’t know if I’m a born tester. I ALWAYS read the instruction manual and I hate code that isn’t documented. I hate badly written instruction manuals and awful user interfaces and I find my testing is centred around that and the user experience. I would love to do more whitebox testing but the great thing about the job is that there are many different roles in the testing family.

    I wish I could say I had prevented the support guys being woken up in the middle of the night, but at least I can now explain to them why it happens.

    1. Thank you Chris for sharing your story – I enjoyed reading it! The testing community is just amazing and people outside the tech field are always amazed on how connected we are. I love testing since as you said there are so many roles in the testing family. I really enjoy session-based testing and recently read about thread-based testing. This is what I love about this field – there is always something new to learn and different ways to approach testing problems. I am getting more into gray-box testing and brushing up my sql skills. As a former programmer I always think in terms of how I would code something and then I need to understand the SQL syntax. I think I am going to create a cheat sheet where I document how I would have coded it, the sql syntax, and then some sample code. I coded for about 12-years and it is just burned into my memory.

      I also find there are more books I want to read than I will ever have time! I always want to do everything and I have to keep prioritizing what I can reasonably complete. Testing being squeezed is such a problem or people wanting to undervalue why we need time because they do not understand testing. I think I will write a posting on the different types of “testers” because many people test but do not truly understand how to test. I hope people find my blog helpful and if you have any suggestions for articles, please let me know.

      I think it is interesting you always read the instructions manual. And again that is what makes testing so great. We can each approach problems differently and yet compliment each other by bringing our strengths together in a team.

  2. […] would like to know more about my earlier days as a programmer and how I became a software tester, click here. Recently Microsoft ended their controversial stack ranking of employees and Yahoo just implemented […]

Now it is your turn! What are your experiences, thoughts, or observations?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: