“Nie da się tak po prostu zautomatyzować wszystkiego.” — każdy sfrustrowany QA, kiedykolwiek

Sytuacja: mamy aplikację webową (App A), mamy desktopową (App B), obie korzystają z jednego API. Brzmi jak plan? Tylko na papierze. W praktyce QA dostaje zapaści przy pisaniu strategii testów.

🤯 Kluczowe pytanie

Jeden z architektów rzucił ostatnio zagwozdkę:

„Jak zapewnić odpowiednie pokrycie testami między webem a desktopem?”

W tłumaczeniu QA-owym:
“Jak przetestować dwa fronty na różnych technologiach, z tym samym backendem, bez zasobów i bez łez?”

Odpowiedź? Ostrożnie jak cholera.

🚧 Zderzenie z rzeczywistością

Automatyzacja desktopu to jak nauka tostera całek. Niby się da, z pywinauto, siekierą i modlitwą, ale czy to ma sens?

Prawda jest taka:

  • Automatyzacja desktopu to krucha sprawa,
  • CI/CD jej nie lubi,
  • A Electron potrafi zawiesić się tak cicho, że nawet logi się go boją.

🔧 Jak nie zwariować

Rozsądny układ sił:

  • 🧪 Web (App A) – pełna automatyzacja UI
  • 🔄 API – testy kontraktowe i walidacja danych
  • 🧍 Desktop (App B) – testy manualne + sanity + eksploracja

API to twoja kotwica. Traktuj je jak wspólny punkt kontrolny między aplikacjami.

✅ API = źródło prawdy

Jeśli:

  • App A coś zmienia przez API,
  • App B to samo odczytuje poprawnie,
  • a ty po drodze walidujesz payload…

To gratulacje – to też jest test E2E. Tylko taki bez bólu i przekleństw.

🧠 Bonus: dogadaj się z devami

Poproś o:

  • data-testid w UI
  • debugowe endpointy
  • spójne ID elementów

Ty im dajesz konkretne bugi, oni ci dają haki do automatyzacji. Wszyscy zadowoleni (w teorii).

TL;DR

Pełne E2E między webem a desktopem to bajka z jednorożcem. W prawdziwym życiu:

  • Automatyzuj web (bo możesz),
  • Testuj API (bo musisz),
  • Testuj desktop ręcznie (bo trzeba),
  • Dogaduj się z devami (bo bez nich dupa).

Brak magii. Tylko pragmatyzm, ryzyko i rozsądek.

Bądź sprytny. Testuj z głową. 🧠🔧 – Karol