How much QA work should I be expected to do in an entry level software engineering position?

Question

Two years ago, I was hired right out of college as a 'Software Engineer in Test' which I was told was going to involve mainly developing frameworks to support things like load testing and UI automating scripts, developing various tools to be used internally, etc, at a company that has < 40 full-time developers. This was not to be a QA position, nor a unit test writing position, I was told more than once in the interviews. Not the best job in the world, but a it seemed like a good foot in the door.

The problem is, is that increasingly I have been 'temporarily' put on preforming manual testing for QA because of an upcoming release, which is a job that makes me wish I ate eyeballs for a living. This happened for perhaps 2 days or a week every couple, three months in the beginning. Although recently it has been occurring with increasing frequency, and for longer periods of time (This last run has been a month at this point).

My question: is this kind of thing to be expected in an entry level job, or any job, or is this case of a company taking advantage of me and it is time to move on? How much QA related work should someone who is employed as a software engineer be expected to preform?

Answer 1

To me 2 years out of college hits the magic number. If you're not content with the work you are being assigned I would first speak with your manager, i.e. a good will effort to improve your position. Failing that I would start looking around. Two years experience gives you enough to move to a 2nd level programmer position at most places.

Also if you speak to your boss first they can't be surprised when you give your two weeks.

Oh and the actual answer to your question. You can be expected to do as much QA as you were told you would be doing when you applied and interviewed. In your case that seems like not much.

Answer 2

I don't think this should be in your job description at all. For several reasons, the first is that testing and QA is a real skill, and on that is quite different to software engineering, and your company should have QA professionals to do this. The second is that it sounds like you are being put on this role as some form of fire-fighting because the products that are being developed are finding lots of bugs in them just prior to launch. This is a sign that the development process should be improved, while what you describe sounds like it is in fact getting worse rather than better.

On the flip side though, its really good experience for you to have some experience of testing, and you can use the experience as a positive to help you predict what is likely to go wrong when you are writing your own code. Not that i'm trying to say whats happening to you is OK, just trying to find a positive in there somewhere

Answer 3

At a decent software engineering place, you should perform very little. The mentality between engineers and QA people can be quite vast. What makes sense to us won't to most other people. Programmers think differently. Our brains are wired differently, and we are in a field that focuses on that difference. That is why we are programmers and other people aren't. That isn't to say that you shouldn't test your code or look at someone else's every once in a while, but you most likely won't excel at it.

Companies which say that devs should also test are fooling themselves in my opinion. When they tell you you're going to test also ask them this: What's there on time completion rate vs. their schedules? What is there percentage of defects of software after shipping/moving to a production environment. My guess is that they don't know, which is a real warning sign that you're going to walk into a bad environment.

Read McConnell's books on software engineering. When you walk into an interview make it clear to the people interviewing you (not hr people) that you understand what we do is an engineering process and that not following it causes problems. If they don't get that concept walk out the door and don't come back.

Answer 4

Have you talked with your manager about your frustration? Does he/she have a clear picture of the position and career you envision yourself in, and do you think they understand it?

Sometimes it is important to firefight, which I think you seem to agree with. However, at some point you need to make a decision whether or not this job will take you down the path you want to head. If this is a company constantly firefighting, they may not be able to help you regardless of their desire.

Good luck, and try and keep the communication open.

Answer 5

QA is a separate profession, don't be fooled into taking a QA job, you are going down the wrong track. Now if you have to QA your own code, that's fine.

Answer 6

It depends. Are you being reasonably compensated? If you are, then the company is not taking advantage of you. They are paying you to accomplish a task that they need done.

Almost all contracts have a clause you sign that says you will basically do any task that a company asks you to do, regardless of the job description.

If you really don't like it and want to be moved to working on the code for the application that you are currently testing, you should have a frank, respectful talk with both your direct supervisor and your HR representative.

If that conversation does not result in the situation changing, at that point, you should make the decision whether to move on or not. Obviously, when making that decision, you should take into account your holistic situation.

As a developer, I have to do more QA than I would like but we can't afford a dedicated test engineer. On the positive side, at least we don't work at Lehman Brothers.

Answer 7

Sounds like you fell for the old "bait and switch", my friend. Like others suggested, have a talk with your manager. If he can't help you, GET OUT ASAFP! Right now you're in a good position -- you still have your development skills, but you have better-than-average skills in QA. However, if you stay much longer you risk being pigeon-holed, and stuck in QA the rest of your career.

Answer 8

No one can point out a time limit where this should change. In fact it probably won't change unless you make it.

It's likely that your adequate at testing, which over times becomes your status quo (pigeon hole, etc). Which means management is unlikely to give up your testing productivity to just give you a shot at something else. Why should they ?

Why ? You have to show them why. Your not going to break this mold in an instant. I'd start with the following which should start to show people in your organization that you have value outside of manual testing.

• Code inspection can be a great way to find defects
  • you'll have a greater understanding of the code base
• Include line numbers, fix recommendations, etc in your testing report.
  • As your test reports become more detailed, it will be evident to others that it's more efficient for you to just work on a few of these issues.
• Why settle for manual testing ? Can you automate any of the testing ?
  • get rid of your job and pick up one you want because the tests run themselves
  • see selenium (web testing) xUnit, FIT, etc.

Is the company taking advantage of you ? Probably not as much as they should be.

Answer 9

The words "in Test" in your title imply your job is a QA related job, so you should be expecting to do quite a lot of QA-related work. If you find the work boring, find ways to make it less so. First come up with a really efficient way of describing the tasks you're actually doing now - a full test specification - such that the task requires a minimum of thought - you're just checking items off in a big table that describes exactly what you do, in what order, what result you expect, and whether you got that. Make the task so well-defined, so cookie-cutter, that it might easily be passed off to someone more junior or - better yet - automated. Try not to be indispensible at tasks you don't enjoy! If there are tips and tricks to doing the work that make you more efficient at it than your peers, write them up in FAQs and white papers and in the test documentation and tell people about these documents you've written.

Then invest brainpower in simplifying further. Write test frameworks. Write UI automating scripts and use automating these tasks to hone their effectiveness. Carve out regular blocks of time to invest in improving the test process rather than simply running tests. Don't ask for approval to do this, just do it.

Keep in mind that part of your job is always to figure out what your job should be. Everybody has to do a certain amount of work that is boring but if you think you are capable of doing better things, seek out and find a way to exercise the skills you care about more. Don't wait for somebody to assign you the tasks you want to do - actively find such tasks that need doing and volunteer to do them. Or just start doing them and report that that's what you've been doing in your status reports. Don't leave it up to your manager to entirely determine the kind of work you do and how you do it.

And if you have concerns, if you have preferences, voice them! Don't make them guess what you want or what you're not happy with, and don't just leave for another job before you try to fix the one you've got.

Good luck!

Answer 10

Well, usual answer to this question is about two years that most people accept to waste on that.

However, unless you aim at a QA career, this time will effectively be lost for you. Whatever the tester do, they are usually not engaged in any kind of "creative" activities. Well, really professional testing environments can be an exception but you are probably not in one of those. The real danger is that after two or so years you attempt to apply for another development job, your future employee will not regard you as a guy with two years development experience. If this is a problem for you, then better act now.

A few years ago I also found a developer job. By that time I also had just a half year of experience, so it could be considered as an entry job. So I took it just to learn they intended to use me as a tester at least half of the time. I didn't understand nor appreciate the joke, so I left by the end of the second month.

And answering your question directly. A developer is supposed to perform that amount of QA work which will allow him to make statements on his code like "I finished implementing that. It works as supposed. Now's the time for QA team to think of all unthinkable scenarios and try to break it.".

Unless agreed otherwise during negotiations at the beginning, a decent place should not put you in the unexpected role. Well, of course, if something major and unexpected happens to the company, like at the release time all testers suddenly got ill and your release is on the verge of collapse then of course you can be expected to lend a helping hand.

Answer 11

As many other people have mentioned, if doing QA was part of your job description then you shouldn't be surprised to do it (although it sounds like you weren't supposed to be doing QA).

As many other people have also pointed out, regardless of your job description you are going to be stuck doing whatever it is your employer tells you to do, so if you are doing QA then you need to decide how to proceed based on that fact.

As has also been mentioned, QA is a separate profession, and generally speaking there is no reason to expect a QA person to be programming and vice-versa. There is no "starter period" where programmers are expected to do QA and work up to actually programming, there just isn't. There is a very simple reason for this - programmer time is skilled labor and expensive, QA isn't (I know that may not be entirely fair, and in my experience QA people tend to get less credit than they deserve, but from a business perspective that's how it is). Programmers, because of their skillset, can get programming jobs that pay programmer salaries. QA people, because of their skillset, can get QA jobs for QA salaries. One possibility is that your company is not using their resources effectively, although that assumes you are actually being paid a programmer's rather than a QA guy's salary (if you aren't properly compensated that in and of itself is reason to look for a new job). If they are paying you a programmers salary for doing QA then technically you are taking advantage of them (...from the market's POV, even if the job doesn't make sense for your career and drives you nuts).

But the bottom line is there is simply no reason to take a QA position if you are a programmer unless that's what you want to do. From a career standpoint you will be building the wrong skillset and losing time that you could otherwise be spending developing your real career.

One possible mitigating factor here is that you mention this is related to an upcoming release. It is not unheard of in the late stages of development when it gets really close to release time and the product is feature complete and just going through QA and bug fixing, for pretty much everyone to switch gears into a phase of just banging on the product and finding and fixing bugs, and at that point even the programmers (the ones without open bugs anyway) are effectively doing QA. But you make it sound like this "upcoming" release has been going on for months and months, and I didn't really get the impression it was that type of situation.

As a helpful hint, maybe you don't entirely realize it or are trying not to admit it to yourself for some reason, but you must be at least 90% aware that the fact that you asked this question means you should be looking for another job.

Answer 12

"Software Engineer in Test" sounds like a QA job to me...