For the last year and a half I've been working in IT quality assurance as a team lead for a small IT organization. To be completely truthful team lead may be a bit misleading right now as our QA team consists solely of me. It's not all that bad, though, since I generally get along with the people on my team (read: voices in my head). Oddly, though, when I look back on my career history and where I thought I was going coming out of college, QA was never a place I thought I'd find myself but somehow... well, it is a good fit for me.
I went to college at St. John's University in Collegeville, MN from 1999 to 2003 and graduated cum laude with majors in both computer science and philosophy, not exactly two majors that you would think go together, but I loved them both... to certain degrees. I came into college extremely focused on my computer science major. I loved technology, had dabbled in BASIC programming (yes, I realize how lame that sounds), and wanted so badly to get through college so that I could get that 6-figure salary working in a cushy office coding at my leisure. Well, that was until the tech bubble had burst and I came to realize programming might not be the thing for me.
As I took more and more of my computer science classes, I found a sharp distinction between those I loved and those I loathed. Anything conceptual I was mesmerized with; anything coding related I slogged through not really enjoying. It was this realization that led me down the path of also pursuing a philosophy degree (it's all about concepts) to augment (or offset... I'm not sure which) what I was doing with getting a computer science degree.
When I dipped my toes into the real world I had an internship for two summers at the same company working on simple coding for a project that didn't appear to be really going anywhere, but it was experience, right? Being dumped into an environment where there were already thousands of lines of code, various technologies being used, and conventions that I wasn't used to did not bode well for me. I spent altogether too much time poring over the little details of how parts of the application worked, I used up a lot of time experimenting with my code to see what different results I could get by changing small things, and, since this was an internship, I played a lot of office games with the other interns and some of the funner programmers.
I quickly learned that programming for 8-10 hours a day wasn't for me, but I still loved technology and had a natural knack for writing (and could churn stuff out pretty quickly) so as I graduated from college, with the dot-com bubble explosion still looming over the tech industry and my not really being that interested in actual programming, I signed on as a technical writer for the company I had interned with. This was actually a pretty solid fit as I was still in the technology world, but I was focused more on writing. As I crafted a 250+ page opus of a user manual for a relatively established software package (that simply didn't have a manual up to that point), I found myself playing a lot in the application, pushing boundaries, and being a little too OCD about functionality... I was essentially doing black box and usability testing of the application while working on the manual, but didn't realize it.
My next move was to the business team for the same employer, working as a business analyst. Essentially I interacted with the company's clients, the business team, and development to see where changes/upgrades/fixes were needed and then write the corresponding requirements documents and specifications. It was interesting in that I was tasked with creating documents that straddled a very thin line between being understandable by the business yet getting across enough specificity that our developers knew how to implement and code the requirements. I found myself drawn to the more complicated requirements where I was forced to search for every possible scenario that could be encountered and specifying the desired outcome. I was intent on making sure every base was covered. I was, in essence, creating test scenarios and use cases that not only translated to development of the application, but fit nicely into a QA format.
Eventually I moved on to another company, this time as a "technology specialist" (quite the ambiguous title, eh?). My job consisted of a myriad of tasks--application configuration, documentation, training, and performing user acceptance testing of applications our team would be using. I was moving on from dipping my toes in the QA waters to actually stepping in to see how the waters felt. I ended up being meticulous with my testing and kept a number of application releases from seeing their scheduled production go-live dates because of issues I had uncovered, which sucked for getting things deployed on schedule but was great for me as it was pointing me in a direction of something I might have a knack for...
This leads us to last year when I was officially given the reigns of a QA team (consisting solely of myself) and practice (which previously didn't exist). It seemed like a natural progression from the path I was on, but I quickly realized that, hey, I was never actually trained in QA! No formal training, no tutelage under another QA professional, no involvement in a QA team... everything I knew was from first-hand experience when given the job of "making sure something worked."
It's worked out well so far, though, as I've continued to take everything I've learned, add some gradual maturity to it, figure out what does and doesn't work, and do the best I can. I've started some training through IIST (working towards my CSTP-M certification) to fill the formal training gap that's missing, I'm trying to read more blogs on the topic of QA, and am trying to interact with other QA professionals through social networks. And, since I seem to cover just about every other topic under the sun that I'm interested on this here blog, I might as well write about my experiences. It might just provide to be helpful for other people that have stumbled into the QA world by accident or, at the very least, give seasoned QA professionals something to snicker at!
No comments:
Post a Comment