Testing

The_B_Man

Just looking for some clarity here as I'm about to embark on a journey into the world of graduate development!!

If I see a role that says its a Testing role, does that mean there's very little programming? Same with Automation.

I really just want to work on software and write code. I suppose I'm just trying to get an understanding of whats involved in these other testing/automation roles so I know to avoid them if they're not what I want.


Any help/advice appreciated.

Royale with Cheese

The_B_Man wrote: »

Just looking for some clarity here as I'm about to embark on a journey into the world of graduate development!!

If I see a role that says its a Testing role, does that mean there's very little programming? Same with Automation.

I really just want to work on software and write code. I suppose I'm just trying to get an understanding of whats involved in these other testing/automation roles so I know to avoid them if they're not what I want.


Any help/advice appreciated.

I worked in a testing role for 6 months. It was partly manual testing but involved maintaining an automated test suite in vb.net. I wrote tonnes of code, at times I was hammering out 1000s of lines a day (a lot of copy and paste involved) but I found it very tedious and a little soulless. I was never doing anything apart from executing actions and asserting values.

I've since been working in development for the past year and there's no comparison. I'd much rather be building something than poking around with a piece of software looking for bugs. That said I think the testing role was a good introduction to software development and I learned a lot about writing good code from it. If you can think like a tester you'll write better code.

The job I applied to was a general software development role with a technology consultancy. I was told testing was a possibility before I joined but due to the nature of the company I only had to do it for 6 months before a better opportunity presented itself. I'd have left the company if I was still doing testing after a year. If you've no interest in it its probably not a good idea to get too much of it on your CV. Personally I wouldn't go for a pure testing role.

Colonel Panic

We got a junior dev in our place who came from a testing role. He's pretty damn good for a junior, not that I'd tell him that to his face!

lowlifer

Depends on what you want. I say the experience can't hurt. In the end, it's better to be working, even as a tester, than sitting at home watching or reading tutorials.

I myself started out as a tester.
The upside was that there was almost no pressure on me, took my time with understanding everything, had time to research, also got home able to work on school stuff.
The downside was that I was paid decently compared to other jobs, but not much compared to developers, was expandable, felt (and probably was ) less valuable than the nontechnical girls from customer support.

After ~5 months I had grown sick of having to test real developers' work and wanted to develop full time, but didn't like my company's projects, so I decided to move on.

The fact that I was looking to quit my current (at the time) job to have more responsibilities looked great on my CV; I was also no longer the newb student guy who would settle for any amount of money you'd throw at him.

Despite not doing a lot of development as a tester, I did great on my new job from the get-go. Graduates with no working experience that come here for interviews are TERRIBLE and would take weeks to get accustomed to our workflow: that's with us having to lose precious time for helping with trivial stuff.

If you are passionate with programming, testing will be a "waste of talent": don't settle with testing, especially since you're a graduate.

The only case in which you should accept a testing position is if you've spoken with every possible company and you couldn't get them to hire you as a developer. Even after this (god forbid) happens, only do it if you're guaranteed a development position within the company after a few months, provided they are pleased with you.

Sorry for the long rant.

srsly78

If you are writing unit tests then that's good. If you are manually performing the tests (ie not developing) then that is bad. Two very different things.

Royale with Cheese

srsly78 wrote: »

If you are writing unit tests then that's good. If you are manually performing the tests (ie not developing) then that is bad. Two very different things.

Coding automated tests and doing proper development work are two entirely different things again though.

srsly78

Not if you are doing test driven development :P