過去十年來在軟件開發領域到來的自動化壹個最大的變化是任務自動化。在過去，像構建壹個應用的特殊版本，創建文檔，或者更新bug報告的狀態是人為的。壹些團隊甚至貢獻為了 啟動壹個版本而負責的"創建人"責任。像這些人為的任務（或者是緊緊地綁定給個人或機器）是消耗時間的，並且創建來為了避免瓶頸，比如創建人占據私人的壹天並阻礙新版本被完成。
幸運的是，持續集成（CI）工具通過允許任務被標準化和自動化來挽救。持續集成服務重要地安排和執行任務，壹個規則的臺式電腦能做的任務並且讓這些任務在目標機器上執行而不是它自己。回到創建版本的例子，取代讓鮑勃為手工在他的機器上創建版本負責，壹個持續集成服務能被集成去選擇壹個目標機器並且在那臺機器上執行版本。不僅使鮑勃不需要身體上在那臺版本機器出現，而且能在任意時刻發生版本創建，不管是已安排的或者是為了響應另壹個動作。
舉個例子，測試者愛麗絲可能想要壹個基於最新改變的應用程序版本去看壹個程序錯誤是否被修復，而且她能自己發起版本創建。這個不僅使資源從做代表性任務中自由運作起來，而且給團隊在個人以外和團隊流程上給予了更多的控制。妳也可以把持續集成任務綁定壹起給更深的線程壹些任務。學習壹個持續集成如何工作是對沒有放很多編程的重點在自動化上很好的引子。
使用持續集成的壹個途徑是跑端到端的測試套裝。這些測試經常需要跑數分鐘甚至數小時。我使用過持續集成去自旋向上和自旋向下測試機器並且發起在那些測試機器上的測試。相對於在妳自己機器上跑這些測試這是壹個很大的幫助，因為它允許壹個測試開發者當測試到處跑的時候去做其他的工作。持續集成的服務器控制著所有這些任務的方方面面。
壹些持續集成服務的普通例子是開源工具Jenkins，基於雲的Travis CI，和專屬工具Bamboo，但是這些也是其他的壹些。甚至更低技術是使用壹個像克隆或者windows任務分配者的工具為了在單壹機器上去使任務自動化。
CI對於開發軟件愛好之外的編程是獨立的，並且它是壹個測試能確實增加價值的壹個地方。
現代源碼控制
我首先需要指出我愛源碼。當編寫代碼（或者博客！）時，它是壹個很有幫助而不僅是工具。對於壹個編碼的測試員，它是壹個無需腦力者。甚至即使壹個測試不編碼，當測試軟件時以現代方法使用源碼控制可能是壹個大的利益。
在現代方法中"我"的意思是什麽？"我"的意思是使用源碼控制1）集成其他工具，比如CI服務器或者問題追蹤器，並且2）允許使用好的團隊流程習慣，比如基於幹線的開發。好的源碼控制允許個人去分析變化和更深地挖掘軟件工程正在發生什麽。
壹個接近源碼歷史和壹些基本學習的測試能問出像"在應用裏的哪個文件有最多的開發在它們上面工作？""哪個文件有最大的變化？""哪個變化的設置包含引起問題的代碼？"等待。這個信息有助於找到步調且暗示壹些事件的引發。
用CI集成源代碼甚至能更加有力。在問題跟蹤者的事件能使它們的狀態在由開發引起的變化中更新。測試者能要求必要的需求在輸入的代碼被自動查找出來，比如通過自動測試或者代碼模式需求。建構和部署能被改代碼發起。當源碼控制被很好使用，在這種情況下有很多種可能，這是壹個在持續傳遞後隱含的概念。
舉個例子，我在壹個使用基於雲集成服務的開源項目上工作為了檢查每壹個由提交者提交的交付。在這個項目裏，持續集成運行所有的自動化測試並且檢查所有為形式和格式增加的代碼。假如壹個提交造成錯誤的測試，或者沒有滿足設置的風格向導，提交失敗了並且暗示了提交者和項目維持者去修改提交。這有助於提供項目歷史裏以統壹的風格每壹個提交並且暗示了提交者在增加或者更新模塊中可能的微小錯誤。
這些目前在源碼控制的熱點是Git，自由和開放代碼的，在它周邊有著健壯的生態系統。這些也是壹些其他的方面，比如Subversion，Mercurial和微軟團隊基金會。
遙測和監控
這是壹個我並不熟悉的主題，但是它確定是測試者們感興趣的。監控是壹種方法，從此掛鉤被放在壹個應用程序裏去發回關於軟件是如何被使用的信息給軟件創造者。這能包含正被使用的後端/服務器應用程序接口函數，並且在哪個指令，由被使用的由用戶界面組成的部分和在什麽頻率上，等等。
這個目標不是為了發送特殊的用戶信息返回給開發團隊，更普通的信息是關於壹個應用程序正在被用著的和如何被用的部分。這提供了終端用戶在做什麽的視角，他們實際上如何使用應用程序，並且特定屬性如何被得到。安蘭培是個微軟測試，曾經簡短討論這事情的他曾做過的通過遙測和監視的壹部分。
類似於最小化資源控制歷史，監視能幫助妳找出答案，從簡單的問題中（"上周多少人記錄？"）到更特殊的和可視化的問題（"當特性X被發布時用戶們如何改變他們的習慣？"）。這些是幫助測試們執行更好的測試策略的種類問題，並且，總的說來，幫助團隊對用戶做更好的選擇。
更多的信息，請檢查AB測試播客頁面和布倫特詹森。壹個主流產品如何使用遙測技術，看壹看Mozillla如何通過火狐使用監測技術。
也使用Selenium
最後壹點，但這不意味著這不重要，對於使用web應用程序以及其相似的應用程序的測試者來說，Selenium WebDriver是壹個很好的工具。在這壹點上，WebDriver是壹個用於自動驅動瀏覽器行為的標準工具，類似於壹個人類用戶如何在瀏覽器中用網站APP交互。它有壹些語言綁定，和壹些主流瀏覽器工作，並且是壹款非常好的能被開發第壹組件的可擴展性API的例子。簡言之，它是壹個優秀的工作。
當被靈活地使用時，WebDriver允許測試和開發去使用戶體驗性測試得到自動化，這個可以被放在壹個持續性的可傳遞流程。我寫了壹個簡單的基於網頁驅動的測試，可以找到像導航到登錄頁面的鏈接的事務，而不是尋找用戶名和密碼場合（由於壞的部署），或者尋找壹個不打開的對話當壹個控制被點擊成想象的（壹個明顯的但嚴重的問題）。這些是很快被找到的事情但是不能被單元測試覆蓋。
WebDriver也能被用在寫自動化的測試，可以被本地執行去雙重檢查那些不會以非預約的方式打斷重要特性的變化。這些甚至是WebDriver用於擴展功能測試以外的用處。
對於對學習代碼感興趣的測試來說，WebDriver能提供壹個好的學習代碼的介紹。自動化測試腳本能是壹個容易的方法去熟悉編程而不是深入挖掘代碼語言鴻溝。它提供足夠的架構去開始，並且仍然能夠完成壹些很好的測試工作。
大腦有這些概念，加強測試自動化，不管妳在軟件開發中的角色是什麽。