I am looking for the high level general steps performed by a QA Engineer on a scrum team using JIRA and a test management tool like Test Rail. I realize this will be different for every company but once a sprint starts, what general steps do QA folks take to move a story from Ready For QA to Done?
You don't wait for a sprint to start before doing test work. You should have been present during the planning of the ticket and given feedback on the feature. Were all possible scenarios spec'd out? Could something be added to improve the testability of the feature? Do you need to create additional work items for yourself to set up an environment or generate test data? Is the acceptance criteria clear and testable?
You will need to spend some time thinking about a test strategy and hopefully writing test cases. This does not need to wait until the sprint starts. This should be communicated to the team but is especially important to discuss with the developer implementing the feature as it could expose a difference of opinion about what the feature is supposed to do.
Once the ticket moves to ready for QA, deploy the feature and run the test cases that were thought about / documented earlier. If a blocking issue is found it moves back into open / re-opened.
Done can have different meanings, but usually means it is merged into master or could be merged into master.
Most common path is: Ready for QA -> In testing -> Done (or reopened). I can hardly see a need to add any additional stages here. Maybe you could need them when testing a big part of functionality. Then, for example, you could use such steps as: "Under Smoke testing", "Under load testing" etc. If there is a bunch of test cases and some of them are automated, then the "In testing" phase can be divided into "Manual" and "Automated" parts.
But, in my opinion, additional phases should only be added when you really need them to get everything organized. Otherwise they can just make everything too complicated. People would sometimes mistake one for another etc...