當軟件開(kāi)發(fā)組織采用敏捷開(kāi)發(fā)時(shí)，測試團隊通常需要花很長(cháng)時(shí)間來(lái)完成轉變。在很多公司中，獨立的質(zhì)量保證團隊已經(jīng)根深蒂固。當它們開(kāi)始適應新的敏捷組織時(shí)，會(huì )遇到難以接受的文化差異。敏 捷測試專(zhuān)家Lisa和J.net對此進(jìn)行了詳細分析，對文化因素在敏捷測試中的影響提出了自己的建議，InfoQ中文站對相關(guān)內容做了整理。
組織文化通過(guò)其價(jià)值、標準和設想來(lái)定義。組織文化支配著(zhù)人們如何溝通、交互和做決定，這可以通過(guò)觀(guān)察員工的行為很容易地看出來(lái)。組織文化可以影響敏捷團隊的成功。敏捷團隊最適合于允許獨立思考的組織。例如，如果一個(gè)公司是等級結構的，所有的項目都鼓勵指令式管理風(fēng)格，敏捷團隊可能會(huì )很吃力。組織以往的經(jīng)歷也可能會(huì )影響新的敏捷團隊的成功。如果公司嘗試敏捷，但是結果糟糕，人們會(huì )懷疑再次嘗試的必要性，舉例證明為什么敏捷不起作用。他們甚至可能積極地反對它。
當嘗試采用敏捷過(guò)程時(shí)，組織文化經(jīng)常被遺忘，人們懷疑敏捷為什么不像承諾的那樣有用。改變已有的過(guò)程是困難的，尤其是當人們覺(jué)得習慣于現狀時(shí)。每個(gè)任務(wù)組形成了滿(mǎn)足自己需求的文化和過(guò)程。他們習慣于自己的工作方式�？謶值那榫w非常強大，如果不能妥善解決，可能破壞向敏捷的轉變。如果團隊成員覺(jué)得新的敏捷過(guò)程威脅他們的工作，那么會(huì )抵制這種變化。
以如何定義軟件質(zhì)量的可接受水平的角度思考組織的質(zhì)量哲學(xué)。是否容忍劣質(zhì)的質(zhì)量?是否考慮客戶(hù)的質(zhì)量需求，還是只關(guān)心是否可以盡快地將產(chǎn)品交付給客戶(hù)?當一個(gè)組織缺乏全面的質(zhì)量哲學(xué)和團隊沒(méi)有生產(chǎn)高質(zhì)量產(chǎn)品的壓力時(shí)，測試人員會(huì )感覺(jué)到無(wú)助。在這種環(huán)境中嘗試使用敏捷開(kāi)發(fā)的團隊會(huì )面臨更大的障礙。
如果一個(gè)現有的質(zhì)量團隊自封為“質(zhì)量警察”的角色，它的成員通常通過(guò)確保 完成代碼審查和缺陷嚴謹地記錄到缺陷跟蹤系統來(lái)保證質(zhì)量。他們跟蹤發(fā)現的缺陷數，然后負責最終決定是否發(fā)布產(chǎn)品。我們曾經(jīng)接觸過(guò)一些測試人員吹噓他們的成就，例如越過(guò)開(kāi)發(fā)經(jīng)理直接強制程序員遵循代碼標準。甚至聽(tīng)說(shuō)有測試人員浪費時(shí)間編寫(xiě)不符合標準的需求的缺陷。這種態(tài)度并不符合協(xié)作的敏捷團隊，將引起敵對行為�！百|(zhì)量警察”角色的另一個(gè)風(fēng)險是團隊不認同構建質(zhì)量的概念，程序員將測試人員視為安全防護網(wǎng)。團隊通過(guò)缺陷跟蹤系統溝通，但這并不是一種高效的交 流，所以團隊并不“凝聚成一團”。
技能和適應能力
很多程序員不能適應敏捷實(shí)踐——但是對于習慣于根據需求文檔編寫(xiě)測試腳本的測試人員，情況如何呢?他們學(xué)會(huì )在編寫(xiě)代碼的 時(shí)候提出問(wèn)題了嗎?不能改變測試方式的測試人員與開(kāi)發(fā)團隊的其他人密切工作的時(shí)候會(huì )很艱難。習慣于通過(guò)用戶(hù)界面手動(dòng)測試的測試人員可能無(wú)法理解敏捷開(kāi)發(fā)的本質(zhì)——自動(dòng)化方式。這些測試人員需要很大勇氣來(lái)面對變化的角色，因為變化意味著(zhù)需要發(fā)展其熟悉范圍之外的新技能。
輔助因素
即使有許多需要考慮的文化因素，但是大部分質(zhì)量保證團隊關(guān)注過(guò)程改進(jìn)，并且敏捷項目通過(guò)使用例如回顧總結等工具來(lái)鼓勵不斷改進(jìn)和適應。大多數質(zhì)量保證專(zhuān)家希望使用他們學(xué)到的知識并改進(jìn)它。這些人 適應性強，不僅能適應，并且能在敏捷項目中獲得發(fā)展。如果你的組織專(zhuān)注于學(xué)習，它將鼓勵持續的過(guò)程改進(jìn)。它將比把更多的精力放在如何應對危險而不是改進(jìn)過(guò)程的組織更快地適應敏捷。
如果你是有效的質(zhì)量哲學(xué)的組織中的一個(gè)測試人員，你可能努力使質(zhì)量實(shí)踐獲得接受。敏捷方式將提供引入優(yōu)秀的面向質(zhì)量的實(shí)踐的機制。像其他學(xué)習如何在敏捷項目中工作的每個(gè)人一樣，測試人員需要時(shí)間和培訓。如果管理一個(gè)有測試人員的團隊，確保給他們足夠的支持。新項目通常不在一開(kāi)始就引入測試人員，一般讓他們適應一個(gè)已經(jīng)在一起工作了幾個(gè)月的團隊。為了幫助測試人員適應， 可能需要引入一名有經(jīng)驗的敏捷測試老師。聘用一名以前在敏捷團隊工作過(guò)的員工作為老師和教練可以幫助測試人員融入到新的敏捷文化中，不管是進(jìn)入一個(gè)現有的團隊還是加入一個(gè)新的敏捷開(kāi)發(fā)團隊。
合適的節奏
傳統的測試團隊習慣于在項目結束時(shí)快速、激烈地測試，這會(huì )導致周末和夜間的加班。在項目結尾的測試階段，一些組織通常會(huì )讓團隊每 周工作五十、六十或者更多小時(shí)來(lái)應付最終期限。組織經(jīng)常將加班作為個(gè)人貢獻的度量標準。這與敏捷價(jià)值沖突，敏捷價(jià)值的中心思想是讓大家時(shí)刻以最好的狀態(tài)工 作。
在敏捷項目中，鼓勵人們以一個(gè)合適的節奏工作。這意味著(zhù)團隊以一致的速度工作，團隊可以保持在這個(gè)保持高質(zhì)量標準的速度。新的敏捷團隊往往對其能夠完成的工作過(guò)分地樂(lè )觀(guān)，而承諾太多的工作。在一個(gè)或兩個(gè)迭代之后，會(huì )學(xué)會(huì )承擔不需要加班完成 的足夠工作。每周四十小時(shí)是極限編程團隊通常的合適速度，這是保證人們連續幾周完成大部分工作并創(chuàng )造優(yōu)質(zhì)產(chǎn)品所能承受的工作強度。
團隊可能偶爾需要高強度地工作，但是這是特例，不是一般情況。如果需要短期加班，那么整個(gè)團隊都應該加班。如果sprint的最后一天某些測試沒(méi)有完成，那么整個(gè)團隊不僅僅是測試人員都應該加班完成測試。在團隊更好地管理負載和節奏之后，加班才會(huì )消失。
客戶(hù)關(guān)系
在傳統的軟件開(kāi)發(fā)中，開(kāi)發(fā)團隊和他們的客戶(hù)之間的關(guān)系更像是買(mǎi)賣(mài)關(guān)系。即使客戶(hù)是內部的，但是感覺(jué)更像是兩個(gè)獨立的公司，而不是為了生產(chǎn)業(yè)務(wù)這一目標而共同奮斗的兩個(gè)團隊。敏捷開(kāi)發(fā)依賴(lài)于客戶(hù)或者至少是客戶(hù)代表的緊密參與。敏捷團隊邀請客戶(hù)協(xié)作，如果可能， 在同一地點(diǎn)工作，并且密切地參與開(kāi)發(fā)過(guò)程。雙方都了解對方的強項和弱點(diǎn)。
不管客戶(hù)是內部的還是外部的，這種關(guān)系的改變需要雙方的認同。開(kāi)放的關(guān)系對敏捷項目的成功至關(guān)重要，在敏捷項目中，客戶(hù)團隊和開(kāi)發(fā)團隊之間的關(guān)系更像是合作關(guān)系，而不是買(mǎi)賣(mài)關(guān)系。擁有一些領(lǐng)域專(zhuān)家代表，并且持續地向所有相關(guān)人員報告狀態(tài)，是實(shí)現開(kāi)發(fā)人員和客戶(hù)成功協(xié)作的辦法�？蛻�(hù)對敏捷項目的成功是至關(guān)重要的。他們對將要實(shí)現的功能確定優(yōu)先級，并對項目的質(zhì)量有最終的評判權。測試人員與客戶(hù)緊密合作來(lái)理解需求，并定義證明滿(mǎn)足條件已經(jīng)達到的驗收 測試。測試活動(dòng)對于開(kāi)發(fā)團隊與客戶(hù)團隊關(guān)系是很重要的。因此，測試專(zhuān)家是敏捷團隊的關(guān)鍵。
組織規模
組織的規模對項目如何運轉及公司如何完善結構有重要的影響。組織越大，結構中的層次可能會(huì )越多。當形成自頂向下的交流渠道時(shí)，報告結構變得指令化，不適合技術(shù)和業(yè)務(wù)的溝通。
溝通挑戰
一些敏捷過(guò)程提供了便于團隊交流的方法。例如，Scrum有Scrum會(huì )議，來(lái)自多個(gè)團隊的代表每天交流。如果工作的測試團隊或其他部門(mén)與編碼團隊分離，那么需要找到保持不斷交流的方式。例如，如果數據庫團隊是完全分離的，那么需要尋找一種與數據庫專(zhuān)家密切合作的方式來(lái)及時(shí)獲得需要的信息。大公司容易存在的另一個(gè)問(wèn)題是客戶(hù)可能不像小公司那樣容易接近。這是當你試圖獲取需求和實(shí)例并牡蠣在開(kāi)發(fā)周期中讓客戶(hù)參與的巨大障礙。一個(gè)解決方案是讓測試人員或分析人員及領(lǐng)域專(zhuān)家作為客戶(hù)代理。交流工具也可以幫助處理這種情況。需要尋找創(chuàng )造性的方式來(lái)克服大公司固有的這些問(wèn)題。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
