I have been writing code for nearly half my life, but I started working in the development of test automation somewhere between 2004 and 2005. I started professionally testing in 2002, although I had been writing my own code and testing it earlier. I also did some testing for others before 2002, but I was not paid for that work. I will try to describe the companies and context a little, but I will not use company names, to protect the innocent. But first, a small introduction to perhaps explain how early on I was interested in QA.
When I started my life in QA, I was roughly 6 years old and curious about this clock in a video game called "The Last Ninja" for the NES. It kept a timer of how long you had been playing the game. It gave hours, minutes and seconds. There was a place where no bad guys were with a stream and a park bench. It was perfect for leaving my ninja to sit and just enjoy the scenery. In only 99 hours 59 minutes and 59 seconds I could find out what happened when the clock ran out. I knew Sonic would run off the screen after 3 minutes, so I conducted some smaller tests. In my smaller tests, I discovered, unlike Sonic, The Last Ninja did not seem to mind waiting for short periods of time, so it seemed easy enough to test the longer case. The only problem was I didn't want to lose my Nintendo for a week while I waited for the result. So when I went on vacation, I left my system running. When I came back, what I found was "0A" and the game was frozen up. Now, many years later, I know 0A is hex for 10, likely meaning the clock had run over to hex and then the game had crashed. I didn't understand the result, but I was curious about it. I was later grounded for leaving my system on for that long. You've been warned kids!Years later, I was looking to get a job out of High School. I had been programming text adventures for some years, but never had a 'real' programming job. I enjoyed programming, I enjoyed the experience of creating, but still didn't feel like I knew that much. Still I kept at it. I had worked at the Post Office for 3 weeks in a Christmas rush season, but had little other professional work under my belt. I was going to school and studying Computer Science, but that was going to take years and I needed money sooner. So I started looking for a computer job. I interviewed once, but didn't know what I was doing and did not get the job. College and High School don't seriously prepare you for interviewing. In my second job interview, I took a computerized test and passed all but one question (I tried typing in a search but they expected me to use the dropdown... No, I'm not still bitter.).
I got the job and started working as a managed contractor for a overly large company who worked on specialized hardware. I was a tester who did everything from competitive intel to stress testing to environment testing to configuration testing. However, I had no training and really no idea that testing was a general skill set. I incidentally learned a few simple QA skills, but nearly all of the learning I did was around social skills in my first year. Perhaps one the most important skills I learned was to apologize is important and doubly so when you are a manager and have made a mistake. I moved to a more complex set of testing, but it was a script based. I learned more about networking and security testing. I almost got a job in a team that was inspired by James Bach's work around exploratory testing (in one of the places that James and his brother did some of the development around the idea of exploratory testing), but I missed out to someone with a lot more experience.
Then, in a sad set of events a former lead who changed shifts passed away suddenly. I took his place, an awkward thing for sure. I learned about this idea that you could 'automate' tests. I began to apply my existing programming skills in order to test various UI elements. It worked well in some cases, but we struggled to handle descriptions (a QTP phrase for describing a way of IDing elements in a UI system). A co-worker of mine had more difficulty picking up the programming as his specialty was in hardware, not software. He came into work more than once complaining of nightmares around programming. My coworker did eventually get better at automation, but that was never his strength (Aside: He's now a big-wig manager, likely making way more than me!).
I bounced around from place to place, with a rough total of nine different jobs (not all jobs were title changes). One thing looking back is how I was always trying to go meta, not just writing good automation but improving the entire process. In a large company, that can be very difficult. I ultimately had a conflict with one of the managers and felt the need to leave. Before I left, I was told to quit trying to improve the organization (by providing useful tools) but instead work on personal projects! I did and learned SQL and web development while looking for a job. I also had multiple open source projects under my belt by this point.
If a big company didn't work, I reasoned that a smaller company would be better! I applied to one company and studied up. Rather than applying to many companies, I reasoned it was better to be prepared. This from having done so poorly years ago seemed to work reasonably well. I got a job offer. I tried to negotiate for more money, but was declined. I declined the job but was later called back and given a slightly higher offer. I concluded that because of the recession that a much bigger offer was not going to happen.
I took a job at a 50 person company, and within 2 weeks of me joining the QA manager had quit. This left the QA group answering to the VP of Engineering and it remained that way for nearly 2 years. I worked for longer hours at this company than anywhere else. I lost another co-worker who I was training, and whom I may have been the last person he talked to. He was hit by a bus. I learned the 'hit by a bus' scenario is both real and the worry about how the business knowledge loss will be much less impactful than the emotional impact from the loss. I learned what the term 'death march' meant as I worked 80+ hour work weeks. I learned how a recession can affect you in spite of the fact that your field is in demand. I learned the dangers of saying that you won't ship with any [known] bugs. I learned how working more hours did not equal more productivity. I wrote nearly 1300 automated UI tests. I found the most bugs at the company, in part because of the automation I wrote, and because all bugs must be fixed, it must logically be concluded I found the most important ones. (Yes, that is sarcasm.) Yet, I was not promoted nor paid more for nearly the entire 3 years I was there. Only after 50% turn over and the firing of upper management did things change even a little, and by then I was too tired to care. I left. In case you want more details, Isaac also detailed his own personal journey at this same company.
Now we are getting into more recent events. To be perfectly honest, I don't plan on telling anything more about the various company cultures because of how it might affect me. However, I still learned social and technical lessons.
I learned that 'manual' testers could appreciate automation and automation results. I, for the first time, got to work with other people with equal or better coding skills than myself as we developed automation. I got to learn how to play a technical leader, even when I was not promoted into a leadership position nor had any authority over others. While I had dealt with databases and did a little database testing before, I got to do development in which nearly all the code was around database usage, including communication between database systems. For the first time I had to deal with the integration of multiple team's automation efforts which were written in different languages. By this point in my career I had written test code in C, Java, JavaScript, SQL (various flavors), C#, J#, VB.NET and VB Script.
On the social front, I got to work with both one of the best teams and one of the most difficult teams I ever worked with. In dealing with the difficult team, I got to see how personality clashes worked and how to work around them. To be fair, I have my own personality quirks too, but when these hit extremes it is imperative that you figure out how to be a positive force for the team rather than yet another point of contention. Perhaps one of the biggest lessons I learned was that it is important to have a solid social connection and understanding of an individual before giving a completely honest evaluation of someone's skill set. In fact, I took the lesson so much to heart that I try to be more careful with my day-to-day speech as a whole.
Finally, I want to describe a little bit of my attempts at professional growth. I spent a good amount of time embracing various avenues for learning. I took BBST, and while I only took the class for the first BBST course, I watched all the videos and read all the material. I have written on this blog for a few years now. I have spent time giving talks at various venues. I have written letters, written for other professional venues, testing non-work apps and taken serious amounts of time trying to understand the systems under which work is performed.
So to sum this all up, I think I have just two simple suggestion for you:
Learn
Making mistakes is fine. Just learn from them. Learn how you learn.
Don't just do work
We all are making a journey, and at some point it will stop. Making an impact is important. But don't make work the only impact in life.
