- 不要承擔發佈產品的責任
當測試工程師對產品的發佈有決定性權力的同時，也承擔了產品質量的全部責任，團隊中的其他成員會爲此放鬆一點。如果測試遺漏了，導致線上bug，團隊其他成員會置身事外，並責備測試工程師，爲什麼交付了存在問題的產品。另一方面，如果測試工程師延誤發佈，也會被追究被承擔很大的壓力。
所以要由控制項目的人或者集體來決定是否發佈產品。如果你被授權決定產品的發佈，那麼建議你毫不猶豫地堅持與項目團隊的其他成員一起分擔這種權力。
- 當心『事不關己，高高掛起』
有些測試工程師認爲，自己的工作內容就是找出產品和需求之間的差別，任何超出這個範圍的問題，比如可用性問題、需求邏輯問題、兼容性問題、易用性問題等都『不關我的事』。建議改變這樣的想法，測試工程師的職責是盡其所能，通知團隊可能會對產品的質量產品消極影響的所有問題。
- 不要指望其他人會理解測試，或理解測試工程師需要具備怎樣的條件才能做好測試
開發或者產品可能會覺得測試很簡單，點點點就可以。產品提出一個需求的時候，可能會覺得這個功能測起來非常簡單，想要儘快上線。
- 進行技術性、創造性、批判性和實用性思考（如使用測試工具）
- 直覺可以是好的開始，但不能作爲結束
我們可以使用直覺來推斷存在問題的地方，但不能作來作爲合理性證明。當有『這是問題，因爲它顯然是問題』的想法是，我們可以換一種方式：這是個問題，因爲它的行爲與需求XXX不一致。
- 運用試探法快速產生測試思路
由於可能的測試用例的數量是無限的，因爲要選出在一定時間和預算等約束條件下有效的少量測試用例。有經驗的測試工程師會收集並共享能夠改進其猜測質量的測試試探方法。一組好的試探方法有助於快速地生成測試。
- 測試邊界。邊界更可能暴露模糊問題
- 測試所有錯誤消息。錯誤處理代碼與主流功能代碼相比，一般比較弱
- 執行比較難想到的測試。在其他條件相同下，易於想到的測試更有可能已經被執行過
- 避免冗餘測試。如果某個測試實際上是重複其他測試，那麼就不會產生價值。
- 注意其他測試工程師所發現的自己本來應該發現，但是沒有發現的問題
- 如果遺漏一個問題，檢查這個遺漏是意外還是必然
拋硬幣時猜正反面，猜錯了，並不意味着策略上有問題，而是概率問題，除非在硬幣上做了的腳。
同理，如果是因爲測試策略的問題，導致了測試的遺漏，那麼就需要總結與改進；如果只是偶發的問題，那麼保持原有方法不變。
- 困惑是一種測試工具，利用困惑
當測試工程師感到困惑時，這可能是某種重要的預示。
- 是需求沒有說明清楚嗎
- 設計不規範嗎
- 產品不方便使用呈