At 12:55 today, I was informed that I had a 4-hour mandatory training session to attend. Sure, I've been working there for 9 months at this point, but management decided it was necessary to train new hires on process tools in use at the company.
Mind you, I've worked a few software quality assurance jobs in my day: I'm lucky to have worked at AOL, Apple, Claris, FileMaker, Microsoft, and Netscape over the past fifteen years. All of these places follow roughly the same pattern when it comes to testing software: write a test plan, write test cases, test software, ship it.
The company I'm currently working for - yeah, the name is friends list only because I don't want to be blatantly obvious about it - has a very, very different test methodology. You begin by writing something called a test case outline. Over the past nine months, I have spent endless lunch meetings going over test cases outlines (TCOs for short). There is serious process associated with these: you can't just write a TCO in Notepad. Instead, you have to use a specialized third party text editing tool (which, annoyingly, is licensed on a per-user basis, and there aren't enough licenses to cover all employees, so you sometimes have to wait for someone to stop using the software before the license server will let you in) that has been specially extended at some point over the past seven years by employees whose job it is is to write specialized process tools - in this case, a Perl script that adds menu items to the text editing software.
OK, so it works like this. You begin by writing a TCO. These look something like this:
e Access API
i Call API with valid data
e Expected result: valid result returned
To me, these are so vague as to be entirely useless. Sure, they're technically correct: after all, when you test an API, this is (in part) what you do: call it with valid data and check the correctness of the response. Ultimately, though, it doesn't mean a thing: if, as a tester, this is all you have to work with, it's a waste of your time.
So. You write one of these bad boys, and then you call the custom Perl script (for which there is apparently an entire team of employees sitting around writing this stuff), and it scans your TCO and generates an output file which is the same damn thing in a slightly different format. It's called a TCL, or a TCO, or a TCBY, or something - I don't know, because I've never actually seen one. The important thing is simply that the Perl script runs, not that it generates anything useful, or that you do anything with it, or anything much at all. What is important is that the Perl script is extremely finicky about indentation, spacing, and the use of i versus e - much of a tester's day is spent running and re-running that Perl script to make sure that the TCO is formatted properly.
Once the Perl script has been successfully run, then... well, nothing. You may find yourself wasting a lunch meeting discussing the TCO with other testers, but that's it. There are no test cases. Before shipping a product, nothing else happens. There is absolutely no accountability, and - God forbid - you don't actually have to test anything. All you have to do is run the Perl script and Bob's your uncle.
This brings me to this afternoon. From what I could tell, the director of test engineering wrote a series of PowerPoint presentations about six or seven years ago that lay out - in excruciating detail - how to write a TCO and how to run the Perl script. Apparently, this is a valid way to test software. Don't worry about test cases, test results, or actually testing anything - just make sure your e lines are correctly indented and ship the pig! And if anyone says "hey, what is this achieving exactly?" just stare off into space like a Scientologist and say "YOU JUST NEED TO APPLY THE TECH MORE CORRECTER" and explain that in time ALL WILL BECOME CLEAR and that YOU TOO WILL SEE THE BENEFIT.
Four hours I spent sitting in that conference room today listening to a coworker (whom I respect, and who really does appear to be fairly smart) read those damn PowerPoint slides word for word. Finally, at the end of the session, I lost it and started asking exactly why we're wasting our time doing any of this. I didn't get anywhere, but I was relieved that six of the nine people in the class felt relieved by someone's daring to speak up - they started asking questions as well. Sadly, the only answer was JUST DO AS WE SAY AND IT WILL EVENTUALLY MAKE SENSE. Ugh.
So, yeah. I need to get the hell out of there. Never mind the unvested 401(k) contributions and the unvested stock options: I can't thrive in this environment.
Oh, and don't even get me started on the people that have worked there for 10 and 15 years and who have zero experience at any other software company, much less the power structures that are so firmly in place there's absolutely no possible way I can ever get a promotion. Oh, and then there's the whole matter of how H1-B visa holders who can't even speak English (seriously, one sitting next to me in class today was killing me with his incomprehensible talk) are hired as engineers, while I'm stuck with a loser job title ("support engineer," I think it is) because my degree from Berkeley isn't as good as their degree from Ball State University or Slippery Rock or wherever - and hell, there are people who don't even have college degrees with job titles that I will never, ever earn because the company doesn't want to jeopardize its H1-B visa allocations by hiring people without engineering degrees into any open position.
Yeah, it sucks. Time to get the résumé together and get the hell out of there... in February 2009.