Tuesday, August 12, 2008

Acronyms: TBD, WFM, JFC...

Guess which one I'm thinking of using?

TBD = To Be Discussed/Determined
WFM = Works For Me

Testers hate the WFM one because it usually comes from a developer unable to reproduce a bug. There are a number of reasons for this; the steps to reproduce the bug are unclear, the issue doesn't occur in a DEV environment (i.e. the DEV was too lazy to try it in a production environment), the DEV didn't actually follow the steps/skimmed the bug description or they really can't reproduce the issue (i.e. the tester screwed up somehow; old build, unclean environment, etc.).

The short of it all, whether right or wrong, it means the DEV has taken the lazy route and just returned the bug rather than attempting to follow up. My response is, and I only have to say this once per DEV, "Awesome, pack up your system, we'll ship it to the customer."

That usually gets a chuckle and we proceed to sort out what the issue was.

However, that's not the acronym I was going to use, I was going to use JFC.

Do I need to explain what it stands for? Given the context of the text above, yeah, this is going to be a work related rant.

I go to lengths to not say who I work for because I want to be able to rant and foam at the mouth somewhat anonymously. It's also unfair to label the whole company with the same brush that I'm using for painting my rant because we're big... really big... and not every product is handled the same way. Some readers know where I work, please, refrain from mentioning it or you'll ruin this as an outlet for me.

With that said... we've had a lull this past month. This is the first time in about six years that we've had a little bit of a lull. I work on a product that gets shipped to a large partner and within two other products for the company I work for so we can be really busy. We just released with two of the products and the partner isn't making any in depth demands.

This is both a time to breathe and improve on what we have. One of the areas we're working on improving is automation. We were previously using a home grown tool that was using some APIs built right into the product by DEVs. They've been slack on maintaining and improving these APIs so we've hit a wall. With that in mind, we're stepping away from that tool and means of automation and going with something else.

We're using an automation tool that allows us to create centralized application map and reuse it in a manner that lets us just make changes to that map and not break any scripts that were created using it.

Pretty easy and the whole team gets involved which is good because previously there were only one or two of us working on the automation... on top of our other testing duties.

Anyway, being the most senior and familiar with the automation tool, I'm sorting running it and I've got everyone on the team (who isn't on vacation) actually making use of it and working on automating their old test areas that are suitable to automation.

The DEVs are looking to utilize some code developed in our tools group for their GUI. There is a lot of underlying code that is supposed to help for their unit tests, localization, stability, etc. Downside is that the automation tool we're using can't see all of the objects (it couldn't see everything before, but I'm awesome and I create code that makes it happen anyway) unless we switch it into a newer mode.

The newer mode might require rebuilding what we've been working on in the last couple of weeks. It's big scary gray area because this new mode is... well... new.

Bonus is that I'm going to be talking with the developers of this tool on Thursday so I can quiz them about this stuff and get a better feel for this 'new' mode.

The JFC acronym comes into play here because DEV is sending me mixed messages. One lead is telling me they're going to make some more use of it. The other lead is telling me they're going to revert the code they put it so far and won't use it this upcoming release. The manager is saying it's too much work so it's not likely to go in.

I'm getting mixed messages and they're not likely to decide until next week. That means I'm going to find out what they're going to do after I'm done getting everything working (really, the application map/framework is just about ready to go) and after I have the ear of the guys who made the automation tool.

So JFC... why can't they have decided and stuck with one decision? And why the hell can't three guys who sit within five feet of each other not be on the same page with whether it is in or not?


Whew... I feel better.

The bottom line is, our automation cannot factor into the decision of whether or not they use this. If it is better for the product that they move to this core code then it's better that they do this move and I'll make necessary adjustments.

It's just really frustrating to have busted my ass the last few weeks getting this all together, ramping up people on the team with how to use the tool (and in some cases, write code!) only to have to rework it.

On the bright side, the team has become more familiar with the test tool and the test tool should be able to handle the new changes to the product, it will just be a matter of recreating the application map... which was the bulk of my work for the last two weeks. I'm also fortunate to have a manager that isn't clueless and understands all this.

Rant off.

No comments: