Covid-19 or Coronavirus.
I am writing this as I am sitting in house quarantine.
Based on the criteria set by Local Authorities given the outbreak of Covid-19 better known as the CoronaVirus, I have to stay home and away from the public for at least 2 weeks (ending this coming Wednesday). This is because I took part in an International Conference during the last 2 weeks.
Do I think I have the Coronavirus?
I am 99.99% sure I did not contract the virus. I feel fine, I do not have any symptoms, washed my hands constantly during my trip, and even used a mask during my flights as a precaution (I’m not going into how effective/ineffective masks are in this post!)
But still, I need to comply with what my Country defined as precautionary practices.
Not because of me. As I said, I am almost certain I do not have the virus. But because of all the rest of the people who were also told to stay at home and keep a safe distance from the public, and the small number within them that have the virus and are still not showing the symptoms.
Rules are not here to be liked, they are here to protect us from ourselves and others.
Do I like it here?
Sure, Home is a relaxing place to be.
I also get some quiet work time (when the kids are not around).
But I do not like being forced to stay here for so long.
The rules keeping me here are not in place to please me or to make me happy. They are here, in this case, to protect everyone else from my potential virus.
This is just as the rules about drinking and driving are there to protect all of us from dying at the hands of a drunk driver. Even if the guy who had 3 beers and feels good enough to drive may see this as an unnecessary inconvenience.
Rules are here because society places the benefit of All on top of the comfort of the Individual. And so it should be, at least in a civilized world.
The same should apply to the rules in Software Development and Testing.
How many times have you heard someone asking to push a small change to production without going over proper testing?
I love it when I get told that “it is only a minor change and that it cannot harm anything else in the system”.
The fact of the matter is that most times this is true. The change is really minor, and when reviewed properly we can see that it does not harm anything in the system.
But the rules to perform this review and the necessary tests are not there for the 95% of cases when the small release is harmless and correct, they are in place for the 5% of cases when we find something the developer missed. Something that might cause an interruption in the service, issues for the customers, and loss of business.
Rules and protocols are there to protect ourselves and most importantly our customers and users. To protect them from the harm that may be caused by inadvertent mistakes made by our team – even if this may potentially happen with only 5% of our cases or less.
A simple 5 min meeting can help to evaluate whether we need to test a little or a lot.
Let me give you an example of the protocol we follow internally at PractiTest.
Whenever we have a new feature we start by deciding up front, during the assessment phase of the user story, if we will want to have someone specialized to be testing it from start to end. We will do this for features that are either large, or small but with a high risk potential to either add big bugs or important bugs to the system.
If we did not choose to have a dedicated tester on top of the feature, we will still do a review once the development is done for it, to evaluate what additional tests we want to run on it.
Obviously every release is reviewed by other developers and we run a bunch of static and dynamic tests via our CI. But here we are talking about additional tests to be conducted by someone else in the team that was not involved in these specific development efforts.
We will review what dept of testing and a range of initial scenarios to be run. They can take everywhere from a couple of minutes to a couple of hours, and after they are done we will do another short meeting to either agree we have enough information to release the feature or choose to continue testing additional scenarios.
As you see, we do not need extensive protocols and sign up meetings, but we do want to be able to evaluate and make an educated decision before we automatically release something to the field.
Rules need to be correct and intelligent, not liked by all.
It is important to still be critical about rules. They need to be cold, calculated and intelligent as much as possible; and not hysterical and counterproductive.
The fact that someone decided to put a rule in place does not automatically mean that the rule is correct. We all need to be critical of the rules we put in place. We need to understand what they are protecting, and how. Under what cases will we use them, and how to apply them to all or as many cases as possible.
It is important to make them self explanatory, and in some cases, we’ll need to explain why they are in place.
Rules will not be liked by all, and they will be especially disliked by the people who are limited by them.
But after all, we need to understand that these rules, being there in Software Development or Disease Control, are there in order to protect the many even if it comes at the expense and inconvenience of the few.
What test case management rules to you have in place? Did you instate them? Do you begrudge them, or think they are pointless? Or do you have a great story about a big issue that was caught and contained thanks to a specific protocol you have in place? Please share here in the comments, I have the time to read them 🙂
From my side of these current rules, I am counting the days until I can finally get out of my house.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.