When implementing software with an implementation partner, client testing is crucial for project success. So, how can clients improve their testing and therefore improve their chances of a successful launch and user adoption? As a consultant, I have worked with many nonprofits of different sizes and organizational cultures. Through numerous projects, I’ve observed a consistent trend among clients who achieve successful launches and high user adoption rates. This common factor is the practice of testing as a team across different functional areas rather than testing individually.
The Process: Comparing Team Testing vs. Solo Testing
When implementing new software, one of the client’s most fundamental responsibilities is to test the software and provide feedback to the implementation team. If you are unfamiliar with the testing process for most software implementations, it generally follows these steps:
- The implementation team completes a set amount of work, typically defined within a sprint.
- The implementation team then provides the client with a demonstration and various test scripts (instructions for testing).
- The client is responsible for using these test scripts to evaluate the quality of the work. If any bugs are found, the client must submit a feedback record (such as a ticket or case) to the implementation team for resolution.
- The implementation team resolves the feedback records.
- This process is repeated iteratively.
The testing performed by the client is a crucial part of improving the quality of the final delivered solution. It also enhances user knowledge and capability, both of which are key factors in driving better adoption of the new system.
The most common approach to client testing, which I consider the standard version, is what I call “solo testing.” In solo testing, the client assigns test scripts to individual testers, who then conduct their testing independently. Testers schedule their own time on their calendars, evaluate their own work, log their own feedback, and share their individual findings in team meetings.
The key characteristics of solo testing are:
- Each tester is fully responsible for testing their own work at their own pace and on their own schedule.
- Each tester only evaluates work that directly relates to their functional department.
- Each tester reports their thoughts and feedback during meetings or asynchronously.
While there is nothing inherently wrong with this method—many clients have experienced success with it—it is worth comparing this approach to “team testing.”
Team testing assigns test scripts to individual testers but introduces a collaborative element. The client schedules meetings where all testers collaborate to perform and discuss testing in real-time. Testers work through their assignments, “pass” test records upstream and downstream to teammates, and collectively address issues as they arise. If unresolved problems persist, they log feedback records. By the end of the session, all testers understand each other’s progress, reducing the need for follow-up reports.
The key features of team testing are:
- All testers participate in pre-scheduled collaborative sessions.
- Each tester is responsible for their tasks while contributing insights to others’ assignments.
- Real-time collaboration ensures the entire team stays informed about submitted feedback and progress.
Let’s look at a real example involving a non-profit organization that operates as a grantmaking entity with three primary departments: Grantmaking, Outcomes, and Finance. In the initial step of team testing, the client lead will schedule weekly meetings for stakeholders from each department to participate and collaborate.
During these meetings, the testers will observe a member of the Grantmaking team as they review a test grant application. This process involves testing various functionalities and ultimately “approving” a test grant record. Following this, all parties will watch the Finance team as they receive the approved test record and go through the necessary steps to review the application and prepare a disbursement for the test grantee. Next, the Outcomes team will examine the test grant, review the test application, and assess the test grantee organization to implement their outcomes tracking methodology.
This collaborative approach exposes each team to more of the overall process, allowing them to understand the unique ways different teams interact with the data and system. For instance, the Grantmaking team may be focused on testing the grant application process, which directly impacts how the Outcomes team tracks successful results. Meanwhile, the Finance team gains insight into the approval process and the circumstances that trigger the disbursement of funds to organizations.
As the testing unfolds, members from each department learn about each other’s roles and how their work influences one another. Once the project goes live, all teams will have a deeper understanding of the decisions made and the trade-offs considered throughout the process. Consequently, the adoption of the new system will be more positive and effective.
The changes are subtle and require slightly more proactive planning on the client’s behalf, so what are the benefits that make Team Testing so much better?
How Team Testing Enhances Project Success
1. Teams provide better feedback.
One significant advantage of team testing is that testers often answer each other’s questions, which helps to address potential feedback before it is escalated to the Implementation team. Although this metric can be challenging to quantify, it is something I frequently hear from clients who conduct team-based testing. During these testing sessions, when someone asks a question or requests a change that would benefit their department, the group has the opportunity to review the request and ensure it does not create issues elsewhere.
What often happens in traditional solo testing is that each user provides feedback that is entirely specific to their own processes or departments. As a result, contradictory feedback is often submitted. In the best-case scenario, the implementation team notices that a request might be short-sighted and raises it for discussion, either within the ticket or during a meeting. We can then discuss the issue together and determine whether the request should be implemented. In the worst-case scenario, the implementation team does not notice the contradiction and implements a change for Team A, which later causes problems when Team B tests it and realizes that the change has disrupted something on their end. Team B then requests that we revert the change. In both scenarios, valuable time is wasted, and in most software implementation projects, the consultants’ time is expensive!
Teams that test together can provide instant internal feedback on ideas, ensuring that when they submit requests to the implementation team, all parties are confident that the request is valid and should be implemented.
2. Team testing encourages collaboration among individuals.
The second benefit of team testing is that it encourages team members to build connections with other users. This collaboration fosters relationships and enhances knowledge about the platform, leading to improved processes and a better overall understanding. Typically, in Solo Testing, individuals tend to only test their assigned test scripts, which relate directly to their department or function. This is understandable, as no one wants to take on extra work. However, when testing as a group, testers organically interact and engage in discussions with other team members, ideally including those from different departments. This interaction exposes the team to a variety of factors, questions, and issues that they may not have noticed on their own. By testing alongside others and observing how different teams utilize the same data or processes, testers gain valuable internal knowledge and a shared understanding.
3. Team testing increases social accountability.
The last major benefit of testing as a team is that it requires the client to schedule dedicated time for testing. The client must take the initiative to coordinate everyone’s calendars and send out invitations to ensure that the right people are present for each session. While this may seem straightforward, it’s crucial for achieving successful outcomes as a team.
Unfortunately, I often observe the opposite situation: testers neglect to schedule dedicated testing time and think, “I’ll test this on Friday during my free time.” However, this free time often gets filled up with meetings or urgent tasks. By sending out calendar invitations that include other stakeholders, it adds a layer of accountability to the process. This approach signals that the testing is important not only for the tester but also for others who are expecting their contributions.
The added social accountability significantly improves the likelihood that testing will actually take place rather than being consistently postponed due to daily emergencies.
Conclusion – Give it a Shot!
Testing as a team is not a guaranteed solution for project success, but I have repeatedly seen clients benefit from adopting a proactive approach to team testing. Clients who embrace this method typically report:
- Teams develop creative solutions to challenges that benefit everyone, avoiding costly rework from the implementation team and saving money.
- Greater accountability in testing, which leads to higher quality solutions.
- Improved collaboration across departments, fostering better team cohesion and understanding.
If you are about to start a new software implementation project, consider making the extra effort to test the software as a team. A little extra planning and collaboration will have a huge impact on your eventual success.