This is a blog for testers, but developers read closely. This post is the story of my testing career (an abridged version, no one has time for the whole thing). A story of how I got where I am and the the mindset and skills I have developed. I’ll be linking to other posts, videos, books and training material as resources in a link above. My hope for this blog is that other testers can learn from my path and pick up useful information to advance their own career.

Lets begin at College were I took a 2 year “Computer Programming” program with 1 year of co-op. This gave me a good foundation of understanding programming and a bit of ‘unit testing’. As a developer I naturally test my code to verify the code functions. With the goal of getting code to work though, I missed the mind set of purposefully testing its weak points and getting it to break. None of my courses ever directly talked about the role of testing and testing skills. This is because from what I have seen, there is no College/University education for a tester’s career path. The tester career path can come from many backgrounds that don’t need to be related at all to programming and technology. The main skill for a successful software tester is a critical thinking mind with the intention to discover the truth about software and report/discuss findings to stakeholders.

I got a co-op at in the government as a LAN Admin, which had nothing to do with computer programming. It really wasn’t the right choice, but it was offered immediately in the interview and I didn’t have a mentor to guide me onto the right career choices. I feel this had a huge cascading effect for the last semester of college, where everyone else had real life coding experience and I was no further ahead in my coding skills. I did try to get involved in coding in my position but got only as close as batch and powershell scripts.

Directly after college I was looking for work and got an interview with a small company. Here I was originally interviewing for a junior developer position. At the end of the interview they had asked me if I was interested in coming back for an interview for the position of Quality Assurance Analyst. Being fresh out of school and looking for work in the field I of course went back for the QA position. I got that job and had worked there for about 5 years. When I first started I had no clue what a Quality Assurance Analyst was actually supposed to do day to day. I learned from senior testers and business analysts there about their approach to testing within the company. The job offered me the opportunity to travel to customer locations around the USA and learn how our product was used in production. This was a steep learning curve as I had to grow my knowledge of how internally we thought our customers were using our product and then compare that to how it was actually used onsite.

This is a key point for doing great testing. If you ever get the opportunity to see how the product is used in the real world, I highly recommend it. Often how the software development team assumes the customer will use the product is not in sync with how it is actually used. This insight helps you the tester focus on what is really important to the customer. Because of my computer programming background my manager got me to work on a project for automating our regression test suite. This did not go well. I am grateful that it did not go well because I learned a good lesson on how to not approach test automation. My manager wanted the tests to be automated using a record and play tool. Because the other software testers did not have a coding background she wanted a tool and process that everyone would be able to work with. Well this is an approach I can now say will not go well, especially for any complex work flow. We had a co op come in and work on this automation project with me and immediately he tried to code the test automation (which was the right thing to do), but sadly I had to squash that and point out management didn’t want a tool the test team couldn’t maintain and work with. At this point in my career I was not ready yet to push back against management and fight for the right way of doing things. I was still too junior.

After years of working at the same place doing mostly the same type of work I started to itch for more depth into my profession. Searching for more knowledge I stumbled upon Open Lecture by James Bach on Software Testing, which was the catalyst for my change in mind of how I go about testing. I started to use this new mind set in my testing and it brought me great pride. Sadly when I mentioned the skills I was working with to my manager there was a disconnect. I realized my manager and fellow testers had not heard or applied this skill set. Around this time I was let go from the company. It was probably one of the scariest things in my career and yet something I appreciate happened. The financial aspect of being layed off was frighting (recently purchasing a new house and new car).

While looking for a new career opportunity I continued to study and reach out for more knowledge to help me land the next job. I came across the ISTQB. An organization that promises software testing qualification certification. I figured this would be a great way to prove my to employers I know what I am talking about. I started reading to prepare for the exam. As I went to job interviews I realized that not so many of the companies I applied for recognized the ISTQB certification when I mentioned I was preparing to take the exam. I had watched videos from James Bach and Michael Bolton (great testers, not musicians) about how the ISTQB certification had no value in their opinion and potentially worse, it could lock you into an incorrect view of how to approach testing. With this information I stopped my efforts in getting certified.

Looking for a pay cheque while still trying to advance my skills I took a contract job that under paid heavily. It was enough to cover bills, but it wasn’t even proper testing. I did data curation. Ensuring that an internet scraper pulled down and properly registered software licenses for open source code. The one benefit to this though was that it got my foot wet in the world of contracting. It felt freeing to not really have a manager. It felt empowering to know my work represented myself. Since I was a contractor with a short contract time I was recommending a lot of improvement for inefficiencies I noticed without worry of being let go. I even created a little chrome extension to assist us when looking through github for licenses.

After this contract was over I moved over to a company that hired me on as a full time employee but contracted me out to other companies. This type of work was a very unique experience to me at the time. The office and work environment was just completely different, with desk hoteling and everyone working on completely different projects, not working together towards a main product of their own. I got some opportunities to work on Protractor while ‘on the bench’. I was stationed on site at a customers office for 3 months working from inside a small boardroom with 2 other contracted developers and 1 in house employ to guide the work. This was a cool project from the stance of porting over an iOS and Android app to Blackberry 10 operating system. I grew to dislike the Blackberry operating system, which I guess my feeling was correct as 3 years later it was a market failure. I noticed while working with this team there was a big difference in expectation and approach to testing that did not follow in line with my new school of through.

For 3 years I worked for a larger company than I was used to. I found this company via Twitter after contacting James Bach and Michael Bolton to ask if they knew of any companies using their Rapid Software Testing. They retweeted it out and I got a response from one of their followers. During the interview I was able to connect on RST. This was a promising start. It turns out the company actually had a great Agile practice going on. I had some struggles early on convincing the company/team of the correct tools to be used for their automation needs. Only near the end of my time there did they finally start following my recommendation. I had some great experiences working directly with developers to iterate rapidly between bug finding and repairing without the distraction of documenting the work. This is also where I got to experience mob programming. We mobbed as a complete team on developing APIs. Learning more about APIs and implementing the various levels of test automation I feel was a milestone in my career.

Another milestone while working for this company was joining their cloud teams. I got to experience some modern technology here finally. I started with testing the web application built using cloud technology. This was not very exciting as testing the front of a web application basically feels the same no matter the underlying tech. However, when I started to work on the infrastructure side of AWS I was happier with my work. I find that I really like a more supportive role when I am developing. I continue to be interested in AWS and am finding opportunities in my new work.

Currently I am early days into a new company that excites me. I am working on projects that I enjoy and expanding on my existing skill set. I plan to spread as much of my knowledge about testing as I can to others here and build my mentoring skills.

Going forward, I will try to plan out my next step. I will start to narrow down how I’d like to specialize my skill set and focus on a deeper understanding.