What should we do with incomplete tasks?

What's the downside of doing them in the next sprint?

It sounds like the current sprint was overestimated to begin with and there are a lot of unknowns due to no dedicated testers. Is Scrum the right framework to be used in this scenario? XP might be better or even Kanban, so that the team can focus more on finishing work than having so much in flight at the same time.

Does the development team have a desire to address the root cause of the bugs and increase their quality? Definition of Done can help make their quality standards more transparent. 

Adding onto the XP thought, perhaps there's things the team could try such as paired programming, mob programming, or team peer code reviews in order to meet their quality standards. 

Stacking a Sprint full of stories that aren't achievable without a lot of bugs, rework, and undone work will surely become frustrating to the team and any stakeholders involved. 

Just on(e) day of our sprint left, and we have a lot of tasks in reviewing and test phase that we can not accept them complete

To me, this seems like a good opportunity to educate the Development Team about the old Agile adage "Stop starting, start finishing."   Also, how can the team improve their "Focus" (Scrum value) to avoid situations like this in the future?

I would be thankful for any idea that helps us with what can we do in this sprint and future.

What are your thoughts about stopping new work completely, until:

• the defects and technical debt you have accumulated so far is remediated, and
• you have a team which can meet a release-quality Definition of Done?

Why the need for "dedicated testers"? Other scrum team has a ratio of 1:5 or no QAs at all.

we have a lot of tasks in reviewing and test phase that we can not accept them complete

Are your backlog items too large? One possible cause of having a lot of work remaining to be tested is that the items are too large, and therefore need a lot of testing before they can be determined as complete. Smaller items lead to smaller cycle times and can result in less of a buildup of testing work.

It would be really tough for the team if we move them in the next sprint and also makes our Jira messy.

Won't this affect the transparency if you don't move incomplete items to the next sprint ? How messy would that be ?

For solving this problem in a midterm we focused on: our DOD, quality of our coding style, developing our automate tasting and culture of the self-organizing team, but it's a real problem that we have a lot of weak outputs that make us more busy with bugs and improvements.

Sounds like you accumulated a lot of tech debt which needs high attention now. Like others mentioned , right time to "stop starting and start finishing". For adding any new code may be add efforts for also clearing the tech debt.

We don't have a dedicated tester, and two of our seniors review and test the tasks (technically & functionality) and PO also tests functionality.

Can this problem be solved by introducing best practices like TDD/BDD ,test automation ?