There are lots of good practices for software development and testing, and I recommend practices all the time. However, I’m very reluctant to call anything a “best practice” (except perhaps “Do unto others…”). Here’s why.
Practices are context-dependent. They work when they fit the particular product, the starting point, the resources available, and the people. We bake some dishes, we boil others. Baking and boiling are both good practices, but boiling a pizza would not yield good results.
Many people are oblivious to context until they change jobs and start working in a completely new context. When I worked in medical product software, I thought I knew the right way to do software. When I moved to consumer printers, I had a challenging year before I realized that context really did matter. You can read about how my perception of quality and “best practice” changed in Culture Clash.
Today, I look for the basic principles behind a practice. When I understand those, it is much easier to identify what aspects of context affect the practice in question. For instance, understanding that agile is using small batches and cadence to control workflow is very helpful in understanding how to use the same principles and get agile-like results on hardware projects – even if the resulting method wouldn’t qualify as “agile” in many people’s minds.
Let’s focus on understanding why a practice is good, so we can use it wherever it will work.