Dear Users… (A thread for Sysadmin, Technical Support, and Help Desk people) Part 10

Status
Not open for further replies.
Not the users fault. Who creates email boxes on a form that hold about 10 characters? Did they ever test these? They can't have.

Though not to your point, a_unique_person, reminded of something relevant here. The chip FAB I work in was recently sold. Prior to that they took on "equipment as a service" and we were all distributed new customer rented laptops. Most, if not all others have been migrated to the new ownership, not ours. In fact the rental tag on the bottom says we are well expired in that EAAS. So we lost our own customer E-mail address, access to MS Teams and basically any way for real time com other than just calling someone (on the crappy, though slightly less than as crappy before, mobile phone system) and hoping they pick up. The customer help desk never does. While I can get into the customer Office 365 main page and had set up some files we could print (maintenance documentation and such) on customer printers. We’ve recently lost printer access, how will I print my novel now? We have no customer Office 365 mailboxes that things like customer network password reset notifications get set to. So we get locked out of things we need and the FAB needs to keep running often. Without us, the place can shutdown to just like a 7 odd billion dollar warehouse (not counting inventory). It’s insane and no one on the customer end (besides the production operators) seems to be advocating for us.
 
Twenty five.

And a half.

Thousand pages printed.

Today. Just today.

The public service is addicted to paper.

And in the last ten minutes - ten minutes - another thousand pages have been printed.
 
Argh. We need to put test data into the production system to test production stuff, sure. But it has to be flagged in such a way that it doesn't get mistaken for real data. Oh, but to test X we need to not flag it the normal way because X filters out flagged test data. Okay, use the second method of flagging test data, that isn't filtered out by X. Wait, now we need to test Y, which filters out both....

...leading to the situation where we have FOUR distinct, different ways to flag data as test data only, do not report on it or treat it like it's real...and some test data is not flagged in any of those four ways and gets mixed in with the real data. Of the data that is flagged, it can have anywhere between one and four of those flags.

And the proposed solution? You guessed it! We're adding a fifth distinct way to flag test data as test data.
How do you test that your flagging works correctly?
 
Argh. We need to put test data into the production system to test production stuff, sure. But it has to be flagged in such a way that it doesn't get mistaken for real data. Oh, but to test X we need to not flag it the normal way because X filters out flagged test data. Okay, use the second method of flagging test data, that isn't filtered out by X. Wait, now we need to test Y, which filters out both....

...leading to the situation where we have FOUR distinct, different ways to flag data as test data only, do not report on it or treat it like it's real...and some test data is not flagged in any of those four ways and gets mixed in with the real data. Of the data that is flagged, it can have anywhere between one and four of those flags.

And the proposed solution? You guessed it! We're adding a fifth distinct way to flag test data as test data.
It seems odd that there's test data in a production system. Isn't that what test systems are for?
 
It seems odd that there's test data in a production system. Isn't that what test systems are for?

Used to drive me insane...

In the middle of an urgent fix, looking at production, I found:

Testy, Tester, living at 356 Test Lane, Testville.

My solution to this was to deny testers access to production.

(Which someone else had granted them).
 
Argh. We need to put test data into the production system to test production stuff, sure. But it has to be flagged in such a way that it doesn't get mistaken for real data. Oh, but to test X we need to not flag it the normal way because X filters out flagged test data. Okay, use the second method of flagging test data, that isn't filtered out by X. Wait, now we need to test Y, which filters out both....

...leading to the situation where we have FOUR distinct, different ways to flag data as test data only, do not report on it or treat it like it's real...and some test data is not flagged in any of those four ways and gets mixed in with the real data. Of the data that is flagged, it can have anywhere between one and four of those flags.

And the proposed solution? You guessed it! We're adding a fifth distinct way to flag test data as test data.
Why isn't your test environment able to process data exactly as the production system?
 
Why isn't your test environment able to process data exactly as the production system?

Because the test environment is only itself, it's not hooked up to test versions of the several thousand other applications the production version communicates with. The test version is only useful for testing things internal to the application. We don't have a test parallel universe set up.
 
People act like companies just love to give unlimited money to testing. It's like pulling teeth to get them to do it all.

Because in general they only begrudgingly agree to the testing they do agree to for ass covering reasons, and ass covering has a much lower threshold then "actually testing the data."
 
Well, yeah, but there's also the matter of practicality: when you test scuba equipment you might have a big pool, but you certainly don't have a second ocean made just for your testing.
 
At big bank we were asked by a board member what it would cost to completely replicate the live mainframes. We sent him a detailed estimate, he turned white and the subject was dropped. It made the cost of our big Y2K environment look like a rounding error.
 
People act like companies just love to give unlimited money to testing. It's like pulling teeth to get them to do it all.

Because in general they only begrudgingly agree to the testing they do agree to for ass covering reasons, and ass covering has a much lower threshold then "actually testing the data."

We had a whole Factory Intagration Test Facility. A mini setup wtih diffrent loops of track for our various types of vehicles. You could run things and modifications there before they hit production. All gone now and the equipment that was there is stored as spare parts.
 
Yes, our test system is based on a 3% subset of the production system.
That's what I'd do.

Because the test environment is only itself, it's not hooked up to test versions of the several thousand other applications the production version communicates with. The test version is only useful for testing things internal to the application. We don't have a test parallel universe set up.
Ouch, that's not test then, really, more development.
 
Because the test environment is only itself, it's not hooked up to test versions of the several thousand other applications the production version communicates with. The test version is only useful for testing things internal to the application. We don't have a test parallel universe set up.

That makes sense. The test data aren't there for the application itself, but for other programs and systems yours interacts with. Hence also the need to have multiple different ways of flagging the test data.
 
Dearest coworker: Microsoft Teams, flawed though it is, has a nice little "Status" option the users can set. I don't know how you use that feature, but when I set mine to "Do Not Disturb" or "Busy" it means **** off and stop sending me messages about nothing that I wouldn't be interested in reading even if I weren't busy. Keep it up and I shall write a Perl script that will text you interesting facts about dogs every minute for the rest of your life. They won't even be a lot of facts, just the same three over and over.

Yours in Christ,
TragicMonkey
 
Status
Not open for further replies.

Back
Top Bottom