Keep on worryingIt is a part of a QA’s daily life to be focused on what could go wrong. This can become all-consuming. It was for me. It gave me a very negative persona. I would be up at night worrying about what would go wrong tomorrow.
I don’t necessarily think this kind of thought process is bad. In fact, I think it is one of the most valuable viewpoints a QA can add. But I realized I needed a way to harness this behavior that would both maximize its value to the team and allow me to live my life outside of work. I came up with a solution that I call 'My Worry List'. It works like this.
Each night, before you go to bed, reflect on your day’s work. Try to identify the three things that worry you most about your project. The criteria involves combinations of severity and immediacy. One example is how our system would react if a third-party vendor goes down in production. After seeing some odd behavior when a simulator went down, I started to question our third-party resiliency. Another day I was reading about SQL injections and began to wonder if there might be SQL injection vulnerabilities in our code.
But whatever your top three are, write them down on a sheet of paper. Then forget about them and get some rest.
In the morning, before heading to work, grab that piece of paper and carry it around with you all day. Make it your goal to try to prove to yourself that you shouldn’t worry about these items. Sometimes, you can do this simply by asking questions. Often it will involve designing and setting up an automated test framework that reassures you that this item won’t ever reappear on your list. Whatever the issue, try your hardest to ensure that is not on your list for long.
Pay attention to what is happening around youI believe, usually, when things go wrong, there were warning signs that went unnoticed. That’s why it pays to track when something breaks in another part of your organization, that typically your team would not be concerned with.
Often, when there’s a problem in one area, it’s only a matter of time before your area encounters the same issue. If one area gets affected by a security vulnerability, maybe your area just hasn’t been targeted yet, despite being equally at risk. If there’s a deployment issue found in someone else’s application, maybe there’s something wrong with the server infrastructure that will hit your application the next time it’s deployed.
Don’t ever think of what you are doing as being in a sandbox. First of all, there may be people playing in your sandbox that you were not aware of. Even if they aren’t, others may be operating in very similar environments that are just starting to expose issues you’ve yet to uncover.
You may find it helps to take note of when someone asks if you know anything about an issue they’re having. Maybe a build pipeline is broke, or they’re experiencing an unfamiliar issue on one of their servers, where they’re unaware of any changes. These might be clues to a potential future issue. If they are asking about your area for the first time, maybe there is a new integration point that you were not aware of. Maybe your area has impacted them several times in the past and while the issues resolved themselves without your intervention, there may be something that can be done to resolve it permanently.
Keep notes when something goes wrongUnfortunately, sometimes, when things get hectic, people's recollections of the details and the timeline can become vague at a later date. By keeping accurate records—of what went wrong, when it was found, when it started, how the issue was found, and when it was resolved—you’re less likely to miss important details.
I’ve found many retrospectives lose their effectiveness because no one really remembered the exact series of events. By having a detailed list of what happened, your retro can avoid being about the big problem and focus on the series of events that led up to the problem and the subsequent events during remediation. Knowing how to ask the right questions can also be a sign of a good leader.
It is not just about the bad things. What some will forget is it’s often the things that we did well that gets lost in rush. Maybe someone detected a problem before it ever affected a customer using a new production monitoring system. Or the path to production has become so efficient, that after solving the problem it only took a short amount of time to get it deployed.