Archive: April 2016

Forehead Slappers Abound

Today, I am shocked, humbled and appalled. Let’s deal with the shocked and humbled emotions first. The QA Superstar of our team, whom I have blogged about previously emailed everyone asking for statistics by each product they are responsible for: how many manual regression tests, how long they take to execute, how many automated test cases and their running time. One of the junior engineers I mentor mentioned that QA Superstar took one look at her accounting and said flat out that we needed more people. When I saw the super engineer’s report, my jaw nearly hit the floor. She has been handling seven active projects and a eighth one is just getting started. She is also working towards a Master’s degree and has to travel to another state once a month for this program. She never complains about her job or how much work she has, unlike the rest of us. She is not a horn tooter either.

Guess who didn’t get a ‘Far Exceeds’ rating for her performance review this year or a promotion to senior level? Principal SDET’s junior minion, on the other hand, got the ‘Far Exceeds’ rating and is probably going to get a promotion and a nice fat raise. He is bright and talented, but I don’t think he ‘far exceeds’ anything. He has not written a single test case for his projects. Nor does the automation he has written cover very much of anything. It never ceases to amaze me how little management knows about who is doing what and how much they are doing. Principal SDET and her junior minion work with an insular group of developers and it really seems obvious to me that they have all formed a mutual cheer-leading squad that is all about pumping each other up so they can get promotions and raises. If I were a manager, I wouldn’t trust anything people say about each other if they are constantly locked in a mutual ass-kissing embrace. Maybe my emotional intelligence and bullshit meter are just more finely tuned than most, but somehow, I don’t think so. I just think management in this particular organization isn’t very perceptive.

Now, on to why I am appalled. Today, I learned that one of the release engineers has been granted the privilege of full time remote employment. This is the second person from the release engineering team who has been granted this highly desirable privilege. He is moving to the Midwest to be nearer to his friends and I am honestly happy for him. He’s a nice guy and very conscientious about his job. However, there are several other employees who asked for full time remote employment who were denied. I am somewhat surprised that two members of the release engineering team were granted this privilege given that they are responsible for maintaining and servicing the two of the most critical systems for our organization like the build system and the source code control system. If either of them goes down, development and testing for hundreds of engineers on both coasts and in several foreign countries comes to a grinding halt.

The other employees who were denied the privilege are not responsible for anything that is even close to that level of critical impact. The one obvious difference between those who were granted the privilege and those who were denied it is gender. The two employees who were given this privilege are men. The three employees who requested it and were denied are women, all working in quality assurance, which is overwhelmingly skewed female. So, basically, male employees get the freedom to relocate to places where the cost of living is much lower while still earning a nice fat urban salary where their commute amounts to a 2 minute walk to their home office, but the women who asked for it have to be content with the oh so generous allowance of one day a week in which they do not have to burn two or more hours a day traveling to and from the office? My two day allowance was treated as it was a monumental favor. I am _grateful_. I personally have not requested full time remote employment. But the way in which I was told that I was being granted an exception to the rule was so patronizing and paternalistic.

Did I mention that the two employees on my team who were fired in the blood-letting recently are women over fifty? So, it makes me wonder if the junior engineer handling SEVEN. FUCKING. PROJECTS. BY. HERSELF!!! was not given an amazing performance review with a promotion because she is a woman whereas the junior engineer who did get the amazing performance review and likely promotion got it partly because he is male. There is of course, the mutual cheer-leading squad arrangement that definitely has something to do with it, but the gender difference keeps nagging at me. It hasn’t escaped my attention that the replacement for my boss who was fired two months ago is a man. And they hired a man for the QA director role. This company is literally swimming in strong and capable QA managers who are women who could have been masterful in that role. I know because I have been interacting with them over the course of the last year as I tried to master more and more of the domain knowledge I need to be effective in my role. Quality assurance is a profession that is dominated by women. But, when it came time to hire a director, we just _happened_ to end up with a man in that role. In a company where most of the managers and executives are men.

One of the women who left for another job in the last year told me a very interesting story trying to get approval to go to a conference related to her job function. The process is full of red tape annoyances, but it’s supposed to go through the employee’s manager and their manager’s boss. When she initially requested permission, her manager, also a woman, didn’t know anything about the conference, but started asking questions to determine if it met the criteria. Somehow, her boss got wind of this. This individual whom I christened as ‘Sir Architect’ in a previous post about the Framework Wars did not go to the employee’s manager to discuss the conference. Instead he went to one of her male peers and asked whether of not the employee should go to this conference. Sir Architect, leader of the effort to redesign our platform from scratch, also had full time remote employment while he worked with the company.

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: