"That which we call a rose by any other name would smell as sweet." True, sloppy naming schemes may be all right in some cases. But as Johanna Rothman explains in this column, when software professionals are looking for a job, hiring, or negotiating work assignments, it's crucial for their job titles to accurately portray the work they do. Read on to see if you agree with the definitions Johanna assigns to the more common QA-related job titles.
What's your job title? Do you work in a QA, Test, or Quality Engineering group? Maybe you work in Development or Technical Services. Each name has meaning, and I wish we could agree on what the meanings are. When the job names don't match the jobs, people across the organization are disappointed. Clay, a product manager, was disappointed with the testers in Technical Services: "If they work for Technical Services, why don't they gather the performance metrics for the product? If that's not a technical service, I don't know what is." Clay's expectations and the Technical Services' group's expectations were completely different.
Accurate job titles can be helpful when you're looking for a job, hiring, or negotiating work inside an organization. Meaningful job titles can help avoid inappropriate expectations.
Since we don't agree as an industry, I'll post my definitions, and invite you to comment.
Tester: Testers test the product, performing verification activities. They discover where the product works and where the product doesn't work. They test in whatever ways the product requires, whether that's for functionality, internationalization, performance, reliability, maintenance, usability, or some other attribute of the system. Testers report the results of their testing to the project team. They use a variety of techniques, including:
- Testing the software from the user's perspective via black box testing
- Verifying that the tests provide some basis-path coverage, via white box testing
- Testing the software from the requirements to show traceability and test coverage from the requirements
- Testing the software statistically by generating the usage model and developing the statistical probability of a given path
Quality Assurance Specialist or Quality Assurance Engineer: QA staff assess the product and the system that produced the product, to see if there are improvements the project team can make for this project or the next one. They ask questions such as:
- How did the project team produce the product?
- What were the results of producing the product?
- Do we have the artifacts that we would expect a project team to create?
QA people audit the product development process. They gather metrics about the product and the process. QA reports the results of their work to the project team and to the process governing body. If there is no formal process body, the report goes to management. In some organizations, the QA staff also tests the system, performing the verification functions of testers.
Quality Engineering: People who engineer the product to improve its quality. For me, developers do the work associated with this title. After all, if the quality engineers are supposed to put the quality into the product, only the people developing the system can do that. Testers can comment on the quality of the product. QA staff can comment on the quality of the process and the product, but only the product creators can actually engineer quality into the product.
Developers: The people who create the product, the code that ships outside of the project team. This includes architects, designers, developers, usability specialists, performance and reliability specialists, writers, and possibly release engineers. However, sometimes writers and release engineers are included in Technical Services.
Technical Services: The people who create code or product that doesn't ship externally. This can include the testers, the writers (even though their product ships, it's not code), release engineers (even though their install scripts ship, if they write the installs), the testers, the process people, the metrics people, and sometimes the project managers. For many organizations, Technical Services is Not Product Development.
What's most important is what your title means to you. Just make sure everyone else's expectations match your title and your job.
Clarifying your job title is particularly important when you're looking for a job or when you're trying to hire a new person. And a job title that reflects the work is equally important when you're already working and you're trying to negotiate who's going to do what. If you're expected to measure product performance, do that, no matter what your title or group name is. And, if you're negotiating a job title or group name, specify the work you'll perform. If we can agree on expectations across inside our organizations, maybe we'll
eventually agree on titles across the industry.
I thank Esther Derby, Dale Emery, Elisabeth Hendrickson, and Dwayne Phillips for their review of this column.