Context-driven testing
A test ideology that I totally agree with is Context-Driven Testing. But I will never describe my activities like that. In short Context-Driven Testing says that the best way of testing depends on the context. There are so many external factors of influence to your test activities, there is no one best practice that will work for all.
So why won’t I use the term Context-Driven Testing?
Because it is a typical engineer’s answer to the question how should be tested: “it depends”. This is true, but the answer will not get you any further.
Of course it depends. Every project is different. Every team is different. The customer, the budget, the timing and the time are all different. So it makes sense that testing is different as well. Therefor every test project should start with a good thinking session about how the test activities should be done. (Actually, the first question is if testing needs to be done at all.)
And best practices, as well as experience, can help you with choosing a strategy, techniques, tools, etc. Like a list of tips & tricks that can be used. Pick the ones you think are suitable or invent your own. Whether or not right for the job is you’re responsibility, not that of the author. No one ever claims that best practices are universally applicable.
Besides, best practices already have a context in them. Testing for traditional engineering is far different than testing software. That’s why best practices are often presented like: “Best practices in Software Testing” or “Best practices for Model Based Testing in an Embedded PLC Solution”. But unfortunately that context is not always copied and the Best Practice ends up on a list of general Test Best Practices.
Nonetheless people talk about testing like it’s all the same. Often you hear a presentation about a strategy on testing a web application and people ask questions with testing of an embedded application in mind. When the context is forgotten, miscommunication is the result.