Odpowiedź.

Pierwsza fala automatyzacji testowania praktycznie nie dotyczyła sprawdzania lokalizacji (i18n), ponieważ główne rynki były nastawione na anglojęzyczny interfejs. Jednak w miarę globalizacji aplikacji wymagania dotyczące jakości lokalizacji wzrosły: interfejs musi być poprawnie wyświetlany we wszystkich obsługiwanych językach, a zasoby tekstowe i sformatowane ciągi muszą być poprawnie ładowane w zależności od wybranej lokalizacji.

Głównym problemem jest to, że ręczne sprawdzanie jest bardzo kosztowne, a testy automatyczne są skomplikowane ze względu na zmienność formatu, kontekstu, specyfikę języków (na przykład pisownię od prawej do lewej lub cechy gramatyczne). Może występować brak tłumaczenia fragmentu, błędy w formatowaniu, naruszenia układu.

Rozwiązania obejmują pracę z danymi testowymi dla każdej lokalizacji, użycie testów snapshot, porównanie elementów UI z wzorcami, wdrożenie narzędzi weryfikujących na zasadzie "klucz-wartość" dla plików zasobów, automatyczne wydobywanie i porównywanie ciągów przez interfejsy API oraz regularne uruchamianie linterów na plikach zasobów.

Kluczowe cechy:

Sprawdzanie obecności i poprawnego wyświetlania wszystkich obsługiwanych języków.
Porównywanie wzorcowych tłumaczeń z obecnym wyświetlaniem w interfejsie.
Walidatory długości i formatowania tekstów w celu uniknięcia naruszeń układu.

Pytania z pułapką.

Czy można stworzyć uniwersalny test, który waliduje dowolną lokalizację jednym skryptem?

Częściowo tak, ale niuanse językowe (przypadki, rodzaj, kierunek wpisywania) często wymagają ręcznych korekt lub dodatkowych warunków w takich testach. 100% uniwersalność jest niemożliwa.

Czy obecność pliku tłumaczenia i jego pomyślne załadowanie oznacza, że test i18n został zaliczony?

Nie. Plik może być nieprawidłowo połączony po stronie aplikacji, błąd może wystąpić w kluczu, kontekst użycia tłumaczenia może być naruszony, mogą wystąpić nieprzewidziane znaki specjalne itd.

Czy ma sens automatyzacja testowania lokalizacji dla języków z < 1% użytkowników?

Tak, jeśli krytyczność biznesowa nawet jednego użytkownika jest duża, na przykład, w przypadku wykonywania obowiązków kontraktowych lub dla rynków z szczególnymi wymaganiami. Automatyzacja znacznie oszczędza zasoby w porównaniu do ręcznych sprawdzeń.

Typowe błędy i antywzorce

Sprawdzanie tylko obecności pliku, a nie rzeczywistego wyświetlania w UI.
Sztywne porównywanie ciągów bez uwzględniania cech gramatycznych i formatu języka.
Ślepe kopiowanie testu z jednej lokalizacji na inne bez adaptacji.

Przykład z życia

Negatywny przypadek

Zespół wdrożył automatyczne testy porównujące klucze w pliku .po z oryginalnym angielskim tekstem, sądząc, że to wystarczy. Testy UI nie zostały napisane — w wersji arabskiej okazało się, że cały tekst wypadł poza granice przycisków, a niektóre wiersze w ogóle nie były tłumaczone z powodu nieprawidłowych kluczy.

Zalety:

Szybkie wdrożenie automatyzacji w zakresie i18n.

Wady:

Niski poziom pokrycia rzeczywistych scenariuszy użytkowników.
Istotne błędy w UX pozostały niezauważone.

Pozytywny przypadek

Zrealizowano połączenie linterów zasobów i testów automatycznych, które karuzelowały interfejs po wszystkich językach, robiły zrzuty ekranu i porównywały je z wzorcowym układem. Odkrywając mieszanie elementów RTL/LTR, zespół znalazł przyczynę i usunął ją przed wydaniem.