UAT v staging… (spot the verb)

Wednesday, 02. 29. 2012  –  Category: IT & Data related

so, one is an activity and the other is hardware. For some reason people love the concept of ‘staging’ as if it will resolve issues related to an inefficient publishing process.

Anyhow, I found a great post on this recently at http://itknowledgeexchange.techtarget.com/profile/Northernoz/ by Tony Bessent of www.cosmoconsultancy.com. Bang on Tony…

The Release management discipline covers moving code form a developers machine to live/production. This is done in the following order or there about:

Developer develops code and runs unit test, integration tests and re-factors the code prior to putting it in to the main build, which then leads to

Install and build test server, this is where the install team install the code which has come out of the build, if the build does not work then the release manager knows there is a problem, most companies have a code curfew where they make sure developers don’t submit code for the nights build unless hey have tested it. Then the Build is automatically run every night using the code cut form the curfew time.

If the install is ok a regression test is run and if this passes, then the code is release to the test team, on one or more ideally two test servers. The testers then run their test scripts against the test plan and test schedule, which is driven by the requirements and change control documents.

Once it is tested by the test team, the code is moved onto the staging server where the business test the code and sign off as to fit for productions, normally refereed to as UAT (User Acceptance testing), then there is OAT (Operational Acceptance testing) which is done on a server which is like production, this is where the staging server come into its own, as this is normally the same as production where the normal test servers are normally virtual servers and lower spec. On the staging server the company may also run performance tests which are linked to the acceptance criteria as agreed between the business and the development team/company.

Then once there is a signature on a release note, down time for production is planned and the release is moved to production and put live, make sure there is a roll back position, if not you could end up with production down for hours and a not very happy business. years ago in a roll for a telco, down time of the network was counted in millions per second, even a single cell or part of the min network could lose a Million every 15 minutes, so the pressure was on to make sure the code was tested and a signature was given before moving to the next stage of the release process.

Leave a Reply