| COLUMN |
Quality process first; quality testing second |
 |
By John Scarpino
09 Jan 2008 | SearchSoftwareQuality.com
|
Quality is not tangible and is often considered unimportant in development. However, the odds of success are better if there's a constructive quality process and testing lifecycle.
A problematic issue that occurs early on during a project may have a ripple effect on how "quality" is viewed within the company, as well as how the quality assurance department is structured.
Often, the struggles that arise in software development take place during the setup of a QA department. Three questions come into play:
- To whom should the QA department report?
- For how much should QA be responsible, in terms of the systems to be tested?
- Should quality processes and practices be covered by the QA team?
To whom should the QA department report?
In response to this question, I will mention that QA is usually positioned under development. If the QA department is to do its job to the absolute best of its ability, it must have independence from other divisions so as to be separated from any biases. For example, the means by which a project is finalized is usually considered more risky to a developer than to a quality analyst. Conversely, what is considered a high risk issue for QA might not weigh the same to development.
My objection to development's involvement in QA's affairs hinges on the following truth: When a deadline is looming and it is clear that the project will not be fully completed on time, it's the responsibility of QA -- not development -- to indicate what the risks would be if the project were to go live prematurely and whether or not to postpone its release. However, due to a "customer-is-always-first" mentality, developers have a hard time understanding how serious the risks may be if a project were to go live before completion. For instance, a senior manager for development might not think it is necessary to test a change in a production system in a "test environment" and will give a minimal amount of time for QA to finalize the system's quality. When an issue does occur, it's not ultimately regarded as development's problem but rather a change management, configure management, quality assurance or support problem.
Of course, an exchange of ideas between development and QA could exist if power were given to a small group of individuals who focus on a handful of given tasks within rapid development. As long as the QA timeline holds the same weight as development's timeline, both could reside under the same umbrella. This would allow QA to reign over the system and do its job without any discrepancies. But as is too often the case, QA is the "little guy" when it comes to risk/quality decisions that impact the needs of client, system quality, performance and cost effectiveness down the road.
Sometimes, QA is positioned under the same management structure as development so that problems can be shoved in a dark corner before they become widely communicated as a "no-no" throughout the company. But my experience has shown that filtering and blocking such information in a secretive manner will only create more problems later on in the lifecycle. If QA must be positioned under a department, it should be under operations, which has a reputation for valuing the company's well being before anything else.
For how much should QA be responsible, in terms of the systems to be tested?
How much testing coverage is required depends on the importance of the software to the consumer. Of course, 100% coverage is always desirable, but how the test plans will be covered is based on severity and priority. For example, a surgical software system would need as close to 100% coverage because if it were flawed, it would risk human life. With bank software that deals with internal billing, however, it would be more reasonable to cut out some coverage because it wouldn't have such dire consequences. This situation must always be reviewed by and from middle to upper management because it can hold a huge risk to customer and end-user satisfaction. It is also another reason why I feel QA needs to be an independent department outside of development. The translation of risk could have several meanings depending on the department.
Should quality processes and practices be covered by the QA team?
The third question about "process" usually doesn't present itself as an issue at the beginning of a project. Nonetheless, process should to be taken into consideration early on or there will be a business-flow problem as the project matures. Who will manage or create the business practices and assure that people meet the engineering expectations? What standard practices, business flow, documentation, standards and policies will people adhere to? These questions about structure seem easy to answer, but all too often companies spend their energy generating profit instead of investing in the internal processes that are integral to achieving the project's end goal. Whether or not it is formalized, a process is always created before the software development life cycle is started.
In conjunction with the above, I would like to mention that software business practice quality rarely is taken into consideration, leaving the QA department to pick up the pieces and form a process on its own. Many software development companies prefer to have only a testing group. They do not see the need to have a group devoted to quality practice because they cannot see the return on investment (ROI) for such a department. Unfortunately, this also allows managers to hold a monopoly over the company's business software methodology and to shape the process according to their likes and dislikes. This is a big problem because without best practices, formalized methodology and company consensus, a project will ultimately fail one way or another.
I have seen senior managers shy away from quality standards and procedures and instead attempt to implement a set of rules based on power and fear. Quality should never be forced upon a company, but rather should be agreed upon by all involved individuals. Here are a few steps to ensure that your company is following the correct process and procedures:
- A senior manager (or his/her subordinate) of every major department must attend each process meeting.
- An individual who has experience with software quality process implementation should lead the others in a uniform manner.
- Personal and petty differences must be left outside the meeting room. Always keep an open mind.
- Best practices, methodologies and procedures must be used as reference support.
- All departments must give insight and communication on the issues at hand equally. No department should steal the show.
- Hold at least two meetings a week to keep a high motivation level. (In some of my consultations I did these once a day until the problem was resolved).
- Always designate someone to take meeting minutes and distribute them after each meeting.
- Make a diagram of the new process and procedure flow to best display a methodology.
- Find a common ground for the process to fit all departments.
- After the process is agreed upon, communicate the process to the group and use it accordingly.
- Archive the location of the new process and procedure needs in a centralized location.
- Regularly reevaluate the process and take suggestions. The moment this ceases, issues may creep in again.
- Governance is important to assure that the process is being completed properly. Often internal audits are conducted and metrics are gathered to view a specific point within the project lifecycle.
- A "time cushion" should be allotted from the very beginning of a project that will go through a new process. I have seen good processes fail because of a short project lifecycle, thus not allowing any time for transition.
Since "quality" is not a tangible entity (unlike the software being tested, for instance), it is often regarded as less important. Companies that do implement a constructive process and testing lifecycle, however, often become very successful.
-----------------------------------------
About the author:John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
|
|
|
|
