Train, Train, Train

Member Submitted

even tested because most of the quality assurance department didn't know how to configure and use SQL Server 2000. When I tested some of the software behind the analysts, I found multiple defects that could have been found if the analysts had only received the proper training. For example, one defect that was found was that the password authentication routine in the SQL Server database connection interface in our software was hard coded to check for the password. If the SQL Server database had any password what-so-ever, the connection would fail. When this defect was filed, the programmer asked me how to change the password on a SQL Server database. The programmer himself didn't know how to change the password. Training was eventually provided near the end of the project, but the prime time for benefits derived from the training had long passed. The timing of the training can be just as important as the training itself.

Provide training on existing software packages. Many times I've found that analysts analyze data in excel spreadsheets and other common software packages. However, most of their time is spent trying to figure out how to accomplish the tasks they are trying to achieve. While they have a basic understanding of these software packages and can perform basic procedures in them without any problem, they lack the more advanced knowledge they need to utilize them to the fullest extent. Although they often times have enough knowledge to eventually figure out how to accomplish what they want to accomplish, they spend huge amounts of time trying to figure out how to perform a task in these software packages like excel, for example, instead of analyzing the data or testing.

Everyone needs training. As the previous examples point out, the need for training isn't limited just to quality assurance analysts. It extends to everyone in the company to include managers. Not only will the training improve the testing skills of your qa analysts, it will improve their overall knowledge of computer technology in general. At a company I previously worked for, all analysts would receive the same updated ghost image periodically so that everyone would have the same patches, service packs, etc. Of course all of these ghost images had the same Administrator password that each analyst should change before resaving the image. Many analysts at this company, to include the quality assurance manager, never gave any thought to changing the default administrator password. They believed that only drives or folders that appeared in their Network Neighborhood were shared. If something didn't appear in Network Neighborhood then it was "safe". All they had to keep safe, they believed, was their password associated with their username they used on a daily basis to log onto the network. They had never heard of administrative shares. As a result, someone connected to the manager's computer over the network using the administrative share and the default administrator password which was never changed and downloaded salary information, annual reviews, and other personal information on other employees. Only after this was revealed by another employee was it discovered that most of the analysts and managers who received these ghost images had no knowledge of administrative shares and most of them had never changed the default administrator password.

Managers are often times hired based on their ability to motivate a team, to convey information, and to keep a project on schedule. They are not always hired based on their technical knowledge or testing ability. I've come across many managers who are great at managing people, keeping the project on schedule, motivating employees, etc,

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.