Since years, many software companies have their Quality department, which in many cases implies that they have the responsibility to assess the quality of the releases. This department is typically called QA department (standing for Quality Assurance), but I rather think that they are doing much more of checking releases than to assure the quality and I see a huge difference these two concepts, that is, between a QA engineer and a QC engineer:

• QA stands for Quality Assurance, therefore an engineer that ensures the quality. Every time a new release is being built, the QA engineer ensures that the quality is built in it. The QA is responsible for improving the processes and participates actively in the creation of the testing tools.

• QC stands for Quality Checking or Quality Control. This engineer typically waits for the release to be finished in order to check if the quality is built there. A Quality Checker typically creates a list of test cases based on the requirements themselves and puts them in a tool to plan each of the BTCs. Later he executes all the test cases, in most cases manually and tracks their execution.

The Quality Assurance engineer makes sure that each release contains the tests in it, focusing much more on the automation testing. They define the best practices for developers, they are extremely skilled and very knowledgeable of the technical details of the code which helps them grasp a whole view of the system.

Google, for example has three types of engineers:

• SWE (Software Engineers): Represents the traditional developer role. SWEs write functional code that ships to users. They create design documentation, design data structures and overall architecture and spend the vast majority of their time writing and reviewing code. SWEs write a lot of test code including test driven design, unit tests and participate in the construction of small, medium and large tests. SWEs own quality for everything they touch whether they wrote it, fixed it or modified it.

• SET (Software Engineers in Test): SETs are developers who write test code and automation as their primary task. They are in every sense of the word a developer. They test well beyond what can be done by unit testing (integration, performance, scale, reliability, etc.), and write programs, tools, and automated tests to aid in the effort. This role is quite similar at Microsoft, where it’s called SDET. The skill set that Google SETs possess makes them perfect candidates for switching to the SWE role.

• TE (Test Engineers): they are the exact reverse of the SET. It is a a role that puts testing first and development second. Many Google TEs spend a good deal of their time writing code in the form of automation scripts and code that drives usage scenarios and even mimics a user. They also organize the testing work of SWEs and SETs, interpret test results and drive test execution, particular in the late stages of a project as the push toward release intensifies. TEs are product experts, quality advisers and analyzers of risk.

Descriptions taken from James Whittaker in his blog. More detailed info can be found on How Google tests software. It’s worth noticing though that all three roles above write code exhaustively and have very detailed knowledge about the internals of the system under development/test.

In my opinion, the QA engineer correlates somehow to the Software Engineer in Test and the Test Engineer combined. He is somebody who needs to understand inside-out how the system works in order to provide added value. Once the QA engineer has been assuring that the release has already the quality built in, then he focuses on Exploratory testing, usability testing, user experience, etc. The quality of this testing will depend on the quality of the engineer both in terms of skill portfolio and knowledge of the system.

On the other hand, the QC engineer executes test cases and in occasions needs support from developers to execute some of them. They focus mainly on the functional part of the tests and they do not necessarily need to have programming skills. Check the post about Black-box testing vs White-box testing.

QC engineers can be converted into QA engineers. It’s a big leap and an immense challenge as those engineers need to increase their programming skills, gather deeper understanding on the code, they need to find ways to ensure that the quality is built and avoid repetitively checking that the quality is there. Once they do that, the products will end up with a much higher quality.

How can you transform QC engineers into QA engineers?

Gaining knowledge takes time and it requires big effort, but you can create a middle class of evolutioned QC engineers that can add much more value. If QC engineers can acquire the capability to create automatic functional tests, the test coverage as a result of this automation will increase and will allow them to receive better releases as a result of executing these tests. One possible way to achieve that is by using a common language for each product that these engineers can leverage. One of these domain specific languages can be BDD and in the related article you can see how to do that.

Related articles

• Black-box vs White-box Testing (technologyconversations.wordpress.com)
• Behavior Driven Development (technologyconversations.wordpress.com)