Auditor to Automation Engineer: How Did I Make The Transition?

Since 2017, I have worked as a Test Automation Engineer. Like the Japanese concept of ikigai, I have found my true calling at the intersection of personal and professional interests. My path to QA, however, first led through accounting, audit, and finance.

So how did I become a QA? People ask me that question a lot. How did I learn to code? What led me to switch? A variety of follow-up questions usually ensue. The answer, essentially, is that auditing and testing have a lot in common. Add a passion for coding, and for me, a career in QA Automation made an ideal fit.

To start, the activities that make a good auditor also tend to make a good tester. As described by The Institute of Internal Auditors:

At its simplest, internal auditing involves identifying the risks that could keep an organization from achieving its goals, making sure the organization’s leaders know about these risks, and proactively recommending improvements to help reduce the risks.

Sound familiar? Software testers, for the most part, have the same responsibilities. A good tester needs to understand how a software application relates to a company's goals, and how risks to the app might affect the company. Communicating those risks is also vital. Whether the task is a single bug report, regression test results, or the findings of a test automation engagement, a tester shares those findings with developers, team members, managers, and other stakeholders to suggest improvements and reduce risk.

Auditors and QA testers must also maintain a skeptical mindset to test effectively. As the Public Company Accounting Oversight Board (PCAOB) states:

Professional skepticism is an attitude that includes a questioning mind and a critical assessment of audit evidence. The auditor should conduct the engagement with a mindset that recognizes the possibility that a [mistake] could be present... In exercising professional skepticism in gathering and evaluating evidence, the auditor should not be satisfied with less-than-persuasive evidence because of a belief that management is honest.

Whether auditing the financial statements of a publicly-traded company or reviewing a new software feature for a company's e-commerce website, both auditors and testers need to have a questioning mindset and recognize that while our coworkers generally have good intentions, anyone can make mistakes so we must stay vigilant.

Okay, so auditors and software testers are both skeptical. Developers would agree! But what about technology? And how did I learn how to code?

Auditors often get a great deal of exposure to technologies that cross over to software testing, such as analyzing spreadsheets and learning SQL. During the early 2010s when I worked at JC Penney, it was a publicly traded company making about $17 Billion in net sales. As a financial auditor, before financial statements were released to the public I regularly audited a variety of underlying data, such as treasury cash, credit card receivables, and store traffic counts. This information was often compiled into spreadsheets by the professionals working on this data, which I would compare to source data by preparing SQL queries.

Though most people don't think of a spreadsheet as a no-code software application, good spreadsheets typically follow design patterns to make them easier to use and less error-prone. Similar to the Model-View-Controller design pattern for websites, a good spreadsheet should separate its data, calculations, and views into distinct sheets. Within the data and calculation sheets, each column cell should contain the same type of data or perform the same calculation.

These practices reduce the likelihood of bugs such as formulas referencing a wrong cell, which is all the more important for spreadsheets because the calculations and business logic are usually hidden from view. As one can imagine, though, most spreadsheets in the real world are not so orderly. Estimates suggest that 90% of spreadsheets contain one or more bugs, which users rarely detect. The desire to create more reliable and auditable spreadsheets led me to learn VBA, a programming language used by Microsoft Excel so that I could isolate calculations into functions that were easier to test.

Once managers and executives realized that I could code, even within Excel, they began to seek me out more for my coding abilities than my accounting knowledge. Soon, I was making executive dashboards, tabulating weekly reports for hundreds of stores, and even building financial models to predict store sales company-wide.

As my financial analyst journey took me to different companies, and the same pattern emerged, I realized that I should dedicate myself to software development. After additional training in front-end Web development to further improve my coding skills and accepting an entry-level role at a software company, I had the chance to prove myself during a company hackathon and pursue an opportunity in the Engineering department. As the ikigai chart suggests, with resolute focus I was able to convert my passion for quality and talent for coding into my profession.

And so my QA journey began...