This is admittedly a glorified About page blog post (and will probably actually function as my About page I think) but it is the first post in the Software Testing Learning Mindmap series and covers the Intro section on Dan Ashby’s mindmap.
Story of Becoming A Tester
I used the graphic above in a career presentation I gave to my son’s middle school (6th – 8th grade students) because I think it can aptly describe a career path that many take to become a software tester. While a degree in computer science or information systems is still a pretty common (perhaps most common) pathway, at my current employer 3 of the 5 testers have come into the profession from a pathway that doesn’t involve one of those degrees.
I graduated from college in History Teaching and began teaching middle school history in Arizona, USA. I spent 3 years me in the classroom (two of those as the computers teacher) including building a PHP application I ran from one of the Macs in my computer lab to help teachers with one of the hourly processes we had to do. After that I moved through educational technology positions at the district and state level before grant funding eliminated my role at the state department of education. At that point, I decided it was time to consider a career path change. I had done some website development and consulting throughout those ten years and began looking for an opportunity that would allow me to jump into software development full-time. A QA job with an organization I admired came available and so I applied and started my first job as a software tester.
My first software testing job provided a great opportunity to immerse myself in software development and the software testing discipline. I jumped into learning all I could (and I had – and still have – a lot to learn), including with the support of my employer attending a conference each year (STARWest, CAST, and STPCon) as well as taking all of the BBST courses offered by the Association for Software Testing as well as a great (and extremely hard) Domain Testing class by Rebecca Fieldler and Dr. Cem Kaner. I became familiar with the different “schools” of testing and felt like much of my learning and experience aligned me more with the Context-Driven School of testing. The two teams of developers I supported operated semi-Agile’ly’ and we weren’t doing much in the way of unit or integration testing, so I did much of my work as manual testing (yes I realize the “controversy” around that term) of our applications. I dabbled in Coded UI tests since our technology was .NET thick clients, but found them brittle and difficult to develop for our complex apps. I managed much of my work using session-based test management exploratory testing (more on that later) though I wished we had more testing layers so I could focus on more detailed and complex user scenarios than the basic functionality I was “checking”.
After about three years, I began looking for some more opportunities to learn and grow and joined a healthcare IT/data startup. Over the last nearly two years, I have wrestled with some data warehouse testing issues, web testing as well as continuing to test thick client apps. I have had opportunities to explore the value of layered testing from unit on up through acceptance tests and how to mitigate risks and gather information by testing at the layer closest to where the risk of failure exists. I have also begun learning about testing in a continuous delivery/deployment release cycle and the challenges that presents (regression testing in any way but automated is impractical) and the role that exploratory testing plays in that process. We are currently very much in a DevOps-type of transition and I’m loving the new testing challenges and opportunities that it is bringing, especially in spreading effective testing across teams/roles so we can confidently deploy our products at any time (at least that’s the idea).
I know that is more background than anything, but these are the experiences and pathway that has brought me where I am today in testing and it’s been a fun journey that has challenged me (and continues to do so). Next post is about some more meaty stuff, What is testing? – a topic which can include some “fighting” words depending on who you are talking to and one that certainly reveals a lot about someone involved in software development.