A redditor asked the following question:

Question#

Where do “To-be-tested” / “In Testing” tickets reside when using trunk-based development release branches?

Read the whole question on Reddit.

My answer#

There is no “in-testing” or “in-review” column in Jira. There might not even be a PR at all.

I’m a developer who uses this technique with my team. The one who suggested it in the first place and convinced everyone to give it a try. After two years, nobody wanted to go back.

First, there are different kinds of changes. When you’re modifying a feature, the first step is usually just making the change possible. That’s basically refactoring: adjusting the internals of the system so a behavior change can happen. Automated tests help with this, and often you can push straight to main without extra human review. If the change is user-facing, you can either release it immediately or hide it behind a feature toggle and release it later. Deployment and release aren’t the same thing. That’s why, instead of long-lived Git branches, you should use a technique called branch by abstraction.

Second, people need to actually work together. Literally. At the very least, your team should be doing synchronous code reviews and testing. At the other extreme, there’s mob programming. Most teams fall somewhere in between, and it can vary depending on the task.

Third, automation! You need to be able to push commits to main quickly. If your system is huge, run the most critical tests before integration. Once a commit lands on main, run the full test suite. If something breaks, the team’s top priority is fixing it, or rolling it back.

The key is to keep changes very small and focused. Even without automation, you can narrow the scope enough to test manually before pushing. The real prerequisite for trunk-based development is a team that works together. Whether you use Scrum or not doesn’t matter, but you absolutely need Extreme Programming practices in place.