Service Quality Model (SQM) and Software Testing

ServQual model
One of the models I cannot forget is the ServQual-model (*1) . It has been thought to me on school were the focus lies more on measuring the quality in providing services. In my opinion one of the strengths of this model is visualizing the possible Gap’s which might danger the quality of delivered services.

Wikipedia: SERVQUAL-model : "It measures the gap between customer expectations and experience."



The Five Gap’s explained
GAP 1 – difference between consumer expectations or quality determinants, and management’s perception of such consumer expectations
GAP 2 – difference between management’s perceived quality determinants and service specifications (i.e., the critical-to-quality specifications)
GAP 3 – difference between quality specifications and actual service delivery
GAP 4 – difference between actual service delivery and the company’s external communications about services delivery (e.g., word of mouth, past experience, promises, reputation, standard of care)
GAP 5 – Difference between expected service and perceived service

The difference between perceived service and expected service is a function of four different gaps GAP5 = f{GAP1, GAP2, GAP3, GAP4}

ServQual model in Software testing
To me this seems similar what we are doing during testing. Normally in software testing we refer to development models to fit our process to the development process. If we approach software testing also as a service and tune the model a bit towards system delivery we might come up with a model like shown below.



The five Gap’s for software testing
Gap 1: User Expectations - Management Perceptions Gap
Gap 2: Management Perceptions - System Quality Specifications Gap
Gap 3: System Quality Specifications - System Delivery Gap
Gap 4: System Delivery - External Communications Gap
Gap 5: Expected functionality- Perceived functionality Gap (or the System Performance Gap)

Challenging the Gap’s
As in software development we have already methods and tools to measure these gap's and control those. So there is nothing new here. What might be new is that instead of keeping the information within the project you bring them to the business. You make your project more transparent by translating development into provide service from the project.
Assuming that these Gaps’s cannot be avoided, transparency can help to increase the level of acceptance by the business.

Examples of activities measuring the Gap's
Gap1: As you see that the distance between the start and ending point is large customer involvement should be allowed and increased. This will help to identify differences in expectations of users and project management. Also a process of defining SMART requirements which fit's to the development approach should be established.
Gap2: Measuring the translation of requirements into written functionality should be one of the basic activities of testing. Only most of the time we avoid the reviewing process of requirements and designs. If these processes are in place we log issues for it when there is no match or functionality is unambiguous.
Gap3: Measuring requirements to delivered functionality is on basic activity of software testing. Here we actually executing test cases on the system to check whether it match the written expectations.
Gap4: This is one of the gaps we usually forget to manage. Only this might be one of the important ones when you check the relations to other activities in the model.
Gap5: Often we see this gap be controlled by performing the user acceptance test. In my opinion these activities will be strongly influenced by other activities from the model. Therefore this might not be sufficient.

Lessons we can learn from this model
1. Business involvement is very important and should exist during the project
2. Requirements should be reviewed and omissions should be communicated not only to project members. Also if some requirements will not be met, inform the business to change their expectations.
3. If issues are found, be honest about this towards the business. Explain what you are going to do about this and when. Every system has its failures, business can understand this. You might use the approach to solve this to build on the confidence of the users. They will be able to match the gained functionality towards their needs. It will also help to manage their perception about received functionality and by being transparent, their trust might grow and they might forget about negative experiences from the past.
4. Transparency should be their. Don't undervalue the power of word-of-mouth communication when users are involved in the project and they are not being heard.
5. Keep track of changes in functionality and also of communication. Perhaps start also maniging your workarounds (see: Start managing your Workaround's!)

For sure there are other things we can learn. Perhaps you can come up with some things. Just keep in mind that this model has its strengths and weaknesses.

(*1) Parasuraman, A. Valerie A. Zeithaml en Leonard L. Berry (1985) "A Conceptual Model of Service Quality and Its Implications for Future Research", Journal of Marketing, volume 49, Number 3 (Fall 1985), p41-50