Scrum Team - allocation of Dev, Test and other Tasks

The Developers are collectively accountable for making sure work is Done, tested, and of immediately usable quality. If they are wise, they'll apply good focus and finish work early and often throughout a Sprint. So think of it the other way round. How could any of them ever be unoccupied and idle?

As a Scrum Master, you do not manage "team task allocation".

A Scrum Team is a cross-functional, self-organizing, self-managing entity focused on achieving a goal. The Developers are the people on the team who create at least one Increment each Sprint. The Developers are accountable for creating a plan to achieve the Sprint Goal, adapting their plan each day as the Sprint progresses, and carrying out the work needed to get work Done.

Although a Scrum Team is cross-functional, it's also useful to have cross-functional individuals. These are often described as T-shaped, pi-shaped, or comb-shaped people. Although they may have one or a few areas of deep expertise, they are also able to contribute across various types of work.

For Scenario 1, you'd want to keep two things in mind:

1. First, you want to get work to Done each Sprint. That means designed, developed, integrated, tested, and ready for delivery, if not delivered. When Done, each Product Backlog Item should be valuable for stakeholders. You don't have design work, development work, and test work. A Product Backlog Item describes a change to the product that adds value to stakeholders and you'll likely need several different skills to get it complete.
2. Second, if a particular person's skills aren't needed on work directly for the Sprint, there are things for them to do. The first thing that comes to mind is refinement of upcoming work. They can help look at the Product Backlog and understand upcoming work, decompose it into smaller (but still valuable chunks), and eliminate dependencies. They can also work on pairing or collaborating with others and developing skills in other areas. 

For Scenario 2, you are going to want to help the Developers to understand their capacity and plan a Sprint Goal and select Product Backlog Items to support that Sprint Goal. Since each Scrum Team is built around a product, most people should have a good understanding of the product or be learning about the product and the stakeholders. The key would be to move from a cross-functional team to a team of cross-functional individuals who can take on a wider variety of tasks.

In each of your scenarios, the first thing you need to do is forget about the story points.  You don't have story points, you have work that needs to be done.  

Next, if you have a Sprint where the only work is writing code, then you will not be able to produce a usable increment and the Sprint should be cancelled and a new one planed.

Further, how do you know what is in an upcoming Sprint?  Each Sprint is planned as it happens and not in advance. This is a quote from the Scrum Guides section where the Sprint is explained.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

The entire Scrum Team is accountable for delivering at least one usable, valuable increment of Product updates each Sprint.  In my 30+ years of software development, I have never seen anything that was not tested before it was considered complete. Perhaps instead of worrying about when these two scenarios occur, it might be better for the Scrum Team if you focused on helping to ensure that the scenarios never occur.

A Sprint can be considered a small project. It has a clear objective to achieve - the Sprint Goal. 

The outcome of the Sprint is the valuable, usable Product Increment. Isn't it expected from any other project where software is being produced?

So, what do test engineers do when the software is being developed in the project?

What I am going to say was already said, but just to emphasize. The biggest mind switch a project manager moving to a Scrum Master needs to make is that you don't assign tasks. The team decides what to pull into a sprint from the product backlog (during sprint planning). One of the functions of the Scrum Master is to assure the team is empowered as a self-managing team. The Scrum Master should  assure the team as a whole makes the decisions. 

.I like this line from @Danial.

You don't have story points, you have work that needs to be done

As a Scrum Master you don't decide how many story points a team pulls in. The team decides how many backlog items they can pull in, irrespective of the story point count. Over time the story points can average to a specific value, but the team decide what workload they are comfortable with . 

This is a critical mind set change a traditional project manager has to make when moving to a Scrum Master. A Scrum Master is still a leader, but leading by helping the team to make decisions, and stop one individual to dominate 

You will need to trust the team that all will be done, but the team is not going to learn unless you allow them to think. Initially mistakes will happen, but persist and let the team learn from their mistakes.

(On your scenarios especially 1,, let the team break the tasks into smaller items, with each item having a Dev and QA component. Every sprint needs to produce working code that is also tested )