12

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
Macy Abbey
  • 667
  • 1
  • 7
  • 15

8 Answers8

12

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
6

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).

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • True Jeff, but I think that first approach doesn't necessarily teach them the tools they need to become more efficient/robust programmers. It does put the pressure on though, which is good. – Macy Abbey Nov 27 '10 at 02:12
  • Also, one of the negatives to this approach is losing a programmer for some period of time, one week...two weeks, a month? And I don't think it's a good idea to have them do jobs which have very little to do with their current job...(scrubbing the toilets :P) – Macy Abbey Nov 27 '10 at 02:13
6

"...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.

the Tin Man
  • 1,122
  • 8
  • 10
  • Hi Greg, I asked the question thinking of a software engineer who is new to the field, and does not understand the value of QA, and who has not had much experience developing towards a set of well defined acceptance criteria. The reason I chose "have to" is because as you said, I don't think many software engineers would choose to work as a quality assurance engineer (as their sole duty) because they clearly chose to be a software developer. I definitely appreciate and share your perspective on what a truly good software developer's attitude and relationship with QA should be. – Macy Abbey Nov 27 '10 at 19:45
  • Do you think having a new software engineer work as a QA engineer would help them reach the point you are at now? – Macy Abbey Nov 27 '10 at 19:45
  • 1
    Absolutely not. Make sure they understand how teams work; Develop an attitude of ownership of problems; Culture an open atmosphere that encourages people to work in ad-hoc teams to discuss and solve problems. Too many people and companies encourage silos of knowledge and an "us against all of them" attitude. Honestly, the "us against all of them" needs to go away inside company walls because it hurts everyone. – the Tin Man Nov 27 '10 at 19:58
  • 2
    @Macy Abbey, one tactic to consider might be to have developers work in concert with the QA team to develop the testing scenarios. The unit tests could be written and designed in tandem, or the QA team could add their tests to the "tests" folder where the developer has unit tests. Some people think there should be separation between dev and QA but that fosters the competition. If both groups use their eyeballs and testing tricks together maybe they can ferret out the bugs and missed features even more quickly. – the Tin Man Nov 27 '10 at 20:06
  • @Greg Thanks Greg, that sounds like a good tactic. I do believe you have convinced me that a mixture of other tactics are better than what I initially proposed. – Macy Abbey Nov 28 '10 at 02:47
  • @Macy: How do you force one to work in QA? Assign most software engineers to QA and they'll quit on you at the earliest opportunity. There is no certification authority, so you can't have it as a certification requirement. – David Thornley Nov 28 '10 at 03:18
5

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.

Michael Shaw
  • 9,915
  • 1
  • 23
  • 36
  • 1
    Thanks Ptolemy, I make this 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. – Macy Abbey Nov 27 '10 at 19:48
  • It's not just that they'd be not working in a position they were hired for, they'd also not be in a position they chose as their profession and went to school for. That is a major slap in the face for a lot of people who put their hearts into their career. For the ones who only consider a job as a paycheck it'll be fine. – the Tin Man Nov 28 '10 at 01:20
  • @Greg: The ones who are in it for the paycheck won't like it either. Their resume will be more valuable with X+1 years of software engineering than X years of software engineering and a year of QA, at least early on. Not to mention you have to pay your QA people as well as your software people, because nobody in it for a paycheck will willingly accept a cut in pay. – David Thornley Nov 28 '10 at 03:20
  • Er, that assumes you're working in a place that pays skilled QA folk less than devs. I know some places do, but it doesn't reflect my experience - when I've known people's salaries they've generally been on a par. – testerab Dec 05 '10 at 03:50
  • 1
    In the early years of being a programmer, your salary is very dependent on how many years programming experience you have. So having 2 years C# and 1 year QA puts you on a 2 year C# salary rather than a 3 year C# salary. – Michael Shaw Dec 05 '10 at 10:56
3

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.

Roopesh Shenoy
  • 827
  • 5
  • 10
  • True Roopesh, although I think there is definitely an intersection between the two skill sets, where working as a QA for a small timeset will increase the speed at which someone improves their testing skills. – Macy Abbey Nov 27 '10 at 19:50
1

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.

testerab
  • 832
  • 6
  • 11
0

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.

Omega Centauri
  • 1,038
  • 5
  • 8
-2

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.

Panjiyar Rahul
  • 99
  • 1