Mimo iż jestem developerem, zajmowałem się dużo tematyką testów (zarówno manualnych, jak i automatycznych - w tym projektowanie i rozwój środowisk do testów E2E). Jeżeli interesuje Cię automatyzacja, to zakładam że chcesz celować właśnie w automatyzację testów integracyjnych lub E2E, ponieważ testy jednostkowe powinni tworzyć developerzy jako część swej normalnej pracy. Potwierdzam wnioski płynące z tego, co napisał @DolBo - jeśli chcesz być dobrym testerem automatycznym, powinieneś tak naprawdę zainwestować w to, aby poznać na rozsądnym poziomie fach developera - tak, jak ja musiałem poznać fach testera również od strony "manualnej", żeby móc robić to, co robiłem :).
Problem polega na tym, że środowisko testów automatycznych to tak naprawdę normalny projekt programistyczny, nieróżniący się niczym od tworzenia normalnych aplikacji. Te same zasady związane z jakością kodu, designem itd., które obowiązują w programowaniu, obowiązują również przy tworzeniu testów automatycznych (o samym środowisku nie wspominając). Aby je umiejętnie stosować, trzeba niestety mieć jakąś praktykę programistyczną, z kolei ich brak sprawia, że koszty utrzymania rosnącego zestawu testów mogą przewyższyć zyski z automatyzacji. Ponadto, im cięższy rodzaj testów, które trzeba zautomatyzować, tym większe wyzwania stoją przed frameworkiem testowym - chodzi tutaj o dostarczenie takich narzędzi, aby jak najefektywniej wykorzystać zasoby czy jak sprawić by pierwszy lepszy fail nie wysypał całego środowiska. Wprawdzie niekoniecznie sam tester powinien takie narzędzia czy framework tworzyć, ale na pewno będzie musiał umieć z tych narzędzi skorzystać.
Jako przykład mogę podać, jak ja się wkręciłem w temat - gdy zaczynałem, istniało sobie kilkaset testów automatycznych i framework do ich uruchamiania. Testy były pisane w autorskim DSL-u, na który wszyscy narzekali ze względu na rozwlekłość (pojedyncza komenda potrafiła zajmować cały ekran tekstu), brak instrukcji sterowania, a także na jakość kodu (spaghetti) samych komend i ograniczoną liczbę konfiguracji, jakie w praktyce można było testować. Problemem było też odpalanie frameworka - dużo plików konfiguracyjnych, brak dokumentacji itd. Rozkminienie całości tak, aby to jako tako hulało i by wykonanie testów docierało do końca, zajęło mi kilka miesięcy (!). Po tym czasie wprowadziliśmy normalny reżim developerski przy tworzeniu testów - review kodu, standardy kodowania, rozplątywanie makaronu. Po pewnym czasie, gdy już mieliśmy doświadczenie, wiedzieliśmy i wiedzieliśmy, czego potrzebujemy, zbudowaliśmy środowisko od nowa. Od początku zaaplikowaliśmy dobre praktyki do testów, projektując wygodne API do ich tworzenia itd. Efekt był taki, że po kilku latach developerzy sami chętnie siadali, aby pisać sobie testy E2E do tego, co właśnie implementowali, albo używali środowiska do puszczania sobie wybranych testów z biurka podczas developmentu (!). I to jest właśnie cel automatyzacji - potwarzalność, stabilność i zaufanie, że jak test mówi PASS, to znaczy, że faktycznie to ma szansę zadziałać.
Jeśli chodzi o sam język programowania, to to zależy od projektu. W powyższym przypadku była to Java ze względu na kompatybilność z technologiami używanymi w projekcie. Dlatego tym bardziej przyda się praktyka developerska - jeśli wiesz, o co w tym chodzi, względnie łatwo douczysz się odpowiedniego języka, gdyby zaszła taka potrzeba.