Co-op: QA at big company or Dev at small company

[phyrefly]

If you had a choice of doing QA/Testing for a very well known company or application development for a small, unknown company, which would you choose?

Application development will certainly be more rewarding, but will having the name of a very well known tech company on your resume outweigh it?

This is for a 4 month co-op job btw.

[GonePostal]

Depends on what you want to do in life. I was in the same position as you back when I was in school. I'd go with the small startup company versus the large company but that's because that is where I want to be. If you want to move into big companies they are more favourable to having other large companies on your resume.

[jmc0]

Since it's just 4 month, I would go with the big name. Never know, QA can be very rewarding. Also having a big name company on resume, might help later on.

[chrome_dout]

I'm currently QA at a large bank, and I would strongly suggest taking the smaller company position. You will learn a whole lot more in terms of the business > dev > qa cycle, which is a great starting point for your career.

[manixc]

Since it's just 4 month, I would go with the big name. Never know, QA can be very rewarding. Also having a big name company on resume, might help later on.

+1

[CSR]

Scotia bank???

[hoopsandyoyo]

working in a big compnay, will teach you first hand experience of the project life cycle and sdlc which I think is VERY important early in your carreer.
BUT I think for coop the application dev position will be of more vaule when you apply for a job coming out of school, reason being in dev you learn much more in terms of programming/dev practice blah blah. QA is just grunt work, unless its like auotmation.

[phyrefly]

Scotia bank???

No. I'm trying to avoid IT in the financial services sector for now. I've worked for a larger financial services company and a large public agency, so I'm aiming for actual tech companies this time.

Both of my pervious jobs gave me a lot of experience with project management and SDLC.

Although I'm looking for meaningful experience, I'd also like to pad up my resume a bit (bad idea :confused: ), since I plan to take a year off after gradaution.

How can QA be a rewarding experience? I've only done some Junit/Nunit testing, so I don't know how the QA process works at tech companies.

[flito ray]

QA is just grunt work, unless its like auotmation.

that's incorrect. good QA work is hardly grunt work. one needs to formulate white box, black box tests and execute them. it's a critical path job that is important for the success of the company. if a company doesn't do proper qa, lots of revenue can be lost from buggy software.

anyone that tells you that QA is "grunt work" doesn't know half a thing about qa and is talking like they do. it's a demanding and tough profession!

[hoopsandyoyo]

that's incorrect. good QA work is hardly grunt work. one needs to formulate white box, black box tests and execute them. it's a critical path job that is important for the success of the company. if a company doesn't do proper qa, lots of revenue can be lost from buggy software.

anyone that tells you that QA is "grunt work" doesn't know half a thing about qa and is talking like they do. it's a demanding and tough profession!

so I've done a year in QA. both white and black, unit blah blah, Even enterprise automation strategy. Dev, requirements, testing, implementation is all critical path....so big whoop.

imo, testing, esp at a bank is zzzzzzzzzzzzz (probably the worst place to do QA). unless your testing something really interesting (games, cool UI etc) or extremely hardcore software (i.e drivers), QA is pretty easy/zzzzzzzzzzz. In banks most of the time your going to be testing functions.....basic functions....ie. press enter.....does it do what you expect...pass. Banks are not leading bleeding edge tech firms making the testing work even worse.

[Rehan]

that's incorrect. good QA work is hardly grunt work. one needs to formulate white box, black box tests and execute them. it's a critical path job that is important for the success of the company. if a company doesn't do proper qa, lots of revenue can be lost from buggy software.

anyone that tells you that QA is "grunt work" doesn't know half a thing about qa and is talking like they do. it's a demanding and tough profession! That's true. But a 4-month co-op job in QA most likely will be just grunt work.

But... I think even if the QA job is just grunt work, working in the trenches of QA is something all developers should experience so they can better understand the failure points of applications and strengthen their own foundation (in terms of the SDLC, etc.). As a junior employee in a larger company you may need to take more initiative to get that understanding, but it can still be done. And if you plan/hope to move up to project management at some point, then having that QA experience will also be helpful in managing the process.

It doesn't really matter which one you take...you'll get benefits from both. The main issue is which one fits better in your career path.

[flito ray]

so I've done a year in QA. both white and black, unit blah blah, Even enterprise automation strategy. Dev, requirements, testing, implementation is all critical path....so big whoop.

imo, testing, esp at a bank is zzzzzzzzzzzzz (probably the worst place to do QA). unless your testing something really interesting (games, cool UI etc) or extremely hardcore software (i.e drivers), QA is pretty easy/zzzzzzzzzzz. In banks most of the time your going to be testing functions.....basic functions....ie. press enter.....does it do what you expect...pass. Banks are not leading bleeding edge tech firms making the testing work even worse.

it's "zzzzz"?? excuse me but maybe your department is overstaffed or has too little to do. in my experience qa people work long hours. at my previous company they pulled 10-12 hour days you know why? so that the software can ship. without proper test coverage there's no way a software can ship on time.

again anyone that poo poos qa clearly doesn't understand the nature of qa or maybe they're not really doing qa and instead they're doing just manual testing which is only one aspect of qa. there are many other aspects.

[hoopsandyoyo]

at my previous company they pulled 10-12 hour days you know why? so that the software can ship. without proper test coverage there's no way a software can ship on time.

clap calp clap......the same goes for dev, prodcurment and every other asepect of project work. If qa is you thing sure it can be rewarding.

again anyone that poo poos qa clearly doesn't understand the nature of qa or maybe they're not really doing qa and instead they're doing just manual testing which is only one aspect of qa. there are many other aspects.
I'm interested to hear the other aspects. We've covered: Testing strats, test planning and execution (black/white/manual/auto). I'm curious to see what Software QA analyst are asked to do in other orgs.

[flito ray]

clap calp clap......the same goes for dev, prodcurment and every other asepect of project work. If qa is you thing sure it can be rewarding.


I'm interested to hear the other aspects. We've covered: Testing strats, test planning and execution (black/white/manual/auto). I'm curious to see what Software QA analyst are asked to do in other orgs.

Well if you're not familiar with what a software qa analyst does, I suggest that you check out this link:

http://en.wikipedia.org/wiki/Software_quality_assurance

as a good introduction. Or even ask a friend or a friend of a friend who works in the field they will be able to give you a more comprehensive answer.

[hoopsandyoyo]

Well if you're not familiar with what a software qa analyst does, I suggest that you check out this link:

http://en.wikipedia.org/wiki/Software_quality_assurance

as a good introduction. Or even ask a friend or a friend of a friend who works in the field they will be able to give you a more comprehensive answer.

so you do know what we've talked about is all covered in there.. seesh.
Its called testing.....in the end no matter what glamour you wanna wrap around it its still testing.

[Rehan]

at my previous company they pulled 10-12 hour days you know why? Because they were understaffed. That's why. :razz:

hoops&yoyo is right. "QA" (I suspect what was really meant to be discussed in this thread is really QC, not QA) is usually boring, even if it is critical. That's why it's generally looked upon as the lowest rung of the folks involved in the SDLC.

[skeletor]

I was a system integration tester a few months back... I hated the job, going through thousands of test cases and creating new test documents and procedures with some perl scripting.. blah, such long hours and tedious work..
however, testing jobs do also lead to development since you work a lot with the dev teams.. It's also really easy to be a test manager since all you have to do schedule test runs give status meetings and everyone's job is pretty much written down on paper.

[hoopsandyoyo]

That's why it's generally looked upon as the lowest rung of the folks involved in the SDLC.

Dead on!! Even though I think it is one of the more important parts of the SDLC after requirements ....its generally the phase that gets shorten when timelines slip.

[Jaytee]

Dev without question.

Dev will give you more options as it will be easier for you to get a QA position with development experience then a dev position with QA experience.

You are also much better off with a software company as oppose to a company that does software to support its core business. Generally a software company will teach you good practices and processes. A company who's focus is not selling software many times do not have good processes in place. Thats just a generalization though having worked for several companies large and small, but you wont really know until you start working there.

[phyrefly]

I was a system integration tester a few months back... I hated the job, going through thousands of test cases and creating new test documents and procedures with some perl scripting.. blah, such long hours and tedious work..
however, testing jobs do also lead to development since you work a lot with the dev teams.. It's also really easy to be a test manager since all you have to do schedule test runs give status meetings and everyone's job is pretty much written down on paper.

Were there opporunities to learn about the systems/programs that you tested? I wouldn't mind doing QA if there's much to be learned, instead of just doing repetitive and unchallenging tasks.

[mypatpat]

If you had a choice of doing QA/Testing for a very well known company or application development for a small, unknown company, which would you choose?

Application development will certainly be more rewarding, but will having the name of a very well known tech company on your resume outweigh it?

This is for a 4 month co-op job btw.

Long story short, I would take the DEV position in the smaller company.

Now the long story...

If your co-op term is up to near a year, then the QA position would have been a better choice. This is because you're inexperienced and over the 4 months you'll be doing testing work (i.e. Quality Control). Generally speaking, in order to do Quality Assurance, a fair bit of knowledge of the application system and the business that drives the system is required. Since your co-op term is short and there isn't time to learn about the business, it doesn't make much sense for you to join to QA world (you don't have and cannot acquire the knowledge to perform Quality Assurance).

The informal definition of Quality Assurance is to prevent problems (e.g. creating test cases while validating the business requirements, improving processes of SDLC), it is generally confused with Quality Control because most Junior QAs are hired as testers (e.g. executing test cases).

On the other hand, the benefit of the DEV position is that it's from a small company. This gives you a more hands on experience not only with the implementation of the application, but since it's a small company and presumably with limited resources, you'll likely be exposed to certain element of the business that's driving the process.

One thing to keep in mind, technology exists to support business and it is always the business that determines what technology is required. Unless you intend to be technical through out your career (which very much limits how high you go), take every chance to learn about the business side of things. I always remind myself that companies like Apple didn't create the iPod to revolutionalize music, it's only revenue that they're after and the "revolution" and related technologies will be dropped immediately when it become unprofitable.

Hope this helps...

[harry131]

In most small companies, you get to learn a lot. But the disadvantage is they rarely have openings and you might not find a job there when you graduate.

For most big companies (but not all), you do small time tasks and don't learn as much as you could have. But the advantage is that they always have job openings in one department or the other...

You pick...