| COLUMN |
Strong quality assurance process adds value to SDLC, ITIL |
 |
By John Scarpino
25 Jun 2008 | SearchSoftwareQuality.com
|
The centralization of quality assurance (QA) plays a key role in any company. Because of this, many larger companies tend to have a dedicated department called the QA Center of Excellence (QACOE), which may be a group that is dedicated to assuring quality for many departments or a department dedicated to assuring QA for a group.
What I have seen in my experience is that QA professionals are often thought of as mere "testers" who run manual or automated testing programs. The corporate world can sometimes forget that QA personnel are not only experts in testing but are also responsible for the capability, security, and performance of the entire software process.
There are instances when an infrastructure group, application/Web group, or security group validates their own changes and environment without first running the modifications past QA. It is at times like those when a gamble is taken with the company's future productivity; instead of preparing properly and relying on a QA expert to affirm that the system is, in fact, glitch-free, trust is put in the assumption that the system will do what it's "supposed" to. An excuse some IT groups/departments use for employing this methodology is that by skipping the QA process, the product will reach the market faster. Although that may be somewhat true, it acts as a scapegoat for the laziness of the department.
|
|
|
|
|
Any task that is developed, changed, modified, installed, or updated needs QA verification
-- including software and infrastructure.
|
|
|
|
|
|
|
|
|
|
Additionally, when a department owns a software product license, it also gives the department the right to manage the validation of the software tools and its processes. This creates a problem because the QA department should always be last to sign off on the product before it goes live. Just because a tool is fully set up with all the bells and whistles for the team doing the change, it certainly does not mean that all the risk that accompanies it will disappear.
The quality assurance process is a way to balance the company's activities and enhance productivity while decreasing risk, all of which is based on the requirements delivered by the client. It also ensures that the steps of the process are conducted in a methodical way. So, any task that is developed, changed, modified, installed, or updated needs QA verification -- including software and infrastructure.
Security testing and performance testing also needs to be validated by the QA group. If a change is made, the individual who implemented the change may use the testing tool to validate it, but the changes must also run past the QA department. Too often, changes that are made within Infrastructure security or performance do not involve QA.
With the Information Technology Infrastructure Library (ITIL) process being so hard-pushed in industry today, it only makes sense to assure any infrastructure change before a client calls customer support with a complaint, such as "the server is down; it is not responding," "I am receiving a 500 Internal server error," or "performance is very slow." From a security and load perspective, changes that are made to the application's environment (server, database, servers, and network) must be tested by the company's internal third-party group, which is the QA department.
This is a diagram that describes the software development life cycle (SDLC) and ITIL process based on the demands that management and customer requirements place on QA.
The size of the company does not necessarily indicate its maturity. Rather, maturity is measured by how a company handles the software it uses. Some corporations like to say they are mature because they follow a certain practice or use a particular tool. But, like during an interview, observation, or analysis, the end result is greater than the sum of the individual parts.
I have worked in small, medium, and large companies. Many people assume that a large company would have a better process than a small or medium one simply because everything is on grander scale, from the tools that are bought and used to the number of employees within a department. However, it has been my experience that a smaller company that has a defined process -- even with a smaller group of people -- can end up having a better product, service, and quality.
What's more, a smaller company generally has a faster speed to market, which helps it remain a contender in the industry. I often think of the old Roman and Greek combat methods -- working together to defeat an enemy that has them outnumbered. If you stick together and have a plan, you generally end up with the sweet taste of victory. Another example is the Japanese car industry, where a quality end product has been the top priority for many years. Japanese companies are based on teamwork and that teamwork continues through until the job is well done. Teamwork is also key for SDLC and ITIL. By having a centralized, non-biased QA department, quality will only increase and risk will decrease.
It seems that maybe certain IT work environments should be improved so as to accommodate a better understanding of the end goal as a collective whole. Sometimes individual departments operate with the mindset that once they're done doing what they're paid to do, there's nothing else they should worry about -- when instead they should be working together on the same team to reach a common goal.
The chief information officer (software), the chief technology officer (infrastructure), the organization, and management must support the customers and assure that the end product meets their needs. QA needs to be involved with software and Infrastructure changes to ensure the functionality, security, and performance. Better communication will arise between these areas once they become closer to achieving a quality output together. And bridging the gap between software and infrastructure through QA will help ensure the client's success and the company's future.
-----------------------------------------
About the author:John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
|
|
|
|
