Best practices for managing clustered test environments. (Enterprise Networking).
One common solution for achieving this balance in supporting large scale, high-volume enterprise systems is to implement various clustering configurations that manage applications, hardware and databases effectively. Clustering is simply a way to physically and logically group hardware and software resources to work together as one system, and there are a variety of clustering configurations that allow for load balancing among the hardware, software and database resources. Clustering effectively improves processing efficiency and performance, while reducing operating costs, especially for large enterprise scale, mission-critical systems.
In a production environment, database and hardware clustering deliver improved availability, performance and scalability. Application clustering, also called software clustering, adds a third dimension to the configuration possibilities that is inexpensive and relatively easy to reconfigure. However, how should these clustering techniques be deployed in a testing environment? Can you afford to replicate a clustered production environment for development and testing environments?
Clustering in an Application Testing Environment
Complete and accurate quality assurance testing is critical for meeting today's demands to deliver applications that work, not only in the initial release, but also throughout the life of the application. Finding and resolving application defects early can significantly improve application quality and reduce or eliminate the costs associated with resolving problems after an application is placed in production. Another important goal is to create a repeatable testing process that improves application quality, reduces time to market and minimizes the cost of development and testing.
Companies are striving to speed the deployment of reliable, high quality applications while staying within tight development budgets. Reducing development and testing costs without sacrificing quality requires a best practices strategy with the right tools for application testing. The fact that most applications today rely on relational database technology further complicates the challenge for testing organizations. The application data model may contain dozens, hundreds, or even thousands of tables, and just as many relationships.
Deploying clustering in a testing environment can be beneficial when used appropriately. Managing your database, hardware and application clustering configurations effectively, as well as carefully choosing the right clustering technique for each phase of the testing process, are key to designing efficient, effective testing strategies for relational database applications.
Relational Data Testing Challenges
Designing a comprehensive strategy for clustered testing environments can be as challenging as designing and developing an application. The starting point is the logical and physical clustering environment--including servers, applications and databases needed to support the application you are testing. Although testing tools are not used in the production environment, the optimal clustering configuration will enable you to determine price/performance tradeoffs for your testing strategy.
Typically, several new test databases must be created and/or refreshed each time a new application is developed or an existing application is modified. Iterative testing involves executing the application using the test database and verifying the results to ensure the application is working as designed. Any problems discovered must be resolved and the test data must be refreshed before testing continues. This process is repeated throughout the various testing phases--unit, functional, integration, system, load and regression--until the application is migrated into production.
Clustering and Cloned Test Databases
Since it is ideal to use "realistic" test data, each test database is usually a clone of the production database, and special test cases may be added before testing begins. For example, in a clustered environment, a one-terabyte database might be cloned and deployed on a database cluster running on two servers. Load balancing can be used to enhance performance and maximize processing resources, depending on the number of test environments created.
Although clustered environments can support cloned databases, the cost and capacity issues make it impractical to clone an entire production database, unless it is absolutely necessary. Consider a typical example like testing an application with a one-terabyte database running on two servers. The same configuration is needed to support regression testing, adding two servers. If the QA functional testing also needs to clone the database, add two more servers. Now, a total of six servers are required with four dedicated to testing. This configuration does not even include the copies of the production database needed in the development environment.
In addition, deploying cloned databases in a clustered test environment during the functional testing phase can actually increase the time required to perform the necessary testing. How can this be? In a functional testing phase, it is not necessary to use a full set of test data because the goal of that phase is to ensure that application functions work correctly. If a fully cloned one-terabyte database is used for testing instead of a smaller subset, then executing the test cases may take longer because there is a larger volume of data to process. There is also a quality issue because the production data may not contain the particular test cases required for effective functional testing, and developers may find it difficult to track and validate specific test cases.
What is important is to always assess the data requirements for a particular testing phase to determine whether cloning the database in an operational clustered environment is truly needed. If not, the next question to ask is, "How can you create smaller subsets of the database to perform testing efficiently and still have complete confidence that the applications are being tested with the realistic test data?"
Subsetting Relational Databases
Subsetting can be used to create much smaller, yet realistic, test databases. Subsetting tools-- for example, Princeton Softech's Relational Tools-- provide the ability to extract complete subsets of related data and keep that data referentially intact. These tools can navigate all relationships in the data model, whether they are defined in the database or the application. Key features include the capability to extract test data that may reside in multiple relational databases, handling data compatibility and translation issues and providing federated data access.
Working with predefined realistic subsets of data that can be refreshed easily improves testing and overall application quality. Including the metadata in extract processing ensures that you can recreate test data quickly and accurately. The ability to save and reuse processing specifications streamlines the testing process and ensures a consistent and manageable test environment.
Subsetting and Test Phases
Subsetting is appropriate for various phases of the application development life cycle and especially when there is no requirement to test with the entire application database. The level of subsetting should be commensurate with the amount of data needed for the specific testing phase. For example, during unit testing, when developers verify the functionality of new features or application units, such as specific modules or subsystems, a very small subset of data is appropriate and actually expedites the testing process and reduces costs.
During functional testing, quality assurance teams verify the operation of the application functions, which requires more data than the initial unit testing phase. The subsetting facilities must be "tweaked" to extract more data. During integration testing, teams verify the integration points between units or functions to identify unexpected updates and anomalies and ensure that various functions now work together. Again, this phase often involves larger volumes of data than the previous phases, and the subsetting process once again can be applied with the objective of extracting a broader set of data.
System testing, sometimes called end-to-end testing, is designed to verify new functionality at a higher level. Quality assurance teams run an application through its paces to make sure that every feature and all functionality performs without errors. Subsetting can also be used during this phase to create yet larger, realistic subsets for test databases, thereby reducing costs and saving time. Finally, load testing benchmarks performance, response time and throughput functionality, while regression testing ensures that application problems are not introduced with newer versions of your application. Because these two final phases test the entire application, a fully cloned database is required in some cases to ensure a representation of the final operating environment, especially for load testing.
Clustering and Subsetting Reduces Costs
Where appropriate, it is much faster and more cost-effective to test with subsets of related data that accurately reflect the production database, without adding overhead to the testing process. Let us revisit our previous example of a one-terabyte database running on two servers to see how subsetting might be applied.
Load testing would require a clone, while regression testing would require 50 percent of the production database, so the requirement would be three servers; two for the clustered load testing environment and one for the regression environment. To support functional testing, the quality assurance team could use a subsetting tool to create a realistic subset of the production database that is only 100GB. This smaller data requirement eliminates the need for at least one server to support quality assurance testing. By using subsetting effectively, four servers are needed instead of six. What's more, quality assurance testing will run faster because the test database is only 100GB instead of one terabyte. That is a net savings of two servers and reduced testing time.
Careful analysis of the testing requirements will help you deploy the right mix of test databases and subsetting in clustered and unclustered testing environments. You will effectively reduce the testing time and resources required, while delivering applications on time with high quality.
Testing applications in clustered environments can quickly multiply capacity requirements and delay development schedules. It is important to develop a best practices approach for each phase of the application testing process based on your company's needs.
Incorporating subsetting tools into your testing strategy delivers dramatic results including improved reliability, faster time-to-market, lower development costs and higher quality. In short, this best practices strategy helps you do more with less.
Jim Lee is vice president of product marketing at Princeton Softech (Princeton, NJ)
|Printer friendly Cite/link Email Feedback|
|Publication:||Computer Technology Review|
|Date:||Jun 1, 2003|
|Previous Article:||Using embedded platform management with WBEM/CIM: add IPMI to provide "Last Mile" Manageability for CIM-based solutions. (Enterprise Networking).|
|Next Article:||Building a high-performance content infrastructure with Web services. (Internet).|