你是一個測試人員，早出晚歸，一身疲憊。你對項目的質量負責。
但每次上線或交付以后，你總是覺得心里沒底，成天惴惴不安。不出問題就好，出了問題，是你沒測出來，鍋是你的，可以選擇忍辱偷生，或是走人。
在大多數時候，大家背地你稱呼你為：背鍋俠。
很多時候項目是這樣一個循環。
需求評審，測試只需要帶耳朵去可以了，你說什么不重要，你人在就行，這就表示流程的要求達到了。這時候你跟道具沒有區別。
開發在憋大招實現需求的時候，你在努力的腦補測試用例。很多時候你可能意識到了，這樣做的效果不好，但你還是需要接着做下去，畢竟，這是你的工作。
終於等到開發寫完了需求，他們會告訴你，來吧，我們做完了，開始測試吧。項目經理會來告訴你，由於需求變更和其他亂七八糟的事情，開發進度有點延后，沒辦法，測試時間需要壓縮，你只能接受，別無他法。
你開始拼命加班，希望多測一點，bug少一點。
你開始白天催促開發改bug，等待開發下班提測，你主要的工作時間是晚上，你守着空盪盪的辦公室，點來點去。
你好不容易趕上了項目進度，按時發出了測試報告，但是在你心里，你覺得總有什么東西是你放不下的，哪天正式環境真出問題了，你反而會長舒一口氣，默默收拾東西，找下一個背鍋的地方。
很久以后，你回憶起年輕時的背鍋之旅，你可能會覺得，也許有什么辦法可以解決這些問題。
測試左移
為什么開發在憋大招寫實現需求的時候測試不能介入？盡可能早的測試，也許能帶來一定的質量改進效果。
持續集成，每次代碼提交或者定期(一般是1天)就對主干代碼進行編譯和測試，這樣開發的整個工程就有了質量的控制和監控，問題可以盡可能早的發現，解決問題的成本也相應會降低。
持續集成並不能消除Bug，而是讓它們非常容易發現和改正。-- Martin Fowle
定期的頻繁的集成和測試會讓開發人員在編寫代碼和提交代碼的時候多一點的責任感，多用點心。開發一認真，bug都害怕。
其實你會發現，所有的流程管理，項目質量回溯等工作，其實其最后的目的都是一個：開發啊，你就長點心吧。
項目的質量很大程度上取決於開發人員的能力和態度。測試同學越努力，開發同學就越警惕，項目或產品的質量可能相對會更好一點。
測試右移
在跟生產環境一致的環境上進行測試，可能會發現一些在測試環境無法發現的問題。
在生產環境進行監控和告警，一旦發現問題，第一時間找出問題並快速上線解決，這種亡羊補牢，讓線上問題的影響減小到對少，並保證數據的一致性和完整性，這其實也是質量控制的一環。
把測試的左移和右移做好，也許對一直在背鍋的你會有一些正面的效果。
不要做背鍋俠，也不要做甩鍋狂魔，有問題就正視他，解決他，少一點陰陽怪氣和怨天尤人，想辦法把事情做好才是正道。