I am a dedicated tester that works on a Scrum team working on a web app. What we do with regards to QA tasks on the taskboard, is we first choose the user stories that are to be tackled in the sprint. We then split those stories into sub-tasks, and add in two sub-tasks for QA: to develop acceptance tests and to run them. The task to develop the tests can generally start immediately and in tandem with the engineering tasks, and the task to run the acceptance tests is performed once the engineering work has been completed on the story. It should be noted that the engineering team also has an acceptance test task which is performed on a local machine deployment, and the QA team then performs the more in-depth testing on a deployment closer to production.
It is not useful for the QA team to attempt to test every task the engineers do, as much of it can be refactoring or such small pieces of functionality that it is much better to take as a whole. All commits go through code review anyway. It would waste a lot of time going back and forth between the QA and Eng teams asking how to test things and being told that the functionality is only on the backend and would not be visible to the user etc. Each feature is already split up neatly into stories and so these stories are the units of work that are tested by the QA team as part of the sprint.
The only downside to this approach is that the engineering can either be left with very little to do in the last 2/3 days of a sprint, or that they can easily be overwhelmed by sprint bugs to fix that may overflow into the next sprint. However, we have found that the very short feedback loop on finding bugs (as bugs can be found in just a day or two from coding) is much preferable to having a cleaner sprint plan but a feedback loop of up to two weeks.