When I first heard about a project involving testing new customer relationship management (CRM) technology, I was delighted but skeptical. “What is there to test?” I thought. “It’s just a set of out-of-the-box features adapted to the client’s needs. It’s nothing.” I was so wrong.
CRM systems manage a company’s business relationships, including customers’ data, information, and interactions, so there’s a lot that can—and should—be tested. Here’s a bit about my experience in testing CRMs to provide some tips for dealing with the trickiest parts of CRM testing, specifically focusing on some preparatory measures, functional testing, integration testing, and test automation.
Data Comes First
In software testing, we often start off with thorough requirements-based functional testing. Even in agile projects, where the requirements develop on the fly, this approach works: We look at the features changed or edited and write necessary test cases. However, the procedure for testing CRMs is different.
The first step in CRM testing usually involves populating the developed CRM with test data to see if it works as expected. And here comes my first tip: Use realistic test data.You don’t need to employ real personal or business data; it’s enough to use real zip codes, phone numbers, and address formats particular to the country or region. This helps prevent UI issues that are common if you use just random test data that may result in an inadequate address or currency rendering.
Besides, well-designed test data may help detect failures in CRM databases and workflows as early as at migration stage. For example, in our project featuring a CRM system for a large bank, timely testing detected about a hundred instances of faulty workflow processes. These issues included incorrect data sorting, failure to save data, and allowing editing for data that can’t be edited (transaction date and time).
Think about Connections
After the data is successfully migrated to the new CRM system, we should make sure it can travel throughout the system according to the established business processes. For this kind of integration testing, I recommend using the built-in search many CRM systems have. Using targeted search queries, you’ll be able to check workflow implementation and input and output data.
Many CRM systems rely on integrations with other systems (for example, the Microsoft Dynamics CRM integrates with SharePoint). I advise you to focus on how the same data is processed and used in different system modules and how it is handled by a specific functionality.
CRM data should remain unchanged during data transfers throughout the system. If the data goes through some valid changes, such as user activities or automated workflows, these changes should be saved and be visible for every system user, and the users should be able to track change history.
A Checklist for CRM System Testing
Here are five principles I follow when testing CRM applications.
1. Support seamless communication throughout the team
Communication is the only thing that works for a clear understanding of user requirements. Developing a quality, functional test suite is not possible without input from business administrators, developers, and target users.
In one of my CRM projects, the customer was an overseas company, and the ten-hour difference made daily online meetups close to impossible. To ensure productive communication, we used a dashboard and a Q&A page in the test management tool. Every team member could consult them when required. We also checked the page during weekly meetings to make sure both parties understood the mutual requests correctly. This helped us ensure comprehension of the application business logic, which is a key point for reliable CRM testing.
2. Mind out-of-the-box features
The fact that CRM software is out-of-the-box (OOTB) often causes an erroneous idea that smart people from Microsoft, Salesforce, or whatever other CRM-developing company have already tested it inside out, so your testing is just a formality.
In fact, the term “OOTB” only describes the processes, entities, dashboards, views, and more that are provided for customization. Customizations expand the OOTB features, but does the new code seamlessly work with the existing code? Not always.
To be on the safe side, I advise you to run integration testing and smoke testing of the customized OOTB feature(s). I’ve had these testing efforts reveal major bugs, including faulty visualization of changes in the CRM data.
3. Test under different user roles.
As CRM applications cater to at least two business departments (marketing and sales), they support user-based access and various user rights. But even people from the same department may have different rights, depending on their positions and responsibilities. Role-based access and user rights are the first lock protecting business-critical information from ending up in the wrong hands.
In one of my projects, role-based access testing uncovered a critical bug: rights for regular users and admins got mixed up. As a result, regular users could run and control system processes, and admins could only view and sometimes edit the available CRM data.
I also recommend that you look at workflows involving various user roles. These workflows may be really complex, so testing may also help you nip some security issues in the bud. For instance, in a project testing a health care CRM, we discovered that patients’ lab tests were sent not to the patient or his or her doctor, but to a completely irrelevant doctor who never saw that patient.
4. Use a bit of nonfunctional testing
Testing customizations involves some nonfunctional testing efforts. On-premises and cloud-based CRMs have client-server architecture, and the client side uses web browsers to run the CRM system, so it’s necessary to check how the client side is rendered in target web and mobile browsers on target platforms (desktop and mobile). So, comprehensive browser and platform compatibility testing is required.
5. Don’t forget regression testing
Regression testing works as a litmus paper that signals a problem in the application. Luckily, there are ways to organize regression testing wisely and efficiently. Though the described approach targets agile projects, you may find some useful tips to adopt and follow even if you use waterfall.
Test Automation: Yea or Nay?
Does automation makes sense in CRM software testing? Well, it largely depends on the project scale and timeline.
Automating complex CRM workflows and interfaces may become really time-consuming. While automated testing may work for large, long-term projects (I’d say a year and up), in projects of smaller scale, I recommend that testing engineers check the accuracy of workflows and adequate data rendering manually.
Ensuring a Successful Rollout
With CRM adoption on the rise, there will be more projects requiring CRM software testing, so you should strive to have a good understanding of its peculiarities. I have four key processes that help me run CRM testing efficiently:
- Prep measures—populating the new CRM with realistic test data and testing it according to workflows
- Making sure everyone understands the business processes and workflows through productive in-team communication
- Testing the integrations of custom and OOTB features and how they are rendered in target environments
- Testing under different user roles.
These types of testing are crucial for rolling out a stable and secure CRM application.