What you have described so far is something I'd call 'scrummerfall', but given how it often turns out, could be spelt scrummerFAIL instead. I see several issues that need to be addressed. @Aruna covered several in their answer, which gets high marks from me. To what they have said I would add the following.
1) the team doesn't understand what 'DONE' means if things are not in a 'ready to ship' state (e.g. testing still needed, bugs found that require fixes, etc) at the end of the iteration.
2) There does not seem to be an emphasis on good 'craftsmanship' of the code, as evidenced by the lack of TDD and unit tests. In an iterative development environment, you need a pretty robust set of automated tests both at the Unit and Integration/Acceptance level in order to be sure that the stuff that was built and working correctly in earlier iterations is not broken by work done in later iterations. If this testing is not automated, then the amount of regression testing needed at the end of each iteration grows larger and larger until it takes over the entire iteration and no work can be done. As a tester, you need enough time in each iteration to produce automated acceptance tests that can form part of a regression suite for use in following iterations.
3) (in a sense continued from #2) In sort iterations it is crucial to build in quality upfront as there is not enough time to try and 'test in quality' during an iteration. I strongly think developers need to be doing some kind of 'test first' practice in order to be successful in the long run. I know of no other practice that can have as much impact in reducing the defect rate. BDD / ATDD (two terms for pretty much the same thing with a few minor differences) would be preferred, TDD otherwise. All of the *DD's are DESIGN/Development practices, designed to help the developer better understand what they are about to code by looking at the required behaviour, as expressed by tests, FIRST before they write code. While unit tests are produced, they are NOT testing activities, and despite the name 'test' in the name, unit tests are the developer's responsibility.
4) They have not really integrated test into the team, and are basically still 'throwing stuff over the fence' at the end of an iteration, that means you are basically still working in separate silo's and not all part of one team. You need to be testing a story as soon as the developers think it's working, not after they finish a sprint.
5) If you are doing scrum without anyone on the team having had any kind of scrum related training (or prior experience on a high performing team) then it's a recipe for failure, have management invest in at least ScrumMaster training for your SM, and I'd strongly recommend Product Owner training for the PO as well.
6) Everyone on the team needs to be clear on how test fits into things, to that end I'd recommend everyone on the team be tasked with reading two very good books that cover this
a) Agile Testing by Crispin & Gregory
b) Bridging the Communications Gap by Gojko Adzic
7) in terms of community, I'd strongly recommend checking out the Agile Testing section of the Skills Matter website where there's a wealth of good free into in the podcasts section. Also, the Agile Testing group in Linked-In is a great place to talk with other agile testers.