Demand for IT contractors rocketing? You're joking.

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

[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

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

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.

[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

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

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.

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

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

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