Автор: Елена Беляева

The paper is devoted to the training program for Software Quality Assurance (SQA) engineer created in Motorola, St.-Petersburg software center to prepare SQA engineers to fulfill their responsibilities. The paper will provide the stages how the training program was formed. We will describe approaches we used for the mentoring program and the effectiveness of the training program.

Internal Training Program for SQA, is it Worth for Money?

1. Introduction

You may ask why an idea to run internal training program for SQA people occurred to us and why we spend up to 6 months to prepare one person when it seems easier and cheaper to hire a specialist with required skills. There are several reasons that will be explained: first, historical, when the center started its work, we were he first who followed the requirements CMM/CMMI model [1] describing quality assurance activities. So we had a limited conception of SQA responsibilities based on our understanding of CMM/CMMI statements and experience of our colleagues from other Motorola centers.  The second reason was lack of educational programs related to quality assurance in St.-Petersburg and even in Russia. Now when they are appearing most of them are still mixed with testing concepts. Third, while the center was growing we were obtaining specific experience, e.g. in auditing approaches and organization metrics database maintenance. All these reasons led to he decision to introduce internal training program for SQA newcomers and to start training newcomers by ourselves.  

2. Training Program Formation

When the center started its work in St.-Petersburg in 1997 nobody knew what requirements for SQA engineer position should be. The primary source was a process area of CMM model (and in the course of the time CMMI model) used in a number of Motorola centers. This process area is devoted to process and product quality assurance. The main requirements are objectively evaluating of performed processes and work products against defined process, reporting of noncompliance issues and ensuring that noncompliance issues are addressed. Looking at CMM model more detailed we will find out additional SQA responsibilities: contribute to project or organization process definition and its improvement, maintain organization metrics database and participate in metrics analysis both at project and organization level. So SQA engineer plays several roles simultaneously: auditor, metrics expert, process and problem prevention consultant.

Since 1997 the organization grew more than 5 times that led to the shortage of SQA personnel to maintain the increasing number of projects/programs. Moreover the diversity of processes, number of process assets and project tailoring scope increased. To keep the system working and up-to-date we introduced automation into the following areas: audit system, organization metrics program and tracking system for process changes.  As a result we needed knowledgeable people who can easily manage the innovations and changes in work situation.

First, we looked at the labor-market and found out that it was hard to find a person with such qualification. There was no any special educational program in universities, and there was no consistency in how CMMI world treated the term of Quality Assurance vs. other world of software production. Most of software companies considered and continue considering QA people as testers.  This also brought an idea to train and bring up quality people ourselves. We defined the minimal requirements for SQA candidates that were vital to start the work successfully:

• computer science education to be on the same level of
• language with the projects;
• basic knowledge of databases and metrics tools;
• communication skills as most of time QA engineers had
• to deal with project teams.

Along with searching process we worked out the training program that would cover both theoretical and practical parts of QA activities.

We tried to look at specially developed courses or certifications for quality assurance, but there were no such courses in Russia and any international certification implied expenses on travel to the place of certification. Additionally due to difference in terminology most of the courses were oriented at testing activities and anyway they gave only general knowledge of the subject: common approaches to auditing, common metrics, etc. However by this time we had a highly-matured organization process with a lot of specific features, even auditing approach was different.  So we started with theory and prepared an induction program for newcomers at SQA position. Then we focused on the second part of training program - practice that can be obtained only through work with projects. We didn‘t want to let newcomers work directly with projects after induction program was completed. What was good in 1999-2003 years did not work in 2004. Our experience showed us the necessity of controlled practice and as a result a mentoring program was introduced.

The created training program contains several parts which are delivered by senior SQA staff:

• Induction training program which provides details in all process and quality areas which are essential to perform SQA duties efficiently. The program was established in 2004 and is being maintained up-to-date
• Mentoring phase with close cooperation of a mentor and a mentee within several selected projects
• Post-induction mentoring phase when a mentee works unassisted and involve the mentor into critical issue resolution

3. Mentoring Program

After completing induction training program a mentee starts his/her work with 4-5 projects under mentors‘ supervision. The first approach to mentoring was the following: there was one or a couple of mentees and several mentors depending on what projects they worked with. In this case mentees received an experience in most of project processes accepted in different programs. On the other side, there were more minuses then pluses as there was no single person of contact (you could ask any mentor, but he/she wasn‘t an expert in the problem of other program), the learning progress was slow and the duration of mentoring phase was unacceptable. After the failure with the first approach we changed it the approach when one or a couple of mentees contact only one mentor. In this case we faced the problem when a mentee had a limited scope of projects where mentor worked. But it was not a real problem as by this time we had introduced program differentiation when SQA engineers had been assigned to the projects from not more than 2 or 3 programs. The gap in knowledge of other program‘s process was closed during sharing sessions within SQA group. For the mentoring phase we introduced coverage matrix, checkpoints and the rules for mentors and mentees. Coverage matrix is a table of regular project/organization tasks implying SQA involvement (e.g. auditing, reviews of project documents, project meetings, metrics update) and the status of their implementation. The practice was considered as complete when it had been done at least 2-3 times: first one with detailed instructions from the mentor and the second or third one unassisted with showing the results to the mentor. During the checkpoints a mentor checked the status of coverage matrix filling in and level of readiness to work unassisted. Step by step the mentors delegated more and more tasks. With the conception of single point of contact and project scope limitaiton we improvement the process of learning and shortened the mentoring phase duration to not more than three months.

Three generations of new SQA engineers were covered by the program from 2004 year (8 people). The duration of post-induction mentoring was shortened 3 times (from 1.5 year at the beginning to up 6 months). From mid of 2006 year in spite of the fact that SQA team consisted mostly of fresh SQA engineers the results of internal feedback survey showed maintained level of SQA competence as exceeding expectations.  

4. Conclusion

In conclusion we would like to stress that to train specialists it is not enough to give them only theoretical knowledge but it is essential to obtain practice under mentors‘ supervision.

We hope you can use our experience to build your own training program for specialists that cannot be found easily at labor-market.

5. References

[1] Capability Maturity Model Integration (CMMISM) for Software Engineering, Version 1.2, CMU/SEI-2006-TR-008, ESC-TR-2006-008, August 2006

Обсудить на форуме

(!) Публикуется с разрешения оргкомитета Software Engineering Conference (Russia) 2008