[p4] Which dept for build/release engineers?

Janulewicz, Matthew mjanulew at alarismed.com
Tue Jun 15 10:01:49 PDT 2004


I think this is the norm, at least in my experience. We have engineers who's
only role is writing automated testing systems. They do belong to the
engineering group, but are really more useful to the testing group.

With all due respect to some folks on this list (just my opinion here, yours
may vary), I think it's a mistake to completely merge an engineering group
and a test group, and calling them the same thing. If everyone is skipping
through the meadow hand in hand, singing nursery rhymes to each other, you
create a comfort zone that can cultivate a culture where engineers are able
to approve their own code for release. You'll get a lot of engineers
slipping code in under the radar/table because their best buddy/tester said
it was okay. I think you need more oversight than that.

The nature of finding and fixing bugs *is* adversarial, and I think it
should be to some extent.


-Matt

-----Original Message-----
From: Ivey, William [mailto:william_ivey at bmc.com] 
Sent: Tuesday, June 15, 2004 9:16 AM
To: perforce-user at perforce.com
Subject: RE: [p4] Which dept for build/release engineers?


> -----Original Message-----
> From: DAO, THOMAS (SBCSI) [mailto:td4585 at sbc.com]
> 
> I've noticed that companies usually place the build/release engineers
> either under the development team or the QA team, just 
> wondering is the
> norm, and the benefits
> and drawbacks of placing them in each dept.


Well, if you have to separate QA from development in the
first place... (Seems to be the norm, but I've seen more
success in companies where each development team had at
least a couple of QA persons embedded in it - it was
like unit testing on steroids.)

Anyway, in my role of build/release something or other I
spend more time working with development than QA. Probably
a 9:1 ratio. Most of this is coaxing developers into
sensible build structures and red-flagging conflicts
between interdependant products, fixing makefiles and
scripts, etc. For QA, I mostly tell them when its ready,
pass along the fixes that were built, and answer a few
questions about structural changes. -Wm
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user



More information about the perforce-user mailing list