What’s In a Title – Part 2

Software development organizations often have a group that has the word “quality” in the group’s name. Depending on the industry and the organization, this group could be called:

• Quality
• Quality Assurance
• Quality Engineering
• Quality Management
• Application Quality Assurance
• Software Quality
• Software Quality Assurance
• Software Quality Engineering
• Test
• Test Engineering
• System Test
• User Experience Testing
• Software Verification & Validation
• Independent Verification & Validation
• Send me your group’s name if it’s not listed above…

Not surprisingly, there are also many titles for people who work in these groups:

• Quality Analyst
• Quality Engineer
• Quality Assurance Analyst
• Quality Assurance Engineer
• Software Quality Engineer
• Software Quality Technician
• Software Quality Assurance Engineer
• Software Verification & Validation Engineer
• Validation Engineer
• Validation Specialist
• Software Validation Engineer
• Software Validation Specialist
• Test Lead
• Test Engineer
• Test Specialist
• Send me your title if it’s not listed above…

Last month, I discussed how the title “engineer” is often applied to many jobs that don’t meet established criteria for engineering disciplines. I also discussed differences between software engineers and programmers. I listed my views on the scope of responsibilities for each and how we need recognize the roles of apprentices and mentors in our industry. It is so important that management support these critical roles.

This month, I would like to continue this discussion by examining differences between software quality professionals and testers.

My pal Watts Humphrey defined Software Quality Assurance (SQA) as:

“SQA is a valid discipline in its own right and people can be SQA experts without being software design experts. This SQA expertise is what is required to establish a strong quality program. It includes knowledge of statistical methods, quality control principles, the software process, and an ability to deal effectively with people in contentious situations.” [1]

In my May 2006 newsletter, I identified many different activities that an SQA group could perform. Roger Pressman often refers to SQA as an umbrella for many diverse and important activities.

Is SQA an Engineering Profession?

The first question is does SQA meet the definition of an engineering profession? If you recall the discussion from last month, to be considered as an engineering profession, five characteristics need to be met [2]:

1. A professional education from an accredited institution
   
   Currently, colleges or universities do not offer undergraduate or associates degrees in Software Quality Assurance.
   
   A few universities are beginning to include Software Quality Assurance courses as part of an undergraduate program in Software Engineering.
   
   
2. Registration of fitness to practice via voluntary certification or mandatory licensing
   
   We do have several examples of voluntary certification. For example:
   
   ASQ-Software Division - Certified Software Quality Engineer
   
   QAI-Worldwide offers the following certifications:

   Certified Software Quality Analyst (CSQA)
   Certified Software Tester (CSTE)
   Certified Manager of Software Testing (CMST)
   Certified Manager of Software Quality (CMSQ)

3. Specialized skill development and continuing professional education
   
   We do have this. Many software quality related short courses and are offered by organizations such as:
   
   
   • ASQ Software Division
     
     
   • Pacific Northwest Software Quality Conference
     
     
   • Boston SPIN
     
     
   • Software Quality Group of New England
     
     
   • Twin Cities Quality Assurance Association
     
     
   • Quality Assurance Association of Connecticut
     
     
   • Greater Kansas City Quality Assurance Association
     
     
   • STAR East and STAR West Conferences
     
     
4. Communal support via professional societies
   
   We do have this. Professional societies include:
   
   
   • ASQ Software Division
     
   • Quality Assurance International
     
     
5. A commitment to norms of conduct often prescribed in a code of ethics
   
   We do have this. The code of ethics appears in the brochure for the CSQE certification…

Clearly the most glaring lack here is in the area of formal education. Working with hundreds of software quality people over the years, I have found that most have not had any formal education in the software quality field. Back in 1997, this is what ultimately motivated me to write a book on this topic…

Many people working in the software quality profession have undergraduate (and often graduate) degrees in fields unrelated to computer science or software engineering. As a result, most folks have learned their craft through on-the-job training. Given the significance of what these people are doing from a quality perspective, this is clearly not the best situation.

The lack of formal training in this field has been one reason people in this field are often treated as second class citizens – especially when compared with software engineers.

What is the SWEBOK?

Over the years, there has been much debate about topics related to software quality and software quality assurance and the relationship of software quality to software engineering. The IEEE Computer Society, working closely with industry, developed a software engineering body of knowledge - called the SWEBOK. After extensive industry review, the SWEBOK was published in 2004 [3]. The SWEBOK presents the body of knowledge in several different areas. These areas include:

• Software requirements
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering tools and methods
• Software quality

It is interesting to note how that Software Testing and Software Quality are listed separately. SWEBOK topics related to software quality [3] are:

SWBOK topics related to software testing [3] are:

The fact that the SWEBOK presents Software Quality and Software Testing as separate areas is interesting. This confirms my belief that we need two well-defined roles - testers and software quality professionals – for the same reasons we need programmers and software engineers. Let’s look at how these two roles would complement each other.

Software Quality Professionals

Software quality professionals are people who could develop and lead an organization’s quality activities. Examples of tasks that software quality professionals would be directly involved in could include:

• Define Software Quality Processes and Procedures
• Review Software Engineering Processes and Procedures
• Define, develop, and analyze Quality Metrics
• Identify appropriate Peer Review techniques
• Identify appropriate Software Risk Management practices
• Identify appropriate Static Analysis techniques
• Actively participate in Peer Reviews and Formal Inspections
• Prepare Software Quality Assurance Plans
• Prepare and review Software Test Plans
• Prepare Software Risk Management Plans
• Audit compliance with software engineering processes
• Review Configuration Management and Change Control processes
• Prepare Defect Management procedures
• Participate in software document reviews
• Assess Test Automation needs
• Plan Manual Testing activities
• Review Regression Testing rationales
• Review Test Reports
• Lead Process and Product Audits
• Define Software Release Procedures
• Establish effective working relationships with Software Development
• Establish procedures for Triage and Root Cause Analysis
• Identify and provide appropriate training for testers
• Actively mentor and coach testers and provide leadership

Software Quality Professionals should have an extensive background in basic quality principles as applied to software development. Software Quality Professionals should be skilled at applying traditional quality principles such as auditing, statistical analysis, root cause analysis, etc. They should also have a considerable amount of domain knowledge of the products being developed. They need excellent interpersonal communication skills. Certifications such as those from ASQ or QAI (mentioned above) should be required along with several years of experience.

Testers

In my view, some of the tasks that testers could be involved in would include:

• Participate in document reviews
• Participate in writing Test Plans
• Write Test Cases
• Execute Test Cases and perform Regression Testing
• Prepare Test Reports
• Track status of testing activities
• Acquire automated testing skills
• Work with Defect Tracking tools
• Participate in process and product audits
• Acquire domain knowledge
• Build effective working relationships with software engineers and programmers

Testing is often viewed as an entry level job for people who are changing careers or looking to enter a high tech industry. People who are new at this obviously need a lot of training, mentoring, and coaching. This is yet another example where an apprenticeship role makes abundant sense.

Testers can also be recruited from within organizations. For example, people who are in a Technical Support, Customer Support or Field Service role can be given an alternative career path – as a tester. This can work very well since people in these roles have lots of domain knowledge. What they lack are basic testing skills. It is much easier and less costly to teach people basic testing skills than it is to provide people who may have testing skills with sufficient domain knowledge.

Summary

Just like other engineering disciplines, we need to recognize the need to have apprentices and mentors both in software development and in the software quality areas. Having apprentices and mentors enables people to develop their skills and become more effective and productive. The relationship between an apprentice and mentor is also something that can have long lasting impact and provide organizations with significant long-term benefits…