Tag: work

Treading Water Is Too Much Work

I honestly meant to post about the daily insanity of my workplace about a dozen times over the last two months. The only problem was that I was working all the time. Something amazing happens every time I step off the Endless Manual Testing Train To Perdition. I always have a giant pile of technical debt to address and I have to work overtime for weeks to catch up on the deferred maintenance. The current task on the pile is implementing an interface for a REST API to query the customer configuration management application for configurations meeting necessary criteria for automated tests. I didn’t want to use the UI to search for these configurations because the test systems are still a steaming pile of crap. Using the UI introduces a ton of new opportunities for their horrible performance to blow a test execution run to smithereens. Plus, these tests already take long enough to run that any means I have at my disposal to optimize the execution time should be put to work.

The API belongs to an ecosystem of APIs the company developed for programmatically interacting with our services and systems. There is a tool available in the The Chosen Framework v2.0 for executing requests against these APIs, but the design is not to my liking. Given the political shit storm that always surrounds any attempt to alter the design or function of any of the services in The Chosen Framework v2.0 and the total lack of staffing to support and maintain the framework, I decided to secretly write my own tool. There is an overly complex authentication system for using any of these APIs, so I had to build out my model for the access control group and user admin business domain to include the credentials needed for authentication. I have a penchant for wanting all my test data to live outside my test suite source code, so everything needed to be serializable/deserializable from both XML and JSON because who am I to dictate which storage format a person should use in order to employ my tools for their own purposes?

One thing lead to another, and suddenly, I had 6 different repositories for tools I have written to model parts of the business domain and as well as services I built on top of those models to automate interactions with the products I test. Not to mention that the number is set to grow because I have plans for additional services for even more automation goodness. In short, this collection of tools and services has become a total beast. It is really an automation framework in its own right. I finally managed to get a Stash project dedicated to them, so I moved everything there. As soon as I did this, I started to get nervous about getting caught for not using the services in The Chosen Framework v2.0. QA Director has been on the warpath against people who don’t want to use the services in the The Chosen Framework v2.0. I believe that the failed effort to shove it down the throats of other business units in the company is a sour and somewhat embarrassing memory for him, especially because several people on our team have turned their own noses up at various tools in framework. I can only imagine what the reaction will be if I get caught for building a rogue framework.

I confessed to my boss today that I was guilty of coding without a license. He asked me why I didn’t use the existing tool and I explained my reasons, and he said I should just add my tool to The Chosen Framework v2.0. This meant I had to explain that this would mean adding other tools to it, including the business objects and page objects that I had been asked to remove last year. He seemed confused and said he would address the issue in Some Very Important Discussions taking place next week among QA Director, the other managers and Principal SDET regarding the future of The Chosen Framework v2.0. I don’t think he realizes yet what a clusterfuck this whole thing has been. I would prefer to have nothing to do with The Chosen Framework v2.0 and continue building out my secret framework, but I know this is never going to happen.

The summer was a busy affair. It started out with a massive fail by the new organization that has taken over support for development tools and infrastructure. They officially took over maintenance of Stash in June and immediately buggered system the first time they did routine maintenance on it. For some reason, the most recent backup available was a month old. Thankfully, I had the most recent version of all my work saved locally, but some teams lost work. I am very happy to see that we are getting something that looks a lot like a real IT support staff, but these handoffs are a bitch. At the very least, before doing anything to the source control system, one should make a backup and then make a couple copies of that backup and store each of them in different locations. They handled the recovery process well, though, with good communication and organization of the effort to glue Humpty Dumpty together again.

As part of my job duties over the summer, I helped Junior SDET Who Should Be Senior mentor our summer intern from MIT. This was one of the most pleasant and enjoyable experiences I’ve had. It’s a lovely experience to work with one of the smart ones who learns quickly and is able to extrapolate abstract principles from a few basic examples and work independently. I highly recommend hiring MIT students as interns. I think a lot of them could easily drop out of school and start working as developers or even start their own companies and be wildly successful.

QA Director has been on everyone’s case about work from home policies and has lately taken up the cause of monitoring what we are doing on our computers at any given time. At one point, he asked Junior SDET Who Should Be Senior to talk to our intern about not playing games or watching any videos while he is in the office. QA Director claimed that ‘someone’ had complained to him about it, but I wouldn’t put it past him to lie about that so that he doesn’t come off as the ‘bad guy’ with a bad case of Hall Monitor Syndrome. I personally think that people who are productive and hit their milestones should be left alone, but I’m not the boss. Right after this, he claimed that ‘someone’ complained about the whole QA team being absent from the office on the first Friday after a giant release date. This was first and foremost, incorrect because I was in the office that day. I’m just too short for anyone to see my head over the top of my cube. Second, several people took vacation after that horrific release cycle, one of us couldn’t work that day because their new H1B visa wouldn’t be in effect until the following Monday, another of us was out sick and the rest were working from home on Friday because that was the day they had chosen for their one day a week allowance.

This of course, ignited a tense and difficult team meeting in which many of us expressed anger and resentment because developers seem to do whatever they want when they want and we are the only team that ever gets called to account for our whereabouts. QA Director became very defensive and sort of pissed at us and then he said he was going to tell the person who complained to mind their own business. Which is what he should have done in the first place. There’s nothing more demoralizing than a boss or director who won’t stand up for their team. Our team manager seems to be getting really tired of all this and has said he is not going to get into the habit of taking attendance because we are all grown adults and he would prefer to focus on the work and whether it is getting done or not. Although I am really pissed that my former boss was fired, I like the new manager a lot. He’s focused on the work and getting the developers to work together with us as a team, which is nice.

I found a senior developer role elsewhere in the company that is with one of the business units that is turning a profit. I have an informational interview with the hiring manager next week. Hopefully, this will be the right fit because it would be really great if I could continue working with the company in a part of it that is actually making some money. I really like the technology here and working with a core piece of it would be a great opportunity for me to gain some new experience and skills. I am still working on acquiring the knowledge and skills to get into data science or machine learning. I underestimated the amount of time that would take. There’s a lot of math. SO MUCH MATH. I built an Anki flashcard deck for the MIT discrete class I studied through MIT OCW. After finishing up the book and the lectures, I started using it study the material. For the first two weeks, it felt like it wasn’t doing anything for me, but now I have started to see cards which are easy for me to answer. The other benefit is that there are many proofs that I ‘know’, but understand more fully as a result of repeatedly reviewing them. Our summer intern is taking the class this fall, so I shared the deck publicly, and it appears to have taken off like wildfire because it has been downloaded 41 times so far. Hopefully, Anki will catch on at MIT and students will make decks for their other classes and post them publicly so I can use them myself.

I also took on the task of identifying the root cause of some TestNG defects related to parallel test execution. These defects have been making it impossible to implement the ability to log my tests to a separate log file by thread without advanced jujitsu configuration and hacking in Logback. If the tests would just freaking execute in the right thread in the expected fashion, this would be trivial, but all these random extra threads get spawned because a new thread worker is inappropriately spawned when you have test method dependencies. TestNG works as expected when test methods don’t depend on each other. Actually, group and test method dependencies are notoriously buggy when trying to use the various parallel execution modes offered by TestNG. It was quite a ride debugging that code base, but I found the bug in the source code and now I am trying to figure out how to fix it. It seems to be difficult to get a pull request accepted in TestNG (for good reason), but I want this bug fixed so bad, I am willing to jump through whatever hoops they want.

Basically, I have a lot of irons in the fire all at once. Hopefully, switching to a role in a profitable part of the company will put me in a less over-burdened role. I am sick of working on an absurdly understaffed team with people in positions of technical leadership who shouldn’t be there because they can’t code or understand basic software architecture design principles. Also, I really want to work for an organization that doesn’t treat me or my team like a bunch of middle schoolers who need a hall pass and a reason to be absent for a bathroom break.

Share This:

The Reality, It Burns!

I am jaded today. I am the de facto tester-in-chief for the tool for migrating customer configurations from the old configuration application to the new one. All the easy stuff has been done, and now we are working on the long tail of the cases that are less straightfoward. There is no benefit to making our junior engineers work on this because the tool is going to EOL and they would have to be trained in something that is going away at the end of the year. For the same reasons, it is completely pointless to automate it. Not that automation is really an option for this kind of work. Due to our appalling lack of internal profiling tools for our data, I must spend at least half of my effort digging through production data by hand to locate the appropriate test cases or for some clues for how to construct them by hand. I have been mostly devoted to this task since March.

QA Director has come back, though he is not in the office much. He has averaged about 2 days a week in the office since he returned from a trip in February to meet up with one of our European teams. At that point, his dog developed a life-threatening health condition and then he suffered a heart attack. When he returned, he made a point of stopping my desk to ask in an out loud and not at all private way if I was happier with my job. Generally, when trying to assess a subordinate’s level of job satisfaction, a leader would give them the benefit of some privacy, but I will assume that QA Director’s recent traumatic experiences are responsible for his appalling lack of social grace in this department. This line of questioning came on the heels of two anonymous surveys sponsored by the company to measure job satisfaction in which I bluntly expressed my opinions about how the SQA function is treated, how women are treated and then how I was treated. I was also free with my opinion regarding the crippling under-investment in tools and infrastructure for SQA, the technical debt that has been allowed to accrue and the inefficient organization of the function and its tasks.

As QA Director is standing expectantly there at my desk, waiting with baited breath for my response, I said that I wanted to be developing, but I was buried under the never-ending task of testing the migration tool and scrambling to do release-level testing for my share of the 60 or so JIRA tickets that get resolved every release. He nodded his head sympathetically, and assured me that will end soon. We just get to get over a couple big hurdles. Just a couple more. I think my eyes glazed over because I have been hearing this for the last four years. This zombie of an idea just keeps going on and on. For four years, the message has been that it’s going to get better real soon and then there will be enough time to write some sweet sweet automation. There are going to be fewer, novel, big features that require weeks of testing and tons of IMs and emails to people who don’t respond to questions about expected behavior because this company treats documentation like it is a weakness. Much better to adhere to an oral tradition for passing down knowledge about crucial features that help make or break customer retention rates.

The new manager has been growing on me, and I actually feel a little sorry for him. I sense he feels a lot like he has been set out to drift on the open sea because QA Director, his boss, is hardly ever around. He is the latest is a series of managerial-level hires who came to this company with enthusiasm and excitement about making positive change. It must seem like a career-making opportunity. Then the grind wears them down to nothing and they quit or settle into the mode of drawing the paycheck and hunkering down for the storm just in case there are any serious bugs that are found after a release goes out. Eventually. That, or they get fired and/or demoted. I haven’t seen anyone quit yet. When our team interviewed the new manager, I asked a series of very pointed questions about how he planned to handle a series of no-win situations drawn from real life experience with every release cycle I have had the opportunity to suffer. He seemed taken aback by the line of questioning and then said that every company is a little crazy and that is just the part of the job, but he would make some process changes to make this all run so much better for us. I am sure he thought I was exaggerating. It would have been interesting to see if he reacted differently to a male employee interviewing him in this way. I get the feeling that women are regularly blown off as exaggerators.

The evolution of the new manager’s demeanor has been interesting to observe. I have to give him credit. He had his Come to Jesus moment faster than most. He finally seems to have accepted that there is no coordination between QA and Dev regarding the content in each new release. He also seems to have realized that QA is a toothless organization which is everyone’s bitch. After experiencing a couple of our typical release cycles, he started sayings things like he needed to manage up through QA Director in order to change some things. I did not say out loud, “Good luck with that!” In a meeting with me and the co-worker who works on the same application, he said that he was going to insinuate himself into the developer’s Sprint-planning meetings and then slowly subvert them. His heart’s desire is to institute a bonafide prioritized and groomed backlog so that our team is not always inundated with piles of new, undocumented features and tickets none of which take into account how long we need to test them. He added that he would push hard for change, but he was not going to stick around if it became clear that the company was not interested in change for real. I wonder how long it will take before he realizes that change will not happen. We will not be getting any additional resources, and I am willing to wager money that our stalled out Sauce Labs adoption will hit the one year mark with no movement because we need the release engineering and operations team to do something for us to make that happen. And our total lack of power and status means that this other team can continue focusing on things they care about and leave us standing there at the party, hand extended for the handshake that never comes.

The company finally gave everyone their raises and they were Not. Especially. Impressive. I think this pissed off Principal SDET and The Minion. The Minion got a promotion so I am not sure exactly, what he has to bitch about. They have been telling their developer friends in the Mutual Cheerleading Squad that if they didn’t get what they deserved they were going to resign and go to another job. Be still my beating heart! That would almost be a reason to stay on. ALMOST. Of course, they aren’t going to do anything at all. It’s idle talk. Principal SDET could not crack any kind of coding interview that she would have to face trying to get that architect job she wants so badly. The Minion’s coding skills have not improved one bit in the two years he has worked with us.

In the meantime, I was contacted by a UXD SDET in the Canadian organization who wanted to know if I had written any page objects. I sent her the information she asked for. Principal SDET got wind of this and immediately situated herself into the middle of the communication channels and set up a demo the The Chosen Framework, V2 for two completely different engineers in the same organization in Canada. I am skeptical that anything will come of either of these encounters. What I predict will happen is that they will just build their own frameworks from scratch like every other team at the company does. She also made a point of telling me to focus my demo and talk on the APIs and not the page objects and business objects. She told me months ago to remove those from The Chosen Framework, V2 because she could not understand why anyone would be interested in code that is usable for writing automated tests right away. I suspect she knows this is a mistake because other people have been asking why there is no common repository for page objects and business objects in the framework. Principal SDET is allergic to admitting a mistake, so I imagine this charade will go on for a long while before she asks me to move them back in. At this point, I don’t actually give a shit because I am patiently planning and preparing for my new job.

Speaking of which, I am coming to end of the MIT OCW course on Mathematics for Computer Science through OCW. My pace has slowed somewhat since I have been trying to spend more time with my children and because I spent a good chunk of every weekend doing DIY work around the house. I finally finished stripping the paint off the window in the room that will be my sons’ new bedroom. Unfortunately, there is enough work beyond this bedroom to keep me busy until next Spring. And I have linear algebra, statistics, and algorithms classes to get through on OCW next, and after, some MOOC courses on data science and machine learning applications and tools before I will be ready to step out there and go after the machine learning jobs I want to do. Meanwhile, I will engage in futile dreams of the amazing testing tools I could build using machine learning techniques against our massive quantity of internet traffic data.

One of the things I have taken a passing interest in lately is the impact of stellar internal tools on a company’s competitive advantage:

The Joy of Internal Tools
This Startup Built Internal Tools to Fuel Major Growth — Here’s Their Approach
How Internal Tools Can Make or Break Your IoT Solution

The matter of internal tools comes up regularly on the steam of submitted questions during the company’s quarterly meetings. It also appears in questions submitted to the CEO on the intranet. And the responses are always the same bland pap: Reassurances that the ruling class at the company totally understands that they have allowed an enormous burden of technical debt to build and they are totally working on that! And to give them credit, they are working on that… for developers. Not for QA. There has been some hiring for a developer productivity tools organization and zip for QA productivity. After all, we don’t create anything or add any value, so why bother spending any money on us.

Share This:

Getting the MIT Education I Should Have Gotten After High School

Today, I am glad. I am so very glad that I took this week off for a much needed vacation. It’s not exactly a vacation. I am helping my husband complete our state tax forms and working on home renovation stuff like scraping paint off an old window and doing a new paint job on the room that will be our son’s new bedroom when it is finished. And to mow the lawn because the grass had gotten about 18 inches tall. Definitely not the kind of vacation that inspires the envy of one’s co-workers and friends, so I won’t be posting any photographs of my family looking obnoxiously happy in an exotic locale. I might post the photos I took yesterday of my son looking tired and hot and my daughter chewing enthusiastically on an empty water bottle at Edaville, a local amusement park for the younger set. I don’t know how other parents manage to get photo-perfect moments of their toddlers and preschoolers. My kids had a blast, but I could only take photos that gave the impression that my kids wanted to give the world a pint-sized middle finger.

I have not written more than 100 lines of code since I completed the localization support for the page objects two months ago. Since then it has been manual testing all the time. QA Director had a heart attack two weeks ago, which I partly ascribe to the pressures of the job. By the time this happened, he had stopped talking about all the great things that were going to happen for our team. A few months ago, he said there were plans to expand the team so that we could do the kind of career building projects that ambitious people salivate over. I think he’s getting the same kind of bait and switch as my old boss. When my old boss recruited me, she was in the process of building out a team of QA super stars whose mission would be to implement a top notch system testing infrastructure. That never happened. We are still doing the same old manual regression testing we were doing four years ago. About 1/3 of the way through the team-building process, her open requisitions were yanked out from under her and she never got them back. My company, like many, loves to talk about much they want great QA, but they want it all for next to nothing. It is clear that the QA function is the last in line where resource allocation is concerned. We still have not closed the deal on our POC Sauce Labs services, a measly 10 test VMs that can barely service a half-assed regression suite for one simple application. Unfortunately, there are security implications to opening up our test environments so that they are accessible from the Sauce test VMs. Getting over this hurdle requires cooperation from another team. They have to configure the environments before we can use Sauce to test against them, and we are probably on the bottom of their list of priorities.

Before his heart attack, QA Director told me that we would be getting a dedicated support staff to support the test environments, which is great news. The shitastic state of the test environments has been a giant source of frustration and there is literally no one in the company who thinks they are properly supported. Up until now, we have all had to rely on the support staff for the production system and a cadre of volunteers to keep them up and running. Otherwise, I doubt there will be much additional investment in our function. Whenever there is money to hand out, every function is competing intensely to get it for themselves and QA does not get a VIP invite to that kind of party. We were even displaced from the space we were given in the new office they moved us into last week. Product Operations and Marketing were unhappy about the spaces allocated for their groups, so they were allowed to take our space from us and now we are no longer located right next to the development teams. Colocation of QA and Dev was highly touted as one of the great benefits of moving to the new office space. When the employee engagement survey results came back last year, there was some ‘concern’ at how terrible the morale for our group was and there were a fair number of earnest promises that these issues would be addressed. I am dying to know what the results of this year’s survey will be.

All of my spare time these days is devoted to MIT OCW. I am working my way through the readings and lectures for Mathematics for Computer Science. I am making Anki flash cards for all of the material as I progress through the course. It is highly labor intensive, but the effort will pay off in that I will thoroughly learn all of the material in the course and I will have spaced repetition flash cards that I can use daily to ensure that I don’t forget any of this material over time. After I complete this course, I am going to go through the intro to algorithms course and do the same. Afterwards, I am going to try out the harder programming problems posted at LeetCode and HackerRank. If I can quickly solve those problems, then I will consider myself prepared to tackle the coding interviews. I found that as I got into the harder problems, I was missing the core algorithmic knowledge they were designed to assess. I could cram, but I don’t want cram-style knowledge. I want a thorough and solid grounding in these concepts. There is no short cut really.

I am about 2/3 of the way through the Mathematics for Computer Science, which is MIT’s introductory discrete mathematics course. Compared to my UMass Boston introductory discrete mathematics course, it covers more material at a deeper theoretical level. Calculus is also a two semester affair at MIT, rather than the three semester program at UMass Boston. There are a few things I wish I had done in my life. I wish I had applied to MIT and chosen to go there for computer science rather than comparative literature at Harvard. Barring that, I wish I had just sucked it up and taken private loans and gone to school full time at UMass Boston for computer science. I tried to cut down on my debt burden by doing school part time and working full time, which in hindsight was a terrible idea. I did not give myself the opportunity to gain the kind of education I should have gotten there. I missed too many classes and focused too much on just getting the degree. The better choice would have been going to MIT for computer science from the beginning. I blame my indecisive and feckless youth for the meandering and unfocused I path I took to this point in my life.

I want to get into data science or machine learning as a developer not a QA jockey. I have given up on quality assurance as a career that is going to offer me any real serious engineering challenges. Most companies just want someone to verify that buttons are enabled and that 1 plus 1 equals 2. They tell potential new hires that the positions they’re offering will be engaging, challenging career-building automation and infrastructure opportunities, but in reality, they want all that amazing automation and infrastructure for nothing more than the cost of a glorified button clicker. Verifying that the button is present and clickable will be the new hire’s first and foremost responsibility. There will be thousands of buttons too, and lots of input boxes to test. Only after the QA engineer laboriously writes all the test cases related to the clicking of buttons and entering of text into input boxes will they be permitted to even open an IDE to write code for automating away that soul-sucking, mind-destroying monotonous shit. Except there will never be any time for automation because they will have run the regression suite of button clicking tests over and over and over again.

Share This:

Swimming Upstream In Molasses

I am demoralized today. It’s as if my previous post was a preamble of sorts for the trajectory my work life would take. I’ll start with my arrangement to work from home 2 days a week. Last week, QA director asked me to come to his office. After closing the door, he opens with, “Do you remember when we agreed to revisit your work from home arrangement in April?” This comes as a surprise to me because we did, in fact, revisit this subject during my performance review in which QA Director told me that he was fine with allowing this arrangement to continue and that he would defend it if questioned about it. I reminded him that we had revisited this issue already and that he had agreed to allow it to continue indefinitely. I did not remind him that he subsequently made the case to me that I had been granted some monumental favor. He brushed this aside like the consummate gaslighter that he is and complained that other people had been ‘asking him for things’ and it was getting difficult because our department has a stated policy that employees only get one day a week to work from home. This incident is not the first time that QA Director has said something only to later pretend that he never said it. He asked me if this was ‘demotivating’. I sat there trying to figure out what I should say to this, since there is a constellation of issues that serve to demotivate me and since I am actively preparing to exit this job within the next 2-3 months, I said simply that this alone was not a demotivating thing. I did not say that adding it to a growing list of things which I find objectionable about working here was basically confirming to me that the time had come for me to move on.

We had a discussion in which I said the policy itself made no sense and reminded him that another employee had been granted full time remote work. I didn’t mention that this kind of privilege seems to always be granted to male employees. I am saving that one for my exit interview with HR and the Glassdoor review I will be writing after I leave. He hemmed and hawed and said that this kind of arrangement is given to employees only when the role is ‘right’ for it and QA roles just aren’t that kind of role because QA people need to go to standup meetings. I guess creating a conference call for a 15 minute meeting once a day is just too hard. The only difference I can see between a QA role and any other technical role at the company is that it is the one technical function which is performed mostly by women.

After he jawed on a bit about the difficulty of handling employees who aren’t getting all the same perks and how everyone seems to know everyone else’s business, the meeting took an interesting turn because he asked me if I thought things in the group were better now. I know that this kind of open-ended question typically means that he is on a fishing expedition, so I asked what he wanted to know about specifically. He asked me if I thought things between me and Principal SDET were better, which was funny because she has been on maternity leave for three months. I said that we had not spoken to one another after The Great Test Case Labeling Shouting Match. This rang my unspoken subtext radar and made me think that the reason my work from home arrangement is being revoked because Principal SDET wants something similar now that she has two small children, one of them a 3 month old nursing baby. I don’t personally like Principal SDET and I definitely don’t think much of her technical prowess, but given her situation, I think some more work from home time would be a reasonable thing to ask for. It really screws up breastfeeding to not be able to feed a baby on demand. It made me sad that QA Director’s response to this situation is to take away a perk that I was told I could keep just to avoid giving this flexibility to a nursing mother.

I suspect he also was trying to find out if I knew that Principal SDET’s minion has been grumpy and insecure about our new hire because he thinks she is getting paid more. I know that The Minion spoke with QA Director and wanted more money. The Minion has been positively insufferable with the new hire. He has been acting like he is her supervisor, dumping tasks on her and demanding that they be done within a specific time frame that he pulled out of thin air. He gave her the task of writing UI automation for some dashboard application and said she should be done in three weeks. She went looking for test cases in JIRA Zephyr and found none because The Minion and Principal SDET are just too good to do something as lowly as write test cases. She began writing them, but the Minion told her to stop and just start coding.

Junior Engineer Who Should Be Senior and I had a good laugh going through all the test automation code in Stash that The Minion and Principal SDET wrote. We are both bewildered that Principal SDET and The Minion are treated as if they walk on water by management. The Minion claimed that he spent three weeks writing UI automation for the dashboard application that was made obsolete by changes in the application which is why he dumped it on the new hire. Neither Junior Engineer Who Should Be Senior nor I could understand how a couple small page objects and ten simple tests could take three weeks. Junior Engineer Who Should Be Senior is inheriting an automation project that was written by Principal SDET. The developer is over the moon because Junior QA Engineer Who Should Be Senior has a great reputation for getting automation done. He complained that the automation that existed was terrible and that he constantly had to patch it up just to get it to run, so he as delighted to be getting an automation engineer to re-write it.

But I digress. There is something interesting about QA Director’s sudden about face on work from home because for the last two and a half months he has hardly been in the office at all himself. His dog is sick and he needs to be at home a lot to take care of him and ferry him to and from doctor’s appointments. He has even stopped alerting the rest of us whether he will be in the office or not on any given day. He is burning through PTO like there is no tomorrow. It makes me wonder, given his employment history of short stints at several jobs in row, if he will flame out and be out of this role within another year. He reminds me a little of another boss I had who also had a similar employment history and condescending attitude towards female subordinates. He flamed out spectacularly in under two years.

I think the thing that pisses me off most about interacting with QA Director is that I always have the sense that he is just waiting for me to stop talking so he can start talking and push whatever agenda he has. He has taken to interrupting me during my status reports in team meetings several times to remind me to keep things in mind that a retarded monkey would know are important, like, “Make sure you focus on the highest priority stuff” and “Stay focused on what’s important” and or to ask a question that reveals an assumption that I don’t know basic shit about time management and task scheduling. I really dislike people who talk down to me. At no time have I let a higher priority task go undone so I could noodle around on something I liked more. Another habit I have noticed is that he addresses female employees with ‘Young Lady’. This would be charming, maybe, in a totally different context, but not in the workplace. It has a weird, diminishing quality and if I wanted to unwrap it even more, it has a lot of weirdness in it regarding ageism and women too. I’ve come to the realization that the only direct supervisors I’ve ever had who treated me like an equal, took me seriously and listened to me are women. Every male boss I’ve ever had has been very dismissive, quick to assume I don’t know what I am talking about or listened to me only halfway with that “Waiting for my turn to talk” attitude.

So, now we have a new manager who, predictably, is also a man. He has hardly said a word to any of us since he started, but has been going to lunch and interacting a great deal with upper management. Not that I wanted him to buddy up with anyone because that kind of thing makes me not trust a new supervisor, but it does reinforce the feeling that this place is a boy’s club. Once thing I need to keep my focus on is getting a few more years experience and then striking out with my own consulting business. I am sick of working for patronizing dudes who themselves are not particularly competent and who want to hire people like themselves. I am still pissed that the only people who got fired are two women over fifty. Another manager in different location was not fired, but demoted to Principal SDET despite having a terrible track record. All five of his senior engineers quit and they were vocal on their way out about how little they respected his management style. Yet, he still has a job and my boss was sent packing.

Share This:

Preparing for the Coding Interview and Other Tales

Today, I am playing the long game. The one that involves intensive and thorough preparation to get a job where I will have complex and difficult challenges to enjoy. Challenges that involve writing code and not long, involved test cases that take a day to design and debug before I can move on to the next test case that is going to take a day to design, debug and write. I contacted a recruiter who specializes in L33t Coding Jobs and he said I would have to get comfortable writing code on a whiteboard. I am not totally certain of the value of these whiteboard coding exercises over just giving the candidate a computer and pair programming through a bite-size problem with them, but I am getting with the program anyway. If this is the hazing ritual I must endure to obtain the my dream job, then I will endure it.

My chosen guide for preparation is the one that everyone uses — Cracking the Coding Interview. I snagged a 5th edition copy and starting working through the first two chapters. There’s one thing I can say for solving programming puzzles with paper and pencil. It’s slow. Okay, I can say some other things too. It does force you to know by heart the core APIs of your language of choice. I got very familiar with the String and Character methods for handling the entire Unicode character set while solving the problems in the chapter about strings and arrays. Most of the problems are actually pretty decent at working my CS student brain back into shape. Some of the problems are just silly and require you to do something that is dumb and the solution they want you to implement is one that wouldn’t pass code review in a decent company. Like — Delete a node from a list given only access to that node. The answer is “Copy the data from the next node in the list and delete that node.” Of course, this doesn’t work if the node you are give access to is the last node in the list. Normally, I would look at this and think, “Either this linked list API is shit and needs to be re-written because this doesn’t fucking work or the person who wrote this clearly doesn’t have a clue how to use a linked list API.”

Given that there are 150 problems to solve in the book, my interview preparation is going to take a couple months. It is worth the effort to escape the manual testing monster that slowing devouring all my joy. Hopefully, they will replace me with a traditional QA type, so the other SDETs can focus on their automation when I leave. The downside to this is that I haven’t had any spare time to work on Brixen, which is making me have a major sad right now. My next step is to write an EnhancedPageFactory class and some annotation classes so that declaring one of the component wrappers in a page object basically works the same way as declaring a WebElement with a FindBy annotation. Of course, specifying all the data for the component wrapper is a lot more intensive that a simple locator for a WebElement, but I figured that could be handled with a configuration file which is declared by the annotation. The intent is to make all that messiness with having to build the component in your page object go away and become completely invisible.

The other thing that bogged me down with the Brixen work was discovering just how painful and difficult C# is when you are trying to assert equality between collections. By default, C# uses reference equality which is totally ridiculous in my opinion. Who the hell though it made sense to not compare the objects they contain for equality? This really pisses me off. There is an interesting library that does this for C#, but I ran into problems comparing values like 64 bit integers and 32 bit integers. This library doesn’t have some mechanism for upcasting the 32 bit value and then doing the comparison. It just returns false. I realized this when the the library I was using to deserialize data from JSON was taking values like integers and returning then as the type with the largest possible values. So, if I serialize an object with a 32-bit field and then deserialize it, I get a 64 bit value for that field. VERY ANNOYING.

QA Director has become a mite touchy on the subjects of under-staffing and our unstable test environments. Apparently, the California team is even more under-staffed than we are. This is supposed to make us less unhappy that we can’t accomplish our objectives without working nights and weekends, and the logical fallacy of this line of reasoning is totally lost on most people. Be happy about suffering unreasonable expectations because other people are being crushed harder by expectations that are even crazier? Of course, we just made an offer to a manager candidate to replace my boss who was fired two months ago as the sacrificial lamb on the alter of blame for our lack of success instead of hiring more people who would actually do some of the work. Unfortunately, this candidate seems to be of the same delusion that it’s better to have a team of people who are doing both the traditional QA work and the automation. This does not bode well.

If I didn’t already understand how little valued the SQA function is, I’ll share a small anecdote about our upcoming monster release. There was a feature that was supposed to be ready by code freeze. It totally wasn’t ready by then, but we said we’d give it the old college try and test it if they could get it done within a few days. A few days later, the engineering team responsible for writing it said it was all done and ready to test. The person testing this feature started the testing and found that none of the REST end points were reachable. The engineering team is in India, so there follows a back and forth dialog between her and the engineering team with 12 hour delays in between communications. It was working for them, so she must be doing something wrong. As the release date grew closer, the testing could not proceed because the feature just wasn’t accessible to the test team. A meeting was called to make the call about this feature, that went like this:

“So, can we release this feature?” the product managers asked earnestly.
“No, we haven’t tested it,” answered the QA team.
“Great! Let’s release this feature then,” replied the product managers.
“We said no. We weren’t able to test it,” interjected the QA team.
“We all know that when QA says no they mean yes, ” laughed the product managers. “So, we’re good to go.”
“No. We are not good to go. The feature hasn’t been tested at all,” replied the QA team. “Not even one little bit.”
“Why are you being so difficult? I thought you said it worked,” barked the product managers.
“We didn’t say that it worked. The developers said it was working on their machines,” said the QA team who are now texting their favorite recruiters on their phones under the table.
“The customers really want this feature,” whined the product managers.
“We understand that. They probably also want it to work too,” said the QA team.
“Fine. Let’s talk about this again in a few days. Maybe the customers can test it for us.”

This happens all the time.

Share This:

Wherein I Give Up Due To Fatigue and Not Giving a Shit Anymore

I am exhausted today. I have been consumed by a tide of work that a team twice our size would not be able to competently manage. It started with a monster new feature that can not be quickly tested via our functional UI regression suite. It requires real end-to-end verification. Normally, we only need to create configurations which use features with the web application for configuration management. For this feature, we have to verify that the configuration is applied correctly once it goes active. This involved a journey of discovery that highlighted the insane lack of coordination and communication between our particular organization and the rest of the company at large.

First, we did not know how to do this end-to-end testing because we have never done it before. Second, we were under the mistaken impression that there was no apparatus for doing this kind of testing in our two test environments. We believed this because we have been told repeatedly that there was no such thing since we were hired. The entire development team and their managers also believed this to be true. A co-worker and I began trying to master this unknown art of end-to-end testing by contacting the team which develops and tests that part of the network. During this first meeting in which the two of us probably sounded as intelligent as brain-damaged turkeys riding the short bus to school, we discovered that both of our test environments did in fact have the networks for doing this end-to-end testing. Not only that, they have had them for FIFTEEN YEARS. It’s impossible to understand that our entire organization could share the delusion that this part of the system was not present in either test environment for so long. I still don’t have an explanation for it. The only thing I can say is that inter-group and inter-department communication is abominable.

We also discovered that another business unit was nearly done with building a system which allows them to go to a website, fill out a simple data entry form and press a button which spins up test VMs on demand that function as a nice little sandbox testing environment for testing for this part of the end-to-end pipeline in isolation. It is well on its way to being part of a continuous deployment testing apparatus where there is little to no human intervention required to spin it up and do tests. I am astonished that my entire organization seemed to be under the delusion that this was an impossible pipe dream. The sheer embarrassment of talking to one team after another about their testing which is so much better than ours and their systems knowledge, which is so much more comprehensive than ours, and their test automation which is so much better than ours has broken something in me. It didn’t help I calculated that it was going to take a month to design, write and execute these test cases. A month in which I would not be writing any code.

Also weighing on me is the task of writing all the functional test cases for the entire UI. There is a hiring freeze and getting new requisitions is akin to an act of god. We have two principal-level employees who want nothing to do with this task. And who would? It’s tedious and unrewarding work to write functional UI test cases. Since I have been tagged as the person who couldn’t get any automation done for three years, I figured it was better to bite the bullet and be the SQA lead even if I am not getting paid to do that role. I’m not even getting paid enough to do my current role. This decision was the genesis for an unpleasant discovery regarding my company’s IT support infrastructure, which is that there really isn’t one. You’d think that a company with 6000 employees would have gotten around to hiring a 24/7 team to support and administer things like the build system, the source code control system and the defect tracking and project management systems. But, sadly, this is not true.

Our JIRA installation started out as a rebel application running off the director of engineering’s desktop computer because a cadre of new employees refused to use Bugzilla. Naturally, because there was no formal introduction of JIRA as a tool, there were no knowledgeable professionals who controlled the adoption. The result is an explosion of project templates with a ton of totally unnecessary custom fields and overly complicated workflows. An organization full of supposedly amazing engineers should be able to design a system that cleanly separates the work of product design, development, testing and customer support, but what we got was a system full of templates and workflows that was designed by a drunken squirrel on acid. Eventually, it got too big to be a rebel application running on the director of engineering’s desktop computer. It did not get big enough, however, to merit a 24/7 dedicated support team. It had gotten big enough to have a part-time support team who were all doing other jobs before they got stuck with the responsibility for managing and administering this monstrosity.

This is where I entered the picture with my quixotic notions of quickly configuring three projects — one for the APIs I wrote for our test automation framework, one for the domain models I have written using the APIs, and one for the QA team to use for defining and managing work related to testing the customer configuration application. I had dreams of using these three projects to define and manage the workload of writing all the formal test cases for the application and the catalog of work that must be done to automate them. This seemingly simple task has been going on since early February. I am in the final stages of getting the correct workflow defined for the Zephyr test tickets. This customized workflow has been most painful part of the process. For everything else, I was able to use the default, out-of-the-box Jira workflow and fields or the agile-style workflow and fields that the team building the new front end uses. The Zephyr test cases were another matter. I wanted a workflow that would accommodate test case design and development for manual tests and automated tests.

I wanted a design phase followed by a review phase. Then, if the test case is to be automated, there is a development phase followed by a code review phase, followed by a testing phase. If manual, the ticket is ‘complete’ after review. If an automated test case successfully gets through testing, it is ‘complete’. I also wanted a workflow that could accommodate sending the ticket back for re-work if review, code review or testing revealed issues as well as a workflow that could handle flagging a test case for needed updates because of changes in the behavior of the application. Granted, this is not a simple workflow design and it didn’t help that I did not initially understand the JIRA terminology or means of representing a workflow. The other problem was that the number of custom issue statuses and fields had completely gotten out of control during the wild west period for our JIRA installation. Apparently, this can cause serious performance degradation in JIRA, so they were no longer allowing any new statuses to be defined. I was thankfully able to choose good statuses from the list of existing ones. That fact that there are about four different statuses signifying that something is ready for development or testing just shows how important it is for a company to get out in front of the problem of building IT support infrastructure instead of chasing after the cowboys who just get tired of waiting for a modern tool chain.

In the midst of this mess, I also took on the task of implementing localization support for my page object library. Our California team requested this feature before Christmas. There are eleven possible languages that a user can select when browsing our customer portal. It took 3 weeks of late evenings and working weekends to pull off locale-agnostic page objects. I also chose to do a major refactor of the DSL API I had written because it badly needed to be simplified and scaled down. I think the system works well. Now all the page objects refer to enumerated constants which represent these localized identities. There is some under the hood tooling that they use for mapping locale-sensitive identifiers to the enumerated constants. It was the best I could do given the short time frame for building it. It was a huge task that burned me completely out.

So, I looking at this job and I have come to the conclusion that nothing is going to change. I have been complaining about the fact that the traditional SQA work and the automation work need to be separate roles since I joined this company nearly four years ago. Nothing has changed. I’m still stuck with work I am not interested in doing and having to burn the candle at both ends to do the work I actually want to do. So, in short, I am looking for a new job as we speak. I finally realized that this company which is supposedly full of amazing engineers is not actually interested in applying solid engineering principles to the test automation. They aren’t even interested in applying solid SQA practices because they severely under-resource the function to the point of absurdity. I keep thinking back to my first real SQA job with a medical device company. The size and scope of the application was smaller, yet we had two managers, four people on the backend and six people on the front end. That’s half again the size of my current team. When I think about this, I realized how totally delusional my company is about the work burden and the complexity of not only testing these applications, but also building robust test automation for them.

Share This:

Some More Reasons Why You Don’t Have Good Automation

It has been a while since our last edition of Why You Don’t Have Good Automation. I am hopeful today. On Monday, I did a presentation on the reasoning and purpose behind my detailed labeling of test cases. The gist of the presentation is that placing emphasis on end-to-end testing as if it were the only way to do automated testing was going to lead us to a limited return on the investment we put into writing all that sweet, sweet automation infrastructure. Once I replaced the older smoke test suite, I was happy to see the dev manager and my boss go all gooey-eyed over it, but I am bothered by the false sense of security that it gives. I am not saying that it is useless, but it has limited potential.

I am disillusioned where end-to-end testing is concerned. It is hideously difficult to build everything you need to implement the plumbing to even get to the point where you can do one end-to-end test. I have been through a couple iterations of this nightmare. The first time was during the Frameworks Wars when my co-worker and I toiled mightily to automate a suite of forty or so manual tests. There was just so much to do and we were slammed over and over again every few weeks with an avalanche of manual testing work for the application. We were also new to the company and not all that familiar with the surrounding, flaky systems that our application interacts with for each of these end-to-end scenarios. Combine this with our total lack of organized training with the some very unreasonable expectations, we were set up to fail and fail hard.

At the time, both my co-worker and I were operating under the same limited perspective as everyone else. End-to-end testing was where it was at and if you weren’t doing that, you were not doing Good Automation. So, we coded and coded, all the while being asked, “Where is all that sweet, sweet good automation?” We actually built a fairly extensive library of page objects which later became of the basis of the current page object library, but because we didn’t have the plumbing to get all the way from A to Z, it amounted to nothing in the eyes of the non-coding people around us. We made some mistakes such as thinking we could not throw our code out there unless it was ‘done’ and leaving the results reporting to the end. We should have had a parade up and down the hallways once a week, given tech talks and otherwise tooted our horns relentlessly. Our unpolished code was better than most of the test code I had seen up to that point. If we had a simple HTML report with green and red pass and fail indicators, I think the non-coding cadre would have believed we were actually doing something.

Our biggest mistake, however, was trying to do end-to-end testing first. If we had broken those long end-to-end test cases up into smaller, atomic test cases that could be strung together in end-to-end scenarios or run as standalone tests, we would have been able to report each week that we had automated twenty-five new test cases. It’s very easy to automate a test that verifies that a dialog opens when you click its accessor. It’s easy to automate a test that verifies that the title on the dialog is correct. It’s easy to automate a test that verifies that the dialog is dismissed if you close, cancel or submit it. Since our application had a gazillion dialogs, we could have written an entire test suite for verifying the basic behavior of dialogs. It’s not easy to verify that a given type of user can log in, access the appropriate accounts, create a configuration, fill out a complicated data entry form, save their configuration and then make it active. There are just so many interactions with the UI along the way, the chances that some flaky thing will happen to short-circuit the test are too high. Maybe one of the dialogs gets stuck, or a page gets stuck and doesn’t load. Given the sorry state of our test environments, this kind of problem arises every other test run, especially during periods of active and intense development. I won’t go into the details, but one of the systems that the application must interact with at the end of the long process for making a configuration go live is the bane of my existence. Imagine what it is like to kick off a test run that has a lower bound on it of ninety minutes to go from start to finish and it fails at the VERY. LAST. STEP. when that final sub-system in the whole pipeline chokes because of a common environmental issue.

The advantage of writing lots and lots of small tests that get into your app quick, verify a few small things and get out quick is that the chain of interactions with the UI is so much shorter. There are fewer opportunities for an unstable test environment to screw up your test results. And if a test does fail? WHO CARES. You just retry it a few times to see if it passes on a subsequent attempt. It’s easy to retry because this isolated little test lacks all those dependencies that a step in a fifty step end-to-end scenario would have. And why do you have to verify everything in one end-to-end chain? Why is it not sufficient to find a way to verify all the little steps in isolation? I’m not saying that you shouldn’t have some end-to-end test automation. There is a place for this kind of test automation. It’s just not terribly comprehensive. I know that sounds crazy. It’s an end-to-end test. By definition, that’s comprehensive, right? Nope. Nope. Nope. It’s anything but comprehensive. It represents one, very narrow and defined pathway through your system. If you want a comprehensive test suite and you want it to deliver results sometime in the next decade, you need a test suite that is composed of thousands of atomic little tests that are scattered across your system’s functionality.

This brings me back to the beginning — Why all these labels on the test cases? This is a way for categorizing all the tests so that it is easy to search for them. When you write a test suite of atomic tests, you will end up with hundreds, if not thousands of tests. Hence, you need to be able to easily find test cases. Second, these labels make it possible to dynamically specify at commit time which tests the developer would like to run. The end-to-end tests, given their limited coverage, long running time, and relative instability are not helpful for this scenario. The developer wants relevant, fast feedback. We also don’t have a giant Selenium grid at our fingertips, so we have to be conservative about how we use these resources. If there are eight commits in a day, the suite of end-to-end tests would overwhelm our resources very easily.

So, in short, if you are a regular worshipper at the idol of the end-to-end test automation god, you won’t have good automation. This god is a fickle liar who tucks you into bed at night with his minion, the Smoke Test Teddy Bear. Smoke Test Teddy Bear whispers sweet nothings into your ear, telling you if the end-to-end test suite passes, all is good. Don’t worry about the thousands of other possible user interactions with your application that it _didn’t_ cover. They are inconsequential seeds of evil doubt that the faithful believers must banish from their thoughts. Shut the closet door on those demons!

Share This:

Leading an Elephant to Water and Convincing Him To Drink It

Large corporate organizations move very slowly and if you are a creative type who hates to coast along on ‘good enough’, you are probably frustrated and demotivated a lot of the time. The modern corporate workplace is a graveyard of good ideas that were quietly drowned in a washtub behind the woodshed. To survive this emotionally draining dependence on comfortable mediocrity, you have to be _really_stubborn. I’ve been thinking over the origins of my greatest frustrations with my employer and most of it boils down to not being heard and having a lot of ideas shot down or otherwise smothered in a flood of boring, soul-sucking manual regression testing that crowds out all joy from the job. Sometimes, it seems that even just exploring or trying out a concept is offensive and upsetting to someone and therefore, It. Must. Be. Stopped.

In the interest of personal development and achieving greater success, I have to own my own part in this. My communication skills have been really lacking, and my messaging has been unfocused and too difficult to understand. I have also come to the conclusion that it is best to toil away privately on some ideas until you have something that can serve as a powerful demo before you reveal it to anyone. As part of my effort to resolve this conflict over the presence of lots of labels on Zephyr test cases in Jira, I actually developed a Powerpoint presentation to cover the problem statement, the challenges and the proposed solution. I feel like a little Agile warrior right now. I’m even thinking that this presentation could work as another conference presentation and I’m kind of excited about proposing it for some other conference in the future.

I saw a really great presentation by a developer from Uber at the Selenium conference in Portland last fall that summed up the kind of frustration that has generated my exit from every job I left that wasn’t due to a layoff or the sudden bankruptcy of the company. She said that most companies exist in the middling, unambitious area where there is no motivation or desire to do more than mediocre QA, but there are organizations where QA is a first order function and that the tools, processes and infrastructure are elite, top-notch stuff. Those companies are where future of testing is.

So, I could quit my job and go work for those companies, but the only problem with that is that I want to _be_ a trendsetter who brings that to a company that doesn’t already have it. I don’t want to show up late to the party after the waves of innovation have already passed through. Problem is, you can hardly be a trendsetter in the most common reality where you work for a large corporation that is in the mediocre middle because the scale of the task is so enormous that no one person can do it. This isn’t one of the lone cowboy kind of projects where one single heroic person toils away to solve the problem and emerges with a shiny, cool solution to the adoring cheers of their co-workers. This kind of paradigm shift takes coordination and cooperation across the organization and it tends to piss of a lot of people because it makes them uncomfortable, insecure and afraid. Lately, I have been having trouble getting buy-in just from my own little team.

So, I have to sharpen my communication skills. I have to learn more patience and I have to get my temper and frustration under control. And I need to start engaging a lot more with other people outside my own insular team.

Share This:

In Which I Pontificate On How a Billion Dollar Company Should Operate

I am anxious today. When we heard that we were going to get a QA director, I suspected that this would not end well for some of us. When I was called in for my initial one on one with the new director, I toyed with idea of just flat out asking if he was here to make some heads roll, but I figured it was pointless to ask this question. Either he was or he was not hired for that purpose and there was little I could say or do that would alter the eventual outcome. Generally, when you work for a department that is considered ‘struggling’ and The People Who Matter Club decides you need a ‘Director’ or a ‘Vice President’ or some other impressive title, you can expect heads to roll. They don’t want to do the dirty work themselves, so they hire someone else to do it for them.

The fallout happened a little at a time, but in hindsight it was obvious where this was going. There is a feeling in the air of waiting for the next shoe to drop. Not all of the fallout was involuntary. Nearly all the original participants in The Chosen Framework, V2, have departed to other teams within the company or for other employers. Those who transferred elsewhere within the company are working on their own automation frameworks, yet The People Who Matter Club still persists in the illusion that The Chosen Framework, V2, will somehow displace all other frameworks, despite our painful lack of resources to do any further development on it. There are days when I regret ever having contributed a single line of code to it because as one of the few developers left standing, I am under tremendous pressure to continue contributing to this project as well as dig our team out from under a mountain of technical debt with respect to the actual automation of regression tests.

For two years, we tried to communicate to The People Who Matter Club that we were not adequately staffed to do our jobs and that lack of communication between development and QA was a serious problem. And for two years, nothing really changed. We struggled to keep up with a never-ending avalanche of new features, the behavior and purpose of which were not well-documented and which were generally introduced to us for testing just before they were to be released. So, predictably, we were always scrambling and of course, always looking as if we couldn’t successfully locate our own asses. Our pleas for additional resources to handle the workload in addition to a sane SDLC process to manage it fell on deaf ears. Then, the new QA director arrives and does the blood-letting that upper management couldn’t bring themselves to do. He says pretty much the same thing that we’ve been saying all along for two years, except that The People Who Matter Club listen to him and now I hear them saying things like, “Hey, we really need a good SDLC process to manage new feature development and we really need to beef up the QA staff levels to handle the workload!”

There has been a lot of heat and fuss around the issue of ‘face time’ in the office. One member of The People Who Matter Club has made this issue a personal crusade and has identified it as a primary reason for the communication problems that have hindered the QA team’s ability to function properly. I could wallpaper the White House if I printed out all IMs and emails I have sent over the last three years that contained questions I needed answers to which went ignored. Silly me, I should have realized that it had _nothing_ to do with a lack of professionalism or consideration that has made it acceptable for people at our company to ignore their colleagues’ emails and IMs! If everyone just limited themselves to one day a week for working from home, the communication would be better! There is a mystical power that is activated when our butts come into contact with our office chair that erases communication problems in the workplace.

The edict came down that we were allowed one day of telecommuting a week. I have an arrangement to work from home 2 days a week for my own personal reasons which so far has not been rescinded, but I am sure it is causing a lot of resentment from others who do not have this arrangement. The fact is… I don’t want to travel into the office 4 days a week. Neither does anyone else. The lack of flexibility with telecommuting is a _huge_ source of complaints at this company. Traveling to and from work is a giant pile of stress and annoyance in this region because There Is. No. Fast. Way. To. Do. It. Traffic is horrific. Public transportation is crowded and slow and increasingly expensive. Imposing the requirement that employees must be in the office means they must devote 2-3 hours of their day traveling. They lose sleep, time with their families and they have to endure stress and frustration to make this trip. All because it supposedly makes communication and collaboration better.

I am not a member of the People Who Matter Club, so my opinion is worth jack, but I going to soapbox it here on this little blog. I’m going to let y’all in on a secret. The benefit of face time in the office for technology workers is overrated. Want to set your company apart and attract a high quality workforce? Let your people telecommute as much as they want. People who are driven to be excellent do not need to be face to face with one another to collaborate or communicate effectively. Good collaboration and communication are personal and individual traits of the employee, not of their physical location. I will point to some of the most successful OSS projects as an example. These projects are developed and managed by people who often never see each other face to face. They often live on different continents. Granted, the class of developer who achieves a role of influence in an popular OSS project is usually a developer of elite caliber, but isn’t that the kind of developer you want? Why pay for all this real estate to house employees who would rather work from home?

So, members of the People Who Matter Club, to close this roundabout post, I want to get back to the issue of ‘communication’. If your rank and file has been screaming for what they need for two years and you hire someone to come in, chop off some heads and then say Exactly. The. Same. Fucking. Thing. only to be treated like a genius for figuring out what the issues are, you might want to take a look at your address. Because, you’ve just bought one of the most expensive houses in Asshole Town.

Share This:

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: