testing, story point and sprint completion

In one particular sprint, a tester had a planned vacation (not for the entire sprint but some part of the sprint). The team started work with upto 12 story points. As each story was completed, the tester started testing it. The development was way ahead of the tester as expected.  However, the working tester fell sick and was not able to complete testing and the stories were not considered done (per our definition).

Why do one of your two testers need to test each story? Is there a reason why the testers aren't being used as experts and specialists in testing and sharing their knowledge with the entire team and building capabilities to remove the bottlenecks and need for hand-offs in the development process?

What should happen to the remaining 3 stories, which have been developed but not tested

1. Move them to backlog to be considered in next sprint. In which case the current sprint velocity will be 6

2. Keep the current sprint velocity as is but convert the testing sub-task to task to be worked in next sprint. In which case next sprint will have testing stories with its own estimate.

3. Other option

You said it yourself - the work is not considered done per your team's Definition of Done. It doesn't make much sense to consider the work to be done and give yourself credit. Because of this, option 2 doesn't seem to be an appropriate choice.

What does your Product Owner think about the importance and value of this unfinished work? Would completing it in the next Sprint add value to stakeholders? Or has the opportunity for it come and gone? Regardless of what you do, I don't feel that it's appropriate to consider partially done work when planning for the next Sprint.

In the team’s current way-of-working, what do testers do before they have any work to test? Do they prepare for testing it in some way?

@ Thomas, The testers are not testing each story but one story per tester. Per the company rules, the testers are responsible for testing and ensuring that there are no bugs/issues. The reason for these options are for determining the current sprint's velocity and the team's average velocity. Each of the option has an impact on the velocity

@ Ian, the testers write the testcases/ test script before testing

1. Move them to backlog to be considered in next sprint. In which case the current sprint velocity will be 6

@sri bhindi, Considering that you have incomplete work, what does the scrum guide say that should be done?

2. Keep the current sprint velocity as is but convert the testing sub-task to task to be worked in next sprint. In which case next sprint will have testing stories with its own estimate.

How would this practice be beneficial and what would it make transparent?

The development was way ahead of the tester as expected

From this line, it appears to be a common occurence, has your team considered adjusting their capacity? It appears to me that your team is packing work into the Sprint, is this a correct statement?

In which case the current sprint velocity will be 6

You seem to be worried that the velocity has gone down, why?

Per the company rules, the testers are responsible for testing and ensuring that there are no bugs/issues.

Why? What benefit does this have? What value does this add to stakeholders?

Sri, a few observations if I may:

Per the company rules, the testers are responsible for testing and ensuring that there are no bugs/issues. 

What is the level of Scrum "buy-in" within the company?   Within senior management?   Is there awareness within the company that micromanaging teams and not allowing them to self-manage around their forecast is anti-Scrum?

What should happen to the remaining 3 stories, which have been developed but not tested

If they do not meet your Definition of Done, then they should not be considered in any velocity calculation, since velocity is based on tallying up the story points of completed items.   Am I missing something here?   Keep in mind Sri, velocity is a planning metric.   It is a misuse to identify it as a measure of team productivity, or as something for teams to "get credit for".

Of more concern to me is the team approach to remain in skill silos.   Why are they not focused on moving the work forward by any means necessary, instead of being dependent on other team members to do specific work?   Do they (and the company) realize how fragile this approach is for getting work done?   

Assuming you are the Scrum Master Sri, what are some ideas you can present to the team to help them avoid such failure in the future?

the testers write the testcases/ test script before testing

Why can’t developers execute the prepared test cases and scripts?

The development was way ahead of the tester as expected.  However, the working tester fell sick and was not able to complete testing and the stories were not considered done (per our definition).

I agree with what everyone mentioned on this topic. For me it also looks like 'Scrumfall' , a waterfall within a scrum. There are handovers between team members in phases , absence of one member disrupts the sprint, dependencies within team members. Sri, if you think such situations can happen again and is unavoidable then you must think on the lines of cross skilling team. 

As per guide 

Development Teams are cross-functional, with all the skills as a team necessary to create a

product Increment