For any piece of work you undertake, there'll likely be one of three constraints on it: time, features and quality. It is absolutely impossible to constrain on all three; at best you can choose two.
In your case, you have a time constraint imposed on you. So a choice needs to be made between features and quality. From your question and reply to Telastyn's comment, it sounds like you also have a feature constrain imposed on you too. In which case, quality has to suffer. So the answer to your question, "Is there such thing as minimum testing required", the answer is yes: that minimum is the amount of testing that can be achieved in the time available. Those setting the constraints have chosen - even if they were unaware of it - to ship with bugs.
This is not a good place to be though. For the sake of your customers, quality should be prioritised over features if there's a hard deadline. So the way to ensure that adequate testing occurs is to test early and often. Break the work down into feature chunks, implement a feature and have it properly tested, before starting on the next feature. That way, when you hit your deadline, you have a higher quality product ready to ship.
You can of course go one stage further: use test driven development (TDD). Start testing before you even write the code by writing a failing unit test, then writing code to make that test pass without breaking any other existing tests. You still need testers to conduct exploratory testing early and often too as unit tests will not catch all bugs, but it'll catch many of them. That way, quality is pushed to the fore. The question of what's the minimum level of testing then becomes moot: you are always doing way more than some arbitrary minimum.