我們是一家小公司，我是一名測試協調員，任命爲公司進行測試。 我們沒有適當的測試流程。開發 - 部署和測試幾乎每天都在進行，通信通過Skype或郵件建立。 我如何開始實施測試流程？如何在瀑布之後的測試過程中引起變化？
我們在8個不同的國家運營，我們沒有專門的測試團隊進行測試。商業用戶是我們的測試人員。 對我來說，讓他們全部在需要時進行測試是非常重要的。 那麼，我如何以他們的工作方式帶來這種變化？
任何建議或幫助，慷慨讚賞。
我認爲這種變化的最佳方法是顯示您的經理的測試價值。
我想如果沒有良好的組織測試過程，最終會發現錯誤。客戶發現的一個關鍵問題的價值可能會導致對公司業務的巨大影響。那麼，你可以等待它發生或剛開始建立測試組。
此外，這是一個普遍的事實，即儘快發現錯誤爲組織節省了大量資金。這主要是因爲解決問題接近開發時間需要更少的時間。
我會推薦Jira作爲開源工具，它允許組織錯誤跟蹤並支持敏捷開發過程。
完全同意你說的話。我們在我們的項目中使用TFS來處理錯誤和其他測試用例。但是TFS中的測試計劃沒有組織。我們每隔一天都會部署到UAT，在這種情況下，如果沒有TFS中的標準測試計劃文件夾，就很難執行測試。您認爲什麼是開始在TFS中組織測試計劃的最佳方式。你會建議從追蹤矩陣開始並相應地創建測試計劃嗎？或者您是否看到其他任何可以說測試覆蓋率處於可接受水平的方法 – user4557522 2015-02-13 01:19:44
TFS是允許在不同項目之間建立連接的良好系統。我建議從項目需求開始，並將它們連接到測試用例，然後連接錯誤。此外，TFS允許將源代碼（在源代碼管理中）與需求連接起來，並再次與錯誤相關聯。這些連接有助於理解哪些代碼/需求區域更成問題。 MS網站上有很多資源來解釋這個過程。開始時請看[這裏]（http://nakedalm.com/requirement-management-in-the-modern-application-lifecycle/） – Eugene 2015-02-13 10:43:16
然後當你的測試覆蓋了所有的項目需求時，你可以說你的覆蓋範圍是可以接受的。 – Eugene 2015-02-13 10:47:37
我會建議考慮Comindware Tracker - 工作流程自動化軟件。只有在完成工作流中的上一步之後，它纔會執行通過將任務分配給正確的團隊成員而自動創建的流程。此外，您可以直觀地創建表單，設置自己的工作流規則並自動處理數據。您可以將Comindware Tracker配置爲在任務或文檔發生特定事件時發送電子郵件通知，或發送預定電子郵件報告。討論線索在每個任務中都可用。您可以與團隊共享文檔，並將其存儲在任務中，支持文檔版本控制。
也許小公司剛開始優化工作流程的關鍵原因應該考慮Comindware Tracker是它能夠在流程執行期間實時更改工作流程而無需中斷流程。由於您在開始階段可能會發生很多變化，因此此解決方案值得關注。此產品的評論可能會有幫助 - http://www.brighthubpm.com/software-reviews-tips/127913-comindware-tracker-review/
免責聲明 - 我在Comindware工作。我們使用Comindware Tracker來管理我們公司內的工作流程。我很樂意回答有關解決方案的任何問題，如果有任何問題應該提出。
欣賞你的回覆時間。 – user4557522 2015-02-13 01:05:21
欣賞你的回覆時間。你會推薦什麼是團隊中最好的實踐，在這個團隊中，每隔一天都會部署UAT。當然，在每次部署之後執行迴歸測試並不是我們看到的正確選擇。如何在經常發生UAT部署的環境中安排測試。你能否建議，即使部署過程應該改變？ – user4557522 2015-02-13 01:20:26
如果您想要頻繁發佈，那麼您應該考慮使用自動化迴歸測試。
這將涉及您的應用程序中的每一個重要功能的自動化測試。此外，當新功能正在開發時，自動迴歸測試將同時編寫。
自動迴歸測試方法的好處是您可以獲得持續集成運行的迴歸測試。這使您可以在代碼寫入後不斷進行迴歸測試並發現任何迴歸錯誤。
手動迴歸測試非常難以維持。隨着您嚮應用程序添加越來越多的功能，手動迴歸測試需要更長的時間，並且很難頻繁發佈。這也意味着測試所花費的時間將不斷增加。
如果您的組織決定不使用測試自動化，那麼我建議您需要創建一個包含手動迴歸測試階段的交付管道。您可能需要考慮對此使用諸如看板這樣的敏捷框架（這通常適用於頻繁發佈）。
我投票結束這個問題，因爲它是關於工作場所哲學的問題，而不是幫助中心定義的編程問題。 – TylerH 2017-01-27 17:26:41