Comment: Re:Developers often make poor testers (Score 5, Informative) 228
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.