CRM Application Testing Help

CRM Application Testing Help

Customer Relationship Management (CRM) systems are at the core of most customer-oriented business. A buggy or improperly implemented feature in your CRM application can have direct impact on how you understand your customers and hurt your revenue. Conversely, a well-implemented CRM can help you gain customer insight and improve customer satisfaction and loyalty.

CRMs also contain a lot of sensitive data about your company and your customers. Any CRM testing program should ensure that the data is accurate and secure during storage and retrieval.

1. Data Quality and Conversion:

The first test cycle focuses on issues related to data quality and conversion. At every step of a migration or update you should be verifying that the CRM is working as expecte3d both with and without data.

Look in particular for the following issues and data quality scenarios:

a)      Duplication of data: No redundancy is allowed.

b)      Wrong fields populated: Transaction details for one card type should not appear under the transaction history of another card. Loyalty card transactions appearing as gift card transactions.

c)      Hidden data is indeed hidden: Only the appropriate data should be visible to various user roles.

d)     Data maps correctly: Grid issues where a selected row’s data goes out of alignment with the fields as you scroll down are very common.

e)      New and updated data saves properly: Customer information and card information should save and update properly.

f)       Partial and full search work as desired: Users should be able to search by first name, last name, company, card and whatever else is deemed necessary.

g)      No data is missing: All of the required data should be available to the right user levels.

h)      Graphs represent data correctly: Critical data like store-specific and program-specific filters and sales percentages should be accurate.

i)        Data sorting: All of the fields that need to be sortable should works as desired.

j)        CRM installs correctly: No critical GUI issues should arise during installation even when the user misses data during installation.

k)      Updating data is smooth and doesn’t require you to move to another form: Information such as customer visit count should update automatically without visiting additional forms.

l)        Data saved in one field does not move to another field after saving it: Fields like address, which may need more than one field, should save to the correct fields.

m)    Check that data which is not supposed to be editable is indeed not editable: Data like date and time of transaction should not be editable.

2. Functionality:

The second cycle of testing focuses on testing the functional aspects of the system. Regression testing of data quality and conversion should also be done.

Here are a few typical functional areas and related scenarios of a CRM application that should be checked:

a)      Access level: User permissions are working as desired. In particular, non-admin users should not have access to any admin functions.

b)      Transaction upload: If the CRM integrates with a POS, then all of the customer’s transaction information should accurately update at the Point of Sale (POS) within a few seconds.

c)      Insufficient card balance: If the customer does not have sufficient balance in the card for complete order payment, then he should be able to pre-authorize for the amount equal to balance available on the account and select another payment for the remaining balance of the purchase.

d)     Connection lost: For an Enterprise-grade CRM application, when the connection between stores gets lost then cards should not work and the proper error message appears.

e)      Card information: A customer’s card number or card type should not be changeable after the transaction has been completed.

f)       Card amount: Negative balances never appear through direct or indirect methods.

g)      Partial search: Partial search for program numbers that can both act as loyalty cards and gift cards should return matches from both types of cards.

h)      Transaction type: Users should be able to change the transaction type before settling the transaction and transactions should settle properly after the change.

i)        Data mismatch: Customers with the same first and last name should not trigger data mismatches and other problems.

j)        Pre-authorization: When a transaction fails while a card is pre-authorized, the payment slip should not print incorrectly.

k)      Department-specific transactions: Any restrictions on which departments accept gift and loyalty cards are working as desired.

l)        Store-specific sales: Receipts are printing the correct store name and address.

m)    Tax: All tax-related scenarios should work fine while pre-authorizing and settling transactions including cancelling transactions.

3. Reporting and Integration:

The third testing cycle focuses on reporting and integration, passing data to or from external systems, with a regression testing done for data quality and functionality.

Testing CRM reports should cover the following areas and scenarios:

a)      Accuracy and reliability: The accuracy of reliability of data and reports from the new CRM solution need to be checked to determine whether they match existing reports and how many, if any, reports must be revised.

b)      Exporting reports: Do these reports export in all formats with the correct data.

c)      AND/OR filter: Check that AND/OR filters work properly even with lots of filters chained together.

d)     No input value: Check that fields with no input value are not getting past filters incorrectly.

e)      Labels match: Label names should be the same regardless of where they appear.

f)       Unnecessary dependencies: Generating a report at one store should not be dependent on any actions at other stores.

g)      Store filters: The correct data appears when store-specific filters are applied.

h)      Date/time: Reports should include the correct date and time of creation.

i)        Headings and build versions: Reports should show the correct headings and build versions.

j)        Report performance: Data should populate the report in a timely manner.

k)      Date ranges: Filtering on date ranges should always be tested.

4. Regression and User Acceptance Testing:

All of the end-to-end business processes are validated by the customer through user acceptance testing. User acceptance testing is process-level testing. All of the testing that has been done to this point is module-level testing.

User acceptance testing should cover the following areas:

a)      Documentation: We refer to project documentation to write the test cases based on the requirements of the users of the application.If the original documentation is incorrect or the end-users have undocumented needs, then the documentation needs to be updated as per the actual customer’s requirement.

b)      Usability: In CRM applications, customization to things like the grid, forms, schema and templates affects the usability. Unless test confirms the implementation is acceptably easy to use, the application should not be released.

c)      Functional Correctness and Completeness: All features should be implemented correctly.

d)     Reliability: The CRM should meet or exceed service level uptime requirements and the end-users should not have to wait a long time for transactions to  upload and data should be available all the time.

e)      Confidentiality: Customer’s details (contacts, points, balance visits etc) should be kept confidential.

f)       Scalability: Test the application for a realistic number of stores connected to a head office.

g)      Stress: The following check points should be monitored for response time  with an increasing number of open (not settled) orders:

i)        Sending order to requisition (kitchen)

ii)      Customer search (especially company search), and saving of the customer (on confirmation of customer info).

iii)    Payment processing on order settlement.

    Begin stress testing by having 10 open checks and then settling them at the same time. Then increase the number to 20 open checks, then 50, 100, 300, and 600.

Finally, check that the CRM application is well integrated with the customer’s other applications or systems such as Outlook, Map Point and Squirrel Explorer.

5. Not-so-final regression test

Once all of the critical defects have been fixed run another round of regression tests on all of the above.

Any time requirements change (a common occurrence in CRM implementations), new features are added or defects are fixed, you should run these regression tests again.