Empowerment of SQA
Sajjadul Hakim | Sunday, 15 June 2008
IN most cases, if there is a so-called SQA (Software Quality Assurance) team in a software development company, they advocate SQA empowerment. If some are not vocal about it, they probably are de-motivated about the fact that they are not authorised to fulfill their quality assurance duties. Usually the primary job of this team is to do testing, but most have the assumption that they were put into this job for a more divine purpose, i.e. assure quality. Things get worse when they are not given the authority to control software release management, feature management, process management etc. In this situation their decision are usually vetoed by the all powerful project managers and superiors.
What is wrong with this scenario? Is it really possible to assure software quality by an isolated team with a biased perspective? Is the perception of quality the same for all organisations or even within the same organisation? The quality attributes upheld by an organisation developing open source applications may be very different from those who don't do this. The process and priorities for developing a social networking application can be quite different from developing a healthcare solution. Sometimes it may be more important to ship a buggy product out the door so that you don't lose out to competition. Does Windows 95 ring a bell? How about Windows Vista? The fact is that the perceptions about quality differ depending on your role in the organisation. Some may be concerned with quickly delivering the next great feature that is a good selling point, while others may be worried about the difficulty of using them. Some may be disturbed by the nitty-gritty production process that is going wrong, while others are anxious to give priority to the needs and issues of the builders over the process itself. They all have a point. Quality is actually a relative term that Jerry Weinberg defines as "value to some person". What is required is for everyone in the production process to work together and make a combined decision about the perceived quality of their product.
Now getting back to the SQA team. If they are empowered to make critical decisions that impact the future of the product solely based on their own understanding of quality, then there may be consequences. Software development is a complex process that will probably never get any easier. SQA people may not have enough knowledge about the sales promises, technical complexities, available resources, project expenses and many other factors that make up the software development ecosystem. They may not even have the experience or knowledge to understand the intricacies of these factors. The SQA team can never assure quality alone. Hence the name of the team itself is inappropriate and misleading. That being said I have no issue with a team calling itself an SQA team. However, I do think it will be naive of them to think of themselves as the guardians of quality.
I myself am an SQA Manager, but I do not suffer this illusion. Rather I believe everyone in the development process is responsible for quality. My team is responsible for testing the application. We are service providers. We investigate the product thoroughly and give timely feedback about its status. This is how we facilitate the project team for making informed decisions. We find problems in the application, but we do not enforce that it absolutely must get resolved. We give information and recommendations about the problem to allow the project team to determine its urgency. This allows everyone to contribute in quality assurance.
Testing has been labeled as quality assurance for a long time. This terminology is so prevalent nowadays, both locally and internationally, that it is safe to speak of QA (Quality Assurance), without fear of being misinterpreted as a quality gatekeeper. It will be assumed that you are talking about testing. Even the mighty Google labels its testing team as QA. Many agile project documents do the same. Interestingly, if you take the QA term literally then the person who comes closest to fulfilling this responsibility is probably the Project Manager.
Of course the so called software development standards, similar to CMMI, do talk of this role of quality assurance as a separate entity, but it does not address many of the concerns outlined above. Even though I do not eliminate the notion that there may be some cases (probably in very very large organizations) where a separate entity with this responsibility may be required. But for the vast majority of the companies in Bangladesh it may not be applicable. Regardless, you need to be aware of the experienced veterans required to drive such an entity to add value and get the acceptance of the project team.
This article was meant to be a brief rant. However, I would be happy to discuss this further at www.sqabd.com (a place where we invite everyone in the software development process to talk about quality).
..................................................
The writer is an SQA Manager
What is wrong with this scenario? Is it really possible to assure software quality by an isolated team with a biased perspective? Is the perception of quality the same for all organisations or even within the same organisation? The quality attributes upheld by an organisation developing open source applications may be very different from those who don't do this. The process and priorities for developing a social networking application can be quite different from developing a healthcare solution. Sometimes it may be more important to ship a buggy product out the door so that you don't lose out to competition. Does Windows 95 ring a bell? How about Windows Vista? The fact is that the perceptions about quality differ depending on your role in the organisation. Some may be concerned with quickly delivering the next great feature that is a good selling point, while others may be worried about the difficulty of using them. Some may be disturbed by the nitty-gritty production process that is going wrong, while others are anxious to give priority to the needs and issues of the builders over the process itself. They all have a point. Quality is actually a relative term that Jerry Weinberg defines as "value to some person". What is required is for everyone in the production process to work together and make a combined decision about the perceived quality of their product.
Now getting back to the SQA team. If they are empowered to make critical decisions that impact the future of the product solely based on their own understanding of quality, then there may be consequences. Software development is a complex process that will probably never get any easier. SQA people may not have enough knowledge about the sales promises, technical complexities, available resources, project expenses and many other factors that make up the software development ecosystem. They may not even have the experience or knowledge to understand the intricacies of these factors. The SQA team can never assure quality alone. Hence the name of the team itself is inappropriate and misleading. That being said I have no issue with a team calling itself an SQA team. However, I do think it will be naive of them to think of themselves as the guardians of quality.
I myself am an SQA Manager, but I do not suffer this illusion. Rather I believe everyone in the development process is responsible for quality. My team is responsible for testing the application. We are service providers. We investigate the product thoroughly and give timely feedback about its status. This is how we facilitate the project team for making informed decisions. We find problems in the application, but we do not enforce that it absolutely must get resolved. We give information and recommendations about the problem to allow the project team to determine its urgency. This allows everyone to contribute in quality assurance.
Testing has been labeled as quality assurance for a long time. This terminology is so prevalent nowadays, both locally and internationally, that it is safe to speak of QA (Quality Assurance), without fear of being misinterpreted as a quality gatekeeper. It will be assumed that you are talking about testing. Even the mighty Google labels its testing team as QA. Many agile project documents do the same. Interestingly, if you take the QA term literally then the person who comes closest to fulfilling this responsibility is probably the Project Manager.
Of course the so called software development standards, similar to CMMI, do talk of this role of quality assurance as a separate entity, but it does not address many of the concerns outlined above. Even though I do not eliminate the notion that there may be some cases (probably in very very large organizations) where a separate entity with this responsibility may be required. But for the vast majority of the companies in Bangladesh it may not be applicable. Regardless, you need to be aware of the experienced veterans required to drive such an entity to add value and get the acceptance of the project team.
This article was meant to be a brief rant. However, I would be happy to discuss this further at www.sqabd.com (a place where we invite everyone in the software development process to talk about quality).
..................................................
The writer is an SQA Manager