Testowanie aplikacji Windows: praktyczny plan

Aplikacja Windows może wyglądać schludnie w trybie demo i mimo to spowalniać działalność w poniedziałkowy poranek. Niezapisany list przewozowy, użytkownik zablokowany po trzech nieudanych próbach, lub okno dialogowe drukowania, które po aktualizacji reaguje inaczej, to nie są błędy kosmetyczne. Kto chce wiedzieć, jak testować aplikacje Windows, nie powinien więc zaczynać od pojedynczych przycisków, lecz od procesów, które kosztują pracę, pieniądze, lub identyfikowalność.

Właśnie w magazynie, warsztacie, dyspozycji, i administracji wiele krytycznych procesów przebiega przez oprogramowanie desktopowe rozwijane przez lata. Nie liczy się tam, czy przypadek testowy jest imponująco sformułowany. Decydujące jest to, czy pracownicy mogą niezawodnie wykonywać swoje zadania w realistycznych warunkach - także przy niekompletnych danych, zmieniających się uprawnieniach, wolnych sieciach, i nieplanowanych przerwach.

Testowanie aplikacji Windows zaczyna się od krytycznych procesów

Nie każda funkcja zasługuje na taki sam wysiłek testowy. Rzadko używany eksport z ręczną obróbką następczą należy ocenić inaczej niż księgowanie przyjęcia towaru, tworzenie etykiety, lub codzienne uzgadnianie zamówień. Zacznij więc od prostego pytania: co konkretnie się dzieje, jeśli ten proces zawiedzie?

Wysoki priorytet mają procesy z bezpośrednim wpływem na zapasy, dostawę, fakturowanie, bezpieczeństwo, lub komunikację z klientem. Należą do nich na przykład logowanie i sprawdzanie uprawnień, tworzenie i zmiana danych podstawowych, księgowania transakcji, drukowanie dokumentów, interfejsy do usług ERP lub wysyłkowych, oraz wznowienia po błędzie. Nawet funkcje używane tylko przez małą grupę osób mogą być krytyczne, jeśli blokują zamknięcie miesiąca lub zwolnienie towaru.

Z tych procesów nie powstają abstrakcyjne listy testów, lecz identyfikowalne kroki robocze. Test przyjęcia towaru mógłby na przykład zacząć się od istniejącego zamówienia, zarejestrować dostawę częściową, zgłosić odbiegającą ilość, przypisać lokalizację magazynową, a następnie sprawdzić, czy zapas, dziennik księgowań, i wydrukowany dokument się zgadzają. W ten sposób testujesz rzeczywisty efekt oprogramowania, nie tylko pojedyncze pola wprowadzania.

Zbuduj bazę testową odzwierciedlającą działalność

Wiele błędów staje się widocznych dopiero wtedy, gdy środowisko testowe zbliża się do rzeczywistości. Aplikacja często zachowuje się inaczej z pustym najemcą testowym niż z kilkuletnimi danymi ruchowymi, zablokowanymi artykułami, brakującymi informacjami obowiązkowymi, lub już otwartymi transakcjami.

Dlatego świadomie przygotuj dane testowe. Niekoniecznie potrzebujesz pełnej kopii produkcji. Sensowniejszy jest kontrolowany zbiór danych z typowymi, granicznymi, i celowo błędnymi przypadkami: artykuły z różnymi jednostkami miary, klienci ze specjalnymi warunkami, zamówienia z dostawami częściowymi, użytkownicy z różnymi rolami, i transakcje już w toku przetwarzania. Dane osobowe powinny zostać zanonimizowane lub zastąpione realistycznymi danymi przykładowymi.

Do bazy testowej należy też środowisko techniczne. Udokumentuj wersję Windows, rozdzielczość, skalowanie, zainstalowane drukarki, dyski sieciowe, wersję bazy danych, podłączone usługi, i uprawnienia. Brzmi to sucho, ale oszczędza czas później. Jeśli błąd występuje tylko na stanowiskach ze skalowaniem 125% lub z określonym sterownikiem drukarki, musi to być odtwarzalne.

Nie sprawdzaj tylko przypadku idealnego

Przypadek idealny dowodzi przede wszystkim, że aplikacja została zbudowana dla oczekiwanej ścieżki. W działalności trudne sytuacje powstają obok niej. Co się dzieje, jeśli użytkownik pozostawi pole obowiązkowe puste, wyzwoli to samo księgowanie dwukrotnie, lub straci połączenie podczas zapisywania? Czy transakcja pozostaje spójna? Czy osoba otrzymuje zrozumiały komunikat? Czy może bezpiecznie kontynuować pracę?

W aplikacjach Windows szczególnie istotne są też obsługa i stan. Okna dialogowe mogą pojawiać się w tle, skróty klawiszowe mogą się nakładać, okna wyboru plików mogą blokować przebieg. Sprawdź, czy fokus, komunikaty o błędach, i blokady są jednoznaczne. Wyjątek techniczny bez wskazówki działania nie pomoże kierownikowi zmiany.

Stosuj testy manualne tam, gdzie potrzebny jest osąd

Testy manualne nie są oznaką niewystarczającej dojrzałości. Są niezbędne, gdy powstaje nowy proces, interfejs jest przebudowywany, lub wiedza fachowa decyduje o jakości. Doświadczony kierownik magazynu rozpozna szybciej niż skrypt, czy maska jest zrozumiała pod dużą presją czasu, lub czy ostrzeżenie pojawia się zbyt późno.

Testowanie manualne staje się jednak kosztowne i niewiarygodne, gdy te same stabilne procesy są powtarzane przed każdą wersją. Wtedy wydanie zależy od dostępnych osób, pamięci, i rozproszonych notatek. Właściwy moment przejścia do automatyzacji leży zazwyczaj tam, gdzie proces jest wykonywany często, może spowodować duże szkody, i ma jasne oczekiwane wyniki.

Dobry manualny przypadek testowy opisuje sytuację wyjściową, kroki, oczekiwany wynik, i potrzebne dane. Przy błędzie dodaj zrzut ekranu, znacznik czasu, wersję aplikacji i buildu, oraz dokładną czynność. "Drukowanie nie działa" nie jest użytecznym opisem błędu. "Po zmianie adresu dostawy okno dialogowe drukowania pozostaje otwarte, zamówienie 4711 nie otrzymuje PDF-a, i nie pojawia się żaden komunikat" jest.

Automatyczne testy regresyjne dla powtarzających się ryzyk

Automatyzacja nie sprawdza, czy oprogramowanie jest zasadniczo dobre. Sprawdza, czy wcześniej działające, zdefiniowane procesy nadal działają po zmianie. Jest to szczególnie cenne dla oprogramowania Windows, którego interfejsy, logika bazy danych, i zewnętrzne interfejsy są rozwijane przez lata.

Zacznij od małego. Wybierz najpierw pięć do dziesięciu krytycznych dla biznesu procesów, które powinny być sprawdzane przy każdym wydaniu. Mogą do nich należeć logowanie z przepływem blokady konta, wprowadzanie zamówień, księgowanie magazynowe, drukowanie PDF lub etykiet, zmiana roli, i centralny import. Dopiero gdy te testy działają niezawodnie, opłaca się rozszerzenie na przypadki specjalne.

W przypadku aplikacji desktopowych zautomatyzowane testy często sterują widocznymi elementami interfejsu: oknami, polami wprowadzania, tabelami, przyciskami, i oknami dialogowymi. To działa, ale jest bardziej wrażliwe niż czysty test interfejsu. Małe zmiany układu, wolniejsze komputery, lub niejednoznacznie nazwane elementy mogą przerwać testy. Dlatego programiści, dział biznesowy, i odpowiedzialni za testy powinni wspólnie ustalić, które elementy są stabilnie adresowalne, a które kroki sprawdzające lepiej zabezpieczyć przez bazę danych, dziennik, lub interfejs.

Sensowny test sprawdza ponadto nie tylko to, że przycisk dało się kliknąć. Kontroluje skutek merytoryczny: czy księgowanie zostało zapisane? Czy zapas jest poprawny? Czy wygenerowano dokument? Czy nie utworzono zduplikowanego rekordu? Widoczna interakcja i weryfikowalny wynik idą w parze.

Dowody są częścią wyniku testu

Sam zielony status rzadko wystarcza w krytycznych aplikacjach. Gdy test zawodzi, zespoły szybko potrzebują odpowiedzi na trzy pytania: jaka była sytuacja wyjściowa? Na którym kroku proces zawiódł? Co pokazywała aplikacja w tym momencie?

Zrzuty ekranu, dzienniki wykonania, i ewentualnie nagrania ekranu czynią błędy przedmiotem dyskusji. Znacznie skracają przekazanie między działalnością, QA, i rozwojem. Dla firm regulowanych lub świadomych bezpieczeństwa stanowią ponadto solidną podstawę do śledzenia zatwierdzeń i odchyleń.

Miejsce przechowywania nie jest przy tym sprawą poboczną. Przebiegi testowe mogą zawierać wewnętrzne dane klientów, cenniki, informacje o zamówieniach, lub widoki ekranu. Kto automatycznie testuje wrażliwe aplikacje Windows, powinien wyjaśnić, czy te dane mogą opuścić własną infrastrukturę. Środowisko self-hosted takie jak COCO może być tu sensowne, ponieważ wykonanie testów, dowody, i ocena pozostają pod własną kontrolą. Czy jest to konieczne, zależy od wymagań ochrony danych, sytuacji umownej, i potrzeby ochrony - nie każdy zespół potrzebuje do tego tej samej architektury.

Wbuduj testowanie w proces wydawniczy

Najlepszy katalog testów traci wartość, jeśli jest używany dopiero po chaotycznym wdrożeniu produkcyjnym. Zdefiniuj stały moment: zautomatyzowane regresje kluczowe uruchamiane są przed każdym wydaniem, ręczna akceptacja sprawdza nowe lub zmienione procesy, a znane ograniczenia są otwarcie dokumentowane.

Nie każdy nieudany test musi zatrzymać wydanie. Błąd w rzadko używanym widoku administracyjnym może być akceptowalny, jeśli istnieje bezpieczne obejście i dotknięty obszar jest jasno poinformowany. Błąd, który błędnie księguje zapasy lub niezauważenie blokuje użytkowników, należy traktować inaczej. Ta decyzja powinna być podejmowana na podstawie wpływu na biznes, a nie samej liczby czerwonych testów.

Utrzymuj testy razem z aplikacją. Gdy proces świadomie się zmienia, aktualizuj przypadek testowy, dane testowe, i oczekiwany wynik razem z wymaganiem. Przestarzałe testy generują szum i w końcu są ignorowane. Kilka wiarygodnych sprawdzeń jest cenniejszych niż setki zautomatyzowanych procesów, których wyników nikt już nie traktuje poważnie.

Ostatecznie nie chodzi o symulowanie każdego możliwego do wyobrażenia wejścia. Chodzi o ochronę pracy, która musi ponownie zadziałać następnego ranka. Zacznij od jednego krytycznego procesu, uczyń jego wynik możliwym do udowodnienia, i buduj dalej stamtąd.