Information Technology Reference
In-Depth Information
QA pulls
Quality
assurance
Engineering
he relationship between engineering and QA
Figure 12.7
Engineering and quality assurance (QA) interact.
treated as cycle completion with a proper QA status given to it. Avoid
terminating a cycle just because the development team made a new code
drop.
The relationship between QA and developers is one of
pull
by QA
(Figure 12.7). Understanding and implementing this equation will go a
long way toward reducing the turbulence that ensues when the develop-
ment team is continuously working on changes. Allowing Engineering to
push
the code, because they are ready, would lead to a volatility that
leaves test cycles interrupted. That is, one circus has to leave town before
the other can open.
The relationships among the various artifacts that make up software
must be taken into account, and a well-defined order of play established,
for the Development Release-to-QA process to work smoothly. Take as
an example an application with four artifacts: (1) a database schema, (2)
some batch jobs that run in the background (perhaps to clean the databases
periodically), (3) the actual customer-facing application, and (4) a set of
reports created outside the application using a different reporting tool that
maps to the schema. The batch jobs, the application, and the reports do
not have a common build, but work together as a system when released.
They are separate artifacts for QA and Engineering. Now take a situation
where the database schema changes; suppose a new field is added. That
it affects the other pieces is well understood. However, the change has
to propagate through the Development and QA teams in an agreed-upon
play order. The order within Engineering could be, for example, that the
Development DBA (database administrator) makes the change first, then
the others make changes to the code in parallel to incorporate the new
fields. There could be reasons why the other three cannot make the
changes simultaneously. The report module may have to wait for the
application to make the changes before it can import metadata from the
application so as to put the schema changes into effect. If any one of the
other three tries to make code drops before the other two are ready, the
result is chaos. Although the pieces will be separately tested, unless QA
has the luxury of multiple environments, its setup would be on the old
schema. It might also be in the middle of test cycles for some of the other
