Słowo „słownik” kojarzy się nam z czymś bardzo poważnym, grubą księgą, którą się ma, ale niekoniecznie używa. Ja tymczasem mówiąc „słownik”, mam na myśli standaryzację nazewnictwa komponentów takich jak menu, okna, widoki, stany w ramach projektu, dzięki czemu praca, a raczej współpraca w zespole i z klientem staje się prostsza.
Weźmy sobie takie przykładowe nazwy dla ikony składającej się z trzech poziomych linii służącej w aplikacjach mobilnych do otwierania menu aplikacji: „hamburger menu”, „trzy paski”, „trzy linie”, „menu z ikoną” czy „ikonka menu”. Jedna mała ikonka a tyle nazw. Podobnie będzie z nazewnictwem ekranów aplikacji, przycisków, stanów.
W przypadku prostych aplikacji składających się z pięciu ekranów, nie będzie problemu, jeśli posłużysz się swoimi nazwami dla kolejnych ekranów opisując kroki testowe. Jednak dla aplikacji skomplikowanych, w których przykładowo koszyk sklepowy może być otworzony z poziomu trzech różnych miejsc, to jak opiszesz kroki testowe, może mieć duże znaczenie podczas odtwarzania błędu.
Jako tester, zarówno manualny, jak i automatyczny, musisz umieć dobrze opisywać widoki, strony i stany, w jakich znajdujesz się w aplikacji.
Dlaczego warto, aby w ramach projektu nazewnictwo okien, widoków i stanów w aplikacji było usystematyzowane?
Będziemy mieć spójność.
Przyjęcie konwencji nazewnictwa sprawia, że wszyscy członkowie zespołu używają spójnych nazw dla komponentów aplikacji. Spójne nazewnictwo redukuje zamieszanie, na przykład podczas retestów, i ułatwia nowym członkom zespołu zrozumienie struktury projektu.
Będziemy mieć klarowność.
Jasne i opisowe nazwy dla komponentów aplikacji ułatwiają zrozumienie ich celu i funkcjonalności. Kiedy komponent jest odpowiednio nazwany, jego cel można wywnioskować bez zagłębiania się w szczegóły implementacyjne.
Ułatwienie podczas tworzenia dokumentacji, przypadków testowych i scenariuszy.
Spójna konwencja nazewnicza dla elementów aplikacji ułatwia także pracę nad dokumentacją testową. Dobrze zdefiniowane nazwy komponentów ułatwiają odniesienie się do konkretnych części aplikacji. Tak stworzona dokumentacja może stanowić cenne źródło informacji dla przyszłych testerów i programistów.
Dodatkowo, jeśli przyjąć standardy opisywania tego, jak powinniśmy opisać to, co zrobiliśmy podczas testowania aplikacji, to współpraca zespołowa i z klientem stają się znacznie prostsze.
Przykłady:
- Jestem zalogowany do sklepu internetowego Empik.com.
- Znajduję się w koszyku zakupowym.
- Mam/Nie mam dodanych produktów.
Jak widać, dodanie kilku szczegółów sprawia, że opis kroków testowych czy warunków wstępnych staje się jasny dla każdego.
Usystematyzowanie nazewnictwa komponentów jest istotne, zwłaszcza w kontekście dużych aplikacji. Może ci się wydawać, że wymyślam i że to, co piszę, jest śmieszne. Musisz jednak zrozumieć, że w dużych aplikacjach, np. bankowych, możesz mieć możliwość wykonania jakiejś akcji na pięć różnych sposobów.
Jeżeli nie jesteś w stanie dobrze opisać, w jakiej sytuacji (w którym z pięciu sposobów) w aplikacji występuje defekt, to zwyczajnie możesz sprawić, że zgłoszenie błędu będzie bardzo trudne. W sumie nie tyle samo zgłoszenie, co późniejsza reprodukcja przez programistę.
Jak nauczyć się tych wszystkich standardów nazewnictwa, jeśli właśnie dołączyłeś do zespołu?
W sumie jest na to dosyć prosty sposób, który wydaje mi się, że duża część firm na rynku stosuje – lub też warto zachęcić firmę do jego stosowania. Przeważnie przy okazji onboardingu w nowym miejscu pracy jest ktoś, kto opowiada o aplikacji tworzonej przez zespół. Poproś tę osobę, żeby Ci przy okazji opowiadania pokazała tę aplikację. Słuchając opowieści i widząc kolejne ekrany, nauczysz się podstawowych nazw używanych w projekcie, co zwyczajnie może pomóc Ci później wystartować z dokumentacją (o ile taką posiadacie).
Ten wpis jest pierwszym z serii kilku, w ramach których omówię tematy, na które powinieneś zwrócić uwagę rozpoczynając pracę jako tester. Będą to raczej krótkie wpisy, które będziesz w stanie przeczytać w kilka minut. Do następnego napisania!
