Information Technology Reference
In-Depth Information
In the marketing world there is a saying that “perception is reality.”
The perception of quality regarding a deliverable may be completely
different from what the QA reports show. The larger issue of quality, both
actual and perceived, is something that should be actively brought into
the development arena.
Quality Assurance (QA) and Testing Skills
As discussed previously, QA and testing are different. A good test engineer
should have a perverse “test-to-break” attitude, a strong desire for quality,
and an attention to detail. Tact and diplomacy are useful in maintaining a
cooperative relationship with developers. Previous software development
experience can be helpful, because it provides a deeper understanding of
the development process and gives the tester an appreciation for the
developer's point of view.
A QA person also needs the same qualities as a good tester. An ability
to find problems as well as to see what is missing is important for inspections
and reviews. Additionally, one must be able to understand the entire software
development process and how it fits into the business aspects of the orga-
nization. Good communication skills and the ability to understand various
sides of issues are important. Patience is necessary, especially in the early
stages of implementing QA processes in an organization.
Summary: Quality Matters
Software development requires a sophisticated, general-purpose infrastruc-
ture that can adjust to and work with a varying mix of language, domain,
complexity, and customer needs. It is an infrastructure that is weighted
toward the quality of the people on the team rather than the equipment
and tools. This dependency on human abilities leads to a variation in
quality of the deliverable.
Quality software requires a good, healthy relationship between the
Engineering and QA groups. The equation between Development and QA
is one of push-and-pull; that is, it is a relationship full of active tension
and cooperation. The tension obviously arises due to the “fault-finding”
mode under which QA, by the very nature of its responsibilities, operates.
Allowing Engineering to
push
the code because they are ready would
lead to a volatility, which leaves test cycles uninterrupted. Realizing this
can go a long way toward reducing the turbulence that ensues when the
development team is continuously working on changes. One circus must
leave town before the other can open its doors.
