Reply to: Oh FFS! Someone's going to get canned for this.

[2BIT]

Testers, Testers, Testers.

Testers are 100% to blame if a system goes live with defects, or goes live and then fails, they should be testing it after it goes live.

whilst I agree the reality in my experience is that the Testers are rarely competent, there are Testers and then those low level bods who are brought in to make up the numbers, I've never worked with a real tester and as a result the testing becomes one big box checking excersize.. not saying these low level bods are all bad but most wont want to be testers for long

for example recently had two tranches of code being tested, mine was being tested by a sharp young guy who loathed the fact he had to do testing instead of analysis and the offshore piece was tested by a 'box checker'

the defects in my code were raised in a timely fashion and fixed well in advance of go live, the off-shore code was approved and signed-off but come go-live it became clear that the code was absolutely riddled with errors

the offshore guy had not unit tested at all (despite saying he had) and the tester didn't really test at all - caused us so many issues its not even funny....

so Testers are essential but treating testing as just a box checking exercise is actually more damaging than not testing at all...

[MarillionFan]

I agree, if you test post production the devs probably never got a spec.

Anything post production is not the dev's fault.

They've now looked into in more detail and the offshore consultancy have come to the conclusion it was the UK contractor who finished up on Friday and had production access. They reckon he must have accidently switched it off when he was deploying a change into production a few months ago and didn't follow process. (basically they didn't manage him as the dev manager bought him in to get us back on target)

Scapegoat contractor found. Dead mans shoes. Bob has saved the day and all is good with the world.

[2BIT]

tested in UAT(by me)

there's your problem right there...

[minestrone]

Testers should not be doing tests in the production system though, should they?

I agree, if you test post production the devs probably never got a spec.

Anything post production is not the dev's fault.

[eek]

Well, according to the developer, in Data Manager someone deactivated SCD on one of the dimensions by unchecking a box.

Not knowing Cognos why on earth was someone playing with Data Manager on a live system?

[MarillionFan]

I agree

it does sound wierd - you can't simply switch off an SCD type 2 - it is either developed or not.

Well, according to the developer, in Data Manager someone deactivated SCD on one of the dimensions by unchecking a box.

[NorthWestPerm2Contr]

Testers should not be doing tests in the production system though, should they?

The fact it could BE turned off seems weird, but perhaps my imagination of a virtual ON/OFF switch is incorrect and by 'turn off' you mean some configuration was deleted or something?

I agree

it does sound wierd - you can't simply switch off an SCD type 2 - it is either developed or not.

[d000hg]

Testers, Testers, Testers.

Testers are 100% to blame if a system goes live with defects, or goes live and then fails, they should be testing it after it goes live.

Testers should not be doing tests in the production system though, should they?

The fact it could BE turned off seems weird, but perhaps my imagination of a virtual ON/OFF switch is incorrect and by 'turn off' you mean some configuration was deleted or something?

[minestrone]

Testers, Testers, Testers.

Testers are 100% to blame if a system goes live with defects, or goes live and then fails, they should be testing it after it goes live.

You ever worked in a place that has a testing budget for post release?

[russell]

Testers, Testers, Testers.

Testers are 100% to blame if a system goes live with defects, or goes live and then fails, they should be testing it after it goes live.

[minestrone]

Given a decent database audit trail you could, however, identify the person who switched it off.

Its a user error issue so its going to go down to who do they most dislike. The downside of being a contractor is that you are the easiest to get rid of.

As for the issue with offshore development don't trust them to do anything correctly. insist on seeing the unit tests alongside the code and manually logic test them yourself to find the flaws and gaps. Then hit them with a sledgehammer.

Someone should have spelling tested that post for you.

It is not admin's fault that got into the DB.

[eek]

You cannot unit test for that.

(DBA, dev, tester usual crisis meeting being played out live here)

Given a decent database audit trail you could, however, identify the person who switched it off.

Its a user error issue so its going to go down to who do they most dislike. The downside of being a contractor is that you are the easiest to get rid of.

As for the issue with offshore development don't trust them to do anything correctly. insist on seeing the unit tests alongside the code and manually logic test them yourself to find the flaws and gaps. Then hit them with a sledgehammer.

[minestrone]

The simple truth is, someone ('now removed') turned off the updating after a week.

You cannot unit test for that.

(DBA, dev, tester usual crisis meeting being played out live here)

[MarillionFan]

I would have turned on the functionality for a couple of days, tell them it will take a few days to get the data as resources are pushed, use the data from post release and the data from the last couple of days and write a script that matches up the missing dates with improvised data, randomise it using cos but keep a general extrapolation of the range.

(If we choose to, it looks like we can recover the whole model from the landing tables)

The simple truth is, someone ('now removed') turned off the updating after a week.

Bearing in mind, last week on a deployment to production(after signoff), I logged in to find that one of the developers had left a truncate table on one of the updates.

[MarillionFan]

Definitely some Kimball subsystems were not in place. Perhaps a design flaw? MF to blame!

It's an odd contract this one.

I came in and was asked to design a data model and follow Kimball. Did that. Left.

Four months later, got a call. Came back in. They'd offshored developed the model, ETL and handed over to their support organization. Could I now define the framework model (have someone else develop it), and the output (have yet another person develop it), test it, manage the client(not the development) and then get it rolled out, before being told to bugger off.

Client sees everything as a production line. They will literally have a contractor come in for five days to do a piece of work(like ETL), not test it properly internally, through it at the client to test, let the developer go, wait a few weeks and when it doesnt work go back out to see if the contractor is available or get another.

I am under strict instructions not to do any development.

Doomed.