Do principles of testing actually work out in real life??

Principles of testing play a vital role in analyzing and judging different projects and thereby concluding the testing by highlighting the points that were actual constraints in the project as per the principles. But now a days, with stakes are high in IT market, some companies request the QA department to compromise on the principles for the sake of client satisfaction. Now, how can a QA engineer can compromise on the things that are invincible. Take an example of Principle#1 i.e. "Testing shows presence of defects",  yes testing does show the presence of defects but consider a scenario where a live project with any defect found might cause danger to human lives, that's right any instrument or machine related directly or indirectly with human being should be carefully tested with all the parameters that any QA engineer can think of.

Principle#2 "Exhaustive testing is impossible", exhaustive testing is indeed very hectic and sometimes take a long duration than expected for completion of test. If you have seen lecture of James Bach on software testing, he stressed upon exhaustive testing a lot saying that QA engineer acts as a border line for any project and he/she is one of the major stakeholders next to client and project manager. A good QA engineer will give it all in order to make sure that application does not fail in any condition.

Principle#3 "Early testing" , okay so the principle says QA Engineer should be involved in testing as early as possible so what about the projects that come at the 11th hour and with strong pressure on QA to test the project functionality. Is it possible to make test cases and test plan in that case?? No, in such scenarios, QA Engineer should consider himself/herself in the comfort zone by just testing the application and ignoring all the deliverables.

Principle#4: "Defect clustering" , yes true most of the defects are discovered during pre-release or alpha testing but what about the issues and bugs that come out on top after deployment, who will gonna test them? Client?? No, in such cases the bugs that were reported during pre-release will not be enough to say everything is alright!!. QA Engineer should devise an strategy to test the post deployed project with the same strategy that was used during pre-release to make sure both pre-release and post deployed project contain minimum low level bugs as you can't eliminate all.

Principle#5: "Pesticide paradox", yes I totally agree with this principle as a QA Engineer should regularly update test cases and take weekly backup of them.

Principle#6: "Testing is context depending", yes testing is context dependent, but what a QA engineer should do here is to enrich his/her knowledge with ins and outs of the project with what are the factors that could cause security breach or project failure.

Principle#7: "Absence – of – errors fallacy", true, keep user in mind but try to coordinate with other stake holders in making the applications reusable and reliable for client.

I know major counter parts against the principles might not actually work in real life due to time constraint , but being an enthusiastic, you should keep on practicing and challenging your skills in order to reach perfection.