Team-BHP (https://www.team-bhp.com/forum/)

-   Shifting gears (https://www.team-bhp.com/forum/shifting-gears/)

-   -   Software Dev. Engineer v/s Software Test Engineer (https://www.team-bhp.com/forum/shifting-gears/36206-software-dev-engineer-v-s-software-test-engineer.html)

Hi guys.. had this question in my mind.

How does a Software Engineer (Testing) compare with a Software Developer, in terms of:

Learning Opportunities
Compensation
Growth prospects


Lets say in the field of Telecom Software.

Both these roles are important in their own ways and have their own challenges. It all depends on person's interests. I believe that Test Analyst will have more opportunties to learn the functional side of the domain. Some bit of technology is also required depending on the kind of testing. So if the person is interested in building skills in a domain (Telecome or any other), Test Analyst role is more suitable.

Compensation should be same. I believe education background and experience are key factors that decide compensation. Growth opportunities will also be same.

The demand for Software Testing Engineers are growing day by day.

I just fear that the software testing profile might become a little monotonous.

IMO, a good test engineer learns more than the developer. As akbaree mentioned, the compensation should more or less be the same. Sometimes, I do feel that test engineers are not given their due at most places and always considered "inferior". That view is changing though and for exactly this reason, I feel growth prospects would be pretty good...

Learning opportunities, well, as a tester , your learning will be along the domain side, About how the telecom software is supposed to work. the terms and definitions of technical terms which are used , You'll get familiar with the business rules of how telecom businesses work. Say you had to test a broadband usage metereting system. You would have to know the difference between KBPS and kbps , upstream and downstream, latencies etc. while this may sound technical, this is only because this is the telecom domain. If you , say got banking domain, you'd have to learn some banking related stuff like accounting and balances .Besides the domain stuff, if you're into automation, then some amount of scripting in whichever tool you're using will be involved for automating tests

A developer on the other hand also needs to know his domain, but his main ability is his coding/development skills.A developer learns more about the technology behind it, while a tester learns the domain. In addition, a tester usually gets (and needs ) the big picture , while the dev just needs to know his module as the tester has to check the whole thing, while the dev just needs to take care of , say report generation, or measurement , or GUI etc. This is because a development takes more time than testing. what a dev takes a week to complete, can be , and usually needs to be tested in a day. In addition , since testing is also known as "quality assurance" you can, if you're interested, hook onto the quality bit , and learn more about CMMI etc. Devs also do end up testing as well, mostly unit testing their induvidual modules, or sometimes in complex integration testing cases. bottom line is , the tester needs to know how the whole app runs , while the dev just needs to know how his code should run.

Compensation, in my organization is the same as a dev, but testing projects command much higher profit margins compared to dev projects. But no , we dont get any of that cash. No idea about averages. I was recruited as a dev guy and then put into testing, hence the same pay.

Growth prospects , at least in my co is superb (at least thats what we've been told ;))
bottom line is , as a tester , you need to have the big picture, which helps when you get into management. And then there is the quality aspect as well. testing folks at my co have high chances at going onsite , much earlier at that!( if thats what you want) and most projects have onsite offshore ratios on an average of 1:3.

Of course , bear in mind , your job will be boring, especially if you are put into manual testing , more so the repetitive ones. Automation ones tend to be a tad better.

but as always , YMMV

Disclaimer: These are my personal opinions and I work in the area of IC design not software. But, of late, the IC design and verfication has moved up in abstraction and has some semblence to software test and design.

I guess its a matter of personal taste, but, I would NOT want to do test if I am given a choice. Here are the reasons:

1. Drive: I personally felt, the drive to optimize things (optimize runtime for example by choosing a better but more complex algorithm) is higher, as your code will show better performance everytime it is run. (If it is ICs, as it was in my case, it would be lesser area, lesser power or more speed). With test, its runtime of your machine or compute servers after all.

2.Ownership: Its harder to associate very high levels of ownership with a product that you have tested. Associating it with something you've created comes naturally.

3. Work Life Balance: As a test guy, you are dependent on the designer to fix bugs to make progress. If the designer screws up on schedule, who suffers? Designer yes, because he deserves it, but the test engineer as well. Who is pushed to the wall to play the catch up game?

If you are a designer, you can test your code to a pretty decent extent beforehand. Nobody can stop you from doing that. If you are a test guy, its very unlikely that you will get the freedom to fix the source-code.

Thanks,
Su-47

EDIT: I just realized that my rants above apply to product companies. For service companies, the project could be sw-testing itself. In that case, things might be different.

Ditto here, IC design, but I have sat on both sides of the fence as well as top of it.
A developer develops more tool knowledge and a tester gets more domain knowledge.
When the gooey substance hits the roof the test guy gets more flak, because he said that the code works, the developer never said so.
On the Plus side when you find enough bugs that the project gets delayed, the developer gets slapped around and the tester gets all praise.
But there is another downside. some managers think test guys are "expendable", which is not the case. Many good projects I have seen have bitten the dust, because the manager thought "I need a good guy for dev, but for testing any monkey will do".

My personal opinion is that a tester need to posses the domain knowledge and common sense to do testing. But a dev needs to have a commanding knowledge of the programming language, more so when the dev is working on Micro-controller based projects where the hardware is driven by software.

My opinion is that a dev can easily move into testing, in the same domain. but it'll be difficult for a tester to move into dev because testing knowledge can be gained in weeks but a sound programming knowledge require months or even years to master.

But I like testing because it has relatively less preassure compared to dev. You get more on-site opportunities and it gives you a faster chance to move up the management if you are smart enough :)

But I work in a small team doing Image processing and optimizations code that runs on dedicated hardware and hence we do all the dev and testing ourselves. No separate testing team is involved and we only have quality checks in stages.

A good QA engineer is as important is Developer . Developer might develop the product .

QA engineers will critic the product not the developer .
They will refine the product .
Think product with respect to customer usage .
Release the product.
Help in good technical documentation and marketing(support from inside) .
Interact with customers in the time of escalations .
Sustain the product and future upgrades .
obviously find defects in the product . :)

Cant imagine a product without QA . None the less developing is also very interesting. Although developing can be complete , QA is never .

Coming to your points ,now think of learning opportunities ,compensation and growth .Its high .

Same with me
Didnt get this one. Management?
I somehow don't agree with this concept. Most companies leave synthesis, integration, formal-verification to another team. So, the tool angle is slowly going away. Only when there is a catastrophy (huge timing violation, or design is non-scanable) does the designer get involved.
The design guys have to have a good deal of domain knowledge. It is more important if they want to manage a full-chip program or move to architecture in the future.
Hahaha! Thankfully, never been there myself.
People usually forget delays, unless you were the long pole and the company lost a customer socket because of your delay. It is a little improbable as well.
But, forgetting about a million dollar of mask cost because of an escaped bug is very difficult.
Totally agree. You need good guys at both places. Having a lopsided arrangement is bound to fail.
On a positive note I see that less than perfect management is a universal phenomenon.

I choose to disagree here , i know this is a bit off topic but Testing and QA are two different ball games and in my opinion not to be used in and interchangeable manner.

Wrong again a QA Engineer will ideally Critic the process and not the product, nor the developer and take steps to see that the same defect doesn't occur again

^^ In some organizations QA is considered separate from Testing while in some they both mean the same thing (product testing, not process).

QA = quality assurance
Testing = QC = Quality control

It is easy to jump from testing to QA, but they arent the same , and QA is more the realm of higher ups :P

http://elsmar.com/pdf_files/QC%20vs%20QA.pdf

Thats right. QA and Testing are interchangeably used in the industry. To each, his own!

As far as the main agenda of the discussion goes, here are my two cents.

Both a development engineer and a test engineer have equally crucial roles to play in the success of a product/project. Gone are the days when one was taught to fight with the developer tooth and nail to prove a point. IMHO, there is a certain amount of harmony essential between the developer and tester to ensure success.

A typical career path for a Test Engineer:
Test Engineer -> Sr. Test Engineer -> Test Analyst -> Test Lead -> Test Manager -> Test Director and so on. However, a Test Engineer if develops sufficient knowledge of the domain in which he/she works by reading, learning can get into the business side of things. Same holds true for a developer as well. Though, a developer tends to get into the Design or Product Management teams after achieving significant knowledge.

The sky is the limit in both professions. It is only how you perceive your job. If one thinks 'testing' is a menial job, he/she is sorely mistaken. Times have changed. And will continue to change. The industry is mature enough to understand the role of a tester or a developer and will treat them on par in the organization.

When I was a Sr. Test Engineer in one of my earlier organizations, I was making more money than a Sr. Developer. It all depends on how competent you are. If your word makes a difference, you get paid better. Complement your words with action and success will follow.

In hindsight, when I think of having spent 6 years in this profession, I do not have an iota of doubt in my mind that I made a prudent choice back then. Respect your colleagues and fellow workers (developers, testers, managers et al) and thats all it takes to climb up the ladder. (Enough sermonizing now -:), I must get back to work)