亚洲中文精品人人永久免费_ 如何結束測試員和程序員之間的戰爭|it技術(shù)文章

　　由于各自角色的著(zhù)眼點(diǎn)不同，測試員和程序員之間自然會(huì )存在沖突。簡(jiǎn)而言之，程序員注重于創(chuàng )造：他們做出的東西是前所未有的。與多數創(chuàng )造者一樣，程序員在創(chuàng )新和解決問(wèn)題上有一種天生的樂(lè )觀(guān)主義（程序員的座右銘是：“只要有足夠的時(shí)間，我什么都能做出來(lái)！”）。

　　而在另一方，測試員注重于求證和懷疑。測試員對所有設計出來(lái)的東西都不信任，他們用自己掌握的知識照亮了決策中的黑暗一角，那正是別人未知或否認的。（測試員的座右銘是：“萬(wàn)物皆有缺陷，我能找到它們！”）

　　把這兩種人－樂(lè )觀(guān)者和懷疑者－聚在一起，以雙方才智的協(xié)同之力開(kāi)發(fā)出更好的軟件是可能的，但這種情況很少發(fā)生。通常每個(gè)人都在走極端，成了狹隘的程序員或測試員，充斥著(zhù)樂(lè )觀(guān)或悲觀(guān)的情緒，卻從來(lái)不愿退一步考慮雙方觀(guān)點(diǎn)中的可取之處。程序代碼成為團隊政治的犧牲品，在雙方的隔閡間被扔來(lái)扔去。等到項目結束，團隊花在爭論怎樣做事上的時(shí)間超出了真正做事的時(shí)間。

　　結束程序員和測試員間爭斗的最好辦法是重新確定工作目標，讓他們的角色關(guān)系成為協(xié)作而不是對抗。雖然可以用許多種不同的形式組建開(kāi)發(fā)團隊，甚至有可能不設專(zhuān)職的測試員（有人說(shuō)一個(gè)稱(chēng)職的軟件工程師才是質(zhì)量保證的根本），本文仍假定你屬于常見(jiàn)的大中型開(kāi)發(fā)團隊，在這樣的團隊中有一些專(zhuān)職的測試或質(zhì)量保障角色。

　　使責任與權利相符

　　測試員或質(zhì)量保障人員面臨的挑戰之一是：他們通常對軟件的質(zhì)量負有責任，但對軟件的設計卻施加不了多少影響。在最糟糕的情況下，編程組的工作先于測試組數周開(kāi)始，在測試組介入前已編寫(xiě)了大量代碼。這不能算是質(zhì)量保障，而是所謂的信任（“我向你保證代碼質(zhì)量會(huì )很高”），他們的測試實(shí)際上是在為質(zhì)量打補?。ā爸灰憬唤o我，我就會(huì )盡我所能把代碼質(zhì)量提高”）。試圖以滯后的測試、少量的資源投入來(lái)做質(zhì)量保障，這其實(shí)無(wú)異于在說(shuō)辦不到。

　　最小化測試與開(kāi)發(fā)間沖突的最簡(jiǎn)單的辦法，就是讓測試組擁有能履行其職責的足夠權利。既要給他們充分授權，以便他們在軟件初期設計階段能夠參與或提供反饋，也要對他們這一角色應有的限制達成共識。但如果你讓測試組夾在中間，責任很大而權利很小或沒(méi)有，那么他們注定會(huì )使整個(gè)項目陷入混亂而導致失敗。我不是在主張由測試員統領(lǐng)一切，而是說(shuō)他們的責任應該與他們的權利大致平衡。

　　我所見(jiàn)過(guò)的最好的團隊都是在一開(kāi)始就進(jìn)入了他們各自的角色。測試員、程序員以及其余的人都會(huì )盡早說(shuō)明他們認為項目中哪些是重要的，他們的專(zhuān)長(cháng)如何能得以施展。如果團隊里有些好主管，他們就會(huì )在如何決策上達成一致，即哪些事情適合由程序員決定，哪些事情適合由測試員決定，還有哪些是由雙方或多方共同決定。

　　盡早開(kāi)始合作

　　如果你希望人們在工作中能相互配合，就必須給他們充分的時(shí)間以建立起工作關(guān)系。你不會(huì )與自己不甚了解的人一起分擔重要的事（設想一下你把自己最隱秘的恐懼告訴郵遞員，他不會(huì )認為你是認真的；更糟糕的是，你可能再也收不到信件了）。如果這就是人類(lèi)本性的真相，那你就不會(huì )對程序員不滿(mǎn)于測試員的介入感到奇怪了。如果只在項目中的某一個(gè)月份測試員才出現并尋找缺陷，他們就會(huì )遇到阻力。程序員編寫(xiě)的代碼的質(zhì)量－這是他們的驕傲之源－被完全處于局外的人所挑戰，此時(shí)測試員就會(huì )被當作威脅而不是支持。

　　所以說(shuō)，程序員與測試員應當從第一天起就協(xié)同工作。他們一起開(kāi)會(huì )討論想從對方那里得到什么，以及他們希望對方做哪些事情。他們會(huì )根據項目目標或工作任務(wù)列表來(lái)安排工作的優(yōu)先級并做出影響雙方的決策。在日常工作中，程序員總會(huì )把測試員的工作看作是幫助他提高工作質(zhì)量的一種方式，這增強了他的自信心。測試員不再是挑毛病、列缺陷的局外人（“爛程序員，真爛！”），與此相反，他們成為一個(gè)局內人、一個(gè)合作者，他們對程序員的工作所給予的密切幫助無(wú)人能及。

　　或許最為重要的是，盡早建立起程序員和測試員之間的工作關(guān)系，這會(huì )打造出一個(gè)使項目能夠經(jīng)受艱難時(shí)刻所需的紐帶。在項目后期問(wèn)題出現、壓力加大，他們將有一段彼此信任的經(jīng)歷。他們會(huì )尋求解決方案應對壓力和新的挑戰，而不是指責對方。

　　帶著(zhù)質(zhì)量意識編程

　　通常程序員和測試員在質(zhì)量的含義上有著(zhù)非常不同的見(jiàn)解。不只是他們，人們有關(guān)質(zhì)量的爭論已經(jīng)持續了幾百年，至今也未取得多少進(jìn)展（參見(jiàn)Pirsig的《禪與摩托車(chē)維護的藝術(shù)》）。不要指望能找到一個(gè)永遠正確的答案，那是不可能的事。質(zhì)量是有高度主觀(guān)性的，而且對于不同的項目其含義也會(huì )不同。主管們要做的是為當前的項目在質(zhì)量問(wèn)題上達成一致，避免哲學(xué)式的爭吵，而不是去尋求一個(gè)唯一的答案。

　　精明的團隊很早就對質(zhì)量進(jìn)行明確。他們知道在項目后期他們需要通過(guò)測試用例找出Bug并評估進(jìn)展，他們決定不等到結束的時(shí)候再去處理這些事情?？梢栽陧椖砍跗诰妥龀鲇嘘P(guān)質(zhì)量的決策。

　　測試驅動(dòng)式開(kāi)發(fā)（TDD）是一種流行的在初期就引入質(zhì)量管理的開(kāi)發(fā)模式，它使測試及質(zhì)量保障與每個(gè)功能特性的設計結為一體。測試用例（軟件在發(fā)布前必須滿(mǎn)足的條件）在編寫(xiě)代碼前就已被創(chuàng )建，以確定代碼應達到的條件。既然你不會(huì )蠢到開(kāi)車(chē)的時(shí)候不知道要去哪兒，為什么要在你還沒(méi)明確目標之前就開(kāi)始編碼呢（除非你喜歡在公路上閑逛或者編的是些簡(jiǎn)單代碼）？

　　 TDD的精髓適用于各種類(lèi)型的工作。如果你能盡早確定最終要實(shí)現的各種特性并把它通知給其他人，成功的機率就會(huì )升高。這就是從各項分工的角度將結果分解，使每個(gè)人都能最大程度地運用各自的技能幫助項目達到目標。

　　只有主管能發(fā)動(dòng)和結束戰爭

　　戰爭史清楚地表明了一點(diǎn)：是那些大權在握者制造了導致戰爭的因素。不管對妥協(xié)是懼怕還是拒絕，主管都有能力發(fā)動(dòng)和結束沖突。測試員和程序員沒(méi)什么差別，如果在開(kāi)發(fā)團隊中發(fā)生沖突，就要從主管身上找原因。

　　高級程序員和高級測試員之間的關(guān)系為組織中其余的人定了調子。如果一方對另一方不予理睬、嘲笑或耍威風(fēng)，那另一方也會(huì )跟著(zhù)這么做。主管確立行為準則－某個(gè)角色的工作該如何去做，他該如何對待其他的角色。這也同樣適用于團隊的管理者，管理所有程序員和測試員的人的行為將確定組織中每個(gè)人的行為準則。

　　為改善測試員和程序員之間的關(guān)系，雙方的主管需要對局勢負起責任，這類(lèi)事情要比那些技術(shù)類(lèi)的工作擁有更高的優(yōu)先級。本文及以前有關(guān)于這方面的文章有助于為解決此類(lèi)問(wèn)題提供一些思路。不過(guò)只有當主管們敢于進(jìn)取，明智地承認這些問(wèn)題，并帶領(lǐng)雙方制定一個(gè)如何改變的協(xié)作計劃，這一切才會(huì )真正得以改進(jìn)。

　　關(guān)于作者
　　 Scott Berkun是《項目管理的藝術(shù)》一書(shū)的作者，他目前是一名項目管理和產(chǎn)品設計領(lǐng)域的獨立顧問(wèn)，并主持www.scottberkun.com網(wǎng)的pmclinic（PM診所）欄目－一個(gè)友好的、有關(guān)項目管理方面的論壇。

本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請點(diǎn)擊舉報。

欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久