During my career as a Quality Analyst, there were times when I felt like I had plateaued in my usefulness to the team as a QA. Get a story, test it, and try to automate as best you can; I felt this was all I could do. In order to get myself out of this situation, I developed a few techniques that I try to blend into my day-to-day activities to keep myself as best placed to help as possible. These are not automation tools. Nor is it technical advice. There are plenty of great articles out there for that. By following these fundamental steps, I believe you will demonstrate why your perspective makes you a unique and valuable member of the team.
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.
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.
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.
Keep on worrying
It 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.
If I am lucky, my biggest worry might be how our system would hold up in a zombie apocalypse.
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 you
I 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 wrong
Unfortunately, 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.
My take away
After realizing that I had reached this rut in my career, I initially looked for the newest technologies or trends that I can learn to bring to the team. However, after really digesting my strengths and weaknesses, I really discovered that it was the unique thought process and viewpoints that a Quality Analyst brings is what helps the team the most. I think this is just a small part of why the role of QA is so important to an organization.Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
