Should we test for serviceability?

What is serviceability? Before coming to the answer let’s discuss the context a little bit.

We often put lot of emphasis on building the software with highest quality. Quality as in the ability to provide the intended function. However we often neglect the maintenance site of the software. How fast we can detect an anomaly? How conveniently we can collect stats? Instrumentation and logs? Alerts? No matter how good the software is, we must always make sure that the serviceability is high in our deliveries. 

See below illustration. It clearly segregated the serviceability from the application quality. However both matters for the end user. 

So the question is who is going to validate whether the application has adequate level of serviceability? One can argue that it must be done from the service teams. It is correct for a certain extent because certain application level monitoring is configured by the service engineering teams. Still there is lot to be done from the software engineering front.

If the mean time to resolution (MTTR) of an issue is high then obviously the software is low in quality no matter how good its functional acceptance by the users. Therefore it is high time to think from both functional and serviceability angles because end of the day what matters most is how quickly you can respond to an anomaly (once of the software is accepted).

I think it is within the Quality Engineering function to validate the required level of serviceability. If the software is not adhered to the defined level of serviceability then it must be recorded as a risk in the risk register of the project. Underlying point here is that, all this contribute to lower the MTTR of an issue and on another side helps to get health reports and usage of the application.

Let’s keep things very simple. Just think about how you can reduce the MTTR of your application as a QE objective. That is all you need to do.

Note: Serviceability may have been explained differently in certain sources.