This has been an interesting question and debate topic. Let's start saying that in Scrum teams are not divided in development and QA, everybody is part of the whole team and takes active part in the Sprint. Further, QA's involvement goes thought all Scrum meetings, artifacts and roles. For instance, a Quality Engineer could be appointed as Scrum Master or even Product Owner.
If we think in planning meetings, QA should participate in user story definition and understanding of what is required to do. Moreover, QA has to create the acceptance criteria for all tasks. Also during the planning meetings, QA participation is crucial when estimating tasks complexity and duration. One important note here, Quality Engineers has to vote during planning poker meetings.
Remember that what we're estimating is complexity and time for tasks that has to be completed during the Sprint, and when I say completed I'm referring to the Definition of Done that has to be agreed by the team. One very common mistake is to include only development's estimations for tasks and as a result tasks get implemented but not tested or tested with bugs.
During the Sprint, QA has to participate in the Daily Scrum Meeting to report its status and blockages. One common Scrum smell is QA reporting that it doesn't have anything to test. Typically QA has almost anything to do during the first weeks of the sprint but in the last days it's suddenly overwhelmed. Again, this is a consequence of bad planning and a violation of the "Sustainable Phase" principle. Workload should be evenly distributed both for development and QA during the Sprint, avoiding killing hours of work at the end only for QA.
Also at the end of the Sprint, QA participates preparing and presenting the demo to clients. Further, during Sprint Retrospective, QA has to reflect in its work and interaction with development and make the necessary adjustments for the next Sprint. One word of caution though, don't wait for the Sprint Retrospective to adapt, adapt as soon as you feel the need.