I go through the results that the search engines throw out about Software Testing, and I am usually intrigued by the variety of perceptions shown in the results. It is quite interesting to note that organisations sometime limit the scope of it to just finding the ‘errors’ in a finished product; as a matter of fact, a company which does it as a service says so in those exact words.
I was discussing with someone on LinkedIn when they posted that they have come up with a definition for it, and I replied them with my own concise definition. The one thing that they said was interesting – that people tend to define it with the eyes of the experiences that they have come through so far, which rang true to me. FYI, I tried to make my definition as generic and inclusive as possible to be adopted by the entire industry rather than limiting its scope to a few areas.
Some years back, we ran a meetup in Bangalore where we discussed what it is and where it is heading. I shared in that meetup that trying to define it based on one’s own experiences is similar to the parable of the blind men and an elephant! Organisations trying to define it with the basis of what they do or what their businesses are is like that. In fact, defining test roles based on what the company aspires to do is also in a way like that. It’s okay to have roles like SDET for the organisation’s convenience, but is it okay to define it based on an organisation’s convenience?
Today I saw a post in Quora saying that Software Testing (‘manual testing’, to be precise) is going away, and people should start learning development, programming languages, design principles, and design patterns. While it is beneficial for a Software Tester to learn those things in order to be effective in their role, is it okay to prescribe to ‘move’ to Software development saying it is dying?
Software Testing is not going away – especially since software is getting complex because of the distributed nature of product deployment and the Software dependencies. Yes, it takes time and commitment to release quality software, and it may not be palatable to some because they want to release the software right away. It is not sufficient to apply quality principles just while developing the product, but also to verify and validate the product after it is built, definitely not just checking for ‘errors’!
