Many of the quality assurance analysts working today are in dire need of training. They need training not just on testing methods and techniques but also on technical matters to include operating systems, security, new software packages, and existing software. New software is being produced everyday that analysts must learn and keep up to date with. In addition, many new analysts are hired with little or no computer or testing experience. Training employees in these areas is essential to a successful company. Training will improve your testers, your products, and your company.

Promote technical training. Testers often never fully test the integration of their software with the operating system they're working on. One reason for this is their lack of knowledge of how the operating system works. For example, I once tested a software module whose main functions were to import and export data in and out of the system from and to various file formats. I tested the software using a file I did not have NTFS permissions to. The software crashed when importing the file, and it allowed me to overwrite the existing file I did not have NTFS permissions to when I exported data. I find these sorts of scenarios are rarely ever tested. Why? Well, after filing the defect, I was approached by the programmer who wanted to know what NTFS permissions were, what they were used for, and how to set them up. I later found that over 90% of the programmers, designers, and quality assurance analysts had never even heard of NTFS permissions. Too many times quality assurance managers get hung up on the idea that they can only promote training strictly related to testing. Often times companies will pay for technical training only for the IT department, only for testing training for the QA department, etc. This is a definite downfall.

A fellow analyst I worked with at one point heard of NTFS permissions and decided to remove all permissions from most of his C Drive with the exception of his own user account. He then started testing a software package only to find that it wouldn't work on his machine. It seemed to install and work fine on all other machines in the testing lab and on other analyst's machines. Everyone, to include management, the analyst, the programmer, etc., were determined to track down the cause of this defect in case a client who received the software had the same configuration as the qa analyst. They literally spent weeks attempting to track down this single defect. They pulled other analysts off of other projects to work on this project to cover the testing while the original analyst focused on tracking down this single defect. After weeks of testing, the defect was discovered to be the result of the analyst removing NTFS permissions. The software needed system level access in order for many of the services to run in the background. A lot of money, time, and effort was spent tracking down this single "defect" because the analyst didn't fully understand NTFS permissions.

Provide training on new software packages and in a timely A software company I once worked for was in the process of converting all of their databases to SQL Server 2000 databases when it first came out. Although request after request for training on SQL Server 2000 was made, training was never offered on it until the end of the project. Management's philosophy was that "As long as everyone had the minimum steps to install SQL Server and connect to it, that's all they needed." However, simple scenarios were not 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, but who know absolutely nothing about what you are talking about if you bring up a conversation related to testing methods or anything of a technical manner

Don't limit the kind of training you offer to your employees. Don't limit who you offer training to. Provide the training in a timely manner. And encourage your employees to attend training. Follow these steps and you'll see improvements in no time!