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 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.