This document talks about functional testing of a Siebel based application

Yes you can test drill down functionality through QTP.
Keep all correct destination view names in a excel file.
In scripting put a match of the same with the view names to which you drilled down.
In excel file add a column as result and whenever you drill down to correct view mention 쏱ass in the excel sheet.This needs to be entirely handled through scripting and use of data table feature in QTP.

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 got 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 BA셲 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.

Share
Related Documents
  1. [Paid] Certitude : Functional Testing tool and Qualification System (1954)
  2. [Video] Literate functional testing (1074)
  3. Functional Testing of Desktop Applications (961)
  4. How to Test Application Security Web and Desktop Application Security Testing Techniques (3495)
  5. What is Siebel Vanilla functionality? (4046)
  6. New QTP 11 Download (Free) (62179)
  7. QTP Siebel Add-In: An Introduction (3974)
  8. Mobile Application Testing (14084)
  9. QTP Descriptive Programming Unplugged (3217)
  10. State-based Testing is Functional Testing (1744)
  11. QTP useful tips (4224)
  12. [Ebook] FreeBSD Testing & Developer Handbook (4578)
  13. When to Regression Test (2214)
  14. Desktop App vs Web-based App (2420)
  15. QTP Benefits (1853)
  16. QTP TOOL TRAINING : BUILDING AUTOMATED TEST SCRIPTS (1441)
  17. Mercury QuickTest Professional Tutorial Version 8.0 (1301)
  18. QTP interview Questions (1518)
  19. QTP interview Questions (1711)
  20. QTP 11 is now available for download (2776)