Do you believe it's a good idea for Software Engineers to have to work as Quality Assurance Engineers for some period of time?

Question

I believe it is. Why?

1. I've encountered many Software Engineers who believe they are somehow superior to QA engineers. I think it may help quench this belief if they do the job of a QA engineer for some time, and realize that it is a unique and valuable skill-set of its own.

2. The better a Software Engineer is at testing their own programs, the less cost in time their code incurs when making its way through the rest of the software development life-cycle.

3. The more time a Software Engineer spends thinking about how a program can break, the more often they are to consider these cases as they are developing them, thus reducing bugs in the end product.

4. A Software Engineer's definition of "complete" is always interesting...if they have spent time as a QA engineer maybe this definition will more closely match the designer of the software's.

Note I make above suggestion with a small time-frame in mind as I am aware having someone work in a position that is not the position they are hired for is definitely a recipe for losing that developer.

What do you all think?

Answer 1

1. I've encountered many Software Engineers who believe they are somehow superior to QA engineers. I think it may help quench this belief if they do the job of a QA engineer for some time, and realize that it is a unique and valuable skill-set of its own.

A good software engineering has a background in quality, including testing, metrics, and statistics. Anyone doing any kind of software development should be aware (if not familiar with) maintaining at quality source code and producing/maintaining effective test cases. Over time, I would suspect that any software developer would gain an understanding of the different facets of quality - code quality, portability, maintainability, testability, usability, reliability, efficiency, and security.

Software engineers might focus on a particular aspect of the lifecycle - requirements engineering, architecture and design, construction, testing, and maintenance. However, regardless of your focus (either as a job or at the current phase of the project), it's important to remember quality.

2. The better a Software Engineer is at testing their own programs, the less cost in time their code incurs when making its way through the rest of the software development life-cycle.

That might be true. But some issues are best seen later in development. For example, performance and efficiency issues might not be seen until integration. Having good, solid code and effective unit tests are just the beginning. Quality needs to begin with requirements, and follow all the way through maintenance activities.

3. The more time a Software Engineer spends thinking about how a program can break, the more often they are to consider these cases as they are developing them, thus reducing bugs in the end product.

That's a totally true statement. But then again, it's also up to the requirements engineers to verify that there are no conflicts in requirements, architects to ensure that the design actually addresses the requirements, and so on. Everyone should be trying to poke holes in their work and then working with the appropriate people to seal them up nice and tight.

4. A Software Engineer's definition of "complete" is always interesting...if they have spent time as a QA engineer maybe this definition will more closely match the designer of the software's.

"Complete" can only be measured against requirements. Either the requirements are satisfied and the project is complete, or there are incomplete requirements and the project is not complete. Any other measure of complete is useless.

Answer 2

"...have to work as QA engineers..."? You make it sound adversarial or punishment.

I am a software developer. I consider it part of my job to be a QA engineer also, even though we have a QA department. It's my job to deliver software that accomplishes certain things, and, to do that I have to write unit tests and make sure the software passes them.

I am in partnership with our QA department. My goal is to make their jobs easier, just as their job is to help me meet my goal of delivering software that does what it should, thereby making my life easier. I consider them my second set of eyes and somewhat of a safety net, just as I do my unit tests.

I choose to develop software, and want to develop software. If some manager came to me and told me I couldn't do that and had to do QA, I'd tell them they need to find a new software developer AND a QA person because I won't be working there. I am anal as can be with my code but the creative process and programming puzzle/challenge is extremely important to me. I'd rather go back to driving fork lifts if I can't write code because being in a corporate environment without the perk of being creative and being challenged the way I am would be absolute hell to me.

In general the options you present sound very adversarial and leave me wondering if you've had some really bad experiences with some terrible developers. In my mind, a developer must ALWAYS be aware of quality issues and testing and should be proud enough of their work that they don't consider it finished until it passes as rigorous tests in their unit testing as what the official QA department will use. If I had a peer, or was tech-lead on a team and had a developer who showed any "'tude" toward QA he'd find me hauling him off for an attitude correction. If both sides of the software-delivery coin can't cooperate and act as a team there is a real culture problem. I wouldn't want to work there and HR, along with upper-management, would need to be clued in.

Answer 3

Making programmers accountable for their code and requiring them to fix their own bugs can take care of this. That and a loss of bonus and/or job.

Not that this experience wouldn't help, but how far can you go with this line of thinking? Technical Support, Sales, Beta User, scrub the toilets (that would be a humbling experience).

Answer 4

Getting programmers to work as QA engineers is a recipe to lose your best developers. Programming and QA require different skill sets and thought processes.

However, It is important that your programmers are skilled in the art of testing and validating their own work before passing it to the QA team. Developers and QA have access to different tools, knowledge and skills. The developers need to be skilled at steping through their code looking for unexpected behavior, unit testing for boundry conditions, stressing threaded code looking for race conditions etc. i.e. Testing from a developer perspective.

QA do their testing from the user perspective. Thinking like different types of users, inventing strange edge cases, and making obscure problems reproducable are QA skills.

Answer 5

Not necessarily - both programmers and testers are required to have different skills. Just because you are a good programmer does not mean you can be a good tester (many people dont understand that, but being a programmer does not automatically qualify you to be a tester).

A great tester needs to have really devilish skills, be able to do things that the software was not designed to do, but can expect the user to do in the real world. That takes skill, patience, ability to see what can go wrong where, an understanding of the user's mentality and so many other factors.

Note that I use the words programmer and tester - but if you are a software engineer and not yet decided whether you want to be a programmer or a tester, then it encompasses both these things and hence yes, you should have experience in both at least in the first few years of your life before taking the decision.

That does not mean that you take an experienced programmer and make him test for a while just to make him understand how hard the QA engineers work.

Answer 6

Here are some potential problems I see with your proposal:

1) If you're suggesting that you would put new-to-the-field software engineers into the QA department for a short stint, won't this just have the opposite effect? - they may assume that QA is something you do when you're a newbie and you don't understand what you're doing - after all, that's how it worked for them.

2) Being a very bad tester for a while will not necessarily teach them anything valuable. But it may make them unteachable later on, because they will assume that they know all about testing now, because they spent 6 weeks in a test department once upon a time.

3) Given that they'll obviously only be there for a short time, and the QA dept will know this, it's also likely that they will only be given relatively undemanding, easy tasks that require little supervision or understanding, but which keep them busy. This will only reinforce 1 and 2.

4) If you want to avoid 1, 2, and 3, how will you persuade your test department that it is worth investing a tremendous amount of energy in teaching and supervising someone who isn't even interested in testing? (I can tell you, it takes a scary amount of time and energy to work with someone who, let's remember, hasn't been picked for their testing aptitude. You're not offering the test team additional resource for a few weeks, you're asking them to lose one of their most experienced people for a few weeks, while they teach your newbie).

Having said all that, I think your overall goal - to increase new software engineers' understanding of testing - is really fantastic. I think that Greg's suggestion is more likely to achieve it though - get your dev & QA teams collaborating closely together, and work on breaking down any barriers between the teams. (I'm currently working in a company where testers and programmers are on the same team - it really is great, and I never want to go back to working in separate teams.)

If you're still keen on having programmers do a stint in QA - here's a suggestion: lead by example. Go yourself first. Perhaps make it into something members of your team get to do when they're already good, and want to get that extra edge, by spending a little time each week with other teams who specialise in overlapping areas - test, DBAs, etc. If you present it like that, then you'll have more chance of success.

Answer 7

I have had sort a career path thats kind of the inverse of what you normally see. I started as software support for scientifically challenging physics, then ended up working in the intersection of architecture, programming, and algorithms for a computer company. After that ran off I did performance optimization of a major engineering code for several years, but even that work ran out. Now, that I'm nearing retirement age I'm doing QA on the same code. It is a combination of challenge, and drudgery. We have a really sharp new guy working 100% on bug fixes, and I spend a lot of working with him. It is a challenging position, and you can learn a lot doing it. At this point my main interest in profesional development is for my twin boys, who are comp sci college freshman. So I have new interest in learning (or relearning) stuff that will be relevant to their careers, especially applied math. I have a different perspective of things now that I am concerned with QA/validation, wheras for the previous quarter century it was speed,speed,speed at any cost.

Answer 8

Software testing is the destructive process rather than constructive. But programmer think of constructive to their product to ensure the product completed on time and with in budget. If software developer think like destructive of their own product then who will be next to built the product. So each portion of software development cycle must be done by the people assigned in each portion of development cycle. If you engaged in two or more field then its is sure your will never be perfect on any of them so do one things either programmer or QA or any other options and be perfect on that.