Quality Assurance & Software Testing Job?

BrokenArrows

A possible job opportunity has come up for me and the role is Quality Assurance & Software Testing.

Is there anyone who currently or previously has a similar role can you give me your impressions and what your day to day life at work was like.

Evil Phil

That's how I started out, some might say that testing is a little boring but if you've a talent for it or talents that suit software development in general you'll soon carve out a place for yourself. If you're looking to get into the industry it's a great place to start. There's loads of stuff involved, it's not sitting in front of a screen following a series of instructions to see if the software behaves. You have to understand how the software works to really be able to test it, then there's creating testing builds, system setup, finding obscure bugs to irritate the dev team, the list goes on. A good tester is worth their wait in gold too.

PhantomBeaker

I currently work as a QA engineer and I have to say it's a great opportunity in some respects. You leave knowing some very valuable skills.

Some of them include being able to write a good bug report (any developer will thank you for that), and understanding how to narrow the scope of a problem right down.

It will exercise your communication skills (I don't know about the place you're applying for, but I have to write reports for engineers who may not speak English as their primary language).

Depending on the type of testing you'll be doing, whether it's manual or automated, you'll get your hand into tool development and maintenance (writing the little programs that make your life so much easier).

Also, if it's a big product, or even if it isn't, you'll gain a lot of experience with the product, building your skillset. Believe me, you never truly know how to use something until it breaks in your hands, and you figure out how to use it anyway.

As Evil Phil said, there are a lot of opportunities... although sometimes QA engineers aren't appreciated as much as others. There's sometimes an attitude of, "You're only finding the bugs, we're fixing them"... but the good devs know that if you've written a thorough bug report, you've done a good chunk of the work for them.

If you're going for the position to go to conferences, don't. Nobody has QA conferences - no company wants to pay for a QA engineer to go and get drunk with a bunch of QA engineers from rival companies trading horror stories about what massive, horrible bugs were deemed OK by management to go out into the wild.

Seriously speaking, my major grief is the workload. It can majorly bog you down some days. You have no control over the number of deviations in behaviour (what one might call them before you're sure it's a bug and not just a problem with your test environment) that you'll observe. If you have to research and analyse each deviation within a specific timeframe, you could end up with an awful lot of work on your plate with a really short deadline.

At the same time, each bug is like a puzzle - figure it out early enough, and you've just saved your company a lot of money (general rule of thumb, the earlier you catch a real bug, the cheaper it is to fix - once it gets to the customer, it gets REALLY expensive to fix). If you have the puzzle-solving mentality, and like to get under the skin of a program, without necessarily looking at its source (believe me, it doesn't help as often as you'd think), then give it a good shot.

Long story short: It's a good job to start out with, and if you ever get a dev job, it'll help you debug your own code (or someone else's code). Or if you turn into a lifer in the QA biz, you'll definitely be worth your weight in gold to a company that can appreciate the value of good QA.

Aoife

pwd

There's a lot of variety in QA engineer roles. Some roles require automation and making test harnesses, which require development skills. This sort of job would be very different to someone following test scripts and manually testing an application I think.

I did manual testing in a few places. It can be fairly tedious to be honest. Also, it requires concentration and attention to detail, as well as clear communication, so you need to stay engaged with it (unlike some tedious jobs which allow you to switch off or daydream).

However, there is often scope to get different types of work while employed in such a role, especially if you take it upon yourself to suggest it. If you write clear bug reports you may be asked to do technical writing, or writing test scripts/strategies/cases. If you suggest fixes to bugs you find, you may get offered development work. It probably largely depends on the particular role and company though.

BrokenArrows

thanks for the info.

I have an interview coming up. any tips on things i should know going into it?

fergalr

BrokenArrows wrote: »

thanks for the info.

I have an interview coming up. any tips on things i should know going into it?

What the company is and does.
What they work at here.

What the software development lifecycle is.
What black box/white box/ gray box testing means. (read wikipedia around these terms)
How to use bugzilla (even if the company doesn't use it, its relevant experience. Go read open source bugzilla repositories)
How to file a good bug report.
How to write a test plan in excel (maybe, depends on the company)

Unix command line.
Scripting of some sort (perl, shell - a few hours on an online tutorial can learn you a lot)

Depending on the area, might be good to have experience just installing and running whatever web server, OS they use, how to install an SQL server, how to do basic networking in the OS of relevance etc.




Words of caution:
Haven't worked QA for a long time, but it can be horrible work, or it can be fine work. Find out as much as you can at the interview about how the company does their QA.

QA can mean, at one end, writing unit tests for the code that the developers are too busy to write, in which case its practically a coding job, and could be fantastic.

At the other end, it can mean clicking buttons over and over again according to the rules in a spreadsheet.

And there's a whole spectrum in between.


A good company will try invest in their QA department and help them unskill, both to combat the frequently high turnover of QA staff, and to do better QA. If you get a company like this, you could learn a lot. A bad company won't do this, and could be miserable to work for.

Personally - and I love tech - I'd probably rather work a manual labour job rather than sit in front of a computer and push buttons according to a script. But some people don't mind it, and it can be a good way to get a foothold in a technical career. Its a personal thing, depends a lot on you as an individual.

But try figure out at the interview what the work you are going into entails, and whether you are a good fit for it.

pwd

I did a spot the difference puzzle to get one decent QA role.
It required a degree, and there were 80 qualified applicants. I kick ass at spot the difference.

If they are in a regulated industry they might need to conform to standards. If you familiarise yourself with any relevant standards it will show you did your homework. (eg iso standards for a company providing software to be used with medical devices).

If it's manual testing they'll be likely to ask you about your attention to detail, and your ability to concentrate on tedious work. If you have good attention to detail, and can concentrate on tedious work, you should be ready to describe experience illustrating these traits. Also have in your mind anything that demonstrates you can communicate clearly in written communication especially.

Some things that they might ask you will be entirely dependent on how they do things, and what they are looking for, and not have a generic correct answer. What I have in mind when I say this is "Do you want to get into development?" Some companies would like to hear a "no", if they want you to stay in the role a good while. Other places would like a "yes", if they have a different path in mind.