當與開發人員談起版本控制時，你一般會聽到他們說，git是一種工作流工具，而github是乙個存放**和個人簡歷的地方。而對於測試人員或業務分析人員來說，git是啟動構建和產生缺陷的神秘之源。測試人員也應該來使用github，不管是出於個人目的還是專案的需要，並成為現有專案的貢獻者。
\u0026#xd;\u0026#xd;
在演講結束後，infoq採訪了heusser和kenst，談論如何在**之外使用github、測試人員如何從github中得獲益，以及如何鼓勵測試人員使用github和其他開源工具。
\u0026#xd;\u0026#xd;
infoq：你們提到說，github不僅僅可以用於存放**，還有其他很多用處。你們能舉一些例子嗎？
\u0026#xd;\u0026#xd;
\u0026#xd;\u0026#xd;\u0026#xd;matt heusser：當然。任何乙個測試相關的資源——測試計畫、會議紀要、簡明指南都可以放到版本控制系統裡。而規範檔案（假設它們是html或ms word格式的）可以放到github上。
\u0026#xd;\u0026#xd;
示例可以激發創造力，所以我舉了一些例子。下面是我建立過的測試資源，它們都很有用。第乙個是關於如何使用elisabeth hendrickson所倡導的格式來編寫探索性測試章程的描述和示例。第三個是乙個字串清單，你可以把它們用在基於字串的輸入欄位上，有助於你找出系統的錯誤，很有意思！
\u0026#xd;\u0026#xd;
infoq：如何使用github來處理非**物件？可以在這些物件上使用github所有的功能嗎？
\u0026#xd;\u0026#xd;
\u0026#xd;\u0026#xd;\u0026#xd;kenst：所有的專案享受同等待遇。在建立倉庫後，你可以使用github所有的主要功能，包括版本控制、問題管理、wiki，等等。即使是非**物件，你也可以提交拉取請求並作出增量性的變更。
\u0026#xd;\u0026#xd;
heusser：是的。除了二進位制檔案的合併和衝突處理，其他的都是一樣的。不過，類似從兩個分支中選擇最新版本的操作對於ms word文件來說是行不通的。
\u0026#xd;
infoq：測試人員能夠從github中獲得哪些好處？
\u0026#xd;\u0026#xd;
\u0026#xd;\u0026#xd;\u0026#xd;kenst：沒錯。不管是盈利組織還是非盈利組織（比如selenium專案），他們都在使用github來託管他們的**。
\u0026#xd;\u0026#xd;
首先，這意味著軟體人才會越來越多地使用github。**變更是通過拉取請求來提交的，測試人員和開發人員可以看到**的變更情況，在合併到生產環境之前，可以分別對它們進行測試。在系統的各個層面進行自動化測試給團隊帶來了優勢。就像matt說的那樣，測試人員也可以參與到**審查過程當中，並通過github issues來提交缺陷。
\u0026#xd;\u0026#xd;
其次，這意味著組織和招聘者會越來越多地通過github賬號來物色候選人。如果有了github上能夠顯示技術能力的東西，為什麼還要去看簡歷呢？儘管這些東西可能會包含一些無關緊要的專案或非日常工作相關的資料，但它們都比單純的簡歷要來得有價值。
\u0026#xd;
infoq：你們在大會上演示了如何註冊乙個github賬號和啟動乙個專案，然後做了相應的解釋。你們為什麼要採取這樣的方式呢？
\u0026#xd;\u0026#xd;
\u0026#xd;\u0026#xd;\u0026#xd;kenst：我們演示的主要目的是要確保觀眾能夠真正地了解如何建立乙個github倉庫並成為乙個貢獻者。基於這個原因和時間上的限制，我們決定先做演示，然後再說明一些背景資訊和額外的例子。
\u0026#xd;\u0026#xd;
heusser：在開始的時候，演示花了很長的時間，而額外的一些補充花的時間更長，我們擔心會超時。不過我們還是緊湊地完成了任務。
\u0026#xd;
infoq：人們應該如何鼓勵測試人員使用像github這樣的開源工具？你們有什麼建議嗎？
\u0026#xd;\u0026#xd;
\u0026#xd;\u0026#xd;\u0026#xd;heusser：這個問題問得很好。說實話，我聽到很多領導或教練說一些「放手去做」之類的話，他們還質疑「為什麼測試人員用不了新工具」。我建議讓測試人員結成對，讓他們使用新工具來完成工作，不管是使用github還是selenium，或者其他的什麼。你可能會覺得這比你想象得要困難一些，需要一些時間和幫助，又或者你覺得這個很容易，結對有助於減小阻力。不管是哪一種情況，你都贏了！
\u0026#xd;\u0026#xd;
這裡有一些給實踐者的建議：啟動乙個專案，學習一些編碼招式（katas）。對於程式語言來說，通過google搜尋到的建議與深度的專業知識之間是有很大區別的。一些技巧經過反覆練習就會變成專業技能。從給我的katas倉庫拉取分支開始，然後使用katagenerator.rb建立你自己的招式。其中有乙個轉化器是最簡單的，它將羅馬數字轉換成小數。做一些修改，然後提交，你就知道該如何向乙個專案提交**了。
\u0026#xd;\u0026#xd;
將來如果你需要其他軟體，卻因預算問題而煩惱時，可以考慮尋找開源的專案。例如，selenium可以用來替換uft。找到這個專案，看看能不能加入其中，或者僅僅是報告一些缺陷。報告缺陷是git的另乙個工作流，學習起來非常簡單，而且開發者會因此而感激你！
\u0026#xd;\u0026#xd;
為了保持與時俱進，測試人員需要關注這些專案（以及其他相關的專案），而這些專案都在github上。
\u0026#xd;
檢視英文原文： github for testers
測試人員的GitHub
當與開發人員談起版本控制時，你一般會聽到他們說，git是一種工作流工具，而github是乙個存放 和個人簡歷的地方。而對於測試人員或業務分析人員來說，git是啟動構建和產生缺陷的神秘之源。測試人員也應該來使用github，不管是出於個人目的還是專案的需要，並成為現有專案的貢獻者。u0026 xd n...
測試人員的GitHub
當與開發人員談起版本控制時，你一般會聽到他們說，git是一種工作流工具，而github是乙個存放 和個人簡歷的地方。而對於測試人員或業務分析人員來說，git是啟動構建和產生缺陷的神秘之源。測試人員也應該來使用github，不管是出於個人目的還是專案的需要，並成為現有專案的貢獻者。在演講結束後，inf...
測試人員的GitHub
當與開發人員談起版本控制時，你一般會聽到他們說，git是一種工作流工具，而github是乙個存放 和個人簡歷的地方。而對於測試人員或業務分析人員來說，git是啟動構建和產生缺陷的神秘之源。測試人員也應該來使用github，不管是出於個人目的還是專案的需要，並成為現有專案的貢獻者。在演講結束後，inf...