This is a scenario that’s all too common: The product gets released and then a serious problem is discovered. You think, “That couldn’t have been caused by me”, but then you realize that it was. After you’re done beating yourself up about the mistake you should ask yourself this question next: How can I prevent this problem from ever occurring again?
If your answer is, “be more diligent in the future” or “don’t do that”, bzzz, wrong answer. That’s not good enough. It allows other employees to make the same mistake in the future. If your answer is, “update the documentation to say ‘don’t do this'”, bzzz, wrong answer. If this mistake can take down an environment, it’s too risky to assume someone will read the documentation to avoid this in the future. Don’t give someone the opportunity to miss this information.
You should make it so someone can’t even make this mistake in the future. Can you change an API so you can’t make this mistake anymore? e.g., if you accidentally called method(String param1, String param2) like this, method(param2, param1) you can prevent this error in the future by using different types on these parameters so you can’t mix them up. For example, method(Param1 param1, Param2 param2) . Now if you swap the parameters, the compiler will catch it before you take down a site. If you can’t do that, can you write an automated test that will discover the problem before it gets released on production?
You should definitely put this in the QA test plan if it exists, but in my opinion that is not sufficient. To err is human. QA is just as busy as you are. It would be much better if you can automate a test to make sure the problem isn’t happening and think of QA as backup.
The main takeaway is that bad things happen, but you shouldn’t let them happen twice.