Testertools Forum

1. Davidcrp
   Member

   Reputation:291

    

   What is a process that works?

   If you have monthly deliverables, is it reasonable to create a series of physical environments where each is used for a different phase of testing; Unit, Integration, Customer, Pre-production

   And that, if each one of these had a four week duration, that the code could move in cascading fashion from one to the other, e.g.; September, August, July.

   Or do you have to create four unique paths each with parallel phases, e.g;
   Unit Integration Customer Pre-production
   Unit Integration Customer Pre-production
   Unit Integration Customer Pre-production
   Unit Integration Customer Pre-production

   Posted 1 year ago #

2. Kumar
   Member

   Reputation:82

    

   If I understand correctly, you're asking if there are then 16 environments?

   Not in my site. Right now there's
   # DEV
   # TEST
   # STAGE
   # PROD

   DEV changes hourly since the coding and unit testing occurs. Individual projects may have different versions of each program.
   TEST gets packages moved in based on schedules and defects found. System testing occurs here.
   STAGE gets ONE set of packages moved in after being blessed by the testers. Integration Testing and install testing occurs here. Go/No-Go decision is made here as well.
   PROD is... well, production. Only rudimentary validation of install testing is done in production outside of business hours.

   This pretty much the pattern everywhere I've been. The acronnms change, and sometimes there are 3 environments, or maybe even 5, but 4 seems the norm from what I've seen.

   My take would be that versioning of programs/packages within those environments should be used rather than adding a whole new set when there are multiple versions in test & development.

   Posted 1 year ago #

3. Davidcrp
   Member

   Reputation:291

    

   You are right Jean, and sometimes more than sixteen (this is a large enterprise). What the crux of my question is getting to is: what is the norm? I've only recently been involved in this since there were some issues with code quality.

   The testers insist that they need these four parallel paths since the movement from on environment to the next is not crisp. That is, code trickles from integrated test to customer test. Errors found in customer test are reintroduced back to unit then migrated through the enviroments back to customer test.

   My concern over this scenario is its complexity and cost. Each environment is comprised of multiple servers, IMS regios, CICS regions and DB2 susbsystems.

   Are these folks right in needing such a complex setup?

   Posted 1 year ago #

4. Paul
   Member

   Reputation:181

    

   Maybe i am way off, but..
   we have a similar system (though not the same scale of complexity in platforms). the solution we have: have a robust CM tool and then have a setup script, which identifies the user say: setup.ksh T (this will identify the user as a tester) and then setup all the paths and environment variables accordingly.
   Code moves from one group to another in the CM tool and then extracted to the respective area (dev vs test).
   When the code is extracted by the tester (from CM tool), he/she runs the setup script and then goes about testing, without worrying about the environment.

   Posted 1 year ago #

5. Patricia
   Member

   Reputation:218

    

   I do know everyone's system is a little different and has different needs, but from what you describe it sounds like there's not a full packaged release that could fit a shorter environment trail.

   I'd be curious to hear the history of the growth of that. Was it something like;
   We need to keep 'A', but we need to start testing 'B' too. "

   My worry with that is that one little slip in movement of code could cascade into a huge version issue.

   And, should the muckety mucks go looking for budget cuts and see all that equipment "Just to TEST?".

   Posted 1 year ago #

RSS feed for this topic

Reply »

You must log in to post.