Mini-waterfalls aren't Scrum
What you are implementing is a mini-waterfalls approach where you have multiple small waterfall development efforts. If that is how you want to run your team then I'm not going to tell you it's wrong. But, this is not Scrum. If you want to run a Scrum process you should be looking to deliver completed enhancements throughout each sprint.
You also need to let the team organise themselves within the sprint to get them working together, most of the time, to achieve the work in the sprint. Hopefully this means people are working together and collaborating on stories most of the time, as opposed to testers waiting until late in the sprint to do their work, or developers twiddling their thumbs for the last couple of days.
Comparison of mini-waterfall vs. Scrum
This section will try to answer some of the follow-on questions from the comments sections.
In a mini waterfall the first few days may be spent by the devs working out how they are going to build something (design) and ultimately building that thing. They may work together or separately on their enhancements. During this time the testers are likely writing the test cases for the work the developers are doing. Once the development work is done, the testers can start testing it. Hopefully there is enough time left for them to do all the testing they want and development didn't overrun. Developers can now spend their time fixing previously logged bugs, which the testers can then confirm are fixed. As bugs come in from the testers on the new enhancements the developers fix those. Again, hopefully the testers don't find so many issues there isn't time to fix them during the sprint. If something is found to be seriously broken and needs to be rewritten (maybe the original design misunderstood the problem) you need to squeeze in another dev-test cycle in the time remaining.
With a Scrum approach, on day one you still do some planning of how work will be done. This should include devs and testers. Testers can highlight things they would look to test for to make sure developers consider those things in their plans. This can also allow the testers to identify small chunks which the developers can deliver to them early for testing. Any test cases needing to be written should be included in the plan for that story. After this is complete the team gets together to work out what pieces of work they will all pick up first. This is repeated each day in the 'daily scrum' meeting. The team will usually not work as individuals on their own enhancements, where possible two or more developers will split up an enhancement to work on in parallel. If all the developers suggested they were about to start work on things which would take them 3 days before there was anything worth testing, the testers should speak up that they need something to do. Possibly some of the quicker bugs to fix need a lot of testing, let's get those fixed first to keep the testers busy while we work on something bigger.
Hopefully this allows a more efficient use of the teams time. I think the situations where the test cases take exactly as long to write as the code are rare. By splitting the work up and allowing the team to decide on a daily basis what they work on they can optimise the use of their time and work together to achieve the sprint goal. The benefits of working like this are many, too many to go into here.