I’m going to answer from a Drupal 7 perspective, since that’s the platform I use, but I think that the same general principles apply in WordPress. Things have changed a lot in Drupal 8+ with the Configuration Management system, but I’m not sure that there’s a parallel to that in WP, so I’ll avoid talking about that.
In general, your choices are:
1. Manually repeat the database changes in each environment as you deploy up the chain toward LIVE
I’m not sure about in WordPress, but if you add the code for a new Drupal module that includes database changes during installation in the DEV environment, and then deploy that code to the TEST environment with the database from the LIVE environment, Drupal will automatically want to re-run those database changes when you check for pending database updates.
Other types of operations that might require manually “replaying” database updates in a higher environment as you suggested would be any site configuration change that modifies the database. In Drupal, common examples would be adding a new page type, adding or editing Views, or adding or manipulating the order of some menu items.
Obviously this approach works, and is easy to understand, but has the disadvantage of being prone to human error as the database changes as manually repeated in each environment. There is also a necessary delay between the deployment of the code and the database changes that can only be as short as your fastest human can manipulate the site’s admin UI.
2. Automate database changes in code so that you can actually “deploy” the database changes in a repeatable way in each environment.
There’s a Drupal-ism called an “update hook” that allows you to write code that can automate tasks that you want performed during a deployment. This can include things like enabling new modules, adding new menu items, etc.
Broadly speaking, this approach fits in with a philosophy of capturing as much of your site’s configuration in code, and making deployment operations repeatable. For further reading on this, I would recommend the Dcycle Manifesto, in particular the section titled “Incremental deployment must be standardized and repeatable.” Again, the tools for this in WP would be different (e.g. “WP-CFM” for WordPress instead of “Features” for Drupal 7), but I think the concepts are largely transferable since both platforms share the complication of both content and configuration being stored in the SQL database.
@ataylorme is a very smart cookie who works at Pantheon and wrote a series of blog posts on configuration management in 2016, including one whole post about managing site configuration in code in WordPress.
I hope that helps and has not confused matters further. In general, I think this approach cuts against the grain of how many Drupal and WordPress developers are used to working, and it can be a bit more time consuming, but it pays huge dividends over time to treat your site configurations as code rather than database changes by giving you an increased sense of control, repeatability, confidence in your deployments, and the ability to have other developers review changes before they are deployed.