Comment Some more thoughts (Score 1) 228
Much interesting stuff ahead of this, one or two more things
QA is basically the meeting place of business/customer requirements and the developer's interpretation of that. So - as a software test engineer you should be able to create a test environment that will sufficiently (and there's a critical value judgement right there) mimic the customer environment. That environment needs good enough controls that it can automatically run through enough of (another value judgement) the functionality to ensure that there are no regressions, it needs to report well enough (ooh look - another value judgement) so that you can write a useful bug report when things go wrong. This needs a historical context of actions so that a good developer can look for a generalized fault (the bad ones just generate point fixes that make that specific problem go away) and enough of a data variance to establish some boundaries for the known good performance envelope for the product.
Having done all that - you need to do enough of a business analysis and provide enough domain knowledge to craft a set of test cases which aim for optimal coverage with minimum effort.
For the new stuff - don't bother automating until it becomes relatively stable, use automation for the things that you think (value judgement - are we seeing a trend yet?) won't change much because people are not good at repetitive tasks so that manual key bashing testing is doomed to expensive failure. Save the warm brains for the new stuff where you are trying to make sure that what the customer ends up with will actually do what they want.
In essence, assuming you avoid the human monkey organisations, you can expect to do everything a developer is called on to do - and then more. Although you may not go to the same depth in any particular sub-field you will be expected to wield a much broader skill set on a day to day basis. If you get lucky and work with good developers then it makes a great team. Of course - there is a more than adequate supply of assholes on both sides of that fence to make that a crapshoot.
You can also expect to be 4th line support once the thing ships - because by that point you will probably have (or at least should have) more practical operating knowledge of the system than anyone else.
Oh - and one other thing - broken by design is still broken :-)
QA is basically the meeting place of business/customer requirements and the developer's interpretation of that. So - as a software test engineer you should be able to create a test environment that will sufficiently (and there's a critical value judgement right there) mimic the customer environment. That environment needs good enough controls that it can automatically run through enough of (another value judgement) the functionality to ensure that there are no regressions, it needs to report well enough (ooh look - another value judgement) so that you can write a useful bug report when things go wrong. This needs a historical context of actions so that a good developer can look for a generalized fault (the bad ones just generate point fixes that make that specific problem go away) and enough of a data variance to establish some boundaries for the known good performance envelope for the product.
Having done all that - you need to do enough of a business analysis and provide enough domain knowledge to craft a set of test cases which aim for optimal coverage with minimum effort.
For the new stuff - don't bother automating until it becomes relatively stable, use automation for the things that you think (value judgement - are we seeing a trend yet?) won't change much because people are not good at repetitive tasks so that manual key bashing testing is doomed to expensive failure. Save the warm brains for the new stuff where you are trying to make sure that what the customer ends up with will actually do what they want.
In essence, assuming you avoid the human monkey organisations, you can expect to do everything a developer is called on to do - and then more. Although you may not go to the same depth in any particular sub-field you will be expected to wield a much broader skill set on a day to day basis. If you get lucky and work with good developers then it makes a great team. Of course - there is a more than adequate supply of assholes on both sides of that fence to make that a crapshoot.
You can also expect to be 4th line support once the thing ships - because by that point you will probably have (or at least should have) more practical operating knowledge of the system than anyone else.
Oh - and one other thing - broken by design is still broken