Long Time, No Post

My translation of the existing Java codebase for Brixen into C# continues to slowly move forward, hampered mostly by long hours for my job and the inevitable craziness of the holiday season. I have not yet encountered anything that I have been unable to duplicate in C#. I have learned how to implement extension methods and how to use generics in C# which is awesome.

I am struggling to replace an old smoke test suite for the product I support before I leave for Christmas vacation. I feel like every victory I have is rewarded with a new and difficult obstacle. Every time I successfully clear one hurdle and need to take the test suite to the next level, there is some new, difficult problem to solve that takes a week to deal with. Meanwhile, the QA Director keeps asking, “Where is that sweet sweet automation you promised us!” It’s hard to explain to people who don’t code the difficulties and challenges of re-tooling something to get around things like defects in the open source tools you’re using, or building out infrastructure to support things like configurable suite options and test data feeding. It always sounds like I’m making excuses for my pitiful lack of amazing progress in producing Teh Automation Suite of Amazingness and Wow-dom.

One thing that annoys the shit of me is that it seems that all prior progress I have made is forgotten as soon as a week goes by without new test cases getting automated. It doesn’t matter that I managed to build infrastructure that allows me to execute the exiting test cases across multiple scenarios as opposed to one. It doesn’t matter I had to stop and produce something for the test automation framework that we are trying to shove down the throats of the other business units. It doesn’t matter that I had to implement a work around for a TestNG defect. All that matters is that new test cases were not automated that week. The fact that I have automated almost 75 percent of the test cases covered by the old test suite I am replacing in addition to automating test cases that the old suite didn’t cover is quickly forgotten.

The QA director has taken to the habit of stopping by my desk and publicly ‘joking’ that I emailed him the night before to tell him that I was already done with the smoke test. Or that I told him I would be done early. Nagging that is disguised as good-natured teasing is more annoying that direct nagging could ever be. Seriously, it just makes me want to spend the next hour Christmas shopping on Amazon for my kids out of spite. The agreed upon deadline for finishing the smoke test replacement effort was still TWO WEEKS AWAY when the nagging began. It doesn’t help that we have all been told to expect lower bonuses this year and that my bonus is riding largely upon the successful completion of this project before I leave on vacation. It isn’t worth working the kind of hours I do to put up with that crap. Plus, all this overtime and stress is getting in the way of moving forward with Brixen which is far more interesting and fun to work on.

Another giant pain in my ass is that the principal SDET and Architect of the automation framework we are trying to shove down the throats of the other business units tried to quietly sneak in some page objects from her old framework into the new one because her junior engineer didn’t want to spend 10 minutes asking me some questions about how to follow the far superior approach I busted my ass to develop. Instead of making a real effort to convert to the new framework, he just wanted to be lazy and just do it the way he had gotten used to doing it. I tried to point out the irony of our effort to make the other business units switch over to our way of doing things while allowing an engineer on our team to avoid doing exactly that, but the principal SDET played dumb and pretended that my point was totally incomprehensible. This lead to a demand for a code review of the core classes in the page object API by the principal SDET.

I wrote a few Wiki instructions for how to use the core classes. For example usages of the API, I used the page objects I had built for the customer portal to support my automation. At one time in the recent past, I had advocated that the API as well as the page objects built with it should both be part of the framework, but the principal SDET insisted that only the API should be in it. So, at her insistence, I moved them out of the framework project. During the code review, the members of the West Coast team who were taking part interrupted me as I was in the process of explaining some of the examples on the Wiki page to ask, “This LoginPage class you show here…. where is it?” So, we had an unscheduled discussion about the new features they wanted in the the LoginPage class and the other page object classes for navigating through the customer portal. I would feel more smugly satisfied if I had not just signed myself up for even more work.

Share This:

0 Comments

Leave a Reply

Your email address will not be published.