When my current employment overlord requested that I leave the world of consulting behind to work for her new fledgling department, it was with the understanding that my skills in software automation would be put to good use. The need for regression testing was paramount in the process adopted from our UK brethren, and I was promised my own then considerable body weight in software tools to get this done.
Then things went insane.
“A testing department, you say?”, was the word spoken all over the company. “WELL, that’s a strange idea, I mean – our programmers are immortal genius’ who never make mistakes. Let’s fill these testers plates with all one million ongoing processes, it’ll be easy work, since all our code is emaculate.”
Needless to say, my time to build these automatic packs and scripts disappeared faster than an Enron executive with a passport. Initially, I was asked to help with manual testing at the same time that I was also needed to build tracking tools to handle the truckloads of defects being discovered by our team (to the company’s surprise). Soon, our team began to grow, and I was needed to build tracking tools to track the team. Considerable time was spent building sophisticated reports for the upper management to glance at briefly, scratch their heads in wonder, and then file away under “Didn’t happen, don’t want to know about it. Launch the code anyway.”
Over a year and a half went by. Then suddenly, the hammer came down from my boss’s boss. “Uh, that Tim guy you have there…wasn’t he supposed to be building the regression packs?”
My boss, in a shining moment of wisdom, answered back, “Well, yes. But even when he does, and writes the 3 billion test scripts that will test our systems up and down…who is available to make any fixes that would be found from his tests? Every company resource we have is working 200% allocation as it is!”
I never discovered their answer to this, but I assume it went something like, “Oh, don’t worry….we have loads of money to hire all new staff to fix this stuff. We just don’t have any places to put them, or people to train them.” (The last bit was probably mumbled quietly).
So, I was asked to build my first scripts, starting with a project to test postal code territory changes. Total built scripts for this project – 21732. Amount of scripts that winrunner can run per day (on average) – 400. Time given to test – 5 days. Do the math…doesn’t add up. So, I made the executive decision to randomize the scripts, so that it’s really doing a sort of hunt and peck test. Not 100% efficient, but with one PC running this stuff for about 10 hours, what else can I do? I can’t even just let it run 24/7 as I’d like to, because they take the QA environment down at night.
Next problem encountered…what do I PERSONALLY do while my computer is running these scripts. It’s busy…I can’t use it. So, after much pressure from myself, my boss has assured me that I will get a second PC to allow me to do my other jobs (ie, write more regression pack scripts). However, it seems kind of moot to do this, because apparently I will not be able to log onto this new PC. Seems the new Security chief at the company has written the decree (without apparent exception), that staff can only use their NT logon’s once – no concurrent logon’s permitted. Also, generic ID’s have been banned. So…I get a nice, shiny new paperweight on my desk…OH JOY!
When I told my boss that this was the most ridiculous thing I’ve ever heard of, she told me, “Well, he has a mandate”, to which I shot back, “Ummm…SO DO WE!!! Why don’t we push back for once instead of letting them walk over us.” She said, “Ok.”
I didn’t trust my boss to phrase the business case properly, so I wrote it for her…and I expect a fun time to watch the fur fly and for exec’s to decide whos’ tape is reddest.
The crap makes my eyes burn…I’m thinking of sticking out my thumb to get a ride outta here.
The saddest thing is, I have been informed that my position is apparently so important that they are hiring a second automations specialist…so that there will be two us sitting around staring at our computers screens.
Maybe the other person will know how to play bridge…I’ve always wanted to learn.
It’s great to see you back.
I contracted for years with Microsoft IT groups. I can’t speak for many product groups, but IT and the groups we worked with were special in the same way.
I submitted a spec bug for one of the product groups (ODBC drivers). A couple product groups asked IT to test their products. It was returned to me for closing, with no action because it was as spec’d. I reminded them it was a spec bug, same response. A kind or ouroboros situation. It ended as I leaving that week for a contract with another company. Good thing, as I dearly wanted to say something that may have precluded future contracts with Microsoft.
I had a similar experiences with the NT and Office groups, and while I think they’re quite funny I’ll spare you.
I’ve worked for dysfunctional knuckleheads who were good to work for and those that weren’t. They do serve to provide good story telling material and to make you greatly appreciate competent management.
Thanks very much Scott, it’s good to be back.
I guess that’s a good way to look at it…if it wasn’t for those morons then the blog world would be a pretty different place. Ack! Probably all about peace and love…who wants to read about that? :}
To be honest, as I too am a programmer, I natively dislike testing…I’d rather spend the time knee deep in code. However, my paycheque comes from testing right now, so testing I do!
Boy do I have a follow-up post as well, but will hold off on that until I’m working with both hands again.