Demand for IT contractors rocketing? You're joking.

[SussexSeagull]

Speaking as a predominately manual tester I think work has reduced over the 12 or so years I have been contracting but I am not convinced it is unique to testing. Fashions in software development do tend to shift between project based teams and specialist teams and at the moment it seems to be agile based project teams. While I certainly think the standard of agile development has improved over the last decade - when it used to be having a daily standup meant you were an Agile environment - I have no doubt it will move back towards specialists one day.

Combined with this people who have never done the job are convinced things like analysis and testing can be done by business experts and money can be saved. This all said, and I am not drawing any conclusions from the last year as external factors have come into play, I still find contracts with usually small to medium clients who recognise they have a short term testing need.

Manual Testing has been about to disappear since I started in it about 25 years ago and it never quite does. Automation is on the rise but more companies than you think still haven't gone near it and to be honest it isn't worth some outfits doing it.

As for immigration we might get more from India but will be having less from Europe. To be frank a populist Conservative government like the one we have at the moment will reduce immigration if it makes them more popular to the electorate even if it means damaging business.

[Fraidycat]

Manual Testing has been about to disappear since I started in it about 25 years ago and it never quite does. Automation is on the rise but more companies than you think still haven't gone near it and to be honest it isn't worth some outfits doing it.

Current client invests in automated testing but also does manual testing on each release.

Now they dont have dedicated manual testers, there are SDET who both write automated tests and do manual testing.

Also the main application developers are expected to do manual 'peer testing' as well, even though there are lots of automated tests run as part of the build process.

[eek]

Nothing wrong with any of that.

I often and still will do regression tests on deployment against known risks (where configuration could break) and changes even if it’s mainly for my own piece of mind

[SussexSeagull]

Developers testing their own code before releasing it isn't a new thing (or at least it shouldn't be). I think usage of automation in testing is one the rise, mainly because it is cheaper than when Winrunner ruled the world.

The fact is once you get anywhere near real world testing tests need to be designed by a human being even if they are being automated. This is the bit accountants are currently trying to squeeze out and it is a specialist job.

[lawnmower]

In the end there will still be some kind of demand for Manual Testers because you still need UAT and you still need someone to try and break the system, and do exploratory tests etc (with an independent perspective). At the moment Project Managers are going through a big phase of believing that automated testing is the answer to everything.

One of the problems with the term ‘Manual Tester’, though,is it tends to suggest that you are not an IT person at all, it conjures up images of someone comparing two bits of paper and entering the results with a quill pen on a parchment scroll, working by candlelight.

In reality, ‘Manual’ Testers are IT Professionals, with more general skills than a technician. It's surely part of the management of a project (I have also been a Test Lead as well). At one time this type of role was considered to be an essential part of the IT world and of any IT project.

A better term to describe this role might be just ‘Test Analyst’, someone who can analyse requirements and specs to create test plans and scripts. You can navigate complex systems to check test scenarios and execute test scripts and enter results of the tests using complex Test Management software like Quality Centre and update tests and raise defects. Then you have to document tests and progress defects etc. You may execute batch jobs to do the tests, or perhaps access a system directly (or via a test harness if not all functionality exists yet). You may be doing anything in the SDLC from unit testing through to UAT.

You may, in fact, be able to do automation, providing a tool that doesn’t require programming skills is being used, maybe something like UFT or maybe just a record and replay tool like Selenium IDE.

The difference between and ‘Automation Tester’ and a ‘Manual Tester’ is basically that a Test Analyst doesn’t program to any degree of complexity. So you wouldn’t do Selenium, but you can do just about everything else. But why on earth do you want your testers to be programmers? Who will check e.g. the SQL that a Test Analyst uses, which, if incorrect, could lead to e.g. invalid defects being raised?

Surely, if you use any automated process (for e.g. comparisons), it will throw out tons of exceptions all of which need to be investigated, ‘manually’. A more sensible approach would be for each Test Team to have one automation tester (i.e. a developer) who could create the automated process that throw out exceptions which the Testers can then investigate. The Automation Tester could also maybe assist with the more complex SQL. For UAT, I would have thought that the ‘manual’ tester was still essential, as you surely then need to use the system as a ‘user’, not via automated tests. Automation may not always be a suitable test tool on a project (would it identify usability issues?) – and certainly not all your testers need automation skills.

I accept the role may be being offshored - although I can't understand why anyone would do that. Surely the obvious thing to do is keep your management functions onshore (PM,PMO,Quality,BA) and offshore development?

[jamesbrown]

How about test-driven development? If developers don't write their own tests (whether unit tests or integration tests or any other tests), they are probably writing crappy APIs as well as buggy implementations. The point of writing tests is to identify how something should behave. Thus, writing tests as a first step makes sense. The point of automation is to eliminate brittle, manual, processes from a deployment pipeline. "Testing" as an independent skillset has always struck me as a bit weird. :shrug

[lawnmower]

Of course developers can do tests - the more of it the better, this is generally Unit Testing. The problem is they aren't doing it from an independent perspective and generally only have limited test environments to work in. There are many phases in the SDLC after this initial development occurs such as integration testing and UAT etc. I was a developer once and I know this to be a fact. You definitely need Testers on a project IMO.

[jamesbrown]

Of course developers can do tests - the more of it the better, this is generally Unit Testing. The problem is they aren't doing it from an independent perspective and generally only have limited test environments to work in. There are many phases in the SDLC after this initial development occurs such as integration testing and UAT etc. I was a developer once and I know this to be a fact. You definitely need Testers on a project IMO.

Some types of independence are bad, like independence of your brainstem from your brain. Developers that don't write their own tests, at all levels of integration, haven't really thought about what their software is supposed to do, whether in terms of accuracy or usability.

[SussexSeagull]

Some types of independence are bad, like independence of your brainstem from your brain. Developers that don't write their own tests, at all levels of integration, haven't really thought about what their software is supposed to do, whether in terms of accuracy or usability.

TBH it depends on the developer and the environment they work in. I have worked with developers who you knew full well you would find little or no problems with but then again there are developers who somehow managed to make two errors that cancel each other out and everything looks fine until it goes into a new environment.

Agile requires developers who can go in an do surgical changes where what doesn't change is as important as what has changed. Problem is a lot of companies switch to agile and carry over developers who are used to everything they do going through a complete regression test and have got a bit lazy.

[jamesbrown]

TBH it depends on the developer and the environment they work in. I have worked with developers who you knew full well you would find little or no problems with but then again there are developers who somehow managed to make two errors that cancel each other out and everything looks fine until it goes into a new environment.

Agile requires developers who can go in an do surgical changes where what doesn't change is as important as what has changed. Problem is a lot of companies switch to agile and carry over developers who are used to everything they do going through a complete regression test and have got a bit lazy.

Oh, agree, but it's still worth distinguishing between good practices and bad practices and assuming that some other person will effectively test the software you wrote is a bad practice, hence TDD.