What Does a Software Tester's Job Constitute?

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?"

Comments

What Does a Software Tester's Job Constitute?

[Anonymous Coward]

A: Suffering

BREAK IT

[phrostie]

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

Re:BREAK IT

[Darinbob]

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

Testing scripts. Lots o' em.

[Kenja]

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.

Re:Testing scripts. Lots o' em.

[afabbro]

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.

Re:Ummmm

[tripleevenfall]

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

Just say no

[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:Just say no

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

Re:Just say no

[tgd]

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.

You are going to be the one who knows the software

[roman_mir]

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.

Are you Sure you are a Software Engineer?

[wwbbs]

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.

Pretty wide berth of possibilities here.

[Lashat]

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.

Some developers appreciate their QA people

[perpenso]

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.

Re:Some developers appreciate their QA people

[stanlyb]

Seconded. If i have to choose between having a manager and QA team.......i would not even try to think.

Re:Some developers appreciate their QA people

[Dastardly]

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

Re:Some developers appreciate their QA people

[dotrobert]

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.

a lot recruiters talk out of there ass / have no i

[Joe_Dragon]

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

I am a software tester.

[CannonballHead]

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.

Re:it means

[Lunix Nutcase]

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

The epitome of a tester

[AliasMarlowe]

Any tips?

Study the techniques of Bob the Bastard in testing hardware. Apply analogous techniques to software. Software developers will fear and respect you, and tremble at the mention of your name.

Re:The epitome of a tester

[Anonymous Coward]

Any tips?

Yes. Review the Anonymous Coward posts in this thread. Many of them were written by software test professionals who don't want to speak frankly where their employers or others can associate it with their name. Many AC comments here are very good.

Variety Pack!

[Isarian]

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.

Automation or manual testing?

[chuckfirment]

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.

Re:scripts

[Dastardly]

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.

Depends on the company and the software package.

[Vandilzer]

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.

Re:scripts

[chuckfirment]

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.

Golden Rule of Testing.

[Modern]

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.

Developers often make poor testers

[perpenso]

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.

Re:Developers often make poor testers

[Firehed]

Indeed. Some stuff happens from weird ways that users try to do things that developers simply wouldn't think to test. Case in point, bug I found today: someone bought a six-month subscription by entering 0.5 as the quantity on a 1-year subscription. Our code wasn't expecting non-integer quantities, but happily did the math to get the line-item subtotal. When the data was stored, the 0.5 quantity went into an integer column, which the database cast to an integer by rounding down and suddenly qty * price != subtotal. It was caught and quickly fixed by a data integrity check, but a QA/dedicated testing person that thinks of weird user interactions like that could have prevented it from going out to production in the first place.

Now we have one more thing added into unit tests so it won't happen in the future, but there you go. The code was not untested, it was just used in an unpredictable way.

Re:Developers often make poor testers

[networkBoy]

Yup.
I write test software, specifically software that acts on firmware. The majority of our devs do unit tests, but once the whole thing is assembled together and used as a system interactions show up that are not ideal.
You need some form of QA department between Devs and Customers.
As someone who is already familiar with software engineering you likely would be an ideal candidate for test engineering, because you know how software generally works, and can write meaningful bug reports.
For an interview, if they ask you for strengths, I would focus on your development background and ability to write meaningful bug reports.
-nB

Re:Developers often make poor testers

[asliarun]

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.

Re:Developers often make poor testers

[Javagator]

Developers often make poor testers

Sometimes professional testers make poor testers. I worked on a project with a professional tester who did her job conscientiously, wrote test procedures and methodically exercised the software. We also hired some college kids during the summer and assigned them to test the software. They just tried things. The kids found a lot more bugs than the tester.

Re:Developers often make poor testers

[Anonymous Coward]

Input testing. I imagine most testers have a love/hate relationship with it. It can be one of the most boring forms of testing as you throw in endless permutations of seemingly random data. But it also where you're most likely to discover the most satisfying kinds of bugs; ones that don't crash the software, but instead trick it into following the most absurd scenarios. Discovering that you can enter scientific notation in a field limited to 10 characters and create loans that cost more than the entire net worth of planet Earth? Oh yeah, that's the good stuff. (Bonus points for the developers though...no overflows!)

Re:Developers often make poor testers

[CokoBWare]

A1 comment. networkBoy knows what he's talking about. I transitioned from software developer to test developer, and it's a different animal, but highly rewarding. Knowing how software works is a boon. You know how to write better bug/issue reports.

Test planning and devising scripts is big where I'm at. I do far more documentation and planning WHAT we need to do than looking at code. I do participate in informal and formal software reviews though to keep my mind fresh with code.

Re:Developers often make poor testers

[mikestew]

One of your mistakes is rating by bug count. Another is thinking that a tester's job is to find bugs. What you ignore is the quality of the bugs your professional found. I'm willing to bet she found bugs the college kids would have never found. She also verified that the software does what it says on the tin. If she's spending her days filing bugs on BS defects like typos and "this button doesn't do anything", you're wasting money and boring her to death with crappy code.

Finally, if some random college kids found a bunch of bugs by "just trying things", I'd consider taking a look at your development process. Most bugs should be harder to find than that, with the caveat that I have no idea what kind of a system you're talking about.

Re:Developers often make poor testers

[networkBoy]

I maintain the test infrastructure kernel. It's a constant battle to keep up with dev changes, they change a struct, I change the struct, for the most part they are well linked (we import their headers), but there are some things that simply cascade downstream bad enough to prevent us from even compiling, it's a niche job, half maintenance coder, half lone cowboy. I really like it, but most people don't last on my team. We have three devs that have been at this one job for more than 3 years. Everyone else either goes to just test development (our customers, and sounds like where you are), the rest go to the dev side of house (you can always tell which ones are going to leave outright because they bitch about the maintenance coding).

One word of advice to new test devs out there: Parent post is right, most test development is spent on documentation, a full 3/4 of your coding time is likely to be some form of maintenance coding, deal with it well and you will not hurt for money or employment. Bitch about it and your co-workers will not like you all that much, which makes for very long working days.
-nB

Re:Developers often make poor testers

[uncqual]

It's the same reason authors need proofreaders.

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

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

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

Re:Developers often make poor testers

[David Gerard]

Testers must have cackled with glee (and C++ developers cried) when fuzz testing was invented.

Re:Developers often make poor testers

[msobkow]

Developers shouldn't test their own code, but some of them are viciously effective at testing other people's code. For example, I knew a fellow who would regularly do perverse things during testing like pasting GIFs and JPEGs into text fields, trying to open binaries instead of XML files, and other such perverse things that regular users do by accident all the time. Very, very few people produced application code that this man couldn't break.

But he had a bit of history in testing. When he was working for the Navy designing tests for anti-missile and anti-aircraft gun systems, he came up with a nasty little test.

The hard-wired two Tomahawk cruise missiles together and launched them at the test ship. The guns aimed at one, then the other, trying to decide which was the bigger threat and had to be taken out first. Because a guidewire was keeping the two Tomahawks running in tandem at the same speed and distance from the ship, the gun system had a fit, spasmed the barrels back and forth for a few seconds, then gave up and put itself into "idle" mode.

They added a random "just pick one" step to the algorithm to fix the problem.

Re:Ummmm

[fooslacker]

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.

Test Engineer

[chrismcb]

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.

from Project Management perspective...

[charlieo88]

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!

It's just what it says it is....

[NotSanguine]

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

Re:Boring test cases

[Anonymous Coward]

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.

A QA Engineers testing tools and skills

[dotrobert]

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!

[turgid]

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

Make sure the position is crystal clear

[Keith111]

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.

As Far As I've Been Able To Tell...

[SageMusings]

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?

Re:scripts

[Gamer_2k4]

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.

How is that a criticism?

[LrdDimwit]

Criticizing someone by saying that they got less done than a group of other people is a pretty lousy criticism. All you've really done is establish that there's a benefit to two types of testing: methodical testing, and let's-just-mess-around-with-it stress testing.

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

I feel sorry for her. It seems like she did a pretty good job, and it sounds like she did exactly what the business hired her to do, yet it doesn't sound like she got any respect for it.

Avoid it.

[NilleKopparmynt]

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.

[wild_berry]

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.

Re:Boring test cases

[shish]

If your test is simple enough that it can be turned into a script for a person to run, turn it into a script for a computer to run, and then go test some other more interesting part of the system

Can mean anything

[jgrahn]

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