Don't use timers for game tick. They are completely unsynchronized with the display refresh rate and you'll always get stutter. You can't make it smooth that way. Definitely don't use msleep or the like either. That's not what it's for.
Change your approach - don't assume a constant for the time interval, that's not happening either. There's no software or hardware that supports that and no serious game engine does it like that.
Instead do your game tick calculation and request display update at the end, e.g. QWindow::requestUpdate. In your paintEvent do your rendering and start another game tick. Qt is (by default) synchronized for 60Hz output. If you sync it properly using monitor v-sync the game runs as smooth as is physically possible and it only takes as much CPU as it needs and no more (Qt idles out when waiting for display's vertical refresh).
That's the basic version. A more advanced version is where you run separate game and render threads and do a so called pipelining - update Nth frame game state on one thread while rendering N-1 frame on render thread. It requires a bit more setup and is necessary when you have so much calculation that you can't fit it together with rendering in a single 16ms window. For simple cases, where your calculations take less than that the first approach is fine, you don't need separate thread.
In any case don't use QTimer for any of that. Don't try to ask for specific time, that's not gonna happen and if you base your animations on that assumed constant interval they will always be choppy. Even if you manage to tweak it on your machine it will break on another, where the timings are a little off compared to yours. Instead measure how much time has actually passed from last frame (use QElapsedTimer for that, like in your threading approach) and use that as a delta time value that you multiply all your movement, animations, velocities etc. by.
