Bloggo back to the blog
An Automated Deployment with Web Interface-->
Test environment in which tests will be run and any other software with which the software under test interacts when under test including stubs and test drivers. Test data is data which has been specifically identified for use in tests, typical of a computer program. 
This paper summarizes the ideas developed for separated testing environment so as to perform tests in compliance with specific test types(unit test, smoke test, functional test, performance test, user accaptance test, skim testing etc…) and utilize “Webdeployer” application for test environment management.
Test environment separate to development environment is to restrict developer’s intervention in test environment during the test phase. This is to be done so that the test results are clear, real and non-ambiguous. 
There exist five seperated database environment for testing:
“DEVDB(development database)” for unit tests, are run and deployed by developers,
“TESTDB(test database)” for common types of tests, are run and deployed by test engineers,
“PRPDB(preproduction database)” for common types of tests for verification, are run by test engineers and deployed by operation team, which is a closer test environment to production,
“BUGFIXDB(bugfix database)”, for common types of tests for production defects, are run by test engineers and deployed by operation team, which is the closest test environment to production,
“PROD -1 DB(prod minus one database)” is one of our test environments that keeps up with production database with one day delay.
All of the applications that are tested are configured to be compitable with seperated databases. Webdeployer application is used for managing test environments automatically from a single point, that are used in configuration. Webdeployer application allows us to deploy Database packages in line with a certain versioning reason to Test environments; to compile database package/procedure in test environments; to have a central access to Cruise Control servers; to compile, deploy and check-in projects intra vires; to shift labels to codes on version control tool and to use Frezee procedure (at the development phase), central access to and management of pools at WebLogic Servers (displaying Pool data and refreshing Pool refresh), LDAP / Local User Support, Role Definition, and Role- and Project-based authorization features. After each environment owner chooses db/schema on db menu, at db side for her/his environment (development, test, operation), he/she writes version control tool path of the file which is to be deployed and then the codes are deployed to the selected database. On the application side, after the server name is selected on the application menu, the application is built. Procedures written at Queue are deployed by an automatic batch at every 30 minutes. (Figure.1, Figure.2)
As the objects on test database are simultaneously complied one by one to different databases, more than one package can be compiled at the same time through multiple choices. The procedure of multiple choices can be performed also in Background Mode and the result of each package is sent to the user in separate e-mails.
Due to success of this application, we have obtained a flexible structure that permits test engineers to easily employ test environment and deployment features by eliminating the operational dependency during Software Development Life Cycle process. Furthermore, we have provided weblogic and database sterilization.
It may actually improve the security and efficiency of both Testing and Development environments if certain infrastructure services and associated security controls are implemented as shared services. For example, it is often, though not always, not a good thing if environments share:
– common configuration management database and associated standard change to control business processes
– common identity management, directory service and access controls (consistent user ID’s different permissions in each environment)
– common audit and accounting log collection (enterprise security controls should span environments)
– common infrastructure services (Storage Area Network, E-mail services, content filtering etc) 
When the complex and great systems into which we are integrated at Testdb are not accessible, environment(s) that is accessed through a tool are virtualized so as to diminish dependency and time loss. Since the integrated systems at Prpdb should always be on, they cannot be virtualized. At the test run phase, once a week, a report which includes the scope of the project, overdue works, completed works, works to be done and environment cuts is issued to the project team. The operation team is responsible for problems experienced in these systems and the problems are followed through a central demand- managing system. The teams generate workaround solutions in line with the severity and priority criteria of the demand within the framework of Service Level Agreements formed for these demands. The teams are also guided to produce long term solutions for cuts defined in the weekly reports.
If the responsibilities and the uses of above mentioned environments are detailed:
The developer, who has completed the developments on devdb which is in his/her responsibility, puts the label of “To_Test” to the related version of the object in the folder beginning with “/db_objects/source/…” to deploy that object to test environment.
These files are versioned in the following way, (Example :
-Release_No=2.16_27102007-1804_Test_3) and checked- in under the same structured “/db_objects/test/…”
The path to which the Developer adds To_Test:
The path which is automatically versioned and checked-in:
The test engineer opens a deployment demand by using the path beginning with “/db_objects/test/….”. The Webdeployer batch operating once at every 30 minutes detects the files labeled with To_Test under the “/db_objects/source” folder and writes it in the row to be deployed. At the end of the deployment, the Webdeployer sends a mail to the developer who creates the version with To_Test label and to those who want to be informed about the changes in the relevant database. The deployment status report allows us to observe fails and successes, perform redeployment, add new deployment or cancel demands waiting in line and not deployed yet. The objects without a To_Test label cannot be deployed to Testdb.
After the completion of deployment to Testdb,
Testdb is the field where Smoke and functional tests are run and controlled under the management of the test engineer. If 20% of the cases fail after Smoke test is run, the test is rejected and sent back to the deployment team. Test defects and solutions are mostly produced in this environment. After solutions of defects, the object versions increase.
Test data in testdb environment are mostly secured by the test driver from production environment through “data masking operations”. The operation team and database administrators are responsible for refreshing data to test environment three times a year so as to update data.
For the management of Test data, “Sovalye” applications (developed in-house) are used to define the relevant fields of data in the whole integrated system and make the data consistent with all of the test systems. Moreover, a refresh calendar is used to clean trash data and reflect new types of data to the test systems.
After the tests are completed, the label of “To_Prp” is added to the objects with current version information. The developer puts the label of To_Prp to the related version of the object in the folder beginning with “/db_objects/test/…” to deploy that object to test environment. The Webdeployer batch operating once at every 30 minutes detects the files labeled with To_Prp under the “/db_objects/test” folder.
Then, the Webdeployer versions these files in the following way and check-ins them under “/db_objects/prp/…” in the same structure.
The path which is added with To_Prp by the developer:
The path which is automatically versioned and checked-in:
After the check-in, Webdeployer also puts the Prp_Versioned label on the version labeled as To_Prp by the developer.
Lastly, Webdeployer sends a mail to the developer who creates the version with the To_Prp label and to those who want to be informed about the changes in the relevant database.
The test engineer opens a deployment demand by using the path beginning with “/db_objects/prp/….”. These objects are deployed to Prpdb. The objects without a To_Prp label cannot be deployed.
Tests in Prp environment are performed with functional, performance, user Acceptance Test and skim testing methods. Prpdb is the closest testdb to production in terms of data and object. It is controlled in Prpdb environment if the entire object list is added with label to be sent to production. Its management is under the control of the operation team.
Moreover, the deployment performed by the operation team in Prp environment is of a rehearsal quality of production shift. “Proddb -1” environment is used to obtain test data in this environment from which a backup of one day older data of production database is secured. The operation team is responsible of it.
After the completion of Prpdb tests, the objects are directed to the Release Management team in order to add them “Freeze” label and to form Release Set. This set may include more than one piece of related or independent objects. Through operational work, these objects are deployed to production environment on “Production Release Date”.
Meanwhile, if a production defect occurs at any time (even if there is a development on the object), the test related with the prod defect is correspondingly realized in Bugfix environment that has no connection with other databases. The intended use of Bugfix environment is to obtain fast action independent from <if> developments of objects with production defects. Unlike Prpdb, objects and data are closer to production environment since this environment is not used for normal test demands.
In sum, test environments intended for different purposes has made it possible to perform simultaneous tests on the same objects, to prevent deployment defects and also to effectively operate release management and software development life cycle.
Asli Karatay Koçak graduated from Istanbul University in 2010 with a computer engineer. She is Senior Software Test Engineer at Turkcell. In this capacity, she is responsible for Information and Communications Technology – Revenue Management Capabilities area of the company. She reports all activities to senior management and Test Architect Committee. She works closely with business analysis team, development team and operational team to ensure SDLC processes are being performed. She also provides certification of Fundamental Test Engineer from ISTQB. She is a member of Turkish Testing Board. She is member of winning team of the competition at Test Istanbul Conference in 24.May.2012 and she has been accepted to present at Conference. She interested in photograph, puzzle, trekking and series.
Lütfiye Yetisen Meliye graduated from Inönü University in 2005 with a degree in economics. She is Senior Software Test Engineer at Turkcell.
In this capacity she is responsible for operational and information systems areas of the Company. She reports all activities to senior management and Test Architect Committee. She works closely with the development team, operational team and business analyst team to ensure SDLC processes are being performed. She also provides certification of Fundamental Test Engineer from ISTQB. She is a member of Turkish Testing Board. She is a member of winning team of the competition at Test Istanbul Conference in 24.May.2012 and she has been accepted to present at the conference. She is interested in books and puzzles.