• White Paper Siebel Test Automation Executive Summary The selection of suitable areas of automation, given the various candidate areas from a typical Automation testing is finding favor in testing Siebel implementation, is of paramount impor - projects across various technologies and tance in order to optimize the automation script domains. It is becoming increasingly popular with development exercise. It is the objective of this Siebel applications because of its ability to white paper to identify suitable areas of automa - reduce testing effort, which can contribute to a tion and provide guidelines on how the automat - faster rollout/upgrade or lower maintenance ed testing should be approached. costs for an already deployed application. This paper attempts to answer the following questions: Relative Ease of Automation of Siebel Test Areas • What is the relative ease of automation testing of different areas of a Siebel application? There are four broad testing areas for a Siebel application: Functional testing, analytics testing, • What are the criteria for selecting appropriate data testing and interface testing. Careful consid - functional test case candidates for automation? eration of each of the aforementioned areas • Given the fact that multi-country deployment leads to the following observations regarding of Siebel applications is fairly common, what automated test case suitability: are the salient points when considering Functional Testing automation testing for a Siebel deployment project? This is carried out to validate the business appli - cation components of the system. Functional Testing of Siebel applications is among the fore - testing is conducted on units, modules and busi - most challenges for clients planning on imple - ness processes in order to verify that the applica - menting Siebel in their IT enterprise. The fact tion is functioning as requested. This covers that there are various modules of Siebel applica - areas such as validating whether a module is per - tions (Sales Force Automation, Marketing, Field forming correctly (e.g., activities are successfully Service) combined with different types of client created), Siebel workflows and assignment rules instances (Web client, wireless Web client, hand - are working properly, and UI layout (i.e., look and held client, mobile Web client and dedicated Web feel, drop-down menus and test fields) is properly client), creates a wide variety of testing scenarios validated. Functional testing offers the maximum for any Siebel implementation project. Post- potential for automation of test cases. The fol - implementation, there remains a challenge in lowing are a few of the areas where automation terms of a disciplined testing effort for regular testing may be explored: changes and upgrades. And because most large Field validation in multi-value groups and pick Siebel implementations span different geogra - • applets phies and languages, testing can be even more complex. A question that is normally faced during • List of Values (LOV) validation any Siebel testing project is, “Can we automate • Modularizing test steps that repeat across mul - Siebel testing to a large extent to reduce the test - tiple test cases (e.g., logon, screen navigation) ing effort and cost and enable test case reuse for future projects?” • Validation of multi-lingual label translations white paper | april 2011 Data Migration Testing appearance of the report) and report data testing (e.g., validation of data in the back-end and Data testing is another appropriate candidate for whether it is being represented correctly in the test automation. Loading of data from external report). Analytics testing doesn’t qualify for sources to a staging table, staging to EIM and EIM automation because activities such as format to database servers, can be tested for data verification are difficult and cumbersome to integrity through the migration process. After implement through automation scripts. loading the data in OLTP database, SQL queries Moreover, the fact that data validation would can be used to check whether all the valid data is involve setting up and executing SQL queries loaded properly in the database. For a large which often results in run-time changes and opti - Siebel implementation where multiple instances mization, which renders the scripts to a great of the same application are being rolled out, this would entail a huge effort. In order to test migra - extent as unsuitable for reuse, thereby defeating tion of data efficiently, and also with reduced the purpose of automation. effort, automation testing can be introduced. Siebel Test Automation Approach Modern day test automation tools provides sup - port for directly querying databases without Figure 1 below highlights a suggested approach accessing the GUI, which facilitates automated for automating testing of Siebel applications. testing of data. This approach is based on the experience of the authors of this paper while working on multiple Interface Testing Siebel automation projects across domains such This is typically not a good candidate for automa - as pharmaceuticals and insurance. tion. Testing of the interface of a Siebel applica - Identification of Test Case Candidates tion with a third-party application can be fully for Automation automated only when the third-party application fully supports test automation. If otherwise, When considering test automation of a Siebel inbound/outbound data passing through the application, keep in mind that it is never possible Siebel system interface needs to be generated to achieve 100% automation coverage. Unless and verified using driver and stub routines, care is taken while choosing test cases which are resulting in extensive effort in certain situations. suitable candidates for automation, it may result in loss of productivity. Dedicating time to auto - Analytics Testing mate test cases which will be executed for few This is comprised of such things as report layout and far between instances cannot justify the testing (e.g., checking the format and overall development effort required. For example, in a Siebel Test Automation Approach TEST CASESS EXECUTE MANUALLY GOOD CANDIDATE NO FOR AUTOMATION? YES ADD TEST EXECUTE SCENARIOS? YES AUTOMATION FRAMEWORK EXISTS? REPORT RESULTS NO DEVELOP CUSTOM FRAMEWORK CAN A FRAMEWORK BE YES DEVELOPED ON BUDGET? NO Figure 1 white paper 2 multi-country Siebel application rollout, automa - testing of a Siebel SFA application which was tion of test cases involving country-specific local - implemented across twenty three countries in ization requirements, which may be executed Europe for a Fortune 500 pharmaceuticals major. only once or twice in the entire testing phase, Estimation of Effort should be avoided. It is therefore imperative to develop selection criteria while considering test Effort estimation for an automation project is a cases candidates for automation. vast topic in itself and is beyond the scope of this Developing the Automation Framework paper. However, there are three critical compo - nents that need to be carefully considered for At the very abstract level, an automation frame - any automation exercise: effort estimation of the work is comprised of a set of standards, guide - time required for developing the automation lines and utilities which are utilized for any test framework; effort estimation of the time automation project. If a framework needs to be required for developing and doing dry runs on the developed, a decision needs to be made on what automation scripts; and, effort required for script type of framework should be used. For example, maintenance. developing a keyword-driven framework takes a Configuring Siebel Environment for Test lot more time and technical expertise than devel - Automation oping a data-driven framework. On the other hand, creating new test cases using a keyword- Automation support is not enabled in a Siebel driven framework is much faster and easier. It is environment by default. Before starting an critical therefore to understand the tradeoff and automation exercise, it needs to be confirmed decide accordingly. Regardless of the type used, whether a License key is available for enabling the framework should have support for most of automation. This license key, which is a 24 to 30 the common tasks that need to be performed digit number, needs to be procured from Oracle easily. and should be added to the Siebel server. Apart from the built-in functionalities, the frame - Adding Test Scenarios/ Re-usable actions/ work should also clearly define the coding stan - Function Libraries dards, the script review and documentation process to be followed across projects. For any Once the framework is ready and all configura - serious automation project, the life time of the tions are in place, specific test scenarios can be automation suite is much longer than the dura - added. These test scenarios leverage the avail - tion of any specific automation engineer’s able support from the framework to quickly auto - involvement with the project. Adherence to prop - mate specific test steps. Generic scenarios for a er coding standards and adequate documenta - specific flavor of Siebel fall under this tion of standards reduces the learning curve for category.(e.g., a medical representative creating any new automation engineer joining the team. an unplanned call with a doctor in Siebel ePharma application or an insurance agent creat - Figure 2 highlights the automation framework ing a new quote for an individual