Lots of good advice here. Here’s my perspective, as someone who started out to be an English professor, and who has managed support and QA departments, as well as having been a product manager and a VP of a software company.
Don’t overlook QA (Quality Assurance) and testing as routes into a technology career. Along with support, it’s probably the best way to get in the door without a great deal of prior experience, and it can lead to a variety of other positions in a tech company (programming, training, product management, etc.). In particular, consider looking at software/hardware companies that create products for the health care industry. This promises to be a fairly downturn-proof segment of the business, and it would allow you to leverage skills and experience you already have. As a QA and support manager, I loved finding someone with sufficient technical aptitude and some subject-matter knowledge and experience that was relevant to our products. While the picture’s a bit different than a year ago, it’s still difficult to find and retain good support and QA people, and one of the prime means for doing so is to invest in additional training and education for good people, so that you could well be able to get the training and education on the clock and on your employer’s nickel. As for opportunity for advancement, the biggest obstacle in support or QA, if you’re good, is simply that you’re too valuable where you are. QA and support people typically get to know how their products really work better than anyone else in the company – how much that’s appreciated is a function of the company culture and a host of other factors.
In particular, your interest in scripting would stand you in good stead in a QA position; nearly every QA team uses scripting and automated testing tools to some degree, and facility in this area will take you a long way. If you think scripting and automated testing is an area that would interest you, you’d be well served by taking a general introduction to programming course, as well as one or two courses each in scripting (e.g., PERL) and in a particular programming language (C++, unless there’s a compelling reason to do otherwise). These need not be accredited university Computer Science courses; junior college or continuing education courses would serve, since the goal is really just to ensure that you understand general programming concepts and have a familiarity with accepted practices in scripting and programming. Most automated test tools use either a PERL-like or C+±like syntax and structure, so this exposure will directly benefit you there, even though the vocabulary and details will be somewhat different. Having this general knowledge will also help you communicate with, and win and maintain the respect of, the programming staff, which can be crucial in designing effective test suites.
It’s not uncommon for successful QA engineers to be transferred to the programming staff, if they’ve shown an aptitude for it. The downside to this is that there’s no secret about it, and both QA and programming managers can be somewhat suspicious of QA engineers who’re too eager to become programmers – especially QA managers, who don’t want to invest a lot of money and time in training staff only to have the programming staff reap the benefits. It’s also not uncommon for successful QA engineers to move into other areas of the business, such as product mangement, if they develop a solid grasp of the business.
The downside of QA is that there’s frequently less respect for QA people than for any other department in the company, with the exception in some cases of the support department. The programmers dislike that you’re always finding the problems in their code; the product managers and marketing staff dislike that the product can’t ship yet because of all these problems you keep finding, etc. In a poorly run company, it’s easy for one or both of these groups to run roughshod over the QA team. QA frequently gets the releases from development late, with insufficient time to perform even a subset of the testing that ought to be done. Frequently, the requirements for the product are incomplete, out of date, or missing completely, and without good requirements you have nothing (other than instinct, insight, and experience with analogous products) to base your testing on. It’s frustrating in the extreme to keep reporting the same problems in version after version and have them dismissed as minor issues until the product manager encounters the problem during a demo to a customer, at which point it becomes an all-hands-on-deck emergency.
If you think you’re interested in exploring QA, I’d suggest taking a look at the web site for Software Testing & Quality Engineering magazine, at http://www.stickyminds.com . In particular, I’d recommend an article by Bret Pettichord that details the differences in mindset that distinguish good software testers from good software developers; it may help you decide where your talents and interests lie. The first few chapters of Testing Computer Software by Cem Kaner, Jack Falk, and Hung Nguyen give a very good overview of the testing process.
