What should be the cut-off time for Developers so that QA get enough time to test in 2 week sprint?

That would be a great challenge statement to pose to your team to figure out during Sprint Planning (the goal is not only what can be done but how the team will accomplish it). 

I don't feel there's a one size fits all answer to this. This really varies on the nature of the work you're doing and how much automation you may have in place. Also keep in mind the team itself should be focused on a Sprint Goal which means even though people within your development team may be specialized (Software Development or QA) the team itself is responsible for producing a working increment. 

This may sometimes require some flexibility of the traditional Dev and QA roles to be successful. 

What should be the cut-off time for Developers so that QA get enough time to test in 2 week sprint?

Suppose a team collaborated closely and limited their Work In Progress. Would that change your thoughts about having any “cut-off time” apart from the end of the Sprint?

The idea that, within the context of a Sprint, there needs to be a cut-off time where development stops and QA starts, seems to be indicative of one of two things.

First, it could indicate a traditional or waterfall mindset. Rather than having a strict separation, it would be better to find ways to incorporate the QA process throughout the entire Sprint, from the time a Product Backlog Item is being refined through the item being considered "done" and ensuring that there is a "done" Increment at the end of every Sprint. It's normal for different people to have different strengths or specialties but a cross-functional team with reduced hand-offs (such as a hand-off between a developer and a tester) will make your process leaner. Instead of handing work off, the specialists in testing should work closely with developers to help consider testability and testing throughout the process.

Second, the fact that the hand-off occurs in the middle of a Sprint seems to be a poorly defined workflow. There are cases where independent quality assurance is desired, or even required. However, I'd question why this would happen in the middle of a Sprint. Instead, in this case, I'd look at the definition of your workflow. The goal would be to have a definition of done that results in a suitable Increment for handing off to the independent QA at the end of every Sprint. I would be cautious in this case, though. Independent QA is not the only instance of testing - this is just waterfall and will only slow down feedback loops if it takes several iterations for problems to be found, triaged, and fixed or if Sprints are interrupted with issues found during downstream testing that is considered critical.

Thank you everyone for the response.

@Tony - For Automation, what is the recommended way? Doing automation Story-By-Story?

In current project QA guys have automation suite which focuses mainly on Regression / base functionality.

When new story comes to QA, they test is manually and later on they write the automation scripts to automate the story (This sometimes happens even after the sprint)

So what is the best way to handle it?

In current project QA guys have automation suite which focuses mainly on Regression / base functionality.

When new story comes to QA, they test is manually and later on they write the automation scripts to automate the story (This sometimes happens even after the sprint)

So what is the best way to handle it?

The best solution is to move automation sooner.

I think it makes sense to have the people writing the automated tests do some level of manual testing. Seeing what the users see plus being able to inspect the final output of web pages both help in automated testing. But writing the automated tests earlier, as part of the Definition of Done, is helpful.

The next question may be how you write sufficient automated tests before the end of the Sprint. The answer to that is to stop isolating your test development to QA. It may make sense for your QA team to maintain and have accountability for your automation test framework, especially for system and acceptance tests, but that doesn't mean that members of your development team can't write tests at the unit, integration, system, and acceptance level, with your QA team being involved in reviewing and the higher level tests.

Unless there is some need to have independent QA, don't. And even if you do, still have QA done by everyone and have the independent QA be a final checkmark.

I don't think there is a one size fits of answer here. This needs to be agreed with QA team rather than enforcing a timeline to to them.