Good morning again. This is one of the reasons I am sad to not be in person at PNSQC. Paul and I go way back, and I always have fun when I hear him speak. We frequently bond over our love of music, especially heavy metal, so Paul, just know that I'd be bending your ear if I were there ;).
How many of us know what a Pyrrhic Victory is? Pyrrhus of Epirus is famous for winning battles with absolutely dreadful losses, so much so that the term "Pyrrhic victory" means a win that comes at such a great cost it's arguable if it was actually worth it.
PNSQChronicles Podcast previewing the details of Paul's talk
AS testers, we are often asked to "do the right thing" (a Spike Lee joint ;) ). For the few of you out there who chuckled, you're my people... I love you :). Automation is something that has a specific purpose. We can argue all day long if that purpose is actually needed or necessary, but for many of us, our jobs would be rendered very difficult without it. We all do some form of automation if we have done something enough times. That's often the first wave of automation, the "Oh my stars! If I have to do this process one more time by hand, I'm going to lose my mind." I'd argue that the people who are least fond of these steps are probably the ones who will embrace and get good at automation the quickest.
In this current age of AI, we have a fresh new danger. AI can write all of the tests and even the test code for us. In truth, it can. However, if we think that we are going to get "one and done" tests that will be resilient, durable, and effective over time, there may be some surprises in your future. In my last gig, I had the experience of doing both roll-your-own automation and working with AI to write the test code and run it. As I was working through those processes, I came to a simple conclusion. The time to have a vetted and confirmed version of automated tests that AI generated vs. tests I created myself... was roughly equal. That's not to say that I'm some amazing automator (I mean, I know some stuff ;) ) and no question, AI can crank out code so much faster than I can. Still, when I question the code and ask why it's doing what it does, the rounds of revisions to get to a truly working and robust version of tests, at the end of the day, were roughly even.
For those who know how I do these, I'm writing this as I'm listening to Paul, but I'm not going to regurgitate his talk. I am going to consider what he is saying and apply it to my own experiences and see what rings true and what I might learn something fresh from. There are absolutely costs associated with using AI, even if it feels like it is cranking stuff out that feels fast, fresh, and amazing. One of the projects I worked on was to take our Documentation as published and make an analysis gap of what tests we had and what options our documentation was saying we did. While I will not claim that's the be-all and end-all of what should be automated, if you want to do an interesting exercise, I recommend doing that process. You can do it all on your own, or you can run it through AI, but either way, it gives you a simple place to start. Do we stop there? Of course not, but at the minimum, you can say that you are making tests that at least cover the areas that you would want to encourage your customers to be doing. Start with the happy paths and then look for the areas that could trip you up. Look for the error code that exists, and then try to create tests that surface all of that error code effectively. Again, whether you do that as a roll-your-own project or you turn over the considerations to Claude Code, OpenAI Codex, or some other AI methodology, ultimately, we want to know what's happening and why.
As a musician, I have many tools that are at my disposal. I use Digital Audio Workstations to do actual recording; I use multiple amp sims and effects that are built into plugins, and I have lots of virtual instruments (even singing voices) so that I can experiment with various things. Some people might remember the early 80s and the advent of MIDI and sequencing software. I remember well the antipathy people had toward MIDI back then, and the feeling that "people were pretending to be musicians" by using MIDI and sequencers. I'd argue that any performer who chose to bring MIDI onstage in those days and orchestrate all of that in a live performance was a braver soul than I. It was easier, in my mind, to just perform than try to wrangle all of that stuff in real time. I remember the snide remarks coming from the metal community especially. The irony is that, a couple of decades later, you would be hard-pressed to hear a metal album produced today that isn't using all of the software recording features that exist today. The beat alignment to the grid and the level of precision that is orchestrated at the point of recording is absurd now. Is it easier than performing it? It might well be. Is there still a performance to be heard there? That's another question entirely. If we are going through and we are massaging every guitar part with quantizing, aligning every beat to the grid, and using Melodyne to clean up every vocal note's tuning, what we end up with may be a pristine recording, an elaborate artifact, but we can't call it a "performance".
To borrow from Jurassic Park, sometimes we get so caught up with what we can do that we might lose sight of what we should do. Knowing when those two options align, and when they don't, is the big thing. I wish I could be there in person to riff with Paul about this, but I hope he enjoys this rambling missive in the meantime :).
No comments:
Post a Comment