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.
