State of the Market

[SueEllen]

I've got a solicitor, but he knows feck all about computers.:rolleyes

It's so you can talk about it when asked at interview.

[SussexSeagull]

Sorry to be harsh but that's a permie mentality. The industry has moved away from your skill set - you need to move on or shut up shop.

I would strongly argue against the two disciplines being interchangeable (which is not to say some people can't do both well).

You need to keep up with the times but everyone seems to assume that all clients are technological pioneers. They aren't. For every client charging ahead with BDD and TDD there is another one using spreadsheets to track defects.

Maybe you are right though and the industry has moved on without me.

[NonnyMouse]

Everyone is assuming I haven't been picking up new stuff on my 'sabbatical'. In my experience people who do the heavy duty test automation (beyond record and replay and basic editing) are from a development background (hence the rise of the Developer In Test) so there is a limit to what can be gained from investing time into that.

I don't think that's true, aside from unit testing most Dev's in Test do automated functional testing for web apps using libraries such as Selenium - you find an element on a page and interact with it, yes you can get a bit fancy and integrate it with builds and do some fancy reporting but knowing what to test e.g. mapping out the manual steps is key. Dave Haeffner has some fab training material on this as does Sauce Labs, most developers would find that kind of work rather unappealing as it isn't designing something new.

[SussexSeagull]

I don't think that's true, aside from unit testing most Dev's in Test do automated functional testing for web apps using libraries such as Selenium - you find an element on a page and interact with it, yes you can get a bit fancy and integrate it with builds and do some fancy reporting but knowing what to test e.g. mapping out the manual steps is key. Dave Haeffner has some fab training material on this as does Sauce Labs, most developers would find that kind of work rather unappealing as it isn't designing something new.

Interesting. I can certainly identify elements and interact with them so maybe I am being too hard on myself!

I tend to find the more established environments are a bit slow to automate test when they would get the most value out of it if they started it from the get go on a system they might use for a decade.

Conversely some developer driven start ups think you can bypass the manual stage and do all testing through automation.

Automation is a bit like Agile in that many people try it but few do it properly.

[squarepeg]

I tend to find the more established environments are a bit slow to automate test when they would get the most value out of it if they started it from the get go on a system they might use for a decade.

Conversely some developer driven start ups think you can bypass the manual stage and do all testing through automation.

Automation is a bit like Agile in that many people try it but few do it properly.

You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.

[NonnyMouse]

Automation is a bit like Agile in that many people try it but few do it properly.

Not relevant, the point is you do it to the best of your ability. I suspect that you are talking yourself out of roles.

[SussexSeagull]

You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.

I would beg to differ. I think every test should be completed manually at least once to check the interface (especially important with mobile).

Part of the art of testing is not getting bored having to repeat yourself!

[SussexSeagull]

Not relevant, the point is you do it to the best of your ability. I suspect that you are talking yourself out of roles.

I wasn't aware this was an interview!

[oliverson]

You can bypass the manual stage, but only if you do it properly. Not many people can and not many teams want that, because it slows developers down, at least initially. But it's worth it. Selenium, BrowserStack, or AWS Device Farm (to name just three) and detect bugs faster and in a more reliable way that a tired human being. API design/development/testing can now be automated with the help of Swagger to the point where you can use the API spec written in YAML to generate server/client/test code and documentation from a single file. Bliss.

Doesn't work. Been tried many times before - Enterprise Architect, etc, and many before that.

Part of the problem with this 'utopia' is the lack of round-tripping. Code and 'spec' evolve separately and no longer represent one another. Not only that but it's very waterfall. This notion that the entire application can be spec'ed-out at the start and code generated from it is utterly ridiculous. Development evolves and so does a developers understanding of the requirements and required solution. Then you have to question who's actually doing the 'spec' from which the code will be generated. It's usually a failed developer who's moved into architecture. And developers 'hate' this kind of approach - filling in the blanks. It's like Van Gogh doing a 'painting by numbers'.

[SuperZ]

Everyone is assuming I haven't been picking up new stuff on my 'sabbatical'. In my experience people who do the heavy duty test automation (beyond record and replay and basic editing) are from a development background (hence the rise of the Developer In Test) so there is a limit to what can be gained from investing time into that.

I've done a lot of test automation in the past but seem to be one of a few that does not like the "Developer in Test" name which leads to some companies expecting experienced application/system software developers to be recruited for such positions.
Testing is expensive, and test automation even more so. Testers and developers have different mind sets and skills. A good test automation engineer usually IMO sits in the middle, ie, is not a software developer by trade but more of a tester but able to write code to achieve the task of automating tests and you do not need to be an code language expert for that. Test automation does get tedious when done properly. A test automation engineer who disagrees is probably not doing it properly, ie, is probably over-engineering the code and not reusing as they should be.

IMO test automation often fails just that the companies don't see it.

Any skilled software developer able to write complex applications and system must cringe at the thought of doing test automation and if hired to do so, will likely do it in such a way to make it more interesting but probably long term quite costly for many reasons. For example, if they leave and the company cant hire a similar dev to do it (as many won't want to) a more traditional test automation engineer may struggle with their overly complex code, lack of comments, lack of framework documentation etc. Not long ago I quizzed a dev in test about some of his code and the maintainability of it especially by those who may take it over and they told me "I'll be gone by then" for example.