Triton Student System (TSS): System Testing

As we move deep into the build phase, testing the Triton Student System (TSS) is a necessary part of the process. Just like chefs taste their dishes along the way to ensure balance and quality, we test what we are building to make sure everything works as intended. TSS is a large and complex system that connects multiple areas across UC San Diego. Testing builds confidence with the system, gives us opportunities to mitigate bugs, reduce confusion amongst users and smooth out bumps in daily processes. 

How We Test 

There are several types of testing that we are performing to build out the new TSS. Quality assurance (QA) testing anduser acceptance testing (UAT) lay out the groundwork of what needs to be in the new TSS. They make sure all the necessary pieces are in place and functioning properly before we build on top of them. 

Quality assurance (QA) testing is guided by the requirement traceability matrix (RTM), a checklist of requirements that makes TSS do what it is intended to do, along with a step by step outline of how things are supposed to work in the new TSS. This testing is essential because it catches problems before they become bigger issues and confirms the system will actually support users’ daily work. 

User acceptance testing (UAT) is another foundational type of testing that is being performed currently. UAT focuses on 22 work process areas, such as student registration, enrollment and advising, that were discussed in earlier planning sessions called Process Design Workshops. UAT sessions give testers and subject matter experts in their work process area the opportunity to try out the new TSS with their actual work tasks, making sure it is ready for daily use and works smoothly before launch.

System integration testing (SIT) focuses on making sure TSS can communicate properly with other campus systems. When TSS connects to external systems such as CourseLeaf or financial systems, this testing validates that information transfers accurately between them. The goal of SIT is to ensure data moves seamlessly between systems – without duplication, loss, or syncing errors. 

The final type of testing is end-to-end testing, which ensures nothing falls through the cracks when different departments work together. Instead of focusing on a single process, this comprehensive approach confirms that everything works together across different departments, applications and systems, just as it will in daily campus operations. 

The build phase of a project and testing go hand in hand. Testing the new TSS  is not just about finding bugs, it is about making sure the system truly works for those that will use it every day. Each round of testing, from QA to end-to-end testing, gives us a chance to smooth out issues, build confidence and get closer to a system that supports students, faculty and staff. 

Testing is an investment in the long term. By taking the time to perform these tests, we are building the new TSS so it can serve the campus for years to come. Over the coming months, you’ll hear more about TSS testing and possibly opportunities to get involved. Want to learn more about TSS testing? You can dive further into TSS testing by exploring our TSS Testing Fact Sheet (Collab access required).