The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the Development Team, regardless of the domains that need to be addressed", and "individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole". If you were adhering to the rules of Scrum, then the whole team would be accountable and you wouldn't have "developers' tasks" or "testers' tasks" but the team would be collaboratively working to get the work done per their Definition of "Done" and ensure the Increment is potentially releasable by the end of the Sprint.
Kanban (assuming you are talking about David J. Anderson's Kanban method) says even less. The principles of Kanban include "start with what you do now" and "respect the current process, roles, and responsibilities", and then "agree to pursue incremental, evolutionary change". If you follow the various practices about visualizing workflow, making your policies explicit, managing the flow of work, and incorporating feedback loops and collaborative improvement, you may identify areas where you want to change your workflow and policies and roles. It's about doing what is right for your team, rather than having explicit definitions - different teams and organizations using the Kanban Method may reach different conclusions.
More important than the methods and frameworks, though, are your organizational constraints. For example, I have experience in regulated fields. When building safety and life critical systems, there may be requirements placed upon the development process. One such requirement for some systems is the need for independent verification and/or validation and objective evidence of that independent verification and validation. This means that a group independent of the development team must perform analysis and testing of the software and system to ensure that it conforms to requirements and is safe. However, it does not mean that all testing and verification must be done by an independent group.
We, in various engineering fields, have found that it is faster and cheaper in order to find and fix defects closer to their point of origin. Two of the wastes from lean are relevant. Discarding or reworking due to earlier injected defects is one type of waste. Hand-offs (of product or knowledge) is another. Reducing defects and minimizing hand-offs to those that are necessary leads to improved quality, improved flow, and often less cost and time.
Even in cases that require an independent group to perform testing, it's wasteful to rely on that group to perform testing. The people producing the product should also be involved in testing it. There may be reasons why an independent group also has to test, but this group should exist to satisfy regulatory compliance and not exist to find defects (although the extra safety net is also good when you're dealing with the most life and safety critical systems).
In the end, I'd say that it's ineffective for any team to have a silo between developers and testers. This applies to both agile and plan-driven teams.