iOS 8 oczami testera aplikacji

Dominik Łada

8

Dodane: 10 lat temu

Świetny, gościnny tekst Krzysztofa Gudowskiego, który zawodowo zajmuje się testowaniem aplikacji mobilnych. Warto przeczytać aby mieć obraz jak wygląda sytuacja od tej strony. Szczerze polecam lekturę.

Zaraz po wydaniu przez Apple iOS 8.0.1, zacząłem dostawać SMS-y od rozemocjonowanych ludzi. Wszystkie charakteryzował ten sam punkt wspólny. „Wstyd”, „Nie zostawią na nich suchej nitki”, „To już nie ta sama firma”.

Z początku nieco mnie to rozbawiło, bo normalnością stało się, że branżowe standardy nie dotyczą z jakichś względów Apple. Po kilku chwilach zdałem sobie sprawę, że moje spojrzenie może nieco różnić się od tego jak przez innych postrzegany jest proces tworzenia aplikacji, ze szczególnym naciskiem na ich testowanie. Tym zajmuję się na co dzień.

iOS – sztuka ukrywania błędów

Mamy tendencję do postrzegania wszystkiego w czarno-białych barwach. Owszem, nie da się ukryć – Apple popełniło błąd wypuszczając 8.0.1 do użytkowników. Czy można jednak stwierdzić wprost, że coś się w firmie zmieniło? Czy to już koniec Apple’a jakiego znamy? Nie. Wyobraźmy sobie zespół ludzi, który zamknięty w określonych ramach procesowych, wypracował sobie metodę na dostarczanie produktu o akceptowalnej jakości, takiej w której błędy nie są uciążliwe dla użytkownika końcowego. W takiej sytuacji jest Apple. Do perfekcji opracowali umiejętność łatania luk w taki sposób, by nikt nie zorientował się, że w niektórych edge case’ach system może się zwyczajnie wykrzaczyć. Po paśmie sukcesów łatwo osiąść na laurach, uznać, że wszystko już jest dobrze i nic złego nie nastąpi. Chyba nie ma lepszego momentu na przyjście otrzeźwienia. I choć wpadka Apple’a mogła być naprawdę dramatyczna w skutkach, w ostatecznym rozrachunku z pewnością wyjdzie firmie na dobre.

W trakcie testów aplikacji telefon staje się przedłużeniem ręki. W skrajnych przypadkach spędza się z nim kilka godzin dziennie, bez większych przerw. Postrzeganie iOS-a jako systemu zmienia się wtedy o 180 stopni. Na początku dostrzega się sporadyczne błędy. Później coraz więcej. Na samym końcu dochodzi się do sytuacji, w której wiadomo już jak scrashować App Store’a czy wyświetlić w nim kilka aplikacji jednocześnie. Jak sprawić by urządzenie zgłupiało przy zmianie orientacji na ekranie blokady, wyświetlając jedynie tapetę. Zdarzały się sytuacje, że komunikaty systemu wyświetlane były do góry nogami. W niektórych językach brakowało jeszcze niedawno tłumaczeń dla nazw krajów i na listach przygotowanych w oparciu o natywne biblioteki Apple pojawiało się dumne (null). Ogólnie rzecz ujmując – w iOS od dawna dzieją się cuda. Trzeba tylko wiedzieć gdzie i jak się „pomodlić”.

iOS w nowym modelu biznesowym

Słyszałem niedawno głosy, że iOS 8 jest zdecydowanie mniejszą aktualizacją od iOS 7. Nic bardziej mylnego. Z punktu widzenia testów, iOS 8 to prawdziwa kopalnia potencjalnych błędów i przeoczeń. Śmiem twierdzić, że w tym przypadku nie uda się osiągnąć pełnej stabilności systemu nawet w potencjalnej wersji 8.1. iOS 7 tańczył i śpiewał. Był na swój sposób rewolucją w historii Apple. Prawda jest jednak taka, że była to wciąż podliftingowana szóstka. Użytkownicy widzieli ogromną ilość zmian, ale to nie szata zdobi człowieka. Oczywiście, Apple nie zapomniało również o „bebechach”, ale ewidentnie postanowiło rozłożyć proces rozwoju systemu na cykle dwuletnie, dobijając tym samym do schematu utartego w przypadku iPhone’ów. iOS8 jest więc udoskonaleniem podzespołów, a nie kompletnie nowym designem. Kolejnych rewolucji spodziewać się możemy dopiero w iOS 9. Zauważcie, że to także pozytywna decyzja z biznesowego punktu widzenia – iPhone 6S byłby nudny bez większych zmian po stronie systemu.

iOS 8 w oczach testera

Postawcie się po stronie testera systemu iOS. Znajdowanie błędów w interfejsie, widocznych elementach systemu jest przyjemne i stosunkowo proste w usystematyzowaniu. Gdy w grę wchodzą zmiany w API, kluczowych funkcjach systemowych – sytuacja jest już zdecydowanie trudniejsza. Tego typu testy wymagają specjalnych narzędzi i większego doświadczenia w pisaniu przypadków testowych czy strategii testów. A to właśnie usprawnienia w API są lwią częścią nowego systemu Apple’a.

Cały proces testowy podzielić można na wiele sposobów. W celu przybliżenia zagadnienia, posłużę się dość uproszczonym modelem, niezawierającym wszystkich składowych. Do wywołania w trakcie testów są: testy manualne (regresje i exploratory testing), testy automatyczne oraz testy jednostkowe i integracyjne. Zanim jednak się to stanie, przygotowywany jest zespół dokumentów: Test Strategy, Test Plan oraz lista Test Case’ów. Pierwszy z nich jest ogólnym podsumowaniem celów do osiągnięcia, obranych założeń, wykorzystywanych narzędzi, instrukcją ich instalacji oraz listą urządzeń wykorzystywanych w trakcie testowania.

Test Plan jest z kolei nieco bardziej szczegółowy. Określa bowiem konkretny release oprogramowania (np. 8.0.1), jego założenia, rozmiar, zagrożenia oraz scope testów (co znajduje się w szczególnym zainteresowaniu testerów w tym wydaniu). Istotną częścią tego dokumentu jest również szczegółowe kalendarium, przedstawiające dostarczanie poszczególnych elementów do działu zarządzania jakością i definiujące wszystkie pozostałe terminy.

Jednym z najważniejszych elementów testowania jest przygotowanie odpowiednich przypadków testowych. I tu pojawia się wiele kolejnych wyzwań. Trzeba sobie postawić pytanie jak duże powinno być pokrycie przypadkami testowymi. Gdy będzie zbyt małe, istnieje ryzyko że jakiś błąd pozostanie niezauważony. Przy zbyt dużej ilości, ich wykonywanie jest żmudne i bardzo wpływa na czas dostarczenia produktu. Kolejną kwestią jest doświadczenie i wyobraźnia testera – tylko od niego zależy ile możliwych błędów znajdzie już na etapie projektowania np. nowej funkcjonalności.

Jeszcze gorszą sprawą jest pisanie przypadków testowych dla elementów, których nie widać na pierwszy rzut oka. Tutaj dodatkowo trzeba wykazać się umiejętnością abstrakcyjnego myślenia i zrozumieniem zasady działania modeli, które się testuje. Mało gdzie i kiedy testerzy mają na to czas lub wystarczająco dużo chęci.

Na szczęście w procesie testowym istnieją jeszcze testy jednostkowe i integracyjne. Te pisane są przez programistów i są wywoływane na poziomie kodu. Testy jednostkowe sprawdzają poszczególne moduły/funkcje, a integracyjne zajmują się nieco szerszym aspektem – np. ich integracją/komunikacją z usługami/innymi elementami. Zważywszy na ilość zmian w systemie, deadline’y i presję w zespole przed wydaniem systemu w formie „używalnej” – testy te prawdopodobnie nie zostały zaimplementowane w przewidywanej liczbie i nastąpi to dopiero teraz. Przy tak dużej liczbie usprawnień w API systemu jest to jeden z kluczowych elementów.

Szukamy winnego

Stało się. Apple wydało iOS 8.0.2, a najgorsza fala kryzysu została w tyle. Media już znalazły winnego. Podobno odpowiedzialnym za błąd ma być kierownik 100-osobowej grupy testerów firmy. Ba, ma to być podobno ta sama osoba, która odpowiedzialna była za te nieszczęsne, niedopracowane Mapy. Wierzycie w to? Jak pięknie i medialnie to wygląda. Dwie wpadki Apple’a na przestrzeni roku. Pan kierownik, który mając pod sobą 100 osób klepie palcem w Mapy i jest na tyle złym pracownikiem, że popełnia kolejny błąd. Nie-wy-ko-na-lne. Niemożliwe jest, że Apple nie rozdziela odpowiedzialności za feature pomiędzy testerami. Założenie bowiem jest takie, że jeżeli dana aplikacja/funkcja jest testowana przez jedną osobę zbyt długi okres czasu, to istnieje ryzyko, że wypracuje ona sobie konkretne ścieżki przechodzenia przez nią i spora część bugów nie zostanie wykryta. Dodatkowo całą odpowiedzialność współdzieli się między różnymi osobami i stara się ją możliwie jak najbardziej uniezależnić od czynnika ludzkiego. Jeżeli zatem błąd przeszedł przez testy niezauważony, winny jest proces. Szukanie kozła ofiarnego to domena mediów i hien. Nigdy nie robi się tego w zespole, gdzie raczej szukać się powinno rozwiązań problemu. To dlatego Apple już po godzinie usunęło 8.0.1 z serwerów. Ktoś podjął męską decyzję w odpowiednim momencie i zmobilizował zespół do szybkiego naprawienia błędu i przeprowadzenia przyśpieszonego procesu testów regresyjnych i akceptacyjnych (sprawdzających wpływ wersji na cele biznesowe). Zlokalizowanie źródła problemu to w takich sytuacjach kwestia drugorzędna. A gdy się to już stanie, wdraża się usprawnienia, które mają je zniwelować.

Każdy błąd może mieć dwa końce

Każdy błąd może mieć dwa końce. Czasami łatwo o tym zapomnieć. W iOS 8 istnieje jeden doskonały tego przykład. Jeżeli spotkaliście się z błędem w oknie udostępniania, który umożliwia przesuwanie jego elementów, ale nie zapamiętuje wyboru użytkownika – rozczaruję Was. Wątpię, by zostało to naprawione. Jeżeli przyjrzycie się ikonom, ich format jest taki sam jak format ikon aplikacji na ekranie głównym. Bardziej prawdopodobne jest zatem, że developer Apple’a reużył elementu z innej części systemu i wyłączył w nim pokazywanie przycisku „X” niż zapomniał zaimplementować zapamiętywanie pozycji elementów. To w iOS8 wprowadzono możliwość umieszczania tu aplikacji zewnętrznych – tak samo więc się zachowują – są linkami do nich. I ktoś zapomniał o wyłączeniu możliwości ich przesuwania.

Co z tym 8.0.1?

Na koniec warto zastanowić się dlaczego błąd w 8.0.1 w ogóle ujrzał światło dzienne. Co mogło pójść nie tak? Oto moje typy „na szybko”:

1. iOS 8 nigdy nie posiadał wsparcia dla iPhone 6 i 6+ w wersji dostępnej w internecie – została ona dodana w wersjach wgrywanych już bezpośrednio na tych urządzeniach w fabryce. Przy iOS 8.0.1 ktoś o tym zapomniał
2. Sposób nadpisywania plików na iPhone 6 i 6+ przygotowany był wyłącznie na wgranie po kablu i ktoś przy 8.0.1 o tym zapomniał
3. Istnieją różni producenci układów wewnętrznych i sterowniki nie zostały przygotowane dla któregoś z nich (vide: wersja OTA na iPhone 6 i 6+ działała u niektórych osób)
4. Zawiodły zabezpieczenia wykorzystywane przy instalacji kluczowych komponentów systemu (uniemożliwiających np. ich podmianę „w locie”)

Podsumowanie

iOS nigdy nie był najlepiej przetestowanym systemem i nigdy nim nie będzie. Z jednej strony Apple ma do pokrycia zdecydowanie mniejszą ilość urządzeń, ale ich liczba powoli staje się coraz większa. Firma może nie być na to jeszcze „mentalnie” gotowa pod kątem procesów. iOS 8 jest najbardziej otwartą i skomplikowaną wersją systemu mobilnego od Apple. Wcześniej, w porównaniu np. do Androida, liczba wewnętrznych zależności wewnątrz systemu/ekosystemu była znacznie mniejsza. Dopiero teraz użytkownik końcowy może zobaczyć to, co wiadome było od dawna. Nie wińcie za to Apple, nie szukajcie winnych wśród ludzi. Dajcie im chwilę na ustabilizowanie wewnętrznych procesów i przede wszystkim – zgłaszajcie znalezione błędy.

Dominik Łada

MacUser od 2001 roku, rowery, fotografia i dobra kuchnia. Redaktor naczelny iMagazine - @dominiklada