Slashdot Mirror

← Back to Stories (view on slashdot.org)

What Does a Software Tester's Job Constitute?

Posted by timothy on 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?"

9 of 228 comments (clear)

  1. What Does a Software Tester's Job Constitute? by Anonymous Coward · · Score: 5, Funny

    A: Suffering

  2. Some developers appreciate their QA people by perpenso · · Score: 5, Insightful

    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.

    1. Re:Some developers appreciate their QA people by dotrobert · · Score: 5, Insightful

      I'm a QA engineer and I *do* consider the app developers to be evil, lazy and malicious. Well, not really, I just agree that I should assume so for testing purposes since they are humans. Also, in response to the parent comment, I'm REALLY glad that we work in parallel and directly with app developers. It gives them *and* us tremendous advantage.

  3. Automation or manual testing? by chuckfirment · · Score: 5, Informative

    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.

  4. Re:scripts by chuckfirment · · Score: 5, Informative

    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.

  5. Developers often make poor testers by perpenso · · Score: 5, Informative

    Taking builk testing responsibilities off developers so they can work on more important stuff.

    Not quite. Developers often make poor testers. Software tends to get debugged and tuned for the way developers use the software, which is not necessarily how others (in particular customers) will use the software. How many developers have written a piece of code, tested it conscientiously themselves, presented it to others expecting no problems, and watched these other folks find serious bugs within minutes?

    Having dedicated testers between developers and customers yields better products, even when the developers take testing seriously.

    1. Re:Developers often make poor testers by asliarun · · Score: 5, Informative

      Taking builk testing responsibilities off developers so they can work on more important stuff.

      Not quite. Developers often make poor testers. Software tends to get debugged and tuned for the way developers use the software, which is not necessarily how others (in particular customers) will use the software. How many developers have written a piece of code, tested it conscientiously themselves, presented it to others expecting no problems, and watched these other folks find serious bugs within minutes?

      Having dedicated testers between developers and customers yields better products, even when the developers take testing seriously.

      Actually, that is not necessarily true. I get what you are trying to say, but you seem to gloss over the differences between QA, manual tester, and what the OP was referring to: Software Test Engineer.

      To highlight some of the differences:

      QA is responsible for "assuring quality". This is different from QC which is "checking quality". More often than not, a good QA is a process expert, with the assumption being that good processes ensure good quality. Their goal is to avoid the problem, not to detect the problem or fix the problem. Where the line gets blurred is the fact that a QA often performs the role of a manual tester. This usually depends on the size of the team.

      Manual testing is usually QC - understanding what to test, how to test, and going ahead and testing it. They start off by translating the requirement specification (or user stories if you are agile) into a suite of test cases, add other test cases that might be non-functional or regression related, and finally test the system manually every time before it is released to customers.

      Generally (although not always true), a "test engineer" is more of a developer than a tester. They are usually tasked to develop test frameworks using third party tools or even creating their own framework. The former usually involves scripting and lightweight coding and the latter can involve full blown coding. They can be developing a test framework for executing and managing unit tests and functional tests (often white box), and integration tests, regression tests, and performance tests (often black box). While many project teams skimp on devoting this much engineering to testing, it can give huge returns, perhaps even better returns than development can after a certain point.

      To be fair, the OP has not mentioned anything else beyond "software test engineer" so the role might very well be manual testing. However, the word "engineer" leads me to believe it is more of a automation role. Having said this, companies often embellish their titles with "engineer" to make it sounds weighty.

  6. Re:Ummmm by fooslacker · · Score: 5, Insightful

    Reading and understanding requirements....Writing testing strategies, test cases, and low level testing scripts that can be traced back to the individual requirements that they test....Understanding which test cases map to which functional blocks of a system....Identifying which test cases should be part of a regression pack and keeping that pack fresh through various versions of the software....running that regression pack when requested during future development cycles...performing change impact analysis to select subsets of the regression pack to test various changes...etc.

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

    ...and of course executing test cases and tracking the results.

  7. Re:Boring test cases by Anonymous Coward · · Score: 5, Informative

    Posting as AC but I've been a tester for over 10 years at different companies, many of them contract work. I very much enjoy the work.

    Let me clarify many of the things about being a software tester (which can also include embedded software/firmware). From my perspective:

    Following the test script as written is only a small amount of the big picture.

    Issue characterization. It's not good enough just to report the issue. How often is it reproducible? Device specific? Configuration specific? Timing specific? Line by line steps to reproduce, what was the observed behavior, what was the expected behavior. Is it only on first time launch? Does it reproduce on a variant? Localization form and fit--even if the language is not fully understood, when checking localized builds for form and fit, is there any trucation or overlap, does text go outside the button areas? Does it always reproduce, or how many times out of how many attempts?

    Severity determination--not everything is going to be a showstopper but properly rate the ones that are showstoppers. Also, a low severity defect can still have a higher priority if more than 50% or so of users will see the issue.

    Exploratory testing skills are equally essential. Even after running the script line by line in order, what else wasn't covered? What if a different file is used, a purposely corrupted file--is the software still robust?

    Quick turnaround on resolved issues. Verify the issue is fixed and close the issue, or reopen the issue with additional information as to why the issue still occurred. However--if the issue was fixed and a new issue is a side effect of the fix, then the issue resolved gets closed and a new issue gets submitted with many testing teams. They do not usually add the new issue to the existing issue except as a comment, so that closing one issue does not lose the other issue.

    Teamwork--collaborating with other testers, developers, managers, maybe even conference calls with outsource vendors.

    Test case authoring. Even in a pure manual testing environment, existing test cases need to be updated (or removed if a function no longer exists), new test cases need to be added for new functionality, best coverage in the least amount of test cases is the goal.

    Automated testing--developing test scripts in the automated testing environment. This is programming for testing purposes in many cases.

    It all varies from company to company, project to project--but in a lot of cases being a software tester is not about just go to the next test case and mark it pass, fail, or blocked/not possible for each working day, every day.

    I hope this helps.