This is a classic challenge with teams starting in Scrum. Most teams are not used to working in this way and moving to these small product increments will have a few bumps in the road. A few things to consider that may help:
Timing and Availability:
You want a consistent sprint length and timing of events. If you have a 2-week sprint that starts on Tuesday, you should stay with that. This will allow people to adjust their schedules to match that. In the case of your QA person, you may want to make sure you are starting your sprint at a time that works best for them or they may been to block off the last few days as unavailable for other work. (I'll get to the multiple teams thing next)
Generally speaking, dedicated teams are preferred when doing team work. What happens when we split people up onto multiple teams and efforts is that we lose time to context switching and schedule problems. Often, we lose more time to that than we gain by "efficient" scheduling of people. Studies have found that we lose as much as 20% capacity to context switching for each extra effort we split our time onto. That said, if you can't reach that goal just yet, the next best thing is to at least have consistent availability to plan around. This can reduce the negative impact of that multitasking.
Stop Starting, Start Finishing:
It is common that team members divide and conquer on a number of backlog items which are worked on over the course of the sprint, often passed to QA at the end, the hopefully wrapped up by the last day. This is often a stressful and frustrating experience for everyone. Rather, teams often find more success in rallying around a few (or even one) backlog item and moving them along quickly. In these cases, the average backlog item moves from start to finished in 2 - 3 days, meaning all members of your team are engaged throughout the sprint. Also, it means of one or two items don't wrap up, you aren't left with nothing.
Finally, a thought on Kanban
Every team I've worked with who used Kanban because they couldn't manage the constraints of Scrum actually had more trouble. While Kanban doesn't enforce a lot of rules, one of the things it asks us to do is measure and observe flow of work and it will spotlight those challenges that you are already seeing. If you aren't making changes to your process to address those flow challenges, you aren't getting anything out of Kanban.