People often ask me why I chose to be a software tester and not something else. I guess, now I can answer this confidently because that’s how my career rolled out in front of me. When I did my first ever post graduate diploma in software, I was more interested in the analysis and designing of the applications, rather than coding. It does not mean that I was bad at coding, it was just that it seemed a bit detailed for my thinking contexts.
One other thing which I discovered in my early career days that I was fond of documentation and detailing. In the student years, I would spend hours in front of spread out papers and books doing research on topics, and then loved the idea of formatting it into a report form.
I was also very fond of presentations, and love to see audience accepting my idea.
I guess, this is what folded over on each other, and formed my cape as a tester. My careers slumped a lot, but during that time period I learned a lot of new lessons. I never lost control of the Quality Assurance and love for documentation, which were the base of my professional growth.
So at the time when I was first recognized as a software tester, I really was a software tester. People could not label me as someone else. They cannot label me as programmer or system architect. They knew who they were meeting with and what that person can deliver.
This is what I now see missing from most of our youngsters. They want shortcuts, they don’t want to excel into their own skills, rather seek out trends and then lost themselves forever. It may earn them good, but it will never give them satisfaction.
Software testing is not a shallow skill. You cannot say “Oh I know about testing, this is where you check a system and find bugs” – Yup, it’s easier to say than done. You need to be detailed, in-depth, analytical, and descriptive. Anyone can spot a bug in the system, but what makes a software tester different than the rest of the lot, is the surgical strike they do to discover that bug.
Real software testers would not regard tools or automation as a separate entity to their skills. They use latter to enhance their performance. They are aware of their tool-belt and they know when to use a hammer and when to use a needle.
I learned this with my experience. I learned it from being close to my developers and business analysts. I learned it from being close to my customers. I learned it from the discovery of the bugs, and I love doing it again and again!
