Forgot your password?
typodupeerror
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:
  • it means (Score:2, Flamebait)

    by gangien (151940)

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

    • by tthomas48 (180798)

      Sounds like someone's got a case of wanting to be a product manager instead of a tester.

    • by perpenso (1613749) on Friday February 10, 2012 @05: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 stanlyb (1839382)
        Seconded. If i have to choose between having a manager and QA team.......i would not even try to think.
      • by Dastardly (4204) on Friday February 10, 2012 @05: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.

      • by rickb928 (945187)

        My QA tester was a contractor, and very good indeed. Among other things, he was totally invested in the process of delivering a great product. Contractor or not.

        And he was let go, as we are making QA and UAT the developer's in-house responsibility. Don't bother to tell me how lousy an idea this is, management has their reasons, without consultation. We would normally predict failure, but it turns our they are releasing a beta of an entirely new product to replace this failed product within 2 months of t

      • by gangien (151940)

        As a developer my OP was more of a joke about my dislike of the arrogance of developers in general. and what seems to be all to often the talking down to the testers.

    • Re: (Score:3, Funny)

      Sounds like someone is butthurt because he got chewed out for filing shitty bug reports that were vague and useless.

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

    A: Suffering

  • 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: (Score:3, Insightful)

      by Dastardly (4204)

      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.

      • 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 @05: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 @05: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 @05: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)

      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

    • by Ichijo (607641)

      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)

      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 @05: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)

      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 (Jav
  • Just say no (Score:2, Insightful)

    by Anonymous Coward

    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: (Score:2, Interesting)

      by Anonymous Coward

      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)

      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

  • by roman_mir (125474) on Friday February 10, 2012 @05: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)

      ...

      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 includin

      • by roman_mir (125474)

        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

        • by no-body (127863)

          Very interesting what synapses got switched on in your system. Please have all the breaks you need.
           

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

  • 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.
    • That's why the good lord invented GUI scripting systems.

    • by Nerdfest (867930)

      If you plan on testing something more than once you're probably wasting your time if you're not automating it. It's wasteful, unreliable, and makes it very expensive in time and money to release new versions, or even patches for old ones.

      • If you plan on testing something more than once you're probably wasting your time if you're not automating it. It's wasteful, unreliable, and makes it very expensive in time and money to release new versions, or even patches for old ones.

        We automate what we can, but there's quite a few things that aren't well suited to automation. A big problem for us is the various display issues with different browsers, or bugs in our stylesheets. That's not something you can automate easily.

    • I'm sure there are also testers that think development is like this, a big inevitable slog. You are both wrong.

  • by wwbbs (60205) on Friday February 10, 2012 @05: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.
    • Your right, you cannot become a SE in any worthwhile college without a course or two mentioning testing and specifically the job of Software Test Engineer.
      That is stuff they start teaching in SE 101.

  • by Lashat (1041424) on Friday February 10, 2012 @05: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)

      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

  • 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 @05: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.

  • 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 @05: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.

  • "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 @05: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.

    • 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

    • by tlhIngan (30335)

      - 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

  • 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), e
  • 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

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

  • by chrismcb (983081) on Friday February 10, 2012 @05: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.
  • 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)

    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?

  • 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 @05: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

  • 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 t
  • Run! (Score:4, Insightful)

    by turgid (580780) on Friday February 10, 2012 @05: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#...)

  • 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 a
  • 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, networ

  • ... 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 @06: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?

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

  • by trolman (648780) *
    Probably will involve TPS Cover sheets.
  • ...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."
  • 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 m

  • 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 @07: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 @07: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.

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

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

  • 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

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

  • 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 @01: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.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington

Working...