Siebel Testing Best Practice

Siebel has provided its base functionality (Vanilla Functionality). For Siebel Testing we have following structured Testing Methodology. We are applying following Strategies against SIEBEL (Sales Module). 1. Functional Testing. 2. Boundary Conditions :Test method and equivalence Partitioning Test Method. New View: Verify the entire BC field Names mapped to UI fields as per Design Document. Verify All the Label Names in List And Form Applet. BC Field Names and Label Names should be consistent in List and Form. If new view fields are exposed in any analysis view, Field label names should be consistent in all related Views (Analysis Views) Validate field Properties (Editable, Read-only, Runtime True and Pick Applet).Should maintain consistency in List and Form Applet. All fields that are in Form Applet should be there in List Applet with same Field Properties. Verify copy functionality in applet level (File). If it is not mention in requirement or Design escalate it to BA (Business Analyst). If a view has been removed, then it should be checked that any hyperlink in any other view should not have this view as its destination drilldown object. If a view has been removed check that it has also been removed from the Site Map. Applet: Verify the entire BC field Names mapped to UI fields as per Design Document. Verify All the Label Names in List And Form Applet. BC Field Names and Label Names should be consistent in List and Form. If fields are exposed in any analysis view, Field label names should be consistent in all related Views (Analysis Views)

 Validate field Properties (Editable, Read-only, Runtime True and Pick Applet). Should maintain consistency in List and Form Applet. All fields that are in Form Applet should be there in List Applet with same Field Properties. Verify copy functionality in applet level (File). If it is not mention in requirement or Design escalate it to BA (Business Analyst). When developer copies the existing Applet and built new functionality on top it. Validate the search spec weather he modified it or not. Also the hyperlinks Whether they should get to the same view or different views. Field: If you add new field do following Testing. Check in list and form applet. Filed Length, Field Properties, Field Mapping, Copy functionality. If it is date, It should not display time Stamp unless it is mentioned in design or Requirement Document. It should verify with BAs where all this field needs to be displayed. When they delete the Field or inactivate the field. Check in List and form Applet. Verify with develop weather that particular field is used in any Script. Test in Reports and other Views if they are deleting from first or second Screen. It should be deleted in BA views. Whenever any field is pulled from join then all associated fields along with the pulled field must be read only. For Ex: Suppose Accounts field is pulled then fields contact, state, country,zip all must be read only. Check the Roll-ups and Calculations in the fields. Check that the numeric fields should not accept negative values. Error message should get fired. Data Validation: You should make use of Filters wherever possible in the excel sheet while updation/validation of data. While creating new records, query from the backend (if possible) so as to minimize the effort.

 If some view or some functionality has to be removed, do check whether the state model has been modified to remove the respective states or not. Assignment Rules: Should check whether the concerned candidate has been added in the rule or not and whether he is an active or a terminated user. Should check that whether the Activation/Expiration date has been filled in case of activation or expiration of the rules. Should check that if a candidate has multiple positions then he should be added in the list for the respective position only.