Reply to: Demand for IT contractors rocketing? You're joking.

[lawnmower]

It also depends on where you are in the Software supply chain. If you are developing software for e.g. an external supplier (working in eg a software house) which is then is sold to an end client, that end client may well want to do loads of conventional tests of the software they are receiving into their organisation. The software house itself may do very little testing or possibly do automated testing carried out by developers etc. However when the software is put into a real life situation where it has to be configured to support a business process, there would definitely be manual and UAT tests and user training as well. Probably a lot of people on this forum are working in more of an external supplier/software house situation, which accounts for their perspective. Having said that there's still a noticeable lack of contract opportunities. Yes BAs may be doing it but that wouldn't be an independent test as the BA would have also produced the requirements presumably.

[Peoplesoft bloke]

At the risk of derailing what has become a narrow debate about testing, demand is patchy. My area - implementations of Workday - experienced an almost total collapse in demand due to a combination of Covid and the recent IR35 changes. Typically we'd do a 6 months contract, sometimes extended sometimes not, then move to the next customer. It's rare to be at any customer longer than 2 years as if you are, their implementation has gone wrong.

There have been a (very) few gigs advertised in the last year or so, but demand certainly hasn't rocketed.

In my sector, it's generally, go FTC, permie or nothing. Almost no clients are offering outside IR35 contracts.

[hungry_hog]

Place I worked before they would have environments as:

dev - very much build and test, nightly releases, tested by devs
UAT1 - automated system test (configured by test team)
UAT2 - manual functional test, tested by BAs
pre prod - prod like, light manual test, tested by BAs
prod - tested by users

[eek]

Code review and automated testing are two different things. The best feedback is from real users and it's better that developers understand them and respond quickly to them (hence DevOps/DevSecOps techniques that cannot work without a high degree automation), rather than have some intermediary between them. I'm not saying that there is no role for manual testing in any context/industry, but there is far too much dependence on brittle testing pipelines and developers that haven't got a clue about what problem their code is solving, ultimately because of poor communication - Conway's law.

I would also say that manual testing and automated testing serve very different purposes.

Manual testing - are the new features in this release working and is the software usable? Yes you can use the customer for that but a tester or two who knows the core product is worth they weight in getting this done in a sane timeframe even if it's just writing appropriate test scripts.
Automated testing - regression test to ensure that the new functionality hasn't broken something from a previous release.

[jamesbrown]

Developers should write their own tests to test their understanding of the problem and the solution they have written. The point of peer review & independent testing is to get a second or more pair of eyes on their understanding and pick up on the tests they failed to code for because they misunderstood and not all of us are perfect.

With automation manual testing will fall and as always everyone is an expert so the BAs end up doing the manual testing (that sadly is my experience).

I'm a terrible lone crusader but even I recognise my limits and encourage testing and peer review however frequently budgets don't.

Code review and automated testing are two different things. The best feedback is from real users and it's better that developers understand them and respond quickly to them (hence DevOps/DevSecOps techniques that cannot work without a high degree automation), rather than have some intermediary between them. I'm not saying that there is no role for manual testing in any context/industry, but there is far too much dependence on brittle testing pipelines and developers that haven't got a clue about what problem their code is solving, ultimately because of poor communication - Conway's law.

[vetran]

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.

Developers should write their own tests to test their understanding of the problem and the solution they have written. The point of peer review & independent testing is to get a second or more pair of eyes on their understanding and pick up on the tests they failed to code for because they misunderstood and not all of us are perfect.

With automation manual testing will fall and as always everyone is an expert so the BAs end up doing the manual testing (that sadly is my experience).

I'm a terrible lone crusader but even I recognise my limits and encourage testing and peer review however frequently budgets don't.

[ladymuck]

Are the following skills out of date? Perhaps that's the problem. If so I'll remove them from my cv.

Stone Age; Cave wall; Flintstone; Woad; Firelight; Runes. So I need to retrain into the bronze age, is that what you are saying.

Fred

You really need to upgrade to wheels, preferably round ones.

[ladymuck]

I usually describe DR as using a different PC to play solitaire.
A BCP is to get a real pack of cards out of the box and do it that way.

I tend to say the BCP is the stop gap to keep you going while you wait for the DR solution to stand up (it's rarely instant). Once DR is in place, the BCP is then any work arounds needed if the DR solution isn't a complete replica of the the one that's failed.

[ladymuck]

LOL I work in service and it's staggering the number of people that don't get the two.

Yeah but your kind of service is the type where you wear a pinny and waft a duster about

[Lance]

LOL I work in service and it's staggering the number of people that don't get the two.

I usually describe DR as using a different PC to play solitaire.
A BCP is to get a real pack of cards out of the box and do it that way.

[northernladuk]

but you can be a service delivery manager for some strange reason

LOL I work in service and it's staggering the number of people that don't get the two.

[Lance]

As has been said elsewhere, if you don't understand at least the fundamental difference between BCP and DR, you probably shouldn't be writing production code.

but you can be a service delivery manager for some strange reason

[malvolio]

As has been said elsewhere, if you don't understand at least the fundamental difference between BCP and DR, you probably shouldn't be writing production code.

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

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