Test environment

Acceptance testing
Test Engineer
I work as a Test coordinator for a hospital org where we do not have a dedicated Test team.I lead and coordiante the test efforts with set of end user SME's who do not have testing background. We are designing and building the configuration of the new system (this an off-the -Shelf product) Can you please provide your recommendations 1) same test environements for building and configuring and functional testing 2)Using seprate company ((Different DB but same servers)and copying the config changes into the new environement 3)Building and testing in production environment.

Software/Hardware used:
Fast Track system

Answer Wiki

Thanks. We'll let you know when a new response is added.

I work at a major public academic health sciences center and have faced a similar challenge. We set up separate environments for development, test, quality assurance, production, and in some cases, reporting. It may seem like a lot of environments, but each one serves a critical purpose. Development is used to develop new applications and as an initial location to install a new commercial application and become familiar with the product and the technology infrastructure. Test is used by the development team to perform integration/system level testing/debugging. Quality Assurance is used by business analysts and end-users for user acceptance testing. Production is production. And, Reporting is used for ad-hoc reporting that would otherwise slow down the Production database. In some cases we host the application and database for an environment on the same machine when resources are tight, but otherwise we have a separate application and database server per environment. We have co-hosted two environments, like development and test, on the same servers when resources are tight too. The key is to provide separate environments to isolate development/testing activities and to allow separation of duties so that only developers can access development and test, business analysts and end-users can access quality assurance, production, & reporting, and change management personnel can access all environments to implement code and data changes as needed. I hope that this answers your questions.

Discuss This Question: 1  Reply

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Sunsetrider
    I would recommend that you create a 'standard' test system for each environment (this will probably create some overlap), but you can use this test system for future changes. Also, you will not need to retain 'experts' for this system, since your test cases and resullts should be the same each time. You can always develop new test cases when new functionality is added. When you are ready to test changes; load your current test system, compare the results with the previous test system (they should be the same, since no changes were introduced); implement your current set of changes; run the test system (adding additional test cases for new functionality) and compare with previous test system output. This is a relatively simple process to ensure only those functions that were modified have been changed. I prefer this technique, rather than copying every db 10th record and turning this into our 'test' system. Using the above example, I have a high confidence level that the changes implement will be adequately tested, and we will not have screwed up something else.
    860 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: