After college, I went on to teach high school math and physics for a couple of years. Then, upon completing a master's degree at Northwestern University in education and social policy I created a career path for myself to write training manuals and teach in a corporate environment.
At one of the first companies I worked at post-graduation, I was tasked with writing a software manual for an app. But because the app had not come out yet, I had to go through it — bugs and all. What started happening was that as I came across defects, I would log them and let the developers know. Then, when the developers fixed the defects, they would tell me, and I would recheck.
In a sense, this was where I fell into my QA role. I was testing the software before it came out, reporting the defects, making sure they got fixed, retesting, and then logging the steps in the defect-free version.
Now, I’m formally a QA, a role I’ve been in for over ten years. I love it, and one of my specialty areas is data integrity. I’m passionate about ensuring that the numerical data presented to a user is not only correct but that it also makes sense. A few years ago, I was working on a project at another company and someone said to me: "Do you see the buttons? They should be green. Make sure you log that." And I told them that I would get to the buttons, but not quite yet. I had noticed that half of the web form being filled in on the front end was not getting to the backend — we were losing half the data. This was way more important. Data integrity is my number one priority, so I always check that first. And because data issues typically take longer to solve, I find them as soon as I can to give the developers on my team as much time as possible to fix.