Automatyzacja testów nie ogranicza się do testowania za pośrednictwem graficznego interfejsu użytkownika. Istnieją narzędzia do automatyzacji testów na poziomie interfejsu API, interfejsu wiersza poleceń i innych punktów styku z testowanym oprogramowaniem. Jedną z pierwszych decyzji, jakie musi podjąć techniczny analityk testowy, jest wybór interfejsu, z którego najlepiej będzie skorzystać w trakcie automatyzacji testów.
Jednym z problemów związanych z testowaniem za pośrednictwem graficznego interfejsu użytkownika jest możliwość wprowadzania w nim zmian w miarę rozwoju oprogramowania. Może to znacznie zwiększyć nakład pracy związany z utrzymaniem kodu do automatyzacji testów, w zależności od sposobu zaprojektowania tego kodu. Na przykład, automatyczne przypadki testowe (często nazywane skryptami testowymi) utworzone za pomocą funkcji nagrywania i odtwarzania mogą po zmianie interfejsu nie działać zgodnie z wymaganiami. Dzieje się tak dlatego, że w nagranym skrypcie zapisane są interakcje z obiektami graficznymi wykonane przez testera po ręcznym uruchomieniu oprogramowania, natomiast jeśli poszczególne obiekty są modyfikowane, może zajść potrzeba aktualizacji skryptu.
Narzędzia rejestrująco-odtwarzające zapewniają wygodny punkt wyjścia do projektowania skryptów automatyzacji. Tester nagrywa sesję testową, a powstały skrypt jest następnie modyfikowany w celu zwiększenia pielęgnowalności kodu (np. poprzez zastąpienie fragmentów skryptu wywołaniami funkcji wielokrotnego użytku).
Dane używane w poszczególnych testach mogą być zależne od testowanego oprogramowania, chociaż wykonywane kroki są w zasadzie identyczne (np. podczas testowania obsługi błędów w polu wejściowym za pomocą wprowadzania wielu niepoprawnych wartości i weryfikacji błędu związanego z każdą wartością). Opracowywanie i utrzymywanie odrębnych skryptów testów automatycznych dla każdej testowanej wartości jest nieefektywne. Często stosowanym rozwiązaniem technicznym tego problemu jest przeniesienie danych ze skryptów do zewnętrznej składnicy, na przykład arkusza kalkulacyjnego lub bazy danych. Tworzy się funkcje uzyskujące dostęp do konkretnych danych dla każdego wykonania skryptu testowego, dzięki czemu jeden skrypt może obsłużyć zestaw danych testowych zawierający wartości wejściowe i oczekiwane wartości wynikowe (np. wartości wyświetlane w polu tekstowym lub komunikaty o błędach). Takie podejście nazywamy testowaniem sterowanym danymi. Opracowuje się w nim skrypt testowy, który przetwarza dostarczone dane, a także jarzmo testowe i infrastrukturę niezbędną do uruchomienia skryptu lub zestawu skryptów. Faktyczne dane przechowywane w arkuszu lub bazie danych są tworzone przez analityków testowych, którzy znają funkcje biznesowe realizowane przez oprogramowanie. Taki podział pracy pozwala osobom odpowiedzialnym za opracowanie skryptów testowych (np. technicznym analitykom testowym) skoncentrować się na implementacji inteligentnych skryptów automatyzacji, podczas gdy właścicielem samego testu pozostaje analityk testowy. W większości przypadków za uruchomienie skryptów testowych po zaimplementowaniu i przetestowaniu automatyzacji odpowiada właśnie analityk testowy.
W innym podejściu, nazywanym testowaniem opartym o słowa kluczowe lub o słowa akcji, dodatkowo oddziela się działania, które mają zostać wykonane na dostarczonych danych, od samego skryptu testowego [Buwalda01]. Aby uzyskać taki stopień rozdzielenia, eksperci merytoryczni (np. analitycy testowi) tworzą metajęzyk wysokiego poziomu, który ma raczej charakter opisowy, a nie służy do bezpośredniego uruchamiania kodu. Każda instrukcja tego języka opisuje pełny lub częściowy proces biznesowy z danej dziedziny, który może wymagać przetestowania. Na przykład, wśród słów kluczowych związanych z procesem biznesowym mogą się znaleźć słowa „Zaloguj”, „Utwórz Użytkownika” i „Usuń Użytkownika”. Słowo kluczowe opisuje działanie wysokiego poziomu wykonywane w dziedzinie aplikacji. Można również zdefiniować działania niższego poziomu opisujące interakcje z interfejsem oprogramowania, takie jak „Kliknij Przycisk”, „Wybierz Z Listy” albo „Przejdź Drzewo”. Służą one to testowania funkcji graficznego interfejsu użytkownika, które nie odpowiadają bezpośrednio słowom kluczowym używanym w procesie biznesowym.
Po zdefiniowaniu słów kluczowych i używanych danych osoba odpowiedzialna za automatyzację testów (np. techniczny analityk testowy) tłumaczy słowa kluczowe związane z procesem biznesowym i działania niższego poziomu na kod automatyzacji testów. Słowa kluczowe i działania, a także używane w testach dane, można zapisać w arkuszach lub wprowadzić za pomocą konkretnych narzędzi obsługujących automatyzację testów opartą o słowa kluczowe. Środowisko automatyzacji testów implementuje słowa kluczowe w postaci zestawu wykonywalnych funkcji lub skryptów. Narzędzia odczytują przypadki testowe zapisane za pomocą słów kluczowych i wywołują odpowiednie funkcje testowe lub skrypty, które je implementują. Skrypty wykonywalne są zbudowane modułowo, aby łatwo je było odwzorowywać na konkretne słowa kluczowe. Do zaimplementowania takich modułowych skryptów konieczna jest umiejętność programowania.
Rozdzielenie wiedzy na temat logiki biznesowej od zadań programowania niezbędnego do implementacji skryptów automatyzacji pozwala w optymalny sposób wykorzystać kwalifikacje osób biorących udział w testach. Techniczny analityk testowy, będący osobą odpowiedzialną za automatyzację, może skutecznie wykorzystać swoje kompetencje w zakresie programowania i nie musi stać się ekspertem merytorycznym w wielu obszarach biznesowych.
Oddzielenie kodu od danych podlegających modyfikacjom pozwala odizolować proces automatyzacji od wprowadzanych zmian, poprawić ogólną pielęgnowalność kodu i zwiększyć wartość zwrotu z inwestycji w automatyzację.
W ramach każdego projektu automatyzacji testów należy przewidzieć awarie oprogramowania i określić sposób ich obsługi. Jeśli wystąpi awaria, osoba odpowiedzialna za automatyzację musi podjąć decyzję dotyczącą działania oprogramowania. Czy awarię należy zarejestrować i kontynuować testy? Czy testy należy przerwać? Czy można obsłużyć wystąpienie awarii za pomocą konkretnego działania (np. kliknięcia przycisku w oknie dialogowym) albo poprzez dodanie opóźnienia do testu? Nieobsłużone awarie oprogramowania mogą nie tylko spowodować problem w wykonywanym w danym momencie teście, ale wpłynąć także na rezultaty kolejnych testów.
Istotne jest także uwzględnienie stanu, w jakim system znajduje się na początku i na końcu testowania. Może okazać się konieczne przywrócenie systemu do zdefiniowanego stanu po zakończeniu wykonywania testów. Zestaw testów automatycznych da się dzięki temu wielokrotnie uruchamiać bez ręcznej interwencji użytkownika, który musi przywracać system do znanego stanu. Aby to osiągnąć, testy automatyczne powinny, na przykład, usuwać utworzone dane lub zmieniać status rekordów w bazie. Środowisko automatyzacji powinno zagwarantować, że zakończenie testów odbędzie się w poprawny sposób (np. nastąpi wylogowanie).