Chris McMahon's Blog

There was a thread on Twitter recently from people who caused major problems in software systems, and I was reminded of the worst bug I've ever seen. Long ago I had published this story with a major tech media vendor, but that article seems to have succumbed to bit rot, so I am going to tell that story here. It happened more than twenty years ago when I had only been in QA for a couple of years, but it is seared into my mind... In the late 1990s I worked for a company that handled 911 land line location software for major telcos. So when you choke on that chicken bone and call 911, you can't talk but they send the ambulance to where you live anyway. We handled about 75% of all the telephone numbers in the USA. So from time to time in those days, there would be an area code split, where a new area code is added to a populous area and phone numbers start getting the new area code where they had a different area code before. In the 911 world, we would maintain records for both old

It often happens that someone creating automated testing programs using Selenium or a similar framework that controls the UI (User Interface) eventually finds it necessary to address a non-Selenium API (Application Programming Interface) of some sort. You might need to create, update, or delete test data. You might need to modify a system setting. You might need to determine the current state of the system. You might need to have your test send or receive a signal from some other part of the deployment process. Often the only way to do these things is through use of an API. API Defined An API is a relationship between a client and a server. The server controls some aspect of the system, and the client wants to see or change some aspect of the system that the server controls. Selenium-webdriver itself operates as an API. The server for the Selenium API is called WebDriver, and WebDriver exists only on the browsers that Selenium is automating. Your script controls the Selenium client tha

Real paella is made in one pan. This recipe is "fake" because the seasoned rice is prepared separately from the other ingredients and added at the end. The advantage is that we can include a bigger variety of fresh vegetables. Feel free to vary the amounts below for your own taste.   Invest in preparation. Once you start cooking, this process goes very quickly. Seasoned rice: 2 cups long grain white rice. (I like jasmine rice, but any will do) 1 spice bottle of saffron (about 1 gram, get the biggest amount for the least cost you can find, more is better) Dried oregano, a healthy shake Cumin to taste (I go easy on cumin, too much smells like armpits) Black pepper, just a bit  Meat and seafood: 1/2 pound or more savory sausage links, like spicy Italian, Andouille, or Spanish chorizo, cut in thin medallions (Note that sausage is required because all the other ingredients rely on a little sausage grease in the pot. If you omit sausage, add a little oil to coo

These are three of my favorite large scale recipes. They all feature complete and concentrated nutrition. They all involve a significant commitment of labor and time, so I learned to make them in large batches. Also, they can all be made in a concentrated form, and reconstituted at serving time by adding water. The marinara and green chile are particularly amenable to freezing and refreezing over and over. Enjoy... Marinara: 5-6 pounds fresh red tomatoes (or more), diced 1 head garlic, skinned and crushed 1 small yellow onion, diced 4 oz fresh basil, diced 4+ oz grated fresh parmesan cheese (optional, see vegan note below) 1 or 2 small cans tomato paste olive oil dried oregano to taste black pepper to taste salt to taste Dice the onion and crush or dice the garlic into a large pot. Cover with olive oil and cook until onion is transparent. Dice the tomatoes and fresh basil and add to cooked onion/garlic. Stir. Add tomato paste, grated parmesan, oregano and black pepper.  Simmer at least

Like any recipe, you can tweak this for your own situation. First, you need a shared test environment to work in. I recommend beginning with a persistent test environment intended to model your production environment as closely as possible. While you may eventually evolve the ability to share a test environment with commonly-configured VMs or containers, having a persistent shared test environment at the beginning gives everyone the experience of keeping something running that looks a lot like the production system. (TOAD! DevOps!) For that matter, proper use of feature flags and such could make production itself a perfectly fine shared test environment. Sharing the responsibility of keeping the shared test environment up and running and valuable is a big part of understanding the value of the recipe. Second, you need some end-to-end tests (Testing!) to run against the shared test environment. You need to set up test data, tear down test data, type the typies and click the clickies

TOAD is Testing, Observability And Devops. We think these three things are related. What would happen if we took each of the three aspects of TOAD and put strong emphasis on each in turn? What happens if we take our testing effort as far as it can go, and "dial it to 11"? Observability to 11? Devops to 11? The meaning of "dial to 11" will be different for different organizations: it might mean hiring staff, or investing in tools, or even just emphasizing the mission more than before. If we dial testing to 11, I think two things will result. For one thing, the number of observable incidents in production will likely go down, because the emphasis on testing means that more problems will be found and fixed before deploying to prod. I also think that rate of deployments (Devops) could potentially increase, because the decrease in observable incidents will make deployments safer. So: increase the T in TOAD to decrease the O and increase the D. With testing at 11, no