分類: 知識 常識詞典 編輯 : 常識 發(fā)布 : 04-05

閱讀 :248

敏捷開發(fā)過程中測試團(tuán)隊(duì)的職責(zé)和產(chǎn)出是什么？更細(xì)一點(diǎn)來描述問題:1. 敏捷開發(fā)過程中, 相關(guān)的系統(tǒng)分析文檔, 設(shè)計(jì)文檔. 對應(yīng)的測試分析文檔, 測試用例, 是否需要按質(zhì)量完成.以前聽過一個(gè)據(jù)說非常成功的案例, 說在敏捷開發(fā)過程中, 測試是使用一張紙的測試文檔的, 這張紙寫清楚需要測試的點(diǎn), 然后開始測試.2. 關(guān)于需求, 敏捷開發(fā)過程中, 是否需求方只需要提供一個(gè)用戶故事, 比如 "我作為PD(代表用戶的意思), 在某些場景中期望達(dá)到什么目的, 所以希望產(chǎn)品如何如何." 而具體的詳細(xì)設(shè)計(jì)在開發(fā)過程中邊設(shè)計(jì)邊討論.3. 敏捷開發(fā)過程, 是否可以等價(jià)于迭代式開發(fā), 比如, 將某個(gè)產(chǎn)品分成幾個(gè)部分, 先完成某個(gè)部分, 再完成其他部分, 或者先做出一個(gè)基本原型. 此原型能夠?qū)崿F(xiàn)基本功能, 再次基礎(chǔ)上繼續(xù)完善其他功能.這樣的說法, 本人基本贊同, 但是會演變成另外一種情況, 就是需求人員自己都沒想好整體產(chǎn)品的細(xì)節(jié), 先把想好的實(shí)現(xiàn)掉, 再實(shí)現(xiàn)的過程中, 再慢慢想其他功能.13 個(gè)答案

答案 1：

1.敏捷中文檔輕量化，但是并不代表不保證質(zhì)量。敏捷是減少不必要的文檔，減少重復(fù)文檔，敏捷中不會出現(xiàn)傳統(tǒng)開發(fā)中分的那么細(xì)的各個(gè)階段文檔，你可以看下scrum中的backlog，這個(gè)文檔可以從需求貫徹到測試整個(gè)過程。對用戶故事，計(jì)劃估算，實(shí)現(xiàn)方法，如何測試等內(nèi)容都有描述。2.是提供用戶故事，但是用戶故事粒度比你說的會細(xì)化很多。敏捷過程中同樣不允許出現(xiàn)需求蔓延情況。一個(gè)用戶故事是能夠帶來用戶價(jià)值的最小需求單位。用戶估算不管如何實(shí)現(xiàn)，但是一定是會把需求說清楚。3.迭代只是敏捷的一個(gè)特征，而不是全部。敏捷更加重要的特征是通過短周期迭代而帶來的團(tuán)隊(duì)不斷自適應(yīng)和調(diào)整。敏捷方法中需求人員在迭代1當(dāng)然沒有必要想好后續(xù)所有迭代的產(chǎn)品細(xì)節(jié)，但是一定要想好整個(gè)產(chǎn)品的功能規(guī)劃，即對產(chǎn)品的高端規(guī)劃和設(shè)計(jì)還是要有。

答案 2：

1.文檔的量我覺得可以少些，過多的文檔是不符合敏捷開發(fā)的理念的，但是文檔的質(zhì)量必須得到保證，測試用例的覆蓋一定要夠，像你說的那個(gè)成功案例，雖然只有一張紙，恐怕上面也有著大量的測試用例吧2.我覺得雖然敏捷開發(fā)可以邊開發(fā)邊設(shè)計(jì)細(xì)節(jié)，但是明確的需求肯定是必須的，任何一個(gè)設(shè)計(jì)在確定時(shí)最好先想想這個(gè)設(shè)計(jì)是否能讓迭代順利。3.我覺得敏捷開發(fā)就是迭代式的開發(fā)，確實(shí)有可能出現(xiàn)邊實(shí)現(xiàn)邊設(shè)計(jì)的情況，這也是很難避免的，因?yàn)樾枨髸r(shí)刻都有可能發(fā)生變化。所以，測試人員應(yīng)該及時(shí)跟上開發(fā)和需求人員的腳步，及時(shí)地更新測試用例，并提醒大家需求的變更是不是超過了限度，該控制控制了。

答案 3：

1. 敏捷開發(fā)過程中, 相關(guān)的系統(tǒng)分析文檔, 設(shè)計(jì)文檔. 對應(yīng)的測試分析文檔, 測試用例, 是否需要按質(zhì)量完成.這些文檔視情況而寫，對于框架平臺的，設(shè)計(jì)文檔可能會要求嚴(yán)一點(diǎn)；業(yè)務(wù)開發(fā)，可能會只需要畫幾個(gè)類圖而已。但是不管如何，測試用例我們是要求寫的。對于測試用例質(zhì)量的要求與傳統(tǒng)敏捷開發(fā)一樣2. 關(guān)于需求, 敏捷開發(fā)過程中, 是否需求方只需要提供一個(gè)用戶故事,而具體的詳細(xì)設(shè)計(jì)在開發(fā)過程中邊設(shè)計(jì)邊討論.用戶故事往往在實(shí)際開發(fā)中不夠，因?yàn)閮r(jià)值的東西都是相對高層的東西，實(shí)現(xiàn)的時(shí)候還需要細(xì)化，可以使用用例、業(yè)務(wù)規(guī)則等形式細(xì)化，檢驗(yàn)的標(biāo)準(zhǔn)就是開發(fā)人員能夠理解需要做什么，知道有哪些流程。詳細(xì)設(shè)計(jì)肯定是在開發(fā)過程中去做的，但是在估時(shí)時(shí)會進(jìn)行簡單的設(shè)計(jì)，這個(gè)準(zhǔn)確度是隨著團(tuán)隊(duì)經(jīng)驗(yàn)以及能力提高而提高的。3. 敏捷開發(fā)過程, 是否可以等價(jià)于迭代式開發(fā)迭-發(fā)并不是敏捷開發(fā)，它只是敏捷開發(fā)的一個(gè)方面。就但說迭代，有沒有固定周期、有沒有價(jià)值目標(biāo)就是敏捷開發(fā)中的一些要素。

答案 4：

1，文檔要全，而且要保證質(zhì)量，不過測試用例例外，看情況而來。敏捷團(tuán)隊(duì)有建議的人數(shù)規(guī)模，測試人員應(yīng)該著眼于關(guān)鍵點(diǎn)，一個(gè)全面的測試用例也常常被證明40%以上的用例是徒勞的。測試人員應(yīng)該具備出色的test sense，根據(jù)經(jīng)驗(yàn)?zāi)軌蚺袛喑瞿睦锸菨撛赽ug、缺陷和主要數(shù)據(jù)流關(guān)鍵點(diǎn)，針對這些地方寫測試用例，方便管理也能夠判斷數(shù)據(jù)流階段性的正確。還有就是TDD在開發(fā)過程中的保證，前期的需求討論，測試人員參與程度應(yīng)比開發(fā)人員更高，而系統(tǒng)架構(gòu)確定、軟件架構(gòu)確定，都是由開發(fā)和測試共同決定，并在開發(fā)過程中出現(xiàn)需求變動，也保持軟件架構(gòu)的相對穩(wěn)定，因?yàn)檐浖軜?gòu)的改動對于測試人員來講不單單是改動，很可能是重新來過。2，這個(gè)不管是不是敏捷的，前期都盡量挖掘客戶的需求，不留下任何潛在的需求。開發(fā)過程中的需求變動，根據(jù)經(jīng)驗(yàn)來說，還沒有遇上過需求不變的。這個(gè)其實(shí)是很無奈的，這是由客戶方不夠?qū)I(yè)引起的，這也確實(shí)沒有辦法，只能是期望變動不是翻天覆地的。3，開發(fā)過程差不多，或者說一樣也可以，但敏捷方法對人員上的控制有一些建議，來使人員工作效率更高，交流成本更低。在這方面來講，敏捷對于人的性格也有要求，不是每個(gè)人都適合參加敏捷開發(fā)，在搞人這方面上，敏捷只是提出了一些建議，最佳實(shí)踐還是得根據(jù)公司人員和公司-結(jié)構(gòu)的實(shí)際情況來定了。

答案 5：

職責(zé)沒有變化，但是意識要有很大的變化。意識需要從發(fā)現(xiàn)Bug轉(zhuǎn)變?yōu)轭A(yù)防Bug出現(xiàn)，從越多發(fā)現(xiàn)Bug轉(zhuǎn)變?yōu)樵皆绨l(fā)現(xiàn)Bug

答案 6：

敏捷中根本沒職責(zé)的概念，沒有測試、開發(fā)的分工，兩種角色可以互換。但是這種要求對現(xiàn)在我們的團(tuán)隊(duì)來說，有點(diǎn)困難 。文檔，敏捷其實(shí)不等于無文檔，只是要產(chǎn)出必要的文檔，在一個(gè)小團(tuán)隊(duì)里，如果人員足夠自主的話，充分的溝通是可以代替文檔傳遞項(xiàng)目內(nèi)容的。但是這個(gè)我們也嘗試失敗了，主要原因還在于人員問題。人員，我曾經(jīng)問一個(gè)培訓(xùn)老師，敏捷是不是對人員要求不顯著，可以通過團(tuán)隊(duì)來彌補(bǔ)一個(gè)新人的技術(shù)能力問題？雖然回答是肯定的，但是我們嘗試過，其實(shí)敏捷對人還是有一定要求的，最少的要求是主動性強(qiáng)。敏捷和瀑布哪個(gè)好？其實(shí)一個(gè)開發(fā)模式?jīng)]有自己的好壞，要看適合與否。瀑布模式會流程感強(qiáng)一點(diǎn)，而且留下的文檔對于產(chǎn)品的長期維護(hù)還是有幫助的。敏捷中產(chǎn)出的文檔太少，項(xiàng)目后期若不補(bǔ)充文檔，產(chǎn)品長期發(fā)展是不利的。如果一個(gè)團(tuán)隊(duì)人員自主性不強(qiáng)，主動性也不好，能力普遍不強(qiáng)，其實(shí)這樣子情況瀑布模式反而會讓人覺得過程可控（感覺上的）。并且這種情況下，個(gè)人感覺瀑布和敏捷差別不大。

答案 7：

我認(rèn)為敏捷測試是為了讓測試團(tuán)隊(duì)回歸測試的本質(zhì)，即驗(yàn)證功能性能，預(yù)防與發(fā)現(xiàn)Bug，測試不是為了出文檔而進(jìn)行的，測試的質(zhì)量不是由文檔來決定的，關(guān)鍵是測試的人員。敏捷測試正是強(qiáng)調(diào)參與人員的重要性。對于比較簡單的場景，減化必要文檔能提高測試的效率，但對于比較復(fù)雜的場景，添加必要文檔也許可以提高效率。

答案 8：

我覺得,不管是不是敏捷開發(fā)。對于測試團(tuán)隊(duì)的職責(zé)和產(chǎn)出是沒有影響的。職責(zé)始終應(yīng)該是根據(jù)需求來檢驗(yàn)產(chǎn)品質(zhì)量，保證最后遞交的產(chǎn)品符合出口準(zhǔn)則。產(chǎn)出應(yīng)該就是各類測試報(bào)告。

答案 9：

主要職責(zé)沒有變化，仍然是以發(fā)現(xiàn)BUG為前提的測試，但是要多一種更積極的溝通意識，很多不是BUG的問題也要盡早發(fā)現(xiàn)盡早反饋。

答案 10：

個(gè)人覺得在敏捷團(tuán)隊(duì)中，測試的難度和挑戰(zhàn)比瀑布模式大的多。不斷變更的需求，技術(shù)重構(gòu)，從story到迭代版本的基本驗(yàn)證，測試...因此測試的主要職責(zé)可以包括以下的幾點(diǎn)：1.需求的把握。測試要對不斷變化的需求都能把握住，以PO（product ower）的標(biāo)準(zhǔn)來要求自己，敏捷的要旨是小步快跑，保證每一步都是對的，這樣在團(tuán)隊(duì)中就需要有人來保證我們做出來的東西是沒有偏離需求的，這個(gè)角色只有測試勝任；2.團(tuán)隊(duì)節(jié)奏的控制。不知道大家有沒有做過敏捷項(xiàng)目，迭代不斷的出現(xiàn)延遲，問題單越來越多，大家疲于根據(jù)計(jì)劃加班。這個(gè)時(shí)候我們可不可以把下個(gè)迭代要做的事情暫時(shí)先停下來，留一個(gè)迭代或者半個(gè)迭代來解決問題，重新讀下代碼，找出那些異味的代碼（-elly code）重寫一下。找找我們流程中的問題并改進(jìn)。這個(gè)事情也是由測試人員來提出比較合適；3.質(zhì)量控制。這當(dāng)然是測試的傳統(tǒng)的工作，找出問題，讓開發(fā)人員來解決。對于一個(gè)tester來說，質(zhì)量控制Quality Control比質(zhì)量保證Quality Assurence更重要。在敏捷階段，不是說發(fā)現(xiàn)的所有問題都需要馬上讓開發(fā)人員去改，因?yàn)榛蛟S這個(gè)bug對應(yīng)的需求還不明確，或許下輪的重構(gòu)就能自動解決問題，或許當(dāng)前這個(gè)迭代使用的技術(shù)解決這個(gè)問題代價(jià)太大... 總之，這里是比較靈活的，也是比較考驗(yàn)測試人員的經(jīng)驗(yàn)的，什么問題應(yīng)該馬上解決，什么問題可以討論。另外，關(guān)于質(zhì)量控制比較重要的一點(diǎn)是分清楚測試階段，這點(diǎn)在國內(nèi)的公司很明顯，單元測試，集成測試覆蓋率低，或者干脆不做，或者做了沒啥作用，每當(dāng)大家回去做問題回塑，會發(fā)現(xiàn)很多問題應(yīng)該在ut或者st階段發(fā)現(xiàn)。那么這里的測試人員要不要去做這些測試，如果要做怎么做，這個(gè)對于不同形態(tài)的產(chǎn)品或許答案完全不一樣。自己參與過的大型產(chǎn)品中測試人員都是做集成測試的，只是這個(gè)過程對測試來說比較痛苦，需要了解代碼，有一定的編碼能力。另外，測試的產(chǎn)出這個(gè)有點(diǎn)不好界定，產(chǎn)出這個(gè)東東感覺是和流程比較強(qiáng)相關(guān)的，我在流程的哪個(gè)階段必須產(chǎn)出什么東西。文檔，測試分析，問題單，測試需求分析等等。。。 這個(gè)也是和產(chǎn)品的形態(tài)有關(guān)，如果是輕量級的產(chǎn)品完全不需要做很多事情，或者很多事情可以合并來做，產(chǎn)出一份文檔或者結(jié)果就可以。

答案 11：

敏捷過程中，測試的主要職責(zé)應(yīng)該是對每次迭代的產(chǎn)出物做驗(yàn)證，確保產(chǎn)出物滿足產(chǎn)品設(shè)計(jì)需求，質(zhì)量合格。

答案 12：

1.關(guān)于輕文檔的說法之前也看了些關(guān)于敏捷模型和方法的介紹性文章，對其中“輕文檔”的概念是深信不以，自己誤將“輕文檔”理解為“無文檔”了 ，這下出亂子了，在一段時(shí)間里需求和設(shè)計(jì)都是采用口口相傳的方式，完全靠個(gè)人的理解和記憶力，使所有成員都處在混沌狀態(tài)（畢竟這種方式對人的要求太高了，按照當(dāng)前中國企業(yè)人員現(xiàn)狀，大家都懂的...），最后連產(chǎn)品經(jīng)理自己都不記得當(dāng)時(shí)是怎么設(shè)計(jì)的了，后來改成了設(shè)計(jì)討論優(yōu)先，技術(shù)同學(xué)可以開始開發(fā)，此時(shí)交互設(shè)計(jì)師同步撰寫設(shè)計(jì)文檔，在產(chǎn)品開發(fā)過程中再不斷完善這個(gè)文檔。但是文檔本身也必須講究輕量級，將主要的邏輯和需求明確清楚，對于異常問題可以隨著后續(xù)的開發(fā)進(jìn)程進(jìn)行補(bǔ)充。對于測試的一張紙的問題，我覺得一張兩張或者三張的這種形式并不重要，重要的是測試用例是一定要有的，另外測試人員也需要對每個(gè)迭代所要達(dá)到的目標(biāo)爛熟于心，這點(diǎn)個(gè)人覺得很重要。2. 關(guān)于需求的這個(gè)觀點(diǎn)，其實(shí)我個(gè)人只能贊同一半了，贊同的是需求可以通過user story card進(jìn)行傳達(dá)，但是設(shè)計(jì)不是要等到開發(fā)時(shí)才出，而是要將本迭代需要開發(fā)實(shí)現(xiàn)的需求要同步討論和給出設(shè)計(jì)來3. 這點(diǎn)贊同人月神話的回答，我再補(bǔ)充一點(diǎn)，“比如, 將某個(gè)產(chǎn)品分成幾個(gè)部分, 先完成某個(gè)部分, 再完成其他部分, 或者先做出一個(gè)基本原型. 此原型能夠?qū)崿F(xiàn)基本功能, 再次基礎(chǔ)上繼續(xù)完善其他功能“的這個(gè)說法，我個(gè)人不是很贊同，敏捷的迭代應(yīng)該是盡量將產(chǎn)品所要傳達(dá)給用戶的最有價(jià)值的功能先行實(shí)現(xiàn)，而不是簡單的說是先實(shí)現(xiàn)幾個(gè)部分再實(shí)現(xiàn)幾個(gè)部分

答案 13：

我越來越覺得 是中國的產(chǎn)品經(jīng)理能力不夠 對細(xì)節(jié)無法把握 也做不出原型 所以我很同意上面的觀點(diǎn) 在反復(fù)中完善細(xì)節(jié) 其實(shí)如果原型交互做的好 真的可以減少文檔 但中國會用工具的人太少了

下一篇:高智商的男人情商一般比較低嗎？？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:-的-辦事處都負(fù)責(zé)哪些業(yè)務(wù)？ 上一篇 【方向鍵 ( ← )上一篇】