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. Training employees in these areas is essential to a successful company.
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
|Train, Train, Train||31.5 KB|