Choosing to be a tester!!

          During interviews I have always come across candidates who wanted to be developers but landed up in QA somehow or they started with QA considering it to be an easy job and want to move to development as they gain experience. I have always been supporter of changing profiles, trying different roles but this one not so much. As those I have seen taking this path are mostly doing this because either they think developers have better roles then testers or they think development is too difficult. According to me if you are working as a tester and believe in any of these two then you probably don't know your art well enough.

          I didn't chose being a tester or would say that was the only road I had seen in my initial career. And I am happy that it out to be the right choice. But what about those who have choice? Given that the average developer to tester ratio is around 4-5 developers per tester, there are good number of testing jobs in the market. And the testing community is definitely in need of people who are passionate about their work. I am highlighting some points that I like most about being a QA:

1. The Role : I prefer to be a QA then tester, here is a great article by Alan S Koch on Testing vs Quality Assurance. All the projects that I have worked my role was never limited to software testing. As QAs we are responsible for varied tasks ranging from software testing, writing automation code, creating test systems, data analysis, requirement analysis, release planning, risk mitigation, iteration planning, reporting, training and many more that varies with teams. We are the gatekeepers, our role is to assure quality of the whole product which is not limited to navigating through the application and writing code.
2. The Work : As a QA my daily work involves both manually testing the functionality and writing automation code. I was once working with a business analyst who had recently moved from QA role, he confessed that he missed writing code. QAs understand the functionality and usability of the system, sometimes more then the business analysts. I have always been excited about exploratory and manual testing as much as automation aspect. I have seen people jumping to automation in the first week of their job, which always wonders me that how in the world can anyone do automation without understanding the application? These are the people who say that manual testing is boring but because of their lack of application knowledge are not able to get good code coverage. 
3. Quality : I have never been a bug hunter, not that I don't find bugs. My aim of testing had never been finding bugs but to assure quality of the system. For me bug count has never been the metrics for evaluating the performance of testing team. Instead how early the testing team can provide feedback once the work is done is the true performance measurement. This approach works really well and dramatically reduces the number of bugs found close to release or in production. Earlier the issue is found and fixed lower is the cost incurred and better is the quality of the system.  
4. The Team : I have always enjoyed working in collaborative teams where I can talk to anyone at any point during my work. Creating protocols for communications reduces the work throughput. QAs always seek answers for their never ending questions to developers and product managers. Teams where QAs are supported well tend to perform better and are more efficient. But its the responsibility of testing team to make sure they are not bugging people with irrelevant question s which can affect the trust in the testing team in long run.

 My experience as QA/tester had been amazing and it's definitely a great role with lot of opportunities in the software industry. Its the responsibility of us who have been in this profession for long time to help and encourage new talent to learn the art of software testing.