Software Tester Jobs

ChRoMe

srsly78 wrote: »

I did not profit from this internship at all.

Someone did.

XVII

Hey OP, how is your progress?

Kidchameleon

XVII wrote: »

Hey OP, how is your progress?

I hope you dont get a slap on the wrist for that. Id love to know the OP's status now...

Perry12

XVII wrote: »

Hey OP, how is your progress?

Thanks for asking! Wow nearly 5 years later! I ended up getting a IT job which pushed me down the networking route, Cisco mainly and went for networking certs.

Then I got some exposure to python and started getting stuck into that as it is used a lot at work. I’m still getting through it and working towards moving into front end dev.

XVII

Haha, sorry didn't want to necro this or anything. I just had this thread among my bookmarks some time ago, as I was looking into similar possibilities. I'm interested in this again now, so went back to this thread for some advice.

Good to hear it all worked out for you!

Kidchameleon

Im about to graduate with a BSC in Computer science. Done a fair bit of Java but would not be near competent to go seeking a job coding yet. Im working on two projects at the moment in my spare time but nothing major.

I was thinking that testing would be the way to go. What do you guys think? Would unit testing be something that someone fresh from college could realisticly get into? My course just had some general testing content so I'd probably have to bulk up my skills

Dubba

Asfaik it's developers, not software testers that write the unit tests. This site has a good breakdown of what involved in a ST's role. I've heard that Selenium is a tool often used in ST, so it might be worth having a look at that if you go down this route.

Whether or not it's advisable as a graduate s/w dev to opt for a ST role, I can't say because I'm in the same position as yourself. Maybe the skills of a tester don't translate well to a developer, so you could be pigeon-holed into this career.

14ned

Dubba wrote: »

Asfaik it's developers, not software testers that write the unit tests.

Varies on the company/team, actually. Some have the developers write the tests, some have the test folk write the tests, some have a mix of both.

Ideally it ought to be highly competent test folk writing the tests, indeed there is an argument that your best developers ought to be in test, not development. A fresh set of eyes always writes tests which test far better than the developer who wrote the code. But far too often it degenerates into someone cheap in a developing world country writing the absolute minimum possible test code which passes, and intentionally not submitting any test code which fails. Which is utterly pointless as an exercise, and yet I've seen it time and again at the clients where I contract.

A superb test team is an amazing asset, yet they tend to get culled/outsourced before dev teams. A shame.

Niall

Raging_Ninja

If you have any skill at all do not go into software testing. If you stay in it for more than a few months you will have great difficulty getting hired into a developer job, and often times the pay will be worse in the long run.

Even automated testing roles, which is largely software development since you are writing code (and which can be harder than writing the software that is being tested), can be very difficult to dissociate from manual testing in the minds of HR drones who most of the time have zero experience with IT beyond knowing a few buzzwords.

I know this from the experience of friends who were hired by a multinational telco who after graduation were put into automated testing roles.

Ned is right to say that a well-performing test team is absolutely essential for any organisation, but I would not willingly be part of such a team.

14ned

Raging_Ninja wrote: »

Ned is right to say that a well-performing test team is absolutely essential for any organisation, but I would not willingly be part of such team.

I'd have to agree for the most part, but there are some exceptions. SDET @ Google is very nice for example, you get paid slightly more than devs, and you're more important in terms of weight with the management. But Google is unusual relative to most, and they have a particularly sophisticated custom test infrastructure which takes a long time to master, hence you add more value than a mere developer.

Niall

moycullen14

14ned wrote: »

Varies on the company/team, actually. Some have the developers write the tests, some have the test folk write the tests, some have a mix of both.

Ideally it ought to be highly competent test folk writing the tests, indeed there is an argument that your best developers ought to be in test, not development. A fresh set of eyes always writes tests which test far better than the developer who wrote the code. But far too often it degenerates into someone cheap in a developing world country writing the absolute minimum possible test code which passes, and intentionally not submitting any test code which fails. Which is utterly pointless as an exercise, and yet I've seen it time and again at the clients where I contract.

A superb test team is an amazing asset, yet they tend to get culled/outsourced before dev teams. A shame.

Niall

Right on the money, Niall.

In all the places I have worked, there is a direct correlation between the quality of the engineering/product and the quality of the test department.

Good QA is a priceless asset yet one that is so often ignored by management.
Generally good testers (and they are rare) combine technical savvy with solid domain knowledge, attention to detail and - this is the crucial bit - the ability to influence developers without creating a hostile, us and them, atmosphere.

Worked in a place once where the CTO decided to get rid of the QA department because they were 'holding up releases' :eek:

beauf

moycullen14 wrote: »

.... this is the crucial bit - the ability to influence developers without creating a hostile, us and them, atmosphere....

I think that mainly comes from Developers not testers. Its one of the reasons I resist moving into any non development role in a project. Developers think they are Bono. They dictate every part of the project, be it Business Analysis, UX, Graphics, DBA, everything when I would say mostly (not always) they are the wrong people to make those decisions. The only way to gain traction with Developer is to be seen as a developer. I would say its one of the major problems in projects.

It why I would say if you are choosing between developer and any other role in IT you are effectively, giving up any opportunity to drive or manage a project.

beauf

moycullen14 wrote: »

R...In all the places I have worked, there is a direct correlation between the quality of the engineering/product and the quality of the test department.

Good QA is a priceless asset yet one that is so often ignored by management.
Generally good testers (and they are rare) combine technical savvy with solid domain knowledge, attention to detail....

But otherwise I agree whole heatedly.

In one place I worked testers were the last to get any promotion. Always lowest in seniority. Then the company wondered why no one would work in the dept. Or why there were do many bugs and problems.

14ned

moycullen14 wrote: »

Worked in a place once where the CTO decided to get rid of the QA department because they were 'holding up releases' :eek:

Yeah I've seen that too. The other thing I've seen is management ordering the devs to write code and commit without testing "because the CI is for doing the testing so the devs don't have to waste time on that".

I can't really begin to describe how stupid that attitude is, but it's awfully common amongst management who don't understand and think automation is there to increase pace of feature addition. It is, of course, there to improve quality and consistency. If anything CI slows down feature development because it raises the quality bar.

Niall

14ned

beauf wrote: »

They dictate every part of the project, be it Business Analysis, UX, Graphics, DBA, everything when I would say mostly (not always) they are the wrong people to make those decisions.

Must be different in these new programming languages, but anywhere I've seen it's the Architects who take all the high level design decisions. Developers are given the design and told to implement it, they can make micro-level design decisions say on an internal function's API, but that's it. Senior Developers spend most of their time in meetings with the Architects arguing about the crappy design, and Junior Developers do all the actual coding with ideally peer review by the senior devs. Senior devs tend to do very little coding end of the day, their purpose is to advise cheaper devs and argue with the Architects.

Maybe it's a scale or size thing. I'm talking about orgs with tens of thousands of devs.

Niall

beauf

I like the way you never mentioned any non developer role in that


That is exactly how many dev's (not those enlightened people on this thread) see the world. You're either a developer or nobody.

14ned

beauf wrote: »

I like the way you never mentioned any non developer role in that

That is exactly how many dev's (not those enlightened people on this thread) see the world. You're either a developer or nobody.

It was intentional. I can't speak much for outside Python and C++, but there's a fairly strict hierarchy of authority maintained by each language ecosystem. There are the shapers of the language and libraries at the top that everyone marvels at and who present regularly at conferences (the leadership). There are the skilled practitioners within each firm who set the pace of development and dictate how things are in any given project and company. Then there are Architects, Senior Devs, Devs, Junior Devs, with authority diminishing with each level. And finally there is "everybody else", of which only the Documentation and Testing folk get any shrift in the pecking order at all, and at that it is to a wildly varying degree depending on the dev's personal opinion and/or we take their opinion seriously up until we don't. Management, Accountants, HR especially receive negative authority rankings on the hierarchy - just read BOFH (https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell)

Now, it's not right that that's the case. As someone with also a Management degree, I can tell you straight out that Management, Accounting and HR are just as tough to master as software development. And what really causes the friction is differing hierarchy of authority, so for example, in Accounting there is an elite leadership that everyone marvels at and who present regularly at conferences and set how Accounting evolves internationally. Within each firm, there are skilled practitioners who dictate how things are in any given project and company. And you're probably getting where I'm going here. Same goes for HR too, and of course Management.

Point is that every profession has its hierarchy of authority where leadership is marvelled at, else it's not a profession. Bourdieu and all that (https://en.wikipedia.org/wiki/Pierre_Bourdieu). And each profession considers other profession's hierarchy as unimportant and usually irrelevant. So next time Management, Accounting or HR trample over Software Development, bear in mind they're just treating you the same way as you treat them from their perspective. Their exigencies are not yours, but they do have exigencies just the same as you. That's the common ground.

Niall

beauf

A brilliant cook but bad at business should not be in charge of the business.

Likewise a bad cook, who is also bad at business should not be in charge simply because they are a cook.

But a cook who happens to be good at business maybe the right person to run the business. But it's not because they are a cook.

beauf

This reminds me of a discussion at work last week about a problem from a user which ran though a chain of technical and development people. They were head down looking at technical solutions and ever increasing complex solutions.

Until I pointed out it was user error, due to a non intuitive UI that the developers insisted on against all advice. They have repeated this poor UI across three generations of the product now.

So if you are thinking of becoming a software tester be aware that it's very difficult to get any traction except in a enlightened organisation.

I have worked in a few places where testing was taken seriously (generally very large organisations) but worked in many were it isn't.