Software QA FYI - SQAFYI

Guerrilla SQA

By: Bret Pettichord

Adequate resources and senior management commitment are oft-cited prerequisites to successful process/quality improvement activities. What if you have neither? The metaphor of guerrilla fighters seems appropriate for the inch-by-inch “underground” effort which can characterize in-the-small process/quality change attempts. This paper suggests how to introduce software quality assurance (QA) and measurement practices where they might most easily be accepted without taking mainstream development tasks head-on. The paper begins by describing an in-the-small, limited resource (“guerrilla”) approach and the context in which it is applied. QA and measurement practices are recommended which support one another and encourage data-centered decision-making. Implementation behaviors to avoid are noted to reduce the resistance faced when introducing such practices flow. A connection is also made between these practices and project risk management since they complement one another.

The “Guerrilla” Approach –

Guerrilla fighters, as opposed to a formally recruited and supported force, have to replace resources with dedicated belief that what they are doing is worth the sacrifice. The armed force likely has the authority of “government” (corporate management) behind them while the guerrilla can, at best, hope for benign neglect from the formal hierarchy as long as they don’t seem to be in the way of “real work.” The guerrillas often encounter resistance from the mainstream “ruling party” (development organizations) who, in all fairness, are given other priorities and whose leadership (middle management) has, indeed, been rewarded for succeeding with the behaviors now in place.

The guerrilla fighters learn to “live off the land” finding the things that feed people’s desire for change/improvement. Because resources are limited and because those they seek to help are usually less adventurously inclined, the guerrilla fighters’ “weapons” (methods and technology) have to be simple. These restrictions also mean the effort must achieve results through “quick strikes” (short-term) not lengthy “campaigns.” And to sustain the gains achieved, a “power to the people” philosophy has to be adopted since the guerrilla fighters, as they move on to the next “encounter,” will have to leave behind (technology transfer) the ability for the people to carry on themselves with few resources and basic technology. Finally, guerrilla fighters come to understand that not all coups are successful and not all guerrilla leaders become heroes. Context for Introducing the “Guerrilla” Approach – The guerrilla approach is based on in-the-small activities which build up, bit by bit, over time into evidence of some “better way” of doing things. If you listen to people talk or read what they write about in-the-large success, one thing becomes clear: an essential element of the success was making it mandatory. One way or the other, management is given the message that being a part of the program is a requirement for staying with the organization (i.e., a “condition of employment,” as one senior manager put it in a process conference keynote talk last year). Even with such support, there will often be resistance from middle management who have “heard it all before” through various flavor-of-the-month programs and who have learned over the years how to weather the political tides in corporate existence to achieve what they perceive to be the “real work” expected of them. The guerrilla fighter must be sure that, no matter the size of the organization, someone feels that things are not “fine as they are.” Dissatisfaction with the status quo which is identified and accepted above middle management will usually get the resources and support (or at least pressure applied) to make something happen with formal organizational visibility. The guerrilla fighter deals with the “local population” (line management and staff) who sense a problem but cannot get the attention and resources to attack it head-on.

Development groups produce the fundamental deliverables to make a software system “happen,” i.e., the executable code and related system elements. They often receive the largest share of project resources (e.g., people, funding, schedule) though they are regularly asked to do with fewer of them. They also usually have the most technology support for what they do because of years of industry focus on source/executable deliverables and the automation potential inherent in such deliverable formats. On the other hand, they are usually faced with the most unpredictable technical situations, constraints, and choices. All this inclines them to be reluctant to have “outsiders” tell them how they “should be doing things.”

Therefore, the guerrilla approach recommends a path which bypasses such “strongholds” in favor of working with areas in the company which may receive less attention, fewer resources, and little technology support: requirements management, project tracking, system (independent) testing, and client (hot-line) support. All of these areas are critical to how the customer is likely to perceive the end product, its support, and its evolution (i.e., viability over time). From a customer perspective, the assurance of software product quality is likely to rest with these organizations.

Focusing Attention On SQA and Measurement –
A large part of the software industry has come to equate QA almost exclusively with activities related to testing code and, upon hearing the word “metrics,” envisions counting lines of code (LOC) or function points (FP). Given this view, the broader range of QA activities may either not be performed, performed consistently, well-coordinated, or monitored for effectiveness while metrics/measurement programs are seen as requiring development staff and management to take on data collection and reporting tasks with little return for the time invested.

Fundamentally, software QA and measurement are about achieving quality through greater visibility and more deliberate communication about how the customer’s requirements are transformed, bit-by-bit, into a functioning software product. Despite the significance of the role of testing in the development of software, it is an after-the-fact QC function which identifies errors that already exist in the software product. Test personnel can have important QA impacts earlier in the lifecycle which will be discussed, but the activities related to testing code fit the QC function not a QA one. QA is foremost about trying to prevent, not detect, errors and uses detection (QC) results to that end. Measurement provides support for evolving a data-centered approach to focusing QA and improvement efforts.

Though it sounds strange on the face of it, “depersonalizing” quality is an important first step in reorienting thinking about software quality. By “depersonalizing” is meant, not removing personal responsibility for quality or for what is produced, but removing a too individual view of project deliverable ownership. If individual egos and personality become identified with specific deliverables, not overall results, it will be difficult to achieve the necessary visibility and improved communication for effective QA and measurement to grow. Unless there is a shared responsibility for the quality of the transformation from requirements through testing, problems may be viewed as purely matters of individual competence and performance, leading to a focus on the deliverer rather than the deliverable. Because of the culture of many organizations, the guerrilla approach of avoiding mainstream development activity is often the line of least resistance in beginning to make this point. It will also be important to develop the understanding that QA is about more than testing code since this is what large portions of the industry, fueled by recruiting advertisements, define it to be, especially in commercial product development and in-house information technology environments. For this reason as well, focusing attention away from mainstream development helps to develop a broader view of what QA (both validation and verification) should mean to an organization in “building the right product right.” A broader view of QA should also be a way to encourage the development of a project culture based on data-centered opinions. The practice of collecting and using data to provide objective background for decision-making is constructively introduced through guerrilla QA. Guerrilla QA includes data collection for immediate, local needs, which can become the basis for eventually providing information of use in the mainstream development lifecycle.

Finally, the link between QA, measurement, and risk analysis and management needs to be made. Effective QA and measurement contribute to risk management by providing feedback on how a project is progressing and where potential problems may be encountered. Developing confidence in the predictive value of such feedback ultimately leads to a willingness to take on more aggressive project goals with greater confidence. In return, risk analysis helps establish specific quality-related goals which provide the visible needs to which QA/measurement practices can be applied and by which broader application of practices can be justified.

The V-Shaped Model –
Making some of these points about software QA and measurement may become easier using a V-shaped lifecycle model of the software development process common in Europe over a decade ago. Its main purpose at that time was to make the link between major software product deliverables and the validation (testing) activities associated with them. Adding a few elements to the original diagram makes the context of the guerrilla approach and its QA/measurement philosophy more clear.

The original model was the “V” with requirements, design, and coding positioned to represent higher to lower levels of specification which parallel unit, integration, and system testing representing internal logic, interface, and external functional validation of the product. Elements added to the model for the sake of this paper include labeling the Build- Verify-Validate aspects of the lifecycle, the quality assurance-control (QA-QC) scoping, the positioning of review processes, key measurement areas, and the dividing line between mainstream development tasks and those likely to be conducted “independently” of development organizations.

Full article...

Other Resource

... to read more articles, visit

Guerrilla SQA