testing, testing

instead of tweeting all of this…

after college hired by startup. basically, one primary customer who eventually bought us. we were "Product Testers" but new QA dev manager got titles changed to "QA Engineers" -- better pay. startup had full spectrum of software we were pushing, but it wasn't taking hold at headquarters. we were CA, HQ in VA. eventually, HQ VP decided publisher project should be transferred to us with me sent to VA for training. project started as Mac design (very elegant), but no formal QA. part of the team transferring West including Dev manager.

when i got back, we had completed switch to new building. my manager gave it a month, while East settled in, before coming to my office saying he couldn't hold them off any longer, start testing. by then i had enough time to know i didn't know how to test this thing and nobody else did either. we were porting a mainframe tree thingabob to WYSIWYG for content publishers and management gong show set "good enough" QA standard. Mac version better developed, but demand for Windows version higher: Win98 about to be released, which meant major new build for HQ software. content publishers were vocal & highly demanding.

so on my first day of "official" testing, i decided to fake it.

for some odd reason, i managed to buy a fifty dollar hardcover book on rapid application development before graduating: THE book on RAD. finally visit Dev manager's new office seeing thick RAD softcover book on the corner of his desk: aha. because of RAD, time became this weird thing with everything moving slowly around me as this project & developers moved at a faster pace. that's when i learned how some Dev teams "throw a build over the wall" to QA.

next, convincing primary Mac developer (whose version would be tested next) that his Mac bugbase would not work. QA West needed to grok status & priority quickly. Mac bugbase would keep them in the dark, but Lotus123 they knew. QA managers knew they were clueless, my job was to get them on the RAD QA cluebus express.

i started going to offices drawing diagrams on whiteboards explaining things. my manager, god bless her, said: that is your whiteboard, i never erase it.

in college we discussed corporate culture and transformation. so i was very aware of the cultural differences between management styles (East vs West), programming strategies ("startup" dev vs transferred dev) &c. as a new QA Lead (on my first project), i leaned on the QA structure our department developed, learning how to re-rig stuff on the fly as needed. massive fundamental revelation: Windows had a gooey and my developers weren't using it. Guys, why is File » Exit way over here and not here where it's supposed to be? doh.

after that first build got thrown over the wall, i learned that RAD developers show up quickly thereafter. how is it‽eek… but, eventually, the real fun began as i learned how to spike the build. life became an endless series of who could spike things faster over the wall. WHO'S LAUGHING NOW! bwahahahahah!

but then… i finally had to face that 100-tabbed, free-floating monster. please test it, pretty please! O-o

after i beat that thing to 64 bugs in the nice public bugbase for all the world to see. RAD Dev manager slooooooooooooowly walked to my office about his boys. {sniffle} Do we have a snowball's chance in hell of fixing this thing?

i laughed. quickly.

of course they can. they're like, totally rad. stop pulling my leg. (forgot when, exactly, i told Dave i followed the ZEN approach to testing radical and transforming software). dev boys reviewed all bugs, called meeting to discuss angle of attack. everything started to gel. we were a team. we could do this.

then. The Bug. but i need a snack nowz, brb.

Dev Dave and i were pretty much in lockstep about everything except Black Bug Day. which appeared near the end of official release, i think. by then we were having weekly and on-need full-on AHOD west/east conference calls about issues. watching my developers at one meeting, quiet, i realized that another aspect of QA was defending your developers. Lead Dev asked me, once, who is my customer? i'm used to thinking that my customer is the "client". i said, QA is the customer. we represent the "client". pass QA and you're good to go. unfortunately, technical challenges of this project were beyond my capacity (therefore, "good enough"). so a brief discussion on reqs & builds.

Win95/Win98 Builds: HQ client software supported older OS versions; there were hundreds of client builds. since our project's client base was 2000 content publishers, we didn't have to support so many builds. however, during the transition we supported both Windows versions so content publishers could continue posting content to current and upcoming versions. once Win98 officially released, we dropped Win95 build.

Localization. huh?. these builds came up toward the end of our release. i remember German, Japanese & what else? each needed two different bit versions (or, something). 16 builds? we didn't have enough people to test all versions. after the last person i talked to said, you need to ask for a requisition. i realized i'd been practicing on everybody i knew so {gulp} my QA manager would call a meeting with our VP to ask for a new req. after my trembly voice explained the reason for the req, VP quietly said, well, I guess you do need a req. where the req actually ended up is another story for another day. (I'm still angry John! you couldve at least told me i GOT the damn thing instead of me feeling embarrassed for asking!).

The Bug produced so many fixes it left my head spinning. that's when i learned how to spike back fast so i could get back to figuring out the source of the problem. around 2AM, at home, finally catching my breath, composing email to everyone about The Bug. BFD since it involved long-standing feature request from advertisers. the fact Dave wanted to move forward w/o fixing confused me until i went to a few of the AHOD meetings and could see his back was up against the wall. what i remember is everyone screaming for the final version. one of the product managers was the guy who hired me, so i went to him first. he already knew something was up and got the other product managers. (i learned during this time some of the startup managers were keeping track of the startup crew and were very protective).

we were in a small cube, me explaining The Bug: if this gets released without fixing it could be our reputation at stake. before we were purchased by HQ we worked with individual advertisers to compress their ads to our compression format. pink backgrounds appearing in transparent animated GIFs could be part of our SDK and my recommendation to Dev: talk to in-house SDK developer. Nope, don't wanna. i understood hesitation as cultural and programming barrier. i needed a West group who could make the case stronger than me to East and get some breathing room for Dev. we got it.

The Fix.

i remember now. that email was after. went to the product managers not because they were product managers, but because if Dave (from back East) didn't get it, then my current QA manager wouldn't get it either (he wasn't from the original startup crew). my guy, who hired me, knew immediately what i was after. don't remember what happened at the meeting, but even Dave got on board after saying, sorry. cool beans. i understood cultural barriers of what different people were up against, my gut figured out who to trust to keep us on track. because QA is also about protecting company assets, then we were talking about our division, our reps and our legacy. if we failed at this, then we'd never get HQ to trust our stuff in the future and we were already having problems about our fit with HQ.

SDKs & Harleys

what i remember about SDK guy was, well. when images failed to compress to our format we had to figure out why. SDK was upstairs with a set of images he couldn't open. i went downstairs to work on them. they opened. wide. beaver shot. i ran back upstairs like a maniac (we had different OS). i also remember him as one of the smartest guys i ever meant who treated me like a fellow team member, willing to explain technical stuff patiently &c. (some developers like to melt your socks off).

i remember talking to SDK about The Bug & he said, tell your Lead Dev to come talk to me. i also knew SDK wouldn't bite Lead Dev's head off. QA vs Dev are notorious for Gingham Dog & Calico Cat sniping. (i've seen QA/Dev managers do everything except draw blood). but internal Dev fights are brutal, and my Dev guys were accused of another issue involving the number of remaining objects. something so highly technical i never understood the full technical scope. after we got some breathing room, SDK & Lead Dev talked and FINALLY, i got my build fix. beautiful job! [later, when Dave took us all out to check how the program was doing out in the field, it was great to see a Mac content publisher (using Windows) saying,, pointing to that very fix]. BFFs SDK Harley & DevDave Harley admired each other's rides (they were beauties). Dev East managed to make a successful transition to the West Coast and, who knows, some of them may still be living out here.

Is That All There Is?

so we released all builds, eventually. someone had to remind somebody that our team had no release party. kinda disappointing, like an after thought. but our team concluded: it ain't shrinkwrap, but it's sure way better than "good enough". and it was.

The Big Project

yup. HQ sent one of the biggest projects to our division. and i wanted nothing to do with it, telling my manager it was going to be a super-duper headache (they had a "war room" and everything!). my fellow QA team member, eager to get out from under me, eventually said i was right, it was a big headache. i got assigned to a smaller project and started working with a younger QA guy who was getting really creative with some of our in-house stuff. we created a skunkwork team to work on a project to highlight in-house Dev work. next thing i knew: R&D Dev came to your office looking for you. i can probably (red-faced) count each finger & each toe how many times i would hear that.

"You Figured It Out"

i remember sitting behind an R&D guy, at a company meeting, as he was awarded a patent and $10K (or $20K). that, i knew, would never happen to me. so then… wtf? what i remember R&D Dev telling me: you figured it out… we were not giving them what they wanted. then he starts telling me about… broadband and pipes that weren't big enough, and… he kept coming to my office. if QA was the loudest department, R&D was the quietest (i know, i crept in once). HQ showed up (something to do with The Big Project), R&D Dev came looking for me, again, saying… get that skunkwork project ready for me. SDK presented it at the meeting, checking in with me when it was over. they liked.

i left the company shortly after. but before i did, standing outside with R&D Dev, saying: if you need a reference, tell them to call me, handing me his card. it took several years for me to realize who i was dealing with and what he was actually thinking and planning.

so why did i write this? HQ, (with its big "war chest") eventually merged new & old media and… fizzled. i don't know what the moral of this story is. maybe change is easy when it's a small team, but harder when it's a huge organization? that's a good place to start i guess…