Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Software Technology

What Does a Software Tester's Job Constitute? 228

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:
  • it means (Score:2, Flamebait)

    by gangien ( 151940 ) on Friday February 10, 2012 @06:05PM (#39000301) Homepage

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

  • by Anonymous Coward on Friday February 10, 2012 @06:07PM (#39000327)

    A: Suffering

  • by X0563511 ( 793323 ) on Friday February 10, 2012 @06:08PM (#39000331) Homepage Journal

    To paraphrase an AC [slashdot.org], you basically follow an established-by-development script over and over and over and over and over and over...

    You do not think, you do not troubleshoot. You perform prescribed actions and check marks on your... checklist.

    • 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.

      • by Gamer_2k4 ( 1030634 ) on Friday February 10, 2012 @08:23PM (#39001847)
        Do you not have an interface on your product? If you do, manual testing is absolutely crucial. Automated test coverage is an excellent thing to have, but it can't replicate the user experience.

        I say this as an automated tester who absolutely hates manual testing. I can't deny its importance, though.
    • Re:scripts (Score:5, Informative)

      by chuckfirment ( 197857 ) on Friday February 10, 2012 @06:30PM (#39000619)

      I have to disagree. I've never worked somewhere like this, and I've been in SQA for many years at many jobs.

      If you want to be a low-paid button pusher, yes. Do the same thing over and over, all day long with no deviation. If you want to enjoy your job testing, test the software. Try to break it. Troubleshoot. Do things the developers wouldn't expect. (After all, who expects an apostrophe in a name field? "We only expect regular text, right Mr. O'Hanlon?")

      The job of a software tester (tester, not button pusher) is to try to find all the defects in the software and report them to development so they can be fixed.

  • 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.

    • by chuckfirment ( 197857 ) on Friday February 10, 2012 @06:26PM (#39000583)

      OP is correct - the job of a software tester is to try to break the software. I've enjoyed working in software quality assurance (SQA) for over a dozen years now. I get paid to break things all day, and when I do break it - I don't have to fix it.

      SQA is very different depending on where you go and what you're testing.

      Web Applications - you'll want programming experience so you can write flexible automated scripts. You can test manually for every supported browser/OS combination, but it's tedious.
      Desktop Applications - Sometimes manual testing is enough. If the software is large, you'll likely want to automate.

      Large companies that move fast will want automation. Small companies that move fast will want automation, but might not realize it. You can get away with manual testing at small slow companies.

      You don't need automation skills to be a software tester. You do if you want to become a software tester with a high income.

    • by Darinbob ( 1142669 ) on Friday February 10, 2012 @07:51PM (#39001603)

      Also you must do this formally and rigorously. That's the real challenge. Read all the specs, or write them if none exist, create a detailed test plan, etc. Very often the testers are the true experts in a product. The devs may understand their little corner of the product but often don't understand the product as a whole. QA is often a liaison to many other groups as well, being asked to replicate bugs that customers or labs found, getting first products from manufacturing and testing those. They QA people know how to configure everything and will be asked about it. Need to keep track of all software releases and remember which bugs were in which, because people are going to ask you this stuff too.

      Automated testing is a very useful skill for QA as well and knowing this stuff can be very helpful in getting and keeping a job. Then there's performance testing, security testing, unit testing, end-to-end testing, integration testing. And meetings.

      Development experience can help too, in that you often have better ideas on how to break things and what corner cases are (of course your job is not really to break things but to verify that they're working, breaking stuff is just a nice perk).

    • by Ichijo ( 607641 ) on Friday February 10, 2012 @07:52PM (#39001607) Journal

      Go down a list of features.

      If you're very lucky, the software will already have a list of requirements [amazon.com]. And if you're almost as lucky, your first job will be to create it.

      If you're not even that lucky, then you're pretty much screwed.

    • by wvmarle ( 1070040 ) on Saturday February 11, 2012 @06:10AM (#39003777)

      How about usability testing?

      And maybe accessibility? (this one is particularly of concern for web sites)

      All I see in this discussion is how to find sofware bugs and issues that crash the software - important sure, but that doesn't mean the software is easy to work with. Having a design team that designs the UI beforehand also doesn't mean there are no bottlenecks there.

      Good software for me means that the software not only does what you expect it to do, but that it's also easy to use.

  • by Kenja ( 541830 ) on Friday February 10, 2012 @06:08PM (#39000345)
    There are several different industry software testing platforms which allow for the creation of complex automated testing scripts. These scripts can be very complex and constitute a programming language in their own right. The idea is to be able to provide a script that the developer can run to recreate a set of error conditions so they can be fixed. Likewise you would end up with a series of scripts, that when run (often over the course of a day or more) will test all aspects of the software and check for new errors or confirm functionality. These scripts will have to be updated as the application changes, so if done right its a full time job.
    • by afabbro ( 33948 ) on Friday February 10, 2012 @06:18PM (#39000463) Homepage

      The job is probably somewhere between these extremes:

      1. As Kenja describes, managing a complex software testing platform, installing the software, licensing it, configuring it, writing the scripts for it, working with the dev team to make sure your testing is in sync with what they're doing, etc. Simply managing a complex product and all of its organizational interconnections could easily be a fulltime job. Besides the product, you'd probably have to know whatever programming language(s) are being used (Java, C#, whatever), plus the app's own scripting language, plus possibly some ancillary languages - perl, SQL, etc.
      2. Having a Word doc with a bunch of tests you are supposed to run every time they are ready to release a new version. You manually go through all these tests and send emails or enter a problem in a bug-tracking system once something breaks.

      If they didn't say "we're looking for someone with GronkTest 3 experience" it's more likely to be nearer the latter than the former.

  • 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.

    • Re:Just say no (Score:2, Interesting)

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

      It depends. Often if you are moving to a better or bigger company they will start you in test. A lot of people move on, but test can be great.

      You typically work less hours.
      Test Automation can often be more difficult that the Engineering positions.
      The pay can be just the same.

    • by tgd ( 2822 ) on Friday February 10, 2012 @07:39PM (#39001457)

      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.

      That depends entirely on the company. Some of the big software companies, like Microsoft as an example, pay equivalent salaries to people who are SDE or SDET at any given level, and its fairly common for people to move back and forth over the course of their career. (Microsoft, to use the example again, has both SDET -- software development engineer/test -- and a very small number of STEs -- software test engineers. The latter are basically click testers, the former are software engineers.)

      A lot of it comes down to what testers are doing at a given company. A good engineering firm, the difference is someone who writes code for customers versus writes code for internal quality uses. The skill, education and experience bars are the same between the two. Often times the actual engineering is more complicated, more interesting and less driven by customer BS doing SDET work.

  • 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 no-body ( 127863 ) on Friday February 10, 2012 @07:26PM (#39001317)

      ...

      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....

      That's incorrect - a tester follows a test plan and performs the test steps. This can be a program and the tester will evaluate the program output if it conforms to specs.

      A test plan is part of the design process and should run parallel to development.

      What you describe is ad-hoc testing - finding additional defects by going outside a structured, predefined test plan.
      There is no way that more complex systems - banking, Internet, manufacturing etc. would function without a highly structured approach including testing.

      The term "Engineer" is undefined - can mean anything.

      • That's incorrect - a tester follows a test plan and performs the test steps.

        - aha. And a developer follows a design and performs necessary steps to build the software.

        And a BA follows necessary steps to collect all of the necessary business requirements.

        And a DBA follows necessary steps to ensure that the data model is correct and the database configuration makes sense for the project.

        And a PM follows the best practices and whatever steps to ensure that the project is on time and within the budget and it delivers what it promises.

        And the sales follow the necessary steps to ensure the customers are buying what they believe they need.

        And the marketing follows the necessary steps to ensure that the offerings are of value to the customers, partners, clients and what not.

        The top management follows the necessary steps to direct the company towards a successful vision, etc.

        And no company fails to achieve its goals.
        And no project fails.
        And no design decision is amiss.
        And no developer makes mistakes.
        And QAs never find the unexpected.

        And banks don't fail.
        And governments don't fail.
        And Challenger didn't blow up.
        And countries don't fail.

        Give me a break. Things don't work the way they are 'supposed' to, a good QA will catch problems even if nobody thought of them and whatever plan that everybody thinks is the shit today, is shit tomorrow, just not that kind of shit. Even in the banks and insurance companies and investment businesses and medical companies and utilities and manufacturers and telecommunications and who knows what else.

    • by stephanruby ( 542433 ) on Saturday February 11, 2012 @03:31AM (#39003401)

      The job of a tester is to put together a meaningful plan...

      ...and then not use it.

      http://googletesting.blogspot.com/2011/09/10-minute-test-plan.html [blogspot.com]

  • by spiffmastercow ( 1001386 ) on Friday February 10, 2012 @06:16PM (#39000439)
    I pity our poor testers.. I have to assume that they must develop some sort of mental detachment capabilities to be able to sit there and test the same thing over and over and over. Go back to your cube. Spending hours trying to get the damn login screen to work in every browser might seem painful, but it's nothing compared to the hell that is testing.
  • by wwbbs ( 60205 ) on Friday February 10, 2012 @06:16PM (#39000441) Homepage
    I've never heard of Software Engineer that did not now what a Software Test Engineer does. Perhaps User Acceptance Training? Your the middle man that takes requirements from client and makes sure that what the Developers produce works within the framework the client provided. Generally you create mock ups and run through the data until all the results and the interface are what the client expects.
  • by Lashat ( 1041424 ) on Friday February 10, 2012 @06:16PM (#39000443)

    Anything from glorified mouse-clicker and result recorder on up to programming test cases and developing an automation framework.

    The line blurs depending on WHO you work for and WHAT you work on.

    My best suggestion is to ask the person offering the job what they have in mind for someone of your skillset.

    • by jtara ( 133429 ) on Friday February 10, 2012 @06:38PM (#39000725)

      Best answer so far!

      I once did a contract job for Conexant, devloping software to acquire and stuff test results into a database, format reports, etc. (for Docsis cable model qualification). Now I wish I'd never put that on my resume, because I get calls for "software test" all the time.

      At Sony I got to see game testing. Now THAT was a three-ring circus! Signs posted about no sleeping in the halls, and no hats or sunglasses... Some of that testing actually is just playing unreleased games and recording your reactions to the game play.

      I'm pretty good at "monkey testing" (pounding on a keyboard to try to make the software break) but I find writing test plans and test cases tedious. I've actually done monkey testing, and there are cases where it's appropriate.

      Rails programmers, of course, all write their own tests. (Riiiiiiiiiight!)

      There really is no way to know just what the term means, because it applies to such a wide variety of activities.

  • by khellendros1984 ( 792761 ) on Friday February 10, 2012 @06:17PM (#39000455) Journal
    We call them "Quality Assurance Engineers" (QA). Ours talk to the software engineers to build applicable test cases, and then continually run the tests on the platforms they've been assigned to work on.

    Most of the job is fairly mindless, just reporting errors to the main developers as bugs so the devs can work on fixing them.
  • 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 gestalt_n_pepper ( 991155 ) on Friday February 10, 2012 @06:19PM (#39000477)

    You have software with expected behaviors. First you verify that behaviors occur. If they don't, you have a fail. You formulate a theory as to what might cause the fail and you test to see if you can reproduce it. If you can consistently create the fail, you report it to development, who may fix it if it's severe enough. It's somewhat analogous to scientific method, albeit writ small.

    That's the box top explanation. In practice, of course, it's *much* more complicated.

  • by CannonballHead ( 842625 ) on Friday February 10, 2012 @06:20PM (#39000491)

    I'm a software tester for data moving products.

    While a lot of testing is repetitive, the repetitive stuff can often be automated. For example, there's functionality that exists in every release ... so automating those testcases such that they are easy to run hands-off is good. This automation is often something the tester will be doing.

    For new features, what typically happens in my group is that the developers will explain how they implemented a given feature and how it should work. We are responsible for testing this feature - with any tips that dev gives us - as well as trying to put it through various scenarios that cause it to break.

    In my product's line, for example, we do clean reboot and power cycle/crash testing. What happens to our product when the power goes out? What happens to the data that was being moved? Does it recover? That sort of thing. This requires thought - and, contrary to some comments here, since we all want our business to SUCCEED and make money, which means customers need to be happy with the product, development is happy when we find errors or scenarios that they did not plan for in their coding. The earlier we find them, the better.

    Day to day activities? Well, I'd break it into two major sections.

    Planning

    The test group, in my case, is responsible for reading through the planned product's features and changes and coming up with a test plan accordingly. This is then reviewed by developers, the test group, etc. Usually, during this time period is when a lot of work on automating previously-manual testcases can be done, in preparation for the next release. Also, planning for what testing environments will need to be setup and starting to set them up... it depends how big your group is I guess. Since mine is relatively small, all the testers help out with setting up various machines for testing, too.

    Testing

    During testing, the test plan is executed. Day to day activities include test environment setup, manual testing, automated testing, discussing potential issues with developers and opening work requests (WRs) if it's decided that it is really an issue and not a weird environmental problem etc.

  • by K. S. Kyosuke ( 729550 ) on Friday February 10, 2012 @06:20PM (#39000495)

    "Can anyone shed light on what a software test engineer's day to day responsibilities are?"

    Making yourself very unpopular among your fellow developers! :]

    Seriously, that really depends on what exactly is being tested and how the testing is organized. I've seen people with the description of "tester" sitting in a single room doing totally different things. Have some more input data?

    (But one virtually bulletproof hint is: If you don't know Python, learn it. It might save your life if you ever decide to test anything.)

  • Variety Pack! (Score:5, Informative)

    by Isarian ( 929683 ) on Friday February 10, 2012 @06:21PM (#39000511)

    As a software tester at my job, my work includes:

    - Building test scripts for each application (I use Google Docs spreadsheets) that we develop
    - Perform feature-specific or fix-specific regular testing of applications during development cycle
    - Argue with developers over severity of bugs
    - Coordinate full-scale software testing before each release
    - Update documentation when developers fail to do so
    - Argue with developers over importance of different features in terms of development time

    A big part of what makes or breaks you as a software developer is the willingness to go off the beaten path. For example, when I test, this is what I consider:

    - Hmm, that's an interesting text field, and it's meant for an IP address. I wonder what happens if I type "abc::1234**!!whymeeee" into it (input validation)
    - This is a resizeable dialog - if I resize it absurdly in vertical/horizontal, do elements in the dialog scale correctly?
    - Here's a text area that's meant for a paragraph or two of text. If I put the Iliad into it, does the text run off the page? (bounds checking, text limit checking)
    - Here's a dialog that has to validate text - what are all the possible errors it could encounter, and are the error dialogs properly implemented for each? (check all error condition handling possibilities)
    - This dialog is localized into 15 languages - is the page sized/formatted correctly in all languages?
    - This program is meant to be installed to C:\Program Files\Blahcompany\Product - what if I install it to a nonstandard location?

    This will ultimately put you at odds with a lot of developers because your job, every day, is to make the assumption that they have made mistakes that you will find. I enjoy it, and find it to be a rewarding experience, but that's because I work at a company that highly values its software testers and takes QA as a serious priority. Try to get a feel for how this company treats QA, because if all they're doing is using you as the fall guy for bugs you made them aware of before a release, it'll be no good.

    • by Ralph Spoilsport ( 673134 ) on Friday February 10, 2012 @06:38PM (#39000733) Journal
      GOOD LIST! I would add that there are other aspects as well-

      There's a "horizontal" distinction in testing, by colour: Black Box, grey box, and white box.

      Black box is what the post above is doing - everything "under the hood" is not to be looked at, only the results. This is the easiest form of testing. It can be automated using scripts, if the UI's field order is stable. I like Black Box - you just get to "fuck shit up". My fave was to copy and paste the Unabomber manifesto into everything and watch the fireworks. Also, in the early stages, Black Box can have a lot of say in the design, because if the UI is crap, the black box tester will notice immediately - workflow is retarded, or there are too many clicks to a result, or similar issues. Also, Black box usualy entails running the daily build server, and doing a daily test of the build to see if it meets minimum criteria. If it doesn,t then the programmers are informed to not use that build and stick with the old one until it passes muster.

      Grey Box is in between - you're looking at the code when you can, and you're developing test scenarios for scripting engines of other systems. For example: you need to test load balancing - so you need to know where in the code stuff goes in and out and how the server takes the data, processes it, and sends it out - that takes a bit of programming - the programmer can write that for you - and then it's your job to suss out what the results mean. Also, when something breaks, you need to find where in the code it's broken. How to fix it is not your job or problem - but you need to be able to say "this is where it divides by zero and causes the computer to puke blood".

      White Box is where you're managing low level testing of each software component (after the programmer runs it to see if it works at all) and if it doesn't work, you need to be able to flag it properly and send it back saying "it broke here because" kind of stuff. I find white box even more stressful and difficult than actual programming. You have to be a "programmer's programmer". Pain inth e ass, and rarely worth the money or hassle.

      I like doing black box testing. It's a blast. I love to just fuck shit up. It's a trip. It's a bit like doing detective work. Grey Box is more intense, but can also be fun, dpending on the app you're testing and the team you're with. IF they hired by the "No Asshole Rule" then grey box can be rewarding - it pays better than black box and it often includes a lot of black box.

      That's how it was when I left software dev in 2005. From what I gather it hasn't changed that much - it's more automated than before, but only after the app is mature enough to withstand it.

    • by tlhIngan ( 30335 ) <slashdot@wo[ ]net ['rf.' in gap]> on Saturday February 11, 2012 @04:15AM (#39003521)

      - Here's a dialog that has to validate text - what are all the possible errors it could encounter, and are the error dialogs properly implemented for each? (check all error condition handling possibilities)

      Don't forget in this case to try Unicode text and make sure it comes out or errors out appropriately.

      This is especially important if one of the tasks is to adapt the information for another system which may be Unicode-unaware - how does the output come out on the other end, and does it still work? Or does the illegal Unicode input make it through (even if you use proper validation frameworks, they may guarantee the output is valid Unicode and not say, ASCII).

      Especially try the bidi override characters to see if your output suddenly goes weird.

  • by perpenso ( 1613749 ) on Friday February 10, 2012 @06:24PM (#39000551)
    It could be something good. At a past employer we had software engineers who developed the product, six figure telecommunications boxes, and software engineers who were part of the QA team. Those who were part of the QA team wrote code to test sub assemblies during manufacturing, to test fully assembled boxes before delivery to customers, regression tests to exercise the development team's software in simulated environments (i.e. testing development versions of code before approving the code for release), etc.
  • by Vandilzer ( 122962 ) on Friday February 10, 2012 @06:28PM (#39000607)

    If they have a good regression system setup, it will mean you will write a test case once and it will automatically run for you, and you are good, you will automate all of this is it is not already done. You will only go back to look at these if something breaks.

    You will also likely get the specifications for a new component and a script and be expect to try all possibilities, the better once know how to program and thus do thing that they know we likely miss. Bad testers are a dime a dozen, good tester are golden.

    Generally think about it like being the first customer and having to learn a new components all the time. A person who's job it is to figure out all the ways to use something within the rules given (not that much different then hacking, actually if you think about it hackers are just really good testers, they win when they find a bug).

    Testers are also involved often in customer deployments and trials here where I work because they have the most experience using new software. Developers know how to write thing, testers know how to use it (Big difference).

    In the end, you will make what you will of it. Go talk with them, all you have to lose is a bit of time.

    Best of luck,

    ---
    I'm a programmer not a English major, if you have a problem with my writing, write a better grammar and spell checker, then we can talk.

  • by rsilvergun ( 571051 ) on Friday February 10, 2012 @06:30PM (#39000631)
    Seriously. The job of most software testers is try the software and then complain it's too hard to use so the UI guys can tweak it down to a 3rd grade level or so. I guess there's regression testing too.
  • by Modern ( 252880 ) on Friday February 10, 2012 @06:32PM (#39000649)

    Those who can, do. Those that can't, teach or QA.

    While not always true, you have probably heard the above statement many times. Testers in many cases are responsible for bringing the whole project together. Other departments might make portions, a graphics/animation department, software programers, maybe math groups or database, however you are the one who has to test all the components together. For all this responsibility you get the least amount of pay, and are expected to know everything about all the parts and pieces. Blame QA is the common cry heard among companies, when something gets out buggy. The job itself could be ungodly script running repetition, or pretty cool new project stuff that has not been automated and the bleeding edge of the companies new products(with ungodly script repetition to follow later).

    It tends to be a pretty thankless job, but in some cases it could be a good way to get into the company and use the job as a stepping stone for a better paid, less responsible, software developer (or otherwise) job at that company.

  • by chrismcb ( 983081 ) on Friday February 10, 2012 @06:36PM (#39000713) Homepage
    A tester tests the code. A test engineer typically will write code to test the code. These aren't unit tests they are writing. But test scripts. Testers tend to test the finished product. They are the ones doing integration testing. If you are currently a programmer you probably will not want to be a tester.
  • by charlieo88 ( 658362 ) on Friday February 10, 2012 @06:41PM (#39000757)
    What Does a Software Tester's Job Constitute? Well, from the perspective of Project Management for my off shore outsourced projects... NOT A DAMN THING!
  • by MagicM ( 85041 ) on Friday February 10, 2012 @06:42PM (#39000767)

    Everything I know about testing, I learned from The Trenches [trenchescomic.com].

    Oh, and doing it myself, of course. Of course I test my code. Why? Who's asking?

  • by DontBlameCanada ( 1325547 ) on Friday February 10, 2012 @06:44PM (#39000789)

    Once you have a "testing" job on your resume, its pretty dang hard to get anyone looking for a coder to consider your application seriously. I've run into at least a dozen hiring managers who discard resumes for dev positions solely because the last job someone held was as a tester.

  • by NotSanguine ( 1917456 ) on Friday February 10, 2012 @06:44PM (#39000807) Journal

    Software test engineer was my first technology job, so I was pretty junior. Your responsibilities might be more extensive if you have more experience. That said, my responsibilities included:
    Overseeing the build process
    Maintain build scripts/makefiles, manage software repositories
    Grabbing the latest code from all modules and building from source
    If the software didn't build properly, identify the source of the problem and (if I could) fix it, otherwise provide feedback to the responsible developer

    Integration testing
    Create and maintain test environments and scripts
    Once the software was built, test major functionality to ensure that new code didn't break anything
    Test whatever functions had been modified (new features, bug fixes, etc.)
    Debug any issues and (if I could) fix them, otherwise provide feedback to the responsible developer(s).

    Troubleshooting
    Reproduce bugs that had been escalated to the dev team
    Debug the issue and identify the source
    Fix the bug (if I could), otherwise provide feedback to the responsible developer(s).

    Software Releases
    Build release versions (Beta and production) for distribution to customers and manufacturing
    Regression test release versions

    Other Stuff
    Create test reports
    manage bug tracking
    Set up dev environments for the developers
    Design and set up test beds for testing and troubleshooting

    Developers were responsible for unit testing their code before releasing it to me for Integration. That may or may not be part of the job you're looking at.

    HTHAL

  • by dotrobert ( 923547 ) on Friday February 10, 2012 @06:54PM (#39000917) Homepage
    What software/application you are working on can really change the equation, just as it does for the application developer, but here is a short list of software and skills I use in testing a publicly available web application, I'm sure I'm missing things, just a quick list...
    • Tests are written in Java.
    • TestNG for managing what gets tested and defining the data providers
    • Jenkins for continuous integration and scheduled testing
    • Selenium to drive the web app ( a proxy that gives us pretty darned complete access to a web page )
    • SQL most often from the java code, but sometimes manually in a SQL Query client to verify data.
    • Linux - general knowledge to help track down the source of problems on occasion. We dont like to throw "dumb" reports back to the devs.
    • Apache/Tomcat - we write log parsers to verify some activities, and sometimes just tail/grep them in narrowing down the cause of a bug.

    And of course we manually test, too. But, damn, is that boring... :)

  • 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 Keith111 ( 1862190 ) on Friday February 10, 2012 @06:56PM (#39000941)
    At Microsoft, for example, there are 2 test positions which sound the same but are VASTLY different. "Software Development Engineer in Test" and "Software Test Engineer" are the two positions, but SDET is given a lot more responsibility and gets to do a lot of development and works very closely with the developers and others on the team. STE generally gets little development and is all about making sure the test environment that actually execute tests is working and making sure the infrastructure is happy and the network is working. So my advice would be to make sure that you ask about other testing positions and discuss the differences and make sure you are getting the right thing. Testing is awesome and fun and very important and usually more difficult to do right than development but not all testing positions are created equally.
  • by PureFiction ( 10256 ) on Friday February 10, 2012 @06:59PM (#39000989)

    Your development background will be very useful in a QA / Test Engineer role, assuming you are considering joining a technically competent organization.

    I say this because many companies have an antiquated view of "testers" as low skilled keyboard jockeys able to bang keys and input fields like monkeys on ritalin. Avoid these places like the plague...

    A premium QA/Test Engineer will apply development and other solid technical skills to:

    - Provision test systems spanning wide varies of operating systems, network configuration, applications and settings, in short: be able to build everything you need to test the systems tasked of you.

    - Obtain a deeper understanding of the system under test; able to dig into code to discern logical errors and oversights, triage down to root cause and even suggest a fix/patch.

    - Integrate test automation technologies into the software process so regression and performance testing is part of a continuous integration & test lifecycle. Manual testing should only be a part of your efforts, as software systems continually expand in scope and a manual-only test process will eventually be overwhelmed by progress.

    - Extend and apply third party tools, ranging from code performance analyzers to network traffic capture/replay, code coverage analysis and unit test frameworks, fuzzers and chaos monkeys, etc.

    - Understand security risks and defensive coding techniques to identify deficiencies in a code base or implementation/design which introduce vulnerabilities. Catching these defects before a product goes live is very rewarding and can be exceptionally cost effective.

    - Develop internal tools or customize existing software using Shell, PERL, Python, Ruby, Java, C/C++, and other languages as required or appropriate for the task at hand.

    - Communicate effectively with multiple stake holders in an organization: development, product support, marketing, administration, operations. These will all be interfacing with you and the ability to tailor the technical depth and nomenclature of your written and oral communications to each of these groups is critical to being an effective QA/Test Engineer.

    And many other skills and capabilities I've not listed, depending on the context of your role in the group and the domain of the organization you work for.

    Many people still consider QA a less important or prestigious occupation compared to other technical professions, like software development. While the prestige may be lacking, the job satisfaction of a competent QA/Test Engineer who applies development, operations, and security analysis skills to improve a product is significant.

    The many varied resources you should incorporate into your tester toolbox is too long to list here. Many sites exist devoted to QA toolsmith / test automation / security analysis roles, and you're going to want some skills and tools from all of these specialties at your disposal.

    Good luck! I hope you consider the switch; the world needs more competent QA/Test Engineers.

  • by Skapare ( 16644 ) on Friday February 10, 2012 @07:09PM (#39001097) Homepage

    ... is that I should have been a software tester because it seems every program I touch I always find something wrong with it or manage to break it somehow.

  • by SageMusings ( 463344 ) on Friday February 10, 2012 @07:25PM (#39001303) Journal

    A tester needs to be prepared to take home less pay and expect high turnover in his/her dept (if he/she doesn't leave first).

    We have a QA dept and they don't stick around more than a year, tops. By the time they really get into the product, they're either fed up with the pay, the hours, or they get switched to another product. QA catches few important bugs because we (a) treat them as second-class citizens and (b) we don't involve them at the beginning of the design cycle.

    I've also seen some pretty brutish egos among fellow devs wear out QA staff. Do you want to subject yourself to that?

  • by dmomo ( 256005 ) on Friday February 10, 2012 @07:26PM (#39001305)

    Among other things, a software tester's job CONSTITUTES the software development process. I think you mean "consist of"?

  • by trolman ( 648780 ) * on Friday February 10, 2012 @07:36PM (#39001425) Journal
    Probably will involve TPS Cover sheets.
  • by ATMAvatar ( 648864 ) on Friday February 10, 2012 @07:50PM (#39001583) Journal
    ...you want quality assurance. Testing is a part of the whole. Good QA is involved throughout the process and involves more than just "pressing ctrl-a while in high-DPI mode with the program maximized caused the DVD tray to pop out instead of display an about box."
  • by barfy ( 256323 ) on Friday February 10, 2012 @08:21PM (#39001837)

    Create and propagate information that helps people to create and ship the software...

    Everything else is details on this. I was the senior software tester for multiple projects. I got paid more than most everyone else, because I owned the above. I helped and did everything, and spent as little time as possible, NOT doing anything else.

    However, most people spent tons and tons of time NOT doing the above. The created very little new and useful information, and propagated very little. The company would make up for this by hiring LOTS of people, to try and create more information. Lots of time, people were given my stuff, in an attempt to expand on it.

    Personally, I spent a very small fraction of my time on regression testing. A little more on verification. But most of my time creating and propagating information.

    I would spend time creating models and predictions, and watching carefully what would happen. I would look at errors, user expectations, standards, behaviors and functionality. And barf stuff out as quickly as possible. And some percentage of time was coming up with larger and better explanations.

    I was never done, and I never could work enough to find them all, and I was never satisfied. There was always rich veins of information to be uncovered and passed on.

    At some point it shipped anyways...

    Sometimes I was there for the next version, sometimes I did other things.

    My personal satisfaction, was knowing that I had a substantial impact on what shipped. And that it was better for me being there.

  • by ChrisGoodwin ( 24375 ) on Friday February 10, 2012 @08:40PM (#39001977) Journal

    Throw a belt sander in the toilet, then turn it on and leave it.

    You'll note that it does a lot of noisy grinding, though achieving very little of value, while being shat upon at random. It will continue doing this until it burns out.

    This is the life of a software tester.

  • Avoid it. (Score:4, Informative)

    by NilleKopparmynt ( 928574 ) on Friday February 10, 2012 @08:52PM (#39002047)

    I have been working in the testing field for almost 20 years but after a 5 year stint at Microsoft I found it to be such a horrible experience that I will never work with testing ever again. There are numerous problems and here is a selection.

    1. As a tester at Microsoft your main use is as a scape goat. If you find a big bug then it is all your fault. No matter when you found it, you should have found it earlier. It is a pretty wierd experience when you do your job properly and well and you still can be blamed for doing a bad job.

    2. As a tester at Microsoft you really are a second class citizen. You are considered less competent and more stupid. You are also far less important than anyone else since what you do does not explicitly impact the product.

    3. As a tester at Microsoft you do not have a career. It is pretty easy for a newbie to reach SDET2 but very few reach senior level. Where I used to work there was a 1:1 ratio between testers and devs but it was a 1:7 ratio between senior testers and senior devs.

    4. When you point out the problem with testers not having careers it only results in you having to listen to the director of test lying to you for an hour or two regaring how they are aware of the problem and how more testers now are going to be promoted. The result that year was that 12 devs reached senior level but not a single tester reached senior level.

    5. If you are good at your job people are going to hate you. Your job (among many other things) is to find bugs in the product and people really love having someone pointing out all the mistakes they make.

    6. If you have bad luck (like me) then you might end up in an automation swamp where the devs repeatedly break your tests and you spend an enormous amount of time fixing all the breaks. This really murders your competence.

    7. If you have really bad luck (like me) then you might find yourself with a test manager that has nothing but contempt for testers and their competence plus thinks it is really important for testers to do a lot of mundane manual testing.

    8. Also, having tester in your CV is bad if you want to pursue a career in software development. It will make it harder for you to get a job as software developer.

    • Re:Avoid it. (Score:4, Interesting)

      by wild_berry ( 448019 ) * on Saturday February 11, 2012 @08:44AM (#39004091) Journal

      I'm a software tester in an organisation which has clear delineation between manual testers, software test engineers who build automated tests and developers (I gotta say that I speak for me and not them here - that's the policy out of the way). The first two of that list need to have a 'question everything' testers' mentality; the last two need to have a technical grasp of how the whole thing works, from the core OS, servers and transports to the libraries used and the UI.

      A manual tester is concerned with the human experience of your software. Typically there will be a script of the exact actions or the class of actions the manual tester is expected to cover. Some firms roll regression testing and new feature testing into the manual tester's role, others have a separate user-acceptance testing team who stand between released software and deployment.

      The automation tester's role is to make the computer test the software, by building a framework around the program and its installed environment to check the system as-a-whole does the intended job. Some automation testers also write unit tests in the core program code; mostly this is left to the developers, who are increasingly being asked to show that their code works - and doesn't break the existing code - before check-in. Some places operate a Behavior-Driven Development (BDD) process where client needs are expressed in testable ways - so that the evidence that your software does what a client wants is written down clearly for the client to see, the tester to test and the developer to build. Some BDD systems even build tests which show that these goals are met, and are known as Test-Driven because the proof of rightness is shown by the tests.

      Preparing for an telephone screening or interview about software test engineer, you will need to show that you're technically-minded, that you've worked engineered a test system before, that you understand the benefits and shortcomings of building such a system (such as knowing when to build tests and when to leave low-hanging test fruit to manual testers), and that you're concerned for the quality of the product more than for building a new toy test rig.

      I disagree with nearly every point made above, but I know this as a tester: there are a lot of people who shuffle into testing because it's the gateway to working in software. That's no bad thing. But mix it with the lack of confidence to apply for and get developer roles, and you will probably harm your sanity and your career. In every job, you need to be competent and confident. On top of that, you need to be personable so, for example, you don't make bug reports critical of the developers who made them (and know how to calm down a dev who's got that idea).

      To be a good tester is genuine hard work requiring the best of your technical insight, pedantry and commitment to high standards, but to be a great tester will call for charisma, kindness, honesty, good working relationships, and the skills to help make a dysfunctional team work right.

      If you're only a tester for a short while and move on to a developer role, you can either blame the economy for not having enough dev jobs (so you compromised in order to fulfill your passion for making software), or you can say that you wanted to improve your developer skills by learning what it's like to be on the other side of the fence as a tester. It's not a black mark if working as a tester makes it a benefit to you and a prospective employer.

  • by Loopy ( 41728 ) on Friday February 10, 2012 @11:15PM (#39002697) Journal

    Software Test Engineer is NOT a subset of Software Engineer.

    Just be honest in the interview. If they ASK you to guess, then guess. Otherwise, just tell them what you know. You might be a perfect fit but you might be missing the particular skills they're looking for.

  • by SirGeek ( 120712 ) <sirgeek-slashdot AT mrsucko DOT org> on Saturday February 11, 2012 @12:05AM (#39002849) Homepage

    As some who DOES do software testing, there are a few things good software testers do but it depends on exactly what type of testing they're looking for.

    1. Are you doing functional testing ?
    2. Are you doing business acceptance testing ?
    3. Are you doing unit testing ?
    4. Are you going to be using Automated Testing ?

    Generally, you will need to analyze the business requirements to create functional tests to ensure that you have code coverage and that the code does exactly what the requirements say. If there are variances, they need to be documented and someone has to determine if they are bugs, or omissions of the requirements (and then update the requirements).

  • by tlambert ( 566799 ) on Saturday February 11, 2012 @02:43AM (#39003259)

    Your question is too broad and too general to be meaningful, since the answer is going to be "it depends on the role they have in mind for you".

    There is no such thing as a meaningful definition of a "certified software test engineer", and there is no such thing as "best common practices" or anything else that would give a common, formal definition of what someone has called "Software Test Engineer" in a job posting means by the title.

    It means whatever it means to the person who told the job poster to write in the job posting. Usually, job postings have lists of relevant experience, certifications/degrees, and tools familiarities which will give you some clue.

    Most software testing is Ad Hoc (read: "not reproducible without activity logging"), and most automated testing is reactive (read: "sure hope we don't see this bug again, let's write a test which will probably never fail again"), rather than a result of a formal specification to which actual software behaviour can be compared.

    It's possible to get to the point where software testing is a formal discipline, but in general, no one seems very interested in doing so unless you are talking about life support systems (e.g. getting correct results from medical equipment, not sending a reactor hypercritical, or not crashing a Mars probe into the ground). Even then, desire is not frequently reduced to practice, and mistakes are made.

    PS: attempting to cram for an interview almost always leads to bad things: claims on your resume to knowledge you do not have in depth, and can not answer deep questions on, or worse, getting a position for which you are not qualified and futzing everything up for everyone else involved.

    -- Terry

  • by DeBaas ( 470886 ) on Saturday February 11, 2012 @09:05AM (#39004143) Homepage

    I have been a test manager for years, that includes doing intakes with new testers. Whilst I highly value development skills, the worst testers are those that just do it because there is a need for testers right now. I always look for that the tester: really chose to be a tester, and did not make that choice just because they couldn't land a contract as a developer.
    There will be exceptions, but most are either gone the moment they do get a better offer or worse, when they find flaws in the software, they try to fix it.

    So my tip would be: either simply do not go for this contract, or come up with some real good explanation that you really want to test. The good explanation should not include anything that is based on money/bad market etc.

  • by gordona ( 121157 ) on Saturday February 11, 2012 @09:59AM (#39004313) Homepage
    Tester to developer: "Your code as a bug". Developer to tester: "Your test code has a bug".
  • by jgrahn ( 181062 ) on Saturday February 11, 2012 @02:15PM (#39005895)
    (Reiterating some things others have said already, I'm sure.)

    A "Software test engineer" job can mean pretty much anything, and you should find out before accepting.

    It can be focused on finding bugs, or on ticking off a list of tests to have passed before shipping.
    It can be close to the code, or with the product as a black box.
    It can be detailed functional tests, performance tests, or big statistical simulations running for days or weeks.
    It can be work together with the developers, or completely isolated from them.
    It can be manual GUI testing, automated, or with a complex mix of test tools

    The tester can be (perceived as) a low-level grunt, or as the person who knows the product the best; the end users' only representative.

Never tell people how to do things. Tell them WHAT to do and they will surprise you with their ingenuity. -- Gen. George S. Patton, Jr.

Working...