|
January 17, 2007
Multiple Testing Environments
In last week's post (PeopleSoft support environments),
I set out a simple suggestion for
development and testing environments. Although it's typical to have only
one development database for each PeopleSoft product line, there are commonly several testing
environments arranged in two logical dimensions (steps along the migration path,
and multiple ones at one step in the migration path).
Today I'd like to talk about multiple testing environments at a single
migration step.
There are many good reasons to have several testing environments.
For example, you might want to refresh a separate environment from your
production database in order to diagnose a particular data issue.
Or there could be security/access considerations that lead you to
maintain separate environments. There might be separate databases
for training. You could even have a bull-in-a-china-shop type of
tester who is best restricted to his or her own environment. The
possible reasons are endless. However, the more testing environments
you must maintain, the more time it takes to maintain them. And there
is one important consideration that reveals a particularly bad
reason to have a separate environment.
If a testing environment is to be truly representative of the current
state of your systems, it must be patched with delivered updates and
also must contain all of your customization. In other words, after
you have developed a custom change in your DEV database, it should be
migrated to all of the testing databases at the next migration step
by default (in the absence of any
particular reason not to migrate it).
This can lead to a particular annoying conflict. The issue is sometimes
raised by project managers who want separate testing environments
for their own projects. For example, the PM for Project A (a normal
customization project, not an upgrade) might want
a separate test database in order to exclude changes from Project B
and/or normal system maintenance. I believe that this should be
avoided whenever practical.
The PM will argue that his or her team members cannot test effectively if
they are constantly hitting issues from Project B's customization.
(The unspoken implication may be that since the PM does not control Project
B, the developers on Project B cannot be trusted. The real
issue may be that the PM is just worried about hitting milestones
on schedule.)
Thoretically, Project B's changes should not intersect with Project A.
(If they were expected to overlap, that's a different issue.) The PM
for Project A says that since the two projects are completely unrelated,
they should have separate testing databases.
OK, but if they are completely unrelated, why are we worried about keeping
them separate? We should just use the same testing database for both.
The PM could then argue that there is a possibility that [the incompetent
fools at] Project B could inadvertently cause an issue for Project A.
That's certainly possible. But then, isn't it good to know that the issue
exists?
It often boils down to politics. The PM does not want anything "external"
affecting the project schedule. But if we give a separate database to
each project, the first time their separate code lines will meet is in production.
That's a particularly bad place to run the merged code for the first time.
It also may be very difficult to keep the code for the two projects
separate—after all, they may both be making changes to the same
objects.
Migrating custom changes only to certain testing databases makes the
other databases out of date and inaccurate. Only a database that contains
all custom changes truly reflects what production will look like.
The purpose of testing is to find problems, not to avoid seeing them
in the first place.
Now, if Project A is an upgrade or some other large-scale transformation
of the entire system, we will need not only a separate database but also
an entire separate string of environments. I'll touch on that next week.
Until next time...
|
