[DirtyDan]

Originally Posted by RX135

First part about about Project leaders, managers is not entirely correct. If you are a GOOD architect, you are possibly paid much more

Many times, testing teams are formed out of very seasoned architects/ programmers. They are highly paid and respected. However, such teams are really rare.

I have no quarrel with this. However, there are not many GOOD Archetects in relation to developers, many of whom never get beyond the brick laying stage IMHO.

[androdev]

Originally Posted by DCEite

The very fact that this thread has run into two pages and most posters have mentioned that Testers are payed nearly the same as developers suggests that you may not be entirely correct.
Why I asked that question? Because i have moved to Testing domain after development. So just wanted to clarify on my fears about Testers being not treated at par with Developers when it comes to pay, growth and learning.

read b/w lines: they can "at best" be on par with dev.

And i don't agree about the interview part. My testing interview was much more intensive (both in terms of quantity and quality) than the development ones i have given.

are you comparing your old company dev interview with the new company's testing interview? then you must try the new company's dev interivew.

my intention is not to put the dev people on a higher pedestal. it is just demand/supply matching. maybe you should get your counsel from your family/seniors/alumni,etc. who have genuine interest in your long term career. IMHO, this thread might do you a lot of damage :-)

Why don't you find a company that:

1. pays more to a tester than a developer
2. has tougher interview/selection for testers than for developers
3. outsources development but does testing inhouse (business critical eh?) - this means as a manager it is very difficult to have more people reporting to you which is a key step in 'empire building'. worse even your job might get outsourced.

but yeah, if you just want to sleep through few initial years and wake up as a middle manager...

please don't take offense at what i said. i'm trying to give you a perspective which i believe is more realistic than what is offered in this thread. i have seen lot of smart people who took to testing during the IT meltdown and had a tough time finding their way back into development.

i think i got carried away :-) i respect your decision. good luck.

[DirtyDan]

Originally Posted by Rocky_Balboa

Late '98,
A guy was pursuing his PG and held 'C' programming above all else. He used to be in complete love with C and Assembly programming and was involved in simulating small scale Viruses and Anti-Viruses for the same. Everyone thought hes gonna evolve into a Programming Architect.

Late '00
He gets employed as a S/W Test Engineer which none of his 29 other classmates appreciated and even jested.
'07
Hes a Tech Lead involved in designing a product along with other experts (Language expert/Tech Architects/SPMs)
This only means that Testing is almost equal level with Development (maybe even a notch higher)

He is involved with development? Then he is not strictly a tester. Nor does anything you say from this one case logically lead to the conclusion that Testing is across the board a better career or more lucrative. In any case his experience as a programmer was hugely beneficial to him in that he knew what a virus was and how to defeat them.

[DerAlte]

Hmmmm! @DCEite, not sure if you got what you were looking for.

Essentially the comparison differs, even in the Telecom field, based on the TYPE of organization that you are working for:

* Product company - developing and making it's own products from own ideas.

Here your professional life is woven around the product, and there is precious little diff between Dev and Test. Everyone does what is required, and role shifting/rotation is quite common. In these organization, a 'tester' HAS TO HAVE development background, and vice versa.

Compensation is roughly equal. (Monetary) Growth and commensurate growth in learning are automatic, but it is normally related to the product that you are working on. If you want to learn beyond that, you have to drive it - any organization that fosters that should be the 1st choice to work for

* 'Development Service Provider' - which develops software to a CLIENT's specifications and ideas.

This is where most of the differentiation and problems are: since you really don't identify with a product, you have to justify existence of individuals - more and more of them - in teams for which the client pays. Developer, Tester, Sr. of the same, Jr. of the same, Tech Lead, Test Lead, Project Manager, Test Manager, Architect, beldar, mistri, choonawala, chaiwala, ... ad infinitum.

Work-wise, it is no different from product companies if your client is a product company. If the client is an Enterprise, where the effort content is more than 50 person-year per year, some differentiation is justifiable from industry experience, as is the requirement for specialization.

Your existence is towards the service revenue earned directly by you. Hence, growth is directly proportional to the same.

Learning? Sure, if you want to, as long as you do it in your own time (except: I have the right to ask "Why haven't you already learnt it?" if it is required to be deployed urgently). Specialization is optional.

Historically, "Developers" have been paid higher than "testers" in such organizations, but that was due to the fact that such companies recruited resources with slightly "lesser" qualifications - B.xxx, M.xxx, GNxxx, Diploma (and I have seen PhD's working happily in Testing) - as compared to B.E./B.Tech./M.Tech. etc.

* Enterprise, which buys and uses products, or gets custom products developed. If you employed here, why worry or differentiate? Your work is anyhow being done by others in vendor companies - you are only required to make sure everything happens on time. Your only worry is if the END-USERs are complaining, and for that it is not Dev or Test that is relevant - it is your ability to walk a thin edge is, and everything else is linked to that!

* 'Body shopper': no products, no execution, just match skill requirement to an individual with the assumption that either the client or the individual knows what is to be done. Works for some who have no emotional relationship with their profession, not for others who have. Lots of money for those who DONT have the emotions, not for others. Growth? Learning? What's that!? You got money, you should be happy, right? Right!

The simple fundas are:
* Compensation and Growth is proportional to value delivered, independent of type of work (sometimes it is illogical like the share market)
* Learning opportunities are driven BOTH by the individual and the organization, and those that encourage are highly valued employers
* YOU have to sense, measure and articulate the VALUE you have delivered. If you can't, don't expect someone else will for you - and then don't complain no one appreciated and that you are underpaid!

[greenhorn]

despite all the stuff that I've said so far, it is better to first get a development background (especially if you are from a non CS/IT background) , and then get into testing. Why i get paid the same as a dev is because i was hired ,and worked as a dev before they put me into testing. Right now , I'm not involved with development at all.

There are non engineering (B Sc etc) folks who were hired as testers, and they're paid significantly less, despite doing the same work as us

[Rocky_Balboa]

Originally Posted by DirtyDan

He is involved with development? Then he is not strictly a tester. Nor does anything you say from this one case logically lead to the conclusion that Testing is across the board a better career or more lucrative. In any case his experience as a programmer was hugely beneficial to him in that he knew what a virus was and how to defeat them.

DD,
He is not involved in Development but Designing the product.
I am not suggesting that Testing is a better career, just that its as lucrative as Development is. If a guy can do excel as Developer, one can definitely excel as a Tester as well.

And this particular guy is not working in any virus solutions or anti-virus solutions. He has switched domain and expertise completely from what he was 10 years ago.

DCEite,
Be dev opening or test opening, if the candidate has fire he will definitely succeed.
Better if hes placed in a Product Oriented company or a service oriented having a longterm relationship with the vendor.

[RX135]

Originally Posted by DirtyDan

I have no quarrel with this. However, there are not many GOOD Archetects in relation to developers, many of whom never get beyond the brick laying stage IMHO.

Then they shouldn't be called Architects At best they are programmers with more years of experience.

[sreenivass]

Originally Posted by tsk1979

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

I can not agree more on the last statement. To me the final call on product quality is from test/ QA.

[sajo]

It would be interesting to know what is you guys' take on the guys who work in "Production Support"?
You know...people who work on break-fixes and changes to a system already in production, maybe for a few years ? They are neither developers nor testers.
I was wondering how the learning/growth potential in that is, especially for a fresher.

[RX135]

Originally Posted by sajo

It would be interesting to know what is you guys' take on the guys who work in "Production Support"?
You know...people who work on break-fixes and changes to a system already in production, maybe for a few years ? They are neither developers nor testers.
I was wondering how the learning/growth potential in that is, especially for a fresher.

No one would let a fresher (or even junior engineer) touch production system, let alone work on it. People working on production system are extremely competent and experienced developers/architects, who have thorough knowledge of the system. Any mistake there can cost a bomb for the company.

[DirtyDan]

Originally Posted by greenhorn

James Bach’s Blog
a testing god
EDIT : agree with balboa 100% . Even i was a bit down when i got assigned to testing. But right now , The stuff i'm testing is 6 months behind ( the schedule was 3 months :P )
Either ways , since they've screwed up. management has delegated full authority to us. Unless we are sure its 100% ready, we wont certify it. Now the devs grovel for mercy at our feet(and I'm talking about senior devs)

PS , we also have senior devs jumping over to testing to grab the significantly higher onsite chances as well

First and foremost a company has to develop software that works or very nearly so. It makes no sense for a company to have its best people in testing. This does not produce software. This produces beautifully written problem papers. Beautifully written problem papers are not working code.

Of course, a company can try to outsource development but if it does that then software maintenance becomes a huge problem because nobody in house knows how the programs work. If maintenance, too, is outsourced then a company loses control of its own I.T. as its software comes under the proprietary control of the vendor company. It is then held at ransom, I have seen it happen.

I have done both testing and developing. Get real, you testers who are answering this thread. The production of code almost always takes precedence over testing which is largely done by the developer anyway. Quite often a developer does not just sit back and write a program like an author writes a book, cover to cover. He writes a little code then tests it. He writes a module then tests it. He strings the modules together then test them again. If it is an intricate program he tests his way to a solution much more than simply writes code. Testing skills abound in a senior programmer/developer. A company whose business depends on I.T. must first and foremost produce code, not problem papers. In fact, testing is often a luxury item that is the first to be curtailed when a company is hard pressed financially or time-wise.

[greenhorn]

Dan, I agree that what you speak about would how things would happen ideally. But thats not how it happens in our large IT companies is it ?

I was among the best coders during training, yet i was assigned to testing.It didn't make sense to me why they would put the idiots in development, and me in testing. You think What you've asked hasn't passed through my mind ? I've asked the same questions to myself EVERY DAY.

But , unfortunately, this is how things are run when a co can afford to treat its people like mutually replaceable "resources" .

A lot of the things you've posted make complete sense, logically, and i agree with you 100%. But thats not apparently how it happens in the real world, or at least in my environment

[DirtyDan]

Originally Posted by greenhorn

Dan, I agree that what you speak about would how things would happen ideally. But thats not how it happens in our large IT companies is it ?

In a word, yes, what I said is GENERALLY true. I was not talking "Ideal", I was talking "Real". Do not take this so personal. I do not know your work situation, maybe it varies from the norm. But, as I said before, I have done testing and programming, more than 2 decades of it and I have seen a lot of shops besides the ones I have worked for. Frankly, I enjoyed testing immensely. I am probably a hacker wanna-be, I enjoy finding holes, breaking things etc. If it's in house software the thrill is only half as great and the pressure is on in other ways. It is hard to pick apart your friend's best efforts sometimes.

[kvish]

Originally Posted by DirtyDan

In a word, yes, what I said is GENERALLY true. I was not talking "Ideal", I was talking "Real".

I agree with your view points, but trying to generalize the en-mass of IT/telecom industry based on just personal experience may not be appropriate. As most people have said, testing is also part of the 'engineering' domain. The question to ask is what the person brings to the table. If a person is willing to spend everyday wagging the tail next to the developer and dance to the tunes, thats what he/she would be. On the other hand, if a person is able to question the implementation and functionality based on statistical data, its obvious who is more valuable.

And when you say developers write code and test it, it really forms a very small part of entire test and c'mon we know how much its tested (I was a developer too ) So thats a completely different topic. If developers were so meticulous, then there would be no tester in the world. Sadly, thats far from reality today and recession or no recession there would be someone to behind the developer's back!

[sajo]

Originally Posted by RX135

No one would let a fresher (or even junior engineer) touch production system, let alone work on it. People working on production system are extremely competent and experienced developers/architects, who have thorough knowledge of the system.

Well, I am a fresher working on one such project. Infact, barring my TL, everybody else in our six member offshore team is a fresher/near fresher.
We have some documentation on how to proceed in different scenarios,but it is nearly not enough. With the impossible timelines given, we dont even get time to sit down and understand the system.

Originally Posted by RX135

Any mistake there can cost a bomb for the company.

Tell me about it! Several times we were only a few inches away from giving our TL/PL a near coronary, especially with those SOx compliant procedures.