PODOBAŁ CI SIĘ TEN ARTYKUŁ?

Sprawdź inne teksty

Podczas tworzenia strony internetowej prowadziłem swojego rodzaju dziennik wydarzeń. Po jakimś czasie zorientowałem się, że może on nieść ze sobą kilka wartościowych spostrzeżeń odnośnie testowania jako zintegrowanej czynności podczas tworzenia strony internetowej, czy jakiegokolwiek innego małego projektu. Dzisiejszy wpis to przebieg tego 'dziennika' i zarazem pierwsza część, która ma odpowiedzieć jak testowałem ten projekt. Już teraz mam w planach stworzyć artykuł, jak powinienem przetestować ten projekt. Tymczasem zapraszam do lektury.

Na początek trochę historii

Kilka lat temu, z inicjatywy testerów w mojej firmie powstało szkolenie pt. Zostań Testerem przygotowujące do zawodu testera oprogramowania wraz z możliwością przystąpienia do egzaminu ISTQB FL. Stale rosnące zainteresowanie zawodem testera sprawiło, że obecnie zbliżamy się do trzydziestej edycji, a dzięki szkoleniu setki osób znalazły zatrudnienie jako testerzy oprogramowania. Jako jeden z obecnie prowadzących takie szkolenia, mam okazję odpowiadać na masę pytań od osób, które pragną się przebranżowić. Chcąc trafić do szerszego grona, a jednocześnie spełniać swoją pasję do testowania i nauczania powstał pomysł na opublikowanie treści próbujących odpowiedzieć na te pytania w jednym miejscu.

Dzień 1

Początkowo zakładałem stworzenie jedynie swojej wizytówki w sieci i tak też wyglądała pierwotna wersja tej strony (możecie zobaczyć ją tutaj w wersji angielskiej). Jedna strona z imieniem, nazwiskiem, tytułem i odnośnikami do mediów społecznościowych wraz z krótką informacją w stopce: 'Find me at social media' (gdzie również zamieściłem linki do mediów społecznościowych). To tyle. Dodatkowo, jako MVP (produkt minimalnie gotowy) założyłem sobie, że moja strona będzie responsywna na urządzeniach mobilnych, tj. będzie na nich dobrze wyświetlana. Postanowiłem też, że szablony będę tworzył od zera, nie korzystając z popularnych blogowych formatów. Mój plan testów musiał więc uwzględnić trzy dodatkowe wersje tej strony dostosowane do różnych rozdzielczości/urządzeń wraz z czasem na stworzenie odpowiedniej struktury. Tak zaczęły się pierwsze moje pierwsze testy RWD (Responsive Web Design). Na szczęście miałem pod ręką testera! ;)

Dzień 2

Po pierwszej optymalizacji wyglądu od razu zabrałem się za szablon strony Jak zostać testerem, na której znalazły się odpowiedzi na ww. zebrane podczas szkoleń pytania w formie pytań i odpowiedzi. Po utworzeniu wstępnego szablonu i układu strony zamieściłem pytania, na które obecnie tam traficie. Wspomniany plan testów wzrósł o dodatkowy wysiłek testerski, który od poprzedniej publikacji wzrósł wykładniczo przez kolejną stronę, którą trzeba było dostosować pod mobilki. Miałem więc teraz do przetestowania responsywność na... 4 wersjach strony x dwa szablony. Dodatkowo należało wykonać kilka testów regresji, aby sprawdzić, czy nie rozjechały się widoki stron.

Po testach, gotowa strona wylądowała na serwerze i od tej pory była dostępna w sieci. Czy to oznaczałoby, że wiedza jest już na wyciągnięcie ręki? Na pewno nie dla strony, do której nie można się dostać! Na tym etapie biłem się z myślami, czy nie pozostawić tej strony jako wiedzy tajemnej. Na stronie głównej dodałem więc obrazek "buga", pod którym umieściłem wywołanie okna z krótką notatką o mojej osobie wraz z odniesieniem do strony Jak zostać testerem. Skupiłem się też na konfiguracji SEO (Optymalizacja dla wyszukiwarek internetowych) mojego rosnącego projektu i... po wykonaniu kilku operacji zgodnie z dobrymi praktykami Jak zostać testerem pojawiła się znacznie wyżej w wynikach. Nie było więc sensu więcej się ukrywać.

PS. Feature z "bugiem" dalej działa ;) I wspominam o tym z pełnym przekonaniem, że przez tak potwornie nieintuicyjne rozwiązanie nikt tam nie klika!

Dzień 3

Zwieńczając drugi dzień testami użyteczności, te wykazały, że nie zamieściłem do Jak zostać testerem żadnego jasnego odniesienia (licząc jedynie na przypadkowe kliknięcie robaczka). Postanowiłem stworzyć górne menu, które jasno przedstawiałoby nawigację po stronie. Dodałem przyciski O mnie i Jak zostać testerem. Strona nabrała rumieńców, ale... menu trzeba było dodać do szablonu na każdej stronie, a więc również z obsługą na urządzenia mobilne. Zakładając, że odwiedzający stronę mogą chcieć się ze mną skontaktować, dodałem wraz z przyciskiem kolejną stronę Kontakt, na której zamieściłem formatkę do kontaktu e-mailowego wraz z odnośnikami do mediów społecznościowych. Wyrzuciłem też podlinkowania do mediów społecznościowych ze strony głównej, a ikonka maila odnosi do zakładki Kontakt.

PS. Na formularzu kontaktu zamieściłem swój profil związany z moją pasją - Hardstyle Kettlebell. Jeśli oprócz informacji o zawodzie testera chcielibyście popracować nad zdrowiem przy pomocy odważników kulowych, zapraszam do kontaktu!

PS 2. Patrząc na testerski wysiłek związany z realizacją swojego wymagania - responsywności na urządzeniach mobilnych, lista rzeczy do przetestowania właśnie podskoczyła do 12 stron!.

Dzień 4

Stwierdziłem, że jednorazowa pomoc i kontakt mailowy pozostawia zbyt małe okno dla osoby, która chce wiedzieć więcej na temat testowania. Jednocześnie uznałem, że nie mogę dodawać zbyt technicznych akapitów w już utworzonym tekście który ma być łatwym progiem wejścia dla każdego odwiedzającego. Postanowiłem więc dodać nową stronę o nazwie Artykuły, w której docelowo będę zamieszczał rzeczy, które mi osobiście pomogły zdobyć upragniony cel.

Następnie trzeba było zasilić tę stronę treściami. Najważniejszym artykułem, jakim chciałem się na początku podzielić był artykuł mojego autorstwa opublikowany na łamach bloga technologicznego <bloger_sii> o testowaniu pokrycia instrukcji i decyzji, który stworzyłem podczas nauki do egzaminu ISTQB. Wpis znajdziecie tutaj (albo w artykułach!). W ten sposób wysiłek testerski zwiększył się do kilkunastu stron do przetestowania.

W międzyczasie w zgodzie z doświadczeniem wyniesionym z pracy jako tester poprawiłem kilka elementów stron z napisanych na twardo (hardcodowanych), na rozwiązania uniwersalne (generyczne). O co chodzi? W pracy testerskiej niebywale ważna staje się umiejętność tworzenia rozwiązań uniwersalnych (tam gdzie możliwe), które można później ponownie używać w wielu miejscach, co po czasie zaprocentuje m.in. mniejszym nakładem pracy (wykonując powtarzalną pracę za nas).

Na przykład: Jeśli podczas wysiłku poświęconego na testowanie kilkunastu stron utworzę wcześniej odpowiednie szablony, to w przyszłości pozostanie mi już jedynie wypełnianie takich szablonów samą treścią zgodnie z potrzebą, bez ponownego ręcznego ustawiania stron pod responsywność. Widać przez to, jak ważna staje się rola testera nawet w najmniejszych projektach. Zmiany potrafią rozdmuchiwać projekt do niebywałych rozmiarów z iteracji na iterację. Wtedy pojawia się potrzeba ujarzmienia procesu i próba zamiany stale nadchodzących nieoczekiwanych zmian.

Dzień 5. Królestwo za UX'owca!

Cała strona zaczęła nabierać odpowiednich kształtów, a ja wciąż miałem ustawioną mentalność (mindset) na rolę testera... Stronie wyraźnie brakowało szlifu. Po przygodzie z bugiem na stronie głównej uznałem, że moje artykuły muszą być okraszone bardziej 'przydatnymi', albo chociaż przynajmniej bardziej intuicyjnymi przyciskami. Zaplanowałem przyciski, które będą nawigowały na stronę główną artykułów. Spędziłem nad designem parę godzin, przeszukując internet w poszukiwaniu wiedzy i stosując różne praktyki. Następnie ...wycofałem całkiem te zmiany, ponieważ przyciski puste, z tłem, tekstowe... to wszystko wyglądało na siłę.

Zakładając, że z perspektywy projektu stałem się w developerem (mam też w zespole testera!), a wynik mojej pracy przedstawiam klientowi końcowemu, to nagle widać, co może czuć taki odbiorca, któremu dostarczane są pomysły będące (jak się okazuje) nieintuicyjne, a kasa na nie została przepalona. Pozostaje więc trzymać się założonego MVP, skłonić się ku minimalizmowi i pozostawić obecny kształt artykułów, dzięki których istnieniu finalnie mogę się podzielić moimi spostrzeżeniami z testowania tej strony w tym wpisie.

Jestem pewien, że to nie koniec zmian na stronie, a mój wewnętrzny klient końcowy cały czas będzie coś podrzucał. Przykładowo, w najnowszej iteracji na każdej stronie znalazły się robaczki w prawym górnym i lewym dolnym rogu formatki.

Podsumowując wpis, wyzwania jakie napotkałem podczas tworzenia strony:

• Szybki wzrost wysiłku związanego z testowaniem RWD poprzez dodawanie dodatkowych stron
• Utrzymanie testów regresji w dynamicznie zmieniającym się projekcie
• Brak innych członków zespołu
• Potrzeba szkoleń, aby sprostać napotkanym problemom z responsywnością
• Ujednolicenie wizji końcowej projektu
• Możliwość poprawy procesu powstawania poprzez ustrukturyzowanie (np. przy pomocy narzędzi do zarządzania projektami)
• Testy 'na produkcji' (sic!) dzięki informacjom zwrotnym od was, niezależni testerzy!

Myślę, że na dany moment udało mi się osiągnąć to, co zamierzałem. A jakie są wasze doświadczenia/odczucia z prowadzeniem takich małych projektów? Często próbujecie wyjść ze strefy komfortu i sprawdzić się w podobnych aktywnościach?

EDIT. Wsparcie grupy testerskiej Testowanie Oprogramowania

W środę 25.03.2020 podzieliłem się tą stroną na grupie Testowanie Oprogramowania. Wielkie dzięki dla was doświadczeni testerzy za poświęcony czas i wspólne zaangażowanie w jej testowanie!. Wasza wiedza przyczyniła się do podniesienia jakości tej strony. Dzięki wam udało się szybko naprostować kilka bugów i stała się ona bardziej przystępna dla odbiorcy. Oprócz błędów w interfejsie, znaleźliście też defekty w samej treści na stronie Jak zostać testerem. Jest to potwierdzenie, że warto angażować niezależne grupy testerskie do swoich projektów, aby szerzej poznać aplikację i wspólnie znaleźć jej słabe punkty, a także wprowadzić usprawnienia (np. w samej treści).
Wiele jeszcze pozostaje do odnalezienia, ale już teraz miło mi wiedzieć, że mogę liczyć na wasze testerskie wsparcie!

DOWIEDZ SIĘ, JAK ZOSTAĆ TESTEREM

REMIGIUSZ BEDNARCZYK

Lorem ipsum

Znajdź mnie na mediach społecznościowych

Polityka prywatności