Release Engineering is how software gets packaged, shipped, and distributed to the end users.

Release Engineering is not QA

A QA role in a typical tech company today comprises of finding and fixing bugs, typically by writing a set of test suites aimed at finding defects and mistakes in the system. With each release, they may aim at a specific subsystem or feature set and focus on finding defects. The outcome of which results in fewer defects, surprises, and a better level of quality for the customer.

While Release Engineering aims to maintain a base level of quality, it is devoid of a detective finding defects in this way. Release Engineering must not guard against such intricate edge cases and obscure flows of the system. Doing so requires substantial investment in writing test suites that embed neatly into the RelEng processes. Moreover, it also increases the time it takes to engineer builds through the process.

QA engineers define and maintain a level of quality customers expect from the system. The classification and choice of which surface area to tackle within the product is a choice made in context of what’s being shipped in the next version and how important a set of features are.

In contrast, Release Engineering does not concern itself with what is being shipped. The process largely remains the same in an effort to scale the number of things being shipped.

Fundamentally, mixing Quality Assurance with Release Engineering responsibilities confuses the role and mindset of the engineers. Having a clear direction to automate workflows in service of the product through to customer takes a vastly different perspective than the defect finding mission QA engineers typically are on.

Release Engineers provide a service that ships the product. QA engineers fix the product from potential defects.

With that said, productive collaboration between QA Engineers and Release Engineers allows promotion of newly discovered as relevant and common test cases that are needed to gain a base level of confidence.

Cloud Foundry maintains a system test suites called CF Acceptance Tests (adoringly named CATs) that each team contributes to. Like a healthy system test suite, they typically do not contain edge cases but most crucial functionality of the system are covered by the test suite.

Exploratory testing and QA teams are a huge asset and any product would be better off investing in, but Release Engineering must not be burdened with this responsibility.

Subscribe to The Release Engineer

Sign up now to get access to the library of members-only issues.
Jamie Larson
Subscribe