Forgot your password?
Software Technology

What Does a Software Tester's Job Constitute? 228

Posted by timothy
from the darts-glue-and-ping-pong dept.
First time accepted submitter rolakyng writes "I got a call from a recruiter looking for software test engineer. I'm a software engineer and my job is development and testing. I know I mentioned testing but I'm pretty sure it's totally different from professional testing practices. Can anyone shed light on what a software test engineer's day to day responsibilities are? They said they'll call me back for a screening and I want to be ready for it. Any tips?"
This discussion has been archived. No new comments can be posted.

What Does a Software Tester's Job Constitute?

Comments Filter:
  • BREAK IT (Score:5, Insightful)

    by phrostie (121428) on Friday February 10, 2012 @06:08PM (#39000339)

    Go down a list of features.
    make sure they work one at a time.
    then try to break them anyway.

  • Just say no (Score:2, Insightful)

    by Anonymous Coward on Friday February 10, 2012 @06:13PM (#39000391)

    If you are a software developer, do not take the job. Development is usually considered more skilled.

    If you want to try just ask for your current salary and than you will have no problem since they will say no.

    In short they are looking at you as a sucker who will accept less pay with more skills.

  • by roman_mir (125474) on Friday February 10, 2012 @06:15PM (#39000431) Homepage Journal

    The truth is that if one wants to find out what software does under different conditions, he shouldn't go the designer or the developer, he should go straight to the tester.

    The job of a tester is to put together a meaningful plan - understand how the software is going to correspond to the business needs and test the main logical paths as well as some optional and failure paths and find out what the software really does as opposed to what people think it should do.

    If the difference between what the software does and what is required is such, that the business will suffer because of it, this should be fixed, so this goes back to the developers.

    Testers prepare test plans and test the software.

    Good testers prepare the data and seed it, so that it is the same at the start of similar tests in each iteration.

    Intelligent testers use various tools so that they don't do this by hand.

    Excellent testers figure out what the business needs and actually provide good user-like (but better) feedback to the development.

  • by perpenso (1613749) on Friday February 10, 2012 @06:17PM (#39000453)

    telling the developer he's right about everything and the product is never broken, or the tester will get a tongue lashing.

    As a developer who was fortunate enough to have an internal QA department I can say that your opinion is not universal. Hell, myself and fellow developers were annoyed when our QA people were moved to an adjacent building. We preferred having them one floor away in the same building so that we could more easily walk over to their cube to see what they see. Of course our QA people were trained, part of the company not contractors, etc.

  • by Joe_Dragon (2206452) on Friday February 10, 2012 @06:17PM (#39000461)

    a lot recruiters talk out of there ass / have no idea about job some times there is not even a real job there.

  • by Dastardly (4204) on Friday February 10, 2012 @06:25PM (#39000573)

    I am a developer and I tell my testers to consider me to be evil, lazy, and malicious. They must assume I am actively trying to fool them into thinking the application is working even if it is not with the minimum amount of work possible. That generally gets them to find the defects.

  • Re:scripts (Score:3, Insightful)

    by Dastardly (4204) on Friday February 10, 2012 @06:28PM (#39000605)

    Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.

  • Re:Ummmm (Score:5, Insightful)

    by fooslacker (961470) on Friday February 10, 2012 @06:36PM (#39000711)
    Reading and understanding requirements....Writing testing strategies, test cases, and low level testing scripts that can be traced back to the individual requirements that they test....Understanding which test cases map to which functional blocks of a system....Identifying which test cases should be part of a regression pack and keeping that pack fresh through various versions of the software....running that regression pack when requested during future development cycles...performing change impact analysis to select subsets of the regression pack to test various changes...etc.

    ....and if it is a manager position then add in all the people stuff on top.

    ...and of course executing test cases and tracking the results.
  • by dotrobert (923547) on Friday February 10, 2012 @06:41PM (#39000763) Homepage
    I'm a QA engineer and I *do* consider the app developers to be evil, lazy and malicious. Well, not really, I just agree that I should assume so for testing purposes since they are humans. Also, in response to the parent comment, I'm REALLY glad that we work in parallel and directly with app developers. It gives them *and* us tremendous advantage.
  • Run! (Score:4, Insightful)

    by turgid (580780) on Friday February 10, 2012 @06:55PM (#39000929) Journal

    I was looking for work recently, too, and got lots of calls from recruiters looking for Software Test Engineers.

    I've worked very hard to get to being a developer, so I resisted and eventually got a better paying and infinitely more stimulating development job.

    Software Test Engineers are sort-of developers, but the emphasis is on understanding requirement to be able to implement a "test matrix" that will (perhaps exhaustively) exercise a system (hardware and software as a whole) through all of the "use cases" that a user might be expected to do i.e. how J Random Luser will use the product.

    Practically, this means implementing hundreds (or maybe thousands) of automated tests driven from something like Fitness. If you're lucky, you'll get to implement your test cases in something like Ruby. If you're unlucky, it might be C#...

    It's quite a skilled job. You need to know a bit of statistics (statistical significance, confidence levels, variance and all that), about Combinatorial Testing (test coverage) and a bit about scripting and good software design. You would also need to understand the difference between white- grey- and black-box tests and when they are appropriate.

    There are two ways in, from being a "tester" upwards or sideways from being a developer. (Note I didn't say "down." It's a skiled job, but I've done it for a few weeks for the experience and I got bored quickly).

    In the spirit of cost-cutting, most Western companies are offshoring their testing. For example, Xerox just got rid of their manual and automated test to HCL in India. McAfee have done the same.

    Stick to development unless you're starving/about to have your house repossessed or want a little extra experience on the side (which is a good thing for your CV as long as you don't make it your whole life).

    One last thing: clueless recruiters see "Test-Driven Development" on your CV and think, "Aha! A software tester!" I had hundreds of phone calls under that misapprehension. (They also don't know what a kernel is (Windows and Linux both have one so they must be the same, right?) or the difference between C, C++ and C#...)

  • by LrdDimwit (1133419) on Friday February 10, 2012 @08:26PM (#39001871)
    Criticizing someone by saying that they got less done than a group of other people is a pretty lousy criticism. All you've really done is establish that there's a benefit to two types of testing: methodical testing, and let's-just-mess-around-with-it stress testing.

    Just messing around is way faster, and it will quickly catch a lot of bugs. But it's no substitute for methodical testing. How many bugs did she find that the entire group of other people would have never noticed?

    I feel sorry for her. It seems like she did a pretty good job, and it sounds like she did exactly what the business hired her to do, yet it doesn't sound like she got any respect for it.
  • by uncqual (836337) on Saturday February 11, 2012 @12:40AM (#39002949)

    It's the same reason authors need proofreaders.

    Similar, but there's a big difference here. The proofreader can catch every actual error so a sloppy writer can be saved by a proofreader. A tester can't test every case (assuming that they are not going through the code line by line, but that's really a development job) so a tester can't save a sloppy programmer, just mitigate the damage they do. Yes, testing is VERY important, but you can't test quality into a software product - you have to develop it in.

    Things like stress testing, edge case testing, and user acceptance testing are not something that your typical programmer performs day to day and may be completely missing from her tool set.

    Stress testing and edge case testing are exactly the sort of testing I expect software developers to do some of and be good at. They should know what the tricky bits are and know how to bend the system to make things fail in minutes and hours instead of months of testing. Without that intimate knowledge of the internals (again, testers could have that, but it's very rare), a lot of stress testing just keeps testing the same thing over and over - not very useful.

Philogyny recapitulates erogeny; erogeny recapitulates philogyny.