| COLUMN |
Time for colleges, managers to focus on software testing |
 |
By Debashish Chakrabarti
12 Dec 2007 | SearchSoftwareQuality.com
|
Often new recruits don't understand the importance of software testing, let alone know how to test. Colleges and managers need to make changes so that testing gets equal treatment.
One of the most common things that I've noticed over the past few years is the reluctance for college students and new recruits to adopt (or even explore) testing as a viable career option. Despite the number of articles that have been written about this, and despite the mouthfuls of platitudes and rhetoric that have been delivered at every other development team meeting, the situation on the ground remains pretty much the same.
|
|
|
|
|
For someone unaware of testing roles and options, it's quite natural that he would look at a tester as someone who is trying to find flaws in his code rather than someone working to ensure quality.
|
|
|
|
|
|
|
|
|
|
In today's world of outsourcing, project teams carry a heavy responsibility for ensuring that all defects and kinks in a release are ironed out before it is delivered to the client. And a key component to ensuring this is the test team. All processes are only as good as the people who implement them, and for testing to be successful, your first (and sometimes only) pre-requisite is a motivated and well-oiled team. Achieving that state obviously becomes difficult if the team members don't appreciate the value of testing.
The root cause of this problem to an extent can be traced back to the education system, where most of the courses related to IT are oriented toward developers. A student gets to learn about data file structures, C, C++, Java, VB-Script, JavaScript, and so on and so forth. I don't see topics such as test automation concepts, test processes, V-model and the like included. All you have is a chapter or two on quality. And for someone who hasn't really seen the industry, the word "quality" is often vague.
Consequently, when the student crosses the threshold and enters the IT industry as an employee, his mindset quite naturally is toward becoming a developer -- and putting to use what he has learned at college.
A cascading effect of this phenomenon is the fact that when such a person is put on a testing team, he is upset that he did not get the job he wanted. It also sows the seeds of an us-versus-them attitude. For someone unaware of testing roles and options, it's quite natural that he would look at a tester as someone who is trying to find flaws in his code rather than someone working to ensure quality.
The problem is further compounded if you have a manager who doesn't really understand the problem. Most managers today try to "solve" the problem with role rotation inside teams, pep talks and the like. It is important for a manager to empathize and then look for a solution. The minute you agree to role rotation as a solution (often too quickly), it could possibly mean that you agree that testing isn't rewarding enough. Moreover, role rotation carries with it the inherent risk of losing focus in the long term. It raises the question of "I was a tester yesterday and am a developer today and maybe a business analyst tomorrow, so what exactly am I?"
To turn this around, here are some possible options:
- Management and thought leaders in the domain need to clearly chart out career options in testing
- Education panelists need to include testing as a regular field of study
- Campus recruiters need to effectively articulate the organizational focus on testing
You have to make someone feel wanted and important if you want them to do a good job, and many project teams today (sadly), have a long way to go towards addressing that.
I'm not saying that it's not being done -- it is, but it needs to happen quicker, more extensively and in the right spirit if we are to truly inculcate a quality mindset in our delivery teams.
-----------------------------------------
About the author: Debashish Chakrabarti works as a senior associate at Sapient Corp. He has worked in IT and testing for approximately eight years and has dealt with functional testing, non-functional testing and test management.
|
|
|
|
