What is the worst thing that could happen?

If you are a tester you probably routinely look at software or a system and try to determine what is the worst thing that can happen? What if there was an alien invasion, or if the server overheated due to a defective cooling fan and the redundant fan failed also? What if all of the nodes in a cluster fail except for one? What if the datatype in the code can’t handle the size or the type of data stored in the database field that it is reading from?

There are so many scenarios to think up and so little time to test them all that you need to focus energy where it is most beneficial for the customers. I can say that prior to this week I have rarely seen a case in my almost two decades testing where the application couldn’t handle data from the database. Typically the database is more restrictive than the application or exactly matched, not the other way around where the app is more restrictive than the database.

How do you even test for that? The answer is that you cannot always do it. Can someone test for it on the team? Most certainly, down at the lowest level in the application, the code, is the best place to test boundaries, to model production data and then try the average data, then maybe even add a factor to it in order to check that there is some growing room. Is that factor 1.1, 10, 100? It all depends on your system and the expected growth of data over the period of time that the application is expected to go without updates to specfically address size or compatibility of data between the application and DB.

Can a tester assist with this data model from production to determine the average dataset and the growth of data in the application over time? Yes they can and they should so that they can use that information to better understand the customer and their usage and also to ensure that the application can scale and remain performing to expectations and also reliable. Testers should also share this information with others on their team and even all the teams, because the more that everyone knows the more that they can add code to protect against certain exceptions or take into account this information to bolster the design or implementation which leads to a better product in the end.

So next time you have the chance to talk about some new feature or changes to an existing one bring data and have a discussion about the customer, how they will use it, and how much the data set will grow over a period of time and how the performance or functionality may be impacted by this growth. The more we ask what is the worst that can happen with the whole team, the better software we will build and the more reliable and performing it will be even in adverse conditions.