So basically in my city, whenever there is heavy rain or thunderstorm or lightning, there is a message 2-3 hours before, from the National Disaster Management team to all the people, and because of that, people leave the office immediately. However, in such cases, if something is urgent, then people have to finish it after reaching home, else it will be postponed to the next day.
And yes in such cases it take around 2-3 hours to reach home which is more difficult than the testing task.
Are you asking how we think about these events when designing tests, or how we physically test for these types of events?
I think I can answer the first part, and that is, we donāt. Or at least we donāt initially, but we learn and bring that learning into the next time we design tests. Just like airplane safety, every time something bad happens, a lot of time is taken to learn the lessons and then, most importantly, apply that learning to the process.
I think nature always have its own plans and works on its own terms ā¦no matter how much humans try to predict, control, or test things there are always forces bigger than us that are usually playing ⦠what we can do best is study patterns, n prepare for possibilitiesā¦But absolute controI is Impossible.
Rare atmospheric events, like storms, sudden bad weather patterns are good reminders of that humbling truth.
Even with all our science, technology n even satellites sometimes all we can do is brace, adapt, and recover..
I think a power cut can count as a thorough Disaster Recovery Test. Maybe we could offer our Testing skils to analyse, design scenarios, test for disaster with our local governments, no?
First of all you need to understand what you are testing for. If there had been ārare atmospheric phenomenaā then finding out what they were and how they may influence your SUT. But as I understand āthe rare atmospheric phenomenaā is a story that was reported in many trusted media, but is actually not true. The lesson to learn is to always consider, if the world could be different than what you have been told, have found out and/or believe. And always remember that your software has to survive, not just in the world delimited by the requirements, but also in the physical world, the social world and the the world of users. You need to always need to consider what can happen: network issues (from the local internet being locally down to the speed of lightning changing) and other physical issues. The same applies with social issues, the requirements may change or cloud computing may be globally outlawed. And the same: what if the user just interprets your UI in a very weird way. You should consider far out and more realistic external conditions and make sure that your software can handle it OR SOMETING LIKE IT. And the last bit is important, because it is within the software you need to ensure resilience against both known and unknown future problems - donāt think you can predict external events: you will never be a good enough meteoroligist to predict the weather, but as a QA you may harden āyourā software enough to handle whatever comes or at least avoid physical and reputational damage.
I believe we should approach this from a more abstract perspective. We are dealing with a complex system composed of many individual components. Since our system performs a critical function, it must be designed with robustness in mindāmeaning that the failure of individual components must not lead to a complete system failure.
Therefore, a key objective of effective testing of such a system is to deliberately trigger the failure of various components and analyze the resulting system behavior.
In my experience, the best narrative we can give higher-ups is to discuss system resilience and recovery times. What is the risk appetite for being out of business for 10 hours? Or that all employees has to work from home due to bad weather. or that staff are at work, but cant get home. How quickly do we want to recover and what impact does it have on the running business.
This can be a (EU NIS2) regulatory issue, but might be handled elsewhere in the org. But if you, as a tester can contribute, itās quite an interesting field in the intersection of compliance, quality and security.
From then on we can design a ātestā that our solutions to the event above actually works. We can throw a disaster party as pr below.