如何設置QA部門？

Question

我是一個小團隊的高級成員（另外兩名程序員）。我們都是新來的公司，我一直在設立所有的開發基礎設施。到目前爲止，我擁有一個出色的版本控制系統（Git），一個出色的問題跟蹤系統（Redmine），而且我即將建立一個構建環境（Hudson）。我現在正在考慮設立我們的質量保證部門。我想建立一個像Scrum這樣的敏捷開發流程，但這還沒有起作用。那麼，我如何開始質量保證問題呢？遵循計劃和報告結果，開發測試計劃的好過程是什麼？是否有任何組織和運行QA的工具？

謝謝！

Answer 1

你表示你想要一個QA小組/部門，但你不知道爲什麼。關於質量保證小組的工作有很多假設。

QA的基本性質是爲了確保正確的產品是第一次構建正確。 Software Quality Assurance通常是關注開發代碼的過程。

或者，你只是在尋找別人來測試你的代碼嗎？

如果您的注意力集中在質量保證的測試方面，我會盡可能地推入您的小組的開發部分。自動化測試將有助於提高第一次獲得正確的機會。此外，測試顯着降低了產品內部變化的風險。而且，不要將大部分測試寫作轉移到團隊的一個子集上。您希望將可測試性作爲設計的關鍵方面，而開發人員不會編寫足夠多的測試，因此不要在設計中充分加以體現。指望一個人或一羣人在一堆測試中跑步意味着你不能經常運行它們，而且你往往會低估舊的迴歸測試。

如果您的重點是QA而不僅僅是測試，那麼值得分配一個主要角色的人是看產品，其複雜性，度量和測試覆蓋率，以確定是否有足夠的測試在正確的位置代碼庫。這個角色與監控總體設計的架構師或專門從事可用性和/或設計指導用戶界面開發的人員無異。角色應該是支持正確的工作，而不一定要執行工作。

我個人對上述所有情況都有一個例外，那就是至少有一個人有正確的心態去執行exploratory testing。探索性測試應該是上述所有測試的一個子集。並且，當發現問題時，應該用於反饋到自動化測試中（例如，如果發現錯誤，則修復操作的一部分應該是編寫測試來演示錯誤和修復。而且，如果測試覆蓋範圍是代碼複雜度較低，編寫其他幾個測試以確保沒有其他錯誤）。用戶界面尤其需要探索性測試。探索性測試通常很好地滿足了用於完成任務的可用方式的排列，以及在舊UI框架中自動化測試的困難。

更新：您可能想要退房Episode 164: Agile Testing with Lisa Crispin

Answer 2

如果你打算使用Scrum，我想你的意思是所有的敏捷方法。不會是測試計劃，錯誤報告和類似的東西有點花銷？

至於工具，我會建議添加wiki或jira作爲地方存儲任務，相關的用戶故事和相關的錯誤。

至於設置QA部門（一個人爲部門O.o），我建議放棄'QA部門'。標籤，只需聘請一名專注於測試的團隊成員。 您可能希望在敏捷工作並具有測試經驗的人員。如果那個人知道探索性測試（工具&技術），那將是很好的。

如果您考慮測試自動化（因爲您已經擁有Hudson），測試人員需要掌握編程技巧。另一方面，您可以讓開發人員自動化，並專注於獲得優秀的測試人員，而不是可以執行一些代碼的平均測試人員。無論如何，我會實施一些測試自動化，一些迴歸。

有一件事，不要陷入質量保證/流程/測試計劃/文檔繁重/詳細的手動腳本/流程導向的事情。保持敏捷，否則很快你會注意到它並不真正起作用。

=================編輯以解決Jacko評論======================== ====

因此，我假設，不打算爲這個開源項目做出貢獻，而是讓一些插件使用它的代碼，但也擴展了它的功能，所以它會適合你自己項目中的需求？涼。

所以，你必須：
其他方開發的，它有自己的時間表，項目計劃等 1）開源項目
2）擴展/插件您開發，使該項目可爲您
3）你自己的項目有一些通過插件委託給開源項目的功能。

我想所有這些都通過一些消息傳遞機制集成在代碼級別上。在這種情況下，我會說，你需要一個可以編碼的人，不管他的背景如何（儘管開發人員會更容易找到，但他會對編寫自動化測試感興趣嗎？）。
無論如何，你需要自動化測試：
A）顯然你的項目 - 寫你現在做的單元測試，或者更多一點。 B）單元測試將確保你的主項目的任何變化都不會中斷它與插件/擴展的交互（開源項目的那些變化）
C）插件/擴展的單元測試 - 它是你編寫的代碼，所以你需要進行單元測試，因爲你的項目需要A
D）（不是很明顯的部分）你需要測試以確定開源項目中的變化是否會影響你的插件。

當然A和B作爲C和D會以某種方式重疊，但在形式上這就是你需要知道的。

因此，回到原來的問題，我不認爲你需要質量保證部門（順便說一句，不是說Scrum說放棄部門標籤，並有一個團隊？）在傳統意義上。找一個能夠（並且喜歡）創建自動化測試的人，可能在單元測試級別上。跟Scrum一起去吧。有一個團隊。跳過全面的文檔，正式的流程，ISO/IEEE標準進行測試。創建輕量級文檔，只是爲了提供主要/總體目標/方法/假設。
...如果它不起作用，回顧討論它，嘗試調整的東西，嘗試新的東西。連續的提高！