Michele Martone

I currently work as a QA manager for an automation team. I value and hire people that can understand and write tests using programming concepts. We use Silktest which has a language that is roughly based upon C. I can't speak about other QA tools, but in Silktest we have common includes which are functions that we can all share. We have coding standards, and we try to create readable test scripts. We have weekly code review meetings to ensure we are creating consistent scripts. So yes, in my team you would have to "program", but it's not as detailed as in our programming team.

Our QA people need to really understand our business also. To me the scenario creation is a fun time because I get to use my business skills, and then figure out how to invoke the scenarios with the QA tools I know.

We also have manual QA testers. If you join a manual test team you will not program. This team runs through a checklist of items that could not be automated for every release. They also must be strong in business, but not strong in technology.

If you go for QA you want to join a company that values QA. If the company values QA you will be paid fairly well if you do automated QA. Not as well for manual QA. If they don't value QA then the team will have no influence and you don't want to work there anyway. So make sure to ask them how much say QA gets in releases, how involved QA is in each production release, and who QA reports to in the company.

In my company we have two types of roles for Production Support. One role are people who watch our overnight jobs. That person knows to some extent how to trouble-shoot jobs to get them started in case of failure. Otherwise they will contact the right person who can fix the problem. Mainly they watch critical jobs though. This first role is not onsite.

Our day time production support is more skilled. They have to be more knowledgeable people because they are business facing. If our business has an issue they call this group. The group needs to know how all of our applications work and how to quickly fix issues. This area is also on call on a rotating basis to help out the overnight support. These people usually come from the business, and also have a desire to know more about how the technology works. This second role must be onsite in my company.

In my company 24x7 means that on a rotation you may have to be available outside traditional working hours.

I went the other route - I am a CPA who is really interested in technology and decided to get a programming certificate. This was a formal program that I started it in 2000 and finished December 2001 all the while looking for positions that used both skills (in a really tough market). I can tell you that there are interesting positions, but noone is quite sure how I fit into them. The most common role employers see me in is a QA role, business systems analyst, or project manager. Of course, it helps that I am in the NY area, surrounded by financial companies. I am not sure if I could get a position that is non-financial based.
It's interesting, the programmers ask me - why didn't you stick being a CPA - don't they work less hours and make more money? (No to both questions.)
Basically I did this because I was really interested. I figured that by adding skills the market would come to me. It didn't turn out quite as good as I expected, but I am challenged by the work I'm doing, and I had great fun learning these new concepts.