我在自己的角度來談這些感觸，不免有些偏見或不足，請走過路過的測試小夥伴輕拍, 也請小夥伴們在留言區分享下感觸，大家一起互動下，互相瞭解、學習，便於日後在工作中小夥伴們可以更好的協作。
感觸1
合作過的一些測試小夥伴，大部分基於頁面、應用界面測試，一起協同工作的過程中最大的感觸就是：測試人員也需要有HTML、JavaScript、CSS、網絡甚至UML等基礎知識，能借助瀏覽器開發者調試工具（F12）簡單的分析、瞭解頁面的HTML元素組成 ，能夠了解基本的網絡協議、常見HTTP狀態碼，這樣才能在日常測試工作中事半功倍（例如：測試、開發溝通方便，測試人員可以自己分析接口API Response信息），而且我認爲測試人員也是技術人員，也應該具備一些基礎的技術知識/技能。
感觸2
合作過的測試小夥伴，他們做的接口測試，更像是單元測試（自己平時單元測試大部分也是藉助Postman、JMeter來做，一些不方便的內部方法單元測試則藉助JUnit或者TestNG來做）；
感觸3
如果測試小夥伴有UML的基礎知識，這就大大的方便了，能減少很多的溝通成本呢，比如我在開發前一般會做功能模塊的詳細設計（有時候是開發結束後補），用例圖、狀態圖、活動圖、時序圖等真的很方便展示、講解對應的業務模塊，也容易藉助這些來了解產品，但實際情況是詳細設計中我畫的這些個圖在用來向高級架構師講解我的設計方案、實現思路後便擱在那裏了，很少/基本不會再用來和測試小夥伴講系統/產品功能，也不能強行這麼做。
小知識
用例圖：從用戶角度描述系統功能。
類圖：描述系統中類的靜態結構。
對象圖：系統中的多個對象在某一時刻的狀態。
狀態圖：是描述狀態到狀態控制流，常用於動態特性建模。
活動圖：描述了業務實現用例的工作流程。
順序圖：對象之間的動態合作關係，強調對象發送消息的順序，同時顯示對象之間的交互。
協作圖：描述對象之間的協助關係。
構件圖：一種特殊的UML圖來描述系統的靜態實現視圖。
部署圖：定義系統中軟硬件的物理體系結構。
包圖：對構成系統的模型元素進行分組整理的圖。
組合結構圖：表示類或者構建內部結構的圖。
交互概覽圖：用活動圖來表示多個交互之間的控制關係的圖。