The release train supports a long-term program that may have many teams and projects inside of it. The teams synchronize, lining up sprints and releases, so the code can be deployed at the same time for each increment. Older versions of SAFe suggested a "hardening sprint" (or two), not for testing within teams as much as for coordinating interfaces between teams. It might be best to think of the hardening sprint as a transitional step something new program teams need to make the release train successful.
Each release team (remember, that's 50,125 people) meets once at the beginning of each release cycle to develop Program Increment Objectives, and the team-level objectives that make the increment objectives possible. The meeting is typically two days long. In addition to simply planning, the meeting has other benefits, like allowing the team to have a sense of team-ness to create the face-to-face conversations that make real progress possible. The meeting include representatives from both business and technology; over the course of the event the two groups merge and align, again reducing friction and errors from misunderstanding.
After planning, the team works on the next program increment (PI), and a small team needs to steer, or coordinate that work to success. SAFe calls that the release management team, which typically consists of the Release Train Engineer (a technical role), Product Management, and a few executives who are not committed to that program full-time. It may also include development managers, senior testers, architects and other roles on the program that could give input. This is the group that communicates with external groups on timing, and takes corrective action when there are schedule problems. SAFe suggests that the group meet weekly.
Crappy code can't scale
One of SAFe's public claims is that "crappy code can't scale." To avoid crappy code, SAFe suggests a handful of practices that are aimed more at prevention than traditional test/fit testing. SAFe starts with Agile Architecture, a principal that architecture is emergent, but the system architecture needs to evolve ahead of the newest features, to make adding those features possible. It includes continuous integration, having the software build and automated checks run for every check-in. SAFe advocates test-first as a philosophy, not just unit tests but also at the specification level. This practice of creating concrete examples, down to the inputs and expected results as a collaborative, whole team effort is called Acceptance Test Driven Development in SAFe.
SAFe also includes classic extreme programming practices like pair work, not just for programmers but for many roles, along with refactoring (improving the design of existing code) and collective ownership. Collective ownership of code gets more complex with multiple teams, but it also means that teams can make corrections instead of creating a "ticket," or "make-work" for another team. This prevents the first team from being blocked and also does not create priority problems for team two as team one's priority and blocker will probably be team two's "nice to have."
Sign up for CIO Asia eNewsletters.