Growing Up With Quality Assurance
I grew up in Italy in a household where “Engineering” and “Quality Assurance” (QA) were terms commonly used at the dinner table. My dad, now 92 years old, is an Electronic Engineer who specialized in quality assurance of space technology. He worked for over 30 years in a large company called Officine Galileo as Director of Quality Assurance. Officine Galileo was founded in 1864 to produce military aiming, tracking and firing equipment, before extending its production to include space equipment.
I recall the fascinating stories my dad told me about testing procedures designed to ensure that satellite instruments could withstand the punishing conditions found in space. Space is a nasty place featuring a zero-gravity environment with tremendous temperature swings, cosmic rays, and swarms of random high-speed particles. Moreover, given the cost of launching satellites, space equipment must be built and certified to function in those conditions for decades with no maintenance.
Still today, I marvel at the discipline and technical creativity that it must have taken to design testing procedures able to simulate those conditions. To make things harder, when my father was working, computers were not in everyday use. He made his math using a wooden slide rule, wrote his documents by hand and then passed them to his secretary to type with a mechanical typewriter. All information he consumed came in the form of hard to find books and manuals. In the 80’s things started to change, but he never personally used computers for his work, and he retired before it was a necessity.
Technology DNA was spread around my childhood house like blood in a crime scene. I remember my dad’s collection of vacuum tubes, beautiful but breakable electronic components that could not be touched with bare hands. At the time, my dad told me that vacuum tubes get hot, and they would break if dirty with the skin oil left by fingers. I never investigated that claim, but still today I would not touch vacuum tube without using gloves.
We also had a vacuum tube oscilloscope. It was a monster that took a long time to warm up, and when it was warm, it required a powerful fan to keep its temperature down. I can still smell the dust burning on the hot vacuum tubes and the strangely super-defined cathode ray tube screen. We also had an elegant and delicate multimeter (I think) built inside a hardwood case.
The Goals of Quality Assurance
At the time, my dad didn’t know much about computers or software. Computers in the ’70s were not a household piece of equipment. Our quality assurance dinner-table small talk was related to circuit boards, hardware equipment, and satellite systems. There is nothing more fascinating than space to a kid, and it was always fun to learn what the conditions in space can do to electronic devices.
Despite the vast difference between hardware and software, the discipline of quality assurance today has the same goals as it did at the time: to guarantee that something is going to work as designed in the conditions it was intended for. At a high-level, it doesn’t matter if what you are testing is a device or a piece of software, or if the environment is space or the AWS cloud. A quality assurance engineer needs to understand how a piece of technology works, what it is supposed to do, in what conditions is supposed to operate, and must be able to design testing procedures to certify that it is going to work as expected.
Certification of quality takes a different mindset than the mindset required to envision, design and build technology. A Quality Engineer (Quality Engineer; a member of the Quality Assurance team.) must think of all the possible unusual conditions in which a piece of technology might have to operate in, including all possible edge cases and boundary conditions.
In the software world, developers design and create systems to resolve problems, and quality engineers think of conditions that could break those systems. Developers spend most of their time thinking of ways to transform well-defined inputs into the right outputs. Quality engineers spend most of their time thinking of all the possible input combinations or contextual conditions that could confuse the code into generating the wrong outputs.
For example, say that you need to create a program that, given two integers A and B passed as inputs, generates the result of A divided by B as output. A developer assigned to this project would focus on creating a program that is fast, efficient and resolves the problem at hand. A good developer would envision edge cases and write tests to ensure that the edge cases work as designed; for example, the result when B=0.
Testers would take that program and would try to feed it every possible good and bad input they could manage to think of. For example, permutations of positive numbers, negative numbers, integers, floating points, huge numbers, small numbers, zeros, strings, malformed numbers, numbers in exponential notation, etc.
Separation of Discipline Is Important
The separation of disciplines allows software developers to specialize in the art of building software, and quality engineers in the art of finding ways to break it. The specialization in one area or the other tends to correlate with the personality and style of thinking of the engineer.
Developers want to build, and testers want to imagine scenarios, verify and break. Developers are excellent general problem solvers, and quality engineers are creative and curious edge-case finders. Developers focus on finding efficient and elegant ways to solve a problem, and quality engineers concentrate on finding all possible ways to make it fail. Developers create solutions and thus understand those solutions in great details, and quality engineers check if those solutions are usable by real people who will use them in surprising ways. Developers are technology-centric, and quality engineers are customer-centric.
I like to think of Quality Assurance as a Developer’s best friend; somebody who catches issues before customers do. A Quality Engineer for a developer is similar to an editor for a writer. The separation of concerns and focus makes the final software product much stronger and resilient to the ultimate tests: real users and time.
Is QA Ubiquitous In All Software Companies?
While you can’t build any software without developers, a specialized Quality Assurance function is not strictly required. The industry landscape shifts constantly and it is still unclear where it will settle. Some software companies used to have a Quality Assurance organization and are eliminating it; others are introducing it; others don’t have it and don’t plan to introduce it.
In organizations without Quality Assurance, the idea is that disciplined developers should be able to do everything that a Quality Engineer does. While the idea of eliminating an entire specialty is economically attractive, I believe that it is a fallacy not to have Quality Assurance. Here is why:
- Developers need to test their code, write unit tests, integration tests and automated tests. Experience shows that, when they are done doing all of that, significant bugs still exist. Quality Engineers go deeper, hunting for mistakes that developers missed due to being too close to the implementation. If a developer could think of all edge-cases, they would have taken care of them during development. The whole point of having separate Quality Assurance is to look at the problem from a different angle and not being blindsided by detailed knowledge.
- Developers and Quality Engineers are different types of engineer. They are wired differently, and they are good at different things. Their function matches with their natural wiring.
- Developing and testing a piece of software might not require the same level of seniority. For example, code created by a junior developer might need to work in a complex eco-system that requires a Senior Quality Engineer for proper testing. Splitting the development and the Quality Assurance responsibilities can result in better allocation of resources. Another example is the video-game industry where much of the testing is done by non-technical testers who are thrilled to be paid to play games. In that case, part of the Quality Assurance leadership role is to manage the work of those kinds of testers.
QA And Testing Are Not The Same
The activities necessary to verify the quality of software includes a good dose of testing, but not only testing. Quality Assurance includes responsibilities such as:
- Specs and designs reviews. QA’s focus on asking questions and seeing edge cases helps immensely during spec and design of software systems.
- Architecture reviews. Quality Assurance should always be pushing for architectures that support testing, and there is no better time for that discussion than during architecture reviews. Additionally, the experience that Quality Assurance has in identifying and troubleshooting issues is critical during architecture design discussions.
- Security reviews. I see the security of software as a dimension of quality, so Quality Assurance should be involved in its evaluation. Developers should be trained to implement secure software practices, and Quality Assurance should be prepared to catch security flaws during all phases of the software lifecycle.
- Monitoring of production systems. In a DevOps world, Quality Assurance and developers need to be aware of what’s going on in production and monitor systems they helped build. Quality engineers are exceptionally well positioned to spot, troubleshoot and report production issues.
- Management of internal bug bashes, temporary testers, contract engineers and third-party testing farms.
- Management and triage of bugs, help requests, test cases, test procedures and security threats.
- Definition and estimation of the overall quality level of a product or features.
- Creation and management of automated test platforms and procedures.
Growing up learning about Quality Assurance made me into a quality-assurance-as-a-specialty believer. Quality Assurance represents an important aspect of the customer-centricity of a software organization, and in many cases is the difference between happy and unhappy customers.