When I was 17:
My primary interests (other than girls) were photography and computers.
I enjoyed programming.
My mother didn’t value my "playing around" with computers.
I didn’t quite understand that software development was a profitable profession separate from the engineering geniuses who designed the machines.
I certainly didn’t know that one could make a living testing software.
I was a bit of a software pirate. I didn’t care much about intellectual property and copyrights.
After some time doing a variety of odd jobs (including work as a part-time database developer) I fell into testing at the young age of 21. I was hired as a "data collector" to execute test cases and report results. I quickly learned that the test cases were ambiguous and investigation was required for good validation and verification work. I learned that testing was investigation. I liked trying things out. I liked the experimentation. I liked discovering important things. By the end of that project, the optimistic engineers who thought they could pre-script everything and only report pass/fail results were fired (contract not renewed) and I – the lowest paid employee on the project – was running things.
My fall into testing also included falling into TACO2 (Tactical Communications Protocol, v2). I became the expert on TACO2 performance. I provided tech support and testing services for TACO2 users for many years. I thought of myself as more of a TACO2 expert than as a tester. Even though I worked for a testing organization and the majority of my work was testing, I didn’t identify myself as a tester – because I didn’t realize testing was a skill of its own. People encouraged me to go back to school and get a degree in Electrical Engineering so I could be a real engineer instead of an "Engineering Technician" or "Functional Analyst" (the two titles I carried during most of my government testing work). I wasn’t told that testing could be a career. Although my work for dozens of companies introduced me to many contexts, most of my work was with programmers or users. I didn’t encounter many people in explicit QA or testing roles.
However, I often fell into testing roles that had nothing to do with my TACO2 expertise. I was brought into projects to help define test approaches and communicate results with stakeholders for technologies I knew little about.
When I left government work, I was given the title "QA Engineer". I read a bunch of books from people telling me it was my job to engineer and enforce process that would produce quality software.
I got arrogant.
I made enemies.
I learned the hard way that software development and testing is at least as much a social activity as it is a technical activity.
I began to better understand the importance of context.
Looking back, I’d want to tell my 17 year old self (and other young people considering QA/testing as a career) that:
- Testing is important.
- Testing is a mindset and set of skills that differs from programming.
- Learn to program; it can help you be a better tester.
- Software development is a social activity. Don’t just focus on the technology.
- Money and hard work goes into producing good software. If you expect to be paid for your work, pay others for their work.
- Not everyone develops software in the same way. This is ok. There is no one best way. Adapt how you work to the context. (but don’t be afraid to push people to try new things).
- Testing is context-dependent
- Testing skills are valued independent of your subject matter expertise.
- You can’t test it all, so choose wisely.