Clients are not QA
We’ve heard stories and spoken to new clients who have been treated a little unfairly by their previous developers who for some reason seem to think it’s ok for the client to be the quality control for an IT project.
Any reputable development team should have some form of formal testing processes and quality checks before a project is handed over to the client for review or User Acceptance Testing (UAT), regardless of the development methodologies employed.
It may be tempting to push the project out to meet deadlines but ultimately this pushes out the project’s overall timeline and wastes the clients valuable time.
Now we understand that issues and bugs are part of the normal development process and that not everything is going to get picked up during formal testing, but we should do our darnedest to reduce the amount of issues that a client might encounter.
The client won’t feel so confident if some really obvious issues crop up. They end up wasting their time in logging the issues, waiting for you to resolve them and then having to spend more time retesting.
A formal process will set you free!
Years ago when we noticed a few quality issues getting out to our clients, we took the quality assurance approach to fixing it. We asked ourselves “What is wrong with our system? What is it about our procedures and processes that lets this happen?”.
In short, we introduced an extra check point in our testing processes and we have seen greater success; less issues being reported and greater customer satisfaction.
If it’s not part of your teams mantra, then we recommend you add this line to your golden rules – “Clients are not QA!”.