Reply to: What to say?

[Freamon]

Possibly the hotel you have been looking for:

Account Suspended

This Account Has Been Suspended

.....

[vetran]

Easy

Of course we can develop in production, it obviously breaches Best practice :

link X,Y,Z

& Company policy
Link

but as its going against our recommendations so long as you take full responsibility in writing for all risks I am willing to go ahead and over ride the QA failures using your authority. Or do you want to try option 3?

Option 3 suddenly looks attractive to most managers.

[JoJoGabor]

Ok, let me explain this to you once and for all.

The goal of this strategy that I describe to you is to buy some time for further development. By making documentation more werbose, by introducing ambiguity into this documentation, the aim is to confuse QA so that they reject RC but the way I make this work is that QA are always the parties who end up with the egg on their face.

Jeezuz you would knowingly waste the time of a whole team, plus yourself, rather than stand up honestly and say, we need more time to develop the fix.

I am confused just reading your post withh those long words I don't understand!

[original PM]

Ok, let me explain this to you once and for all.

The goal of this strategy that I describe to you is to buy some time for further development. By making documentation more werbose, by introducing ambiguity into this documentation, the aim is to confuse QA so that they reject RC but the way I make this work is that QA are always the parties who end up with the egg on their face.

You goon - you do not buy time for future development you accept that the current development is not up to standard so it is not released until fixed - or as Chef said you release without the change which is causing the problem.

It is people like you with who will not stand up and tell the truth who cause the rest of us professionals so much trouble.

Unless the company is heamoraging (sp!) money and the risk involved in putting in the buggy change is less than the risk to the business of putting in no change at all.

[Pondlife]

I tell you what; I know I look thick and I've been knocked unconscious on a rugby pitch a few times, but I'm not that thick.

Mods, Can we have a new fishing rod smilie please.

[Mich the Tester]

Ok, let me explain this to you once and for all.

The goal of this strategy that I describe to you is to buy some time for further development. By making documentation more werbose, by introducing ambiguity into this documentation, the aim is to confuse QA so that they reject RC but the way I make this work is that QA are always the parties who end up with the egg on their face.

I tell you what; I know I look thick and I've been knocked unconscious on a rugby pitch a few times, but I'm not that thick.

[TheFaQQer]

That makes it sound pretty cut-n-dried IMO then; this is the right way... you can do this and still discuss patching prod directly, and then conveniently drag out the time until you've done the upgrade and it's no longer an issue

FTFY

[d000hg]

the release is made up of multiple changes that are not related therefore the release can go ahead in December but I recommended that we pull this particular change from the release and implement it end of Q1 shortly after the upgrade. So essntially your option 4 and my option 3 are the same.

That makes it sound pretty cut-n-dried IMO then; this is the right way... you can do this and still discuss patching prod directly, and then conveniently forget about it

[Hill Station Murthy]

Why do QA reject things?

Ok, let me explain this to you once and for all.

The goal of this strategy that I describe to you is to buy some time for further development. By making documentation more werbose, by introducing ambiguity into this documentation, the aim is to confuse QA so that they reject RC but the way I make this work is that QA are always the parties who end up with the egg on their face.

[Mich the Tester]

But if RC keeps getting rejected by QA it's never going to make it to Live isn't it?

HTH

Joshi

Why do QA reject things?

[Hill Station Murthy]

Ok, I'll bite, first up WTF are you talking about? at what basic level have I failed at? if you mean not having a paper trail, then I never ever keep things discussed verbally, I always follow it up with an email to ensure I have full recollection of what was said or agreed, by whom and when. Not only as it is good business practice but my memory is pretty p!ss poor at the best of times and so having it written down helps (see Memento for an example)

Second, the installation was performed months before i even walked on site. The change documentation at client co is shocking and it is very clear that the corruption is in no way related to me and was only discovered by me as part of me developing the requested change, client co recognise and agree that (in writing). So my arse is well and truly covered, even more so by highlighting this problem to them BEFORE migrating it to a 2nd environment and spreading the cancer corruption further.

I wasn't of the understanding that you were not present on client site at install time. For this, excuse my imperinence.

But when I talk of paper trail perhaps I misled you. What I was meaning was that I always have full audit trail covering any operational aspects of any application I am working on, including install. With install, I would generate log and wehn this problem installation took place I would take my log to the highest level and show them proof that I wasn't responsible ofr installation because my log will contain windows user account of the installing user.

Ok hotshot, you would knowingly migrate a partially corrupt system from dev (where it currently affects nobody as little is dev is done) to test where the effects would be further realised to the live production system where it is used globally 24/7 ???? And you would "delay" this by delivering shoddy documentation in the release candidate to confuse UAT and therefore have client co. think you are a muppet who isn't the expert you were brought in as and cant do what was asked of him by producing a legible release candidate???? remind me not to work on your dev team.

But if RC keeps getting rejected by QA it's never going to make it to Live isn't it?

HTH

Joshi

[wobbegong]

Firstly I would say as a security expert that you should always ensure that installation regime is written with this auditing functionality to point the finger of blame and cover your backside.
ALways make sure you have a paper trail. In my opinion I think you have failed on this basic level.



I recommend 1

I have been in your shoes many times in the past and let me tell you very clever way to ameliorate this tricky situation you are finding yourself in:

Production of very verbose documentation with many ambiguities in release candidate to your UAT team. They will keep rejecting RC because they can't folow documentation and by time they have accepted documentation the fix will be fully implemented.

This is good way of buying time in my opinion.

HTH sasguru

FTFY

[chef]

Any test manager worth his salt is alert to the tactic of trying to confuse testers with long, shoddy documents and will advise his client not to accept until those documents are clarified; he'll also investigage further to find out why a dev manager is using an obvious obfuscation tactic. There is a reason why good test managers earn good money; we're not as thick as some people like to think.

I totally agree. Hill Station Murthy has gone down greatly in my estimation with that advice. I didn't realise it was rodeo season already.. yeeehaaa.

[Mich the Tester]

Ok hotshot, you would knowingly migrate a partially corrupt system from dev (where it currently affects nobody as little is dev is done) to test where the effects would be further realised to the live production system where it is used globally 24/7 ???? And you would "delay" this by delivering shoddy documentation in the release candidate to confuse UAT and therefore have client co. think you are a muppet who isn't the expert you were brought in as and cant do what was asked of him by producing a legible release candidate???? remind me not to work on your dev team.

Any test manager worth his salt is alert to the tactic of trying to confuse testers with long, shoddy documents and will advise his client not to accept until those documents are clarified; he'll also investigage further to find out why a dev manager is using an obvious obfuscation tactic. There is a reason why good test managers earn good money; we're not as thick as some people like to think.

[TheFaQQer]

the release is made up of multiple changes that are not related therefore the release can go ahead in December but I recommended that we pull this particular change from the release and implement it end of Q1 shortly after the upgrade. So essntially your option 4 and my option 3 are the same.

That's what I would recommend.

Keep stressing "in my expert opinion..."