注意：作為工程師和技術負責人，我在軟件開發領域有25年的經驗。

好的QA工程師對開發團隊來說是很有價值的，這是他們工作的一部分應該是挑剔的-但在某些特定方面。

交付的功能應該有預期的結果-在這種情況下，界面是UI。質量檢查工程師應該知道預期的結果，並對照預期檢查交付的功能。如果存在任何差異，則以約定的方式（錯誤報告工具等）記錄它們，並提供盡可能多的詳細信息-至少提供預期結果，實際結果以及重現實際結果的步驟。

Sonarcube等會檢查代碼質量，在我看來，這不是質量保證工程師的責任-高級開發人員或技術負責人應對此負責。

在按鈕和允許自動化的字段是完全合理的要求，如果開發人員不願意，可能是因為他們沒有意識到自動化測試的好處？您可以向他們解釋-也許提供一個簡短的演示文稿以及一些工作示例將是一個好選擇-優秀的開發人員將很快意識到，在過程的早期檢查錯誤的一切最終都將使他們的生活更輕鬆。

關注您需要承擔的任務-軟件準確性，符合要求，測試自動化。交付這些，人們將在流程中看到您的價值。

^{背景：我是一位年輕的軟件開發人員 sup>}

向他們解釋為什麼，他們需要更改編碼方式。我認為有充分理由說明您為何要求他們這樣做。

“代碼質量，可操作性和可測試性”聽起來像是對開發人員的侮辱（即“您的代碼質量很差”）。這些術語太籠統，通常收不到。

相反，請詳細解釋 問題是什麼以及為什麼需要它們來更改某些內容。這將使他們理解，或至少減輕他們對決策者的憤怒/煩惱（即，決定您需要適當測試的人。如果碰巧是您，您還可以解釋測試的必要性）。以可測試性為例：像這樣對您的問題進行解釋將比對可測試性的一般批評產生更好的結果：

我注意到某些重要的HTML元素沒有id屬性。我知道他們不一定需要一個程序就能使我們的應用程序正常工作，但是如果沒有它們，我們將無法為決策者XY要求的UI創建適當的測試。因此，我需要查看id屬性添加到this，this和that元素，以及將來視圖中的所有按鈕和input-elements上。我知道這需要您做更多的工作，但是對我們的應用程序進行正確的測試是必要的。

TL; DR
讓開發人員了解編碼更改的原因。當他們確切地理解了您為什麼要問他們時，他們將不再對您懷恨在心。

坦率地說，開發人員的編碼方式與您無關。如果您試圖讓他們改變這一點，那麼您只會流鼻血（比喻說）。您的業務是產品的質量，以及一切有助於您完成工作或使工作變得更艱難的事情。開發人員的代碼不屬於此部分。

如果沒有適當的流程來促進質量檢查，那麼請確保創建這些流程，與相關人員討論並實施。

如果有可以幫助您測試的產品功能，請確定並確認這些功能，然后索取它們，這些功能將像其他功能要求一樣被優先處理。如果您有任何需要，請很好地詢問，如果他們的時間和其他優先事項允許，合理的團隊將為您提供幫助。

但是，告訴開發人員如何做自己的工作，無論您如何嘗試，都會使您陷入困境。

就“ nitpicky”而言：當您檢查產品是否達到了預期的功能時，您應該是nitpicky。對於質量檢查工程師而言，“ Nitpicky”是積極的品質。我有一位QA工程師，他不挑剔，但絕對是邪惡，這對改善產品質量有很大幫助。

如果產品有很多小缺陷，只有“挑剔的”質量檢查工程師會抱怨，那麼如果遇到大問題，客戶的寬容度就會大大降低。挑剔的質量檢查工程師的另一個優點是：開發人員經常了解小錯誤，並希望解決這些小錯誤，但在管理方面有壓力去做其他事情。該開發人員可能會感謝您創建錯誤報告，因為現在他們可以說“我必須解決此問題，因為質量檢查人員抱怨”，而不是“我想解決此問題，因為它看起來不太正確”。

添加後：如果開發人員對額外的工作感到惱火，那是正常現象，無需擔心:-)但是，您需要研究在您的位置如何處理工作。

如果您只說“我需要XYZ”，而開發人員花了一天時間為您做XYZ，那麼對他的老闆來說，好像他整天什麼都沒做。在我的地方，您會填寫一個請求，我會做，將請求標記為“完成”，然後我可以對老闆說：“不，我一天都不懶，我做到了這一點非常重要中午完成她的工作所需的東西”。一切都與眾不同。

如果您的住所還沒有那樣好的組織方式（並且僅在兩週前就引入了質量檢查，我可能會擔心最壞的情況），那就需要這樣做。這可能是值得採取主動行動的地方。重要的是，您要為開發人員創建額外的工作（完全是您的工作），然後必須以老闆可見的方式完成工作。

我是從具有豐富經驗的DevOps負責人/軟件架構師的角度出發的，他與質量檢查人員合作，包括自動質量檢查。

我對您的問題的正式回答是選擇您的問題最初要進行認真的鬥爭，最終要擴大您的計劃範圍，以產生您希望並知道要取得良好的影響。

我的意思是：添加代碼質量計劃，這些計劃可以很快獲得回報，宣傳活動。在HTML中為事物添加id是一個很好的例子。

代碼質量具有長期的好處，但是由於其工作通常不被認為是生產性的，因此可以在短期資源成本上受益。生產力的某些定義：即“完成新功能”。

在已建立的代碼庫中，全面提高代碼質量是一件很難的事。我還建議採用更具戰略性的零散流程，因為它已經在運行代碼，並且更改代碼會帶來風險。

我建議找到一些簡短的措施來證明自己的利益，這時開發人員更可能意識到您的計劃不僅要遵循繁瑣的煩人規則，而且會長期有益於他們的活動。

我還強烈建議您通過過多的背景知識和背景來最大程度地減少海洋的前部負荷和沸騰為什麼要做某事。代碼質量固然重要且良好，但許多人對此並不感興趣。

並且，提出一種好的實施計劃的方法至關重要。優先選擇“請用Y代替X”而不是“不要用X做Y”這樣的語句。 （如果您仔細觀察，這句話將根據它所支持的準則來組織。）

好的，我們現在已經有了很多答案，可以從專業工程和工作場所方面為您的問題提供建議。我或多或少都同意他們的觀點，所以我會在這方面保持我的2美分，並考慮到您所處的人際關係，嘗試給出此答案。

免責聲明：堅持自閉症譜系我可能會談談大多數人甚至都不認為是問題的細節。但是，由於它們對我來說是有問題的，它是我處理它的方式的備份。

因此，我從大多數答案中看到的第一個對比與您的情況相反，大多數人的回答是擁有QA經驗的專業人士。只要您公司中的大多數員工不是高級開發人員，您就可以假設他們沒有這樣的先前經驗。

在我以前的工作中，我一直都是“討厭的同事”，但這是主要原因，質量檢查不是我的工作。從那時起，我可以告訴你的有趣的事情是：人們通常並不反對我。他們只是在一種工作文化中而不是在乎質量，因此發現有人在乎質量，但會抑制噪音。

因此請記住，您的工作也可能會遇到這種情況（即使顯然是這樣，待更改）。

讓我簡單介紹一下我目前的職位。我知道這是您不能獨自實施的事情，也不是可以短期實施的文化變革。但是，如果公司的高層在您的身旁， ^{1 sup>。}

所以與我以前的工作相反，我現在在一家非常大的公司工作，花費大量資源來提高質量。我不是直接在質量保證部門工作，而是作為許可證合規性分析師，因此，總的來說，驗證其他人的代碼仍然是我的工作。實際上，任何產品在發布之前都必須通過我們的檢查。產品必須滿足有記錄的要求，才能由我的團隊檢查，而我們要做的就是檢查並給予批准或拒絕。因此，不是我們要決定要檢查的內容。結果是，項目團隊不會把我們看作是困擾他們的最後期限的人，而是如果他們的項目沒有通過我們的分析並且他們不知道如何解決這個問題，而是向我們尋求幫助 ^{2 。}

因此，考慮到這一良好的工作程序，我將向您提出以下建議：

首先，由於是孤獨症患者，對我來說尤其重要 ^{3 sup>，請確保對您的角色有什麼期望。儘管挑剔對QA工程師來說是一個很好的特徵，但您的公司可能對QA工程師應負的責任有錯誤的認識。}

因此與您的上司約好，並請他們給您上司明確定義您的職責。盡量避免告訴您您認為自己的責任是什麼，並要求確認，而是讓他們解釋自己的想法。嘗試讓他們的解釋與您自己應承擔的責任的想法完全區分開，如果發現不完整，請澄清，但不要爭論。

此後，寫下您的責任建議。同樣，您只是如何理解它們，而不是您認為的樣子。然後在提案中添加一個部分，說明不是您的責任。在這裡，您可以添加您認為應該屬於角色但未提及的所有部分。您對不屬於您的角色感到不舒服的程度越大，我的措辭就越戲劇化。 ^{4 sup>。}

將該建議交給上級，並請他們批准。最終修改該提案，直到獲得批准並生效為止。您對責任有明確的分類。

這可以通過3種方式給您確定性：

• 您知道質量的哪些方面對公司很重要，因此您必須關心什麼。

• 您不必擔心發現與軟件質量有關的重要內容有明確的書面建議，不要考慮這些方面。這也很有用，可以避免將來因未註意這些措施而受到指責，因為您已書面建議不要這樣做。

• 對於OP而言，這很重要。這不再是您個人對質量的個人意見，而是關於公司應確保的意見的書麵條約。因此，您再也不會因此而受到指責。或者，如果這是“不願意”的一部分，那麼您和開發人員都不必費心，因為該公司明確表示不希望該部分被覆蓋。

^{1 sup>我希望他們是什麼，否則您的工作將是一場鬧劇。}

^{2 sup>好吧，我很確定他們仍然以這種方式看到我們。但是關鍵是，我們不必告訴他們如何修復代碼，而必須問我們如果代碼存在問題，使代碼無法通過我們明確定義和記錄的檢查，該怎麼辦。}

^{3 sup>當我進入一個工作環境時，我幸運地意識到這裡可能出錯了，幸運的是，每個方面的內容都被記錄在案，而且我注意到我的工作中有多少誤解的餘地}

^{4 sup>我不知道這是好是壞建議，這正是我會做的。}

我是一名開發人員（C ++），經常遇到完全相同的問題。我年齡較大（26），但還比較年輕。我們的團隊由5名成員組成，平均年齡為35歲。我是我們團隊中唯一真正關心可讀性，可維護性和一致性方面的良好代碼的人。我們中有3個人從6-10年開始從事這項工作，他們有（部分是不良的）習慣。特定的編碼行為。非常重要的一點是，不要批評它們，而應使新樣式更具吸引力，因為沒人喜歡告訴別人他做錯了什麼。

嗨，您的命名約定是可以理解的，儘管我們可以通過在標識符上添加“ id”來改進它。這樣，通過查找包含“ id”的所有行來遍曆元素將非常舒適。在使用自動完成/智能提示時，我們也會有一個更好的概覽。

如果我的建議聽起來像批評家，我會感到很少有成功。如果您知道您的建議是真正的改進，您將找到理由。只是永遠不要成為個人，而是要表現出比實際編碼風格更有價值的東西。

^{背景：我在管理方面有10年以上的經驗，在IT環境中工作了19年，而我目前的2年職位是開發團隊的一部分。 sup >}

您可能對一些一些開發人員對檢查工作的反應是正確的，但是由於您似乎具有技術背景並且正在使用技術解決方案來實施此類檢查，認為您會很好。

開發只是我工作的一部分，所以我的回答可能比其他一些人的技術要少，但是我已經看到自己的環境從那裡改變了。幾乎沒有任何控件，並且開發人員處於大型組織的腰包，以自己的風格完全自主地開發，並使用Git存儲庫，版本控制等適當控制的環境。這些事情很快就被開發人員所接受，因為一件事情您可以說大多數開發人員是他們愛緊跟最新的工具。擁有控制措施帶來了一定程度的管理負擔，但同時也帶來了許多好處，並且由於一項技術本身是非常“酷”的：)在介紹諸如SonarQube之類的東西時，開發人員可能會喜歡它。

我的建議是：

1。
從一開始就清楚一點，在所有工作中，您要扮演的角色是監督 code 的質量，不會暴露表現不佳的開發人員。

2。技術性。但是不要虛張聲勢
我已經看過數十次了-人們來到IT環境中工作，他們害怕知道的東西比其他所有人都少，他們試圖通過技術交流虛張聲勢。別。你只會變得愚蠢。每個人都有自己的長處和短處，因此要對自己知道的事保持自信，而對自己不知道的事要誠實。邀請他人幫助您填補知識方面的空白。許多開發人員喜歡一個機會來談論他們所知道的內容，如果謙虛地承認自己不了解某些內容，那麼您會變得更加平易近人。

3。將您介紹的任何新措施或控制措施轉變為“個人發展機會”。
許多其他組織已經採用了許多您將介紹的措施。因此，與其說讓您覺得給他們帶來行政負擔，不如說是將改變“賣”給了他們，從而使他們個人發展。如果他們將來在其他地方找到新工作，那麼他們在這裡的經驗將是一個決定性因素。可以說，可以說他們已經在適當控制的環境中進行了質量檢查，這是他們的頂峰。

4。保持您的權限
平衡以上所有內容，並保持您在此角色中期望獲得的權限。試圖與員工成為朋友的經理通常會發現自己的權威受到破壞。儘管您可能不是開發人員的直屬經理，但您仍有工作要做，因此請確保他們不會阻止您執行此操作。當然，您聲明的目標是避免成為“挑剔的人”並激怒與您共事的人，但是從職業角度而言，您可能希望更專心於如何實現對角色的期望並取悅老闆，而不是被別人接受。實際上，您扮演著不同而獨特的角色。