Test Automation is Not the Only Answer

I have worked on several test automation projects over the past few years. I also conduct test automation trainings as a part of our company’s CSR initiative and actively participate in online discussions about testing.  Since my work is centered on test automation, a lot of people frequently come to me with questions, some of which I would like to address in this blog post.

Question: “I recently graduated with a Bachelor’s in Computer Science. I am interested in pursuing software testing as a career. Can you recommend an automation tool that I can take up?”

Question: I am interested in software testing and have 3 years of experience in the BPO industry. I also underwent a 3 month QTP and Selenium training. Will this help me get a job as a tester?”

Question: “I have been working as a tester for the last 6 months. I want some growth in my career, so I am planning to move towards test automation. Which tools do you recommend I should learn?”

Question: “I have been working in manual software testing for over 4 years now. I think this has been a great mistake as far as my career is concerned. Most of my colleagues and friends are in test automation and it drives me up the wall .I also want to shift to automated testing; can you guide me as to how I should start?”

These and many similar questions have been asked frequently. All of these questions have a common line of thought: Test Automation. It makes me wonder if automated testing really is more important than manual testing!

Most testers I spoke to wanted to learn test automation only for the following reasons:

  • Knowledge of test automation tools can help their testing career and get them better job opportunities.
  • Some of them wanted to learn test automation just because their colleague was learning it!
  • Adding an extra point in their resume to make it stronger.
  • Highlight the fact that they learned automated testing in their performance appraisal meeting! 🙂

I am not against these testers but want them to realize that automated testing is not the only choice they can make to advance their testing career. Manual testing also offers a lot of growth. Knowledge of automated testing is definitely beneficial, but manual testing is also a very lucrative career path to pursue.

What I’m trying to say is that each of these roles – Manual Testing and Automated Testing have their own very unique challenges. Someone well versed with one role might not necessarily be well-acquainted with another. Treat yourself as a tester; not a manual or automation tester. Think of yourself as a tester with a set of skills, specialties, abilities and domain expertise.

Assuming that automated testing can replace manual testing and using automation tools without understanding testing & the underlying application can be very dangerous. Manual testing is not simple. It’s an art and requires high intelligence, creativity, judgment and skill with domain knowledge.

Finally, remember that human brains cannot be replaced by automated robots. 🙂

Any comments and suggestions are welcome.

Hemant Jadhav | Zen Test Labs

Developer + Tester = 1?

Recently I attended a software testing conference where the main focus of discussion revolved around future of testing and how innovation can be ingrained more in testing!

The speakers included Randy Rice, Michael Bolton and Lee Copeland. When asked about the future of testing, and each one said that it was a too dangerous to predict. They realized that when they were asked this question ten years back, their predictions failed thoroughly J  Quoting Neils Bohr “Prediction is very difficult, especially if it’s about the future”.
A common point said by each was that it would be more complex and besides functional testing, security testing would be a major game.

One of the intriguing points I found was in order to enhance creativity,asking the developer to also play tester. I think it is a recipe for disaster to expect a developer to test his baby.

The reasons why the developer and the tester should be different are:

–          The developer works  on building a particular module but the tester has to think of the integrating that part as well, thus varying  the scope and efficiency expected from the tester and the developer

–          The creative process of a developer works on a structured constructing process, where as a tester proves his creativity by breaking the barriers and rules

–          A developer is entitled only to the code and does not work with the mindset of looking for failures, where as a tester whether access to code or no code works towards digging failures

–          However, when a new Functional Specification Document or a Business Specification Document is acquired, the tester and the developer can start working simultaneously, by adopting Agile more productivity and efficiency is attained over a limited period of time.

If I must combine the role of a tester and a developer, then

A developer can enhance his productivity by unit testing, if there is an error in the code it is easier found by the developer rather than a separate tester who might or might not have the knowledge of that technology/language.He can also build by thinking of end to end business flows.

A tester can wear the developer’s shoes by building automated scripts and applying Oops concepts in his test cases.

I believe this would also add in enhancing the innovation in testing! These are my views acquired over dedicating a period of time in testing, Would be great to know yours?

Poonam Rathi |Test Consultant | ZenTest Labs