Pewnie nieraz dostałeś pytanie, na które odpowiedziałeś: „To zależy”. Kończę właśnie pracę nad e-bookiem, w którym zawarłem odpowiedzi na ponad 100 pytań rekrutacyjnych. Zauważyłem, że w przypadku części pytań nasuwa się od razu odpowiedź „To zależy”. Na przykład, jak podczas rekrutacji wybrnąć z pytania: „Znalazłeś błąd w piątek pod koniec dnia, co robisz?”. To pytanie akurat dotyczy wiedzy i doświadczenia bezpośrednio dotyczącego testowania, ale już pytanie „Jak przetestować włącznik światła?” już nie. Obydwa pytania łączy sposób, w jaki należy podejść do odpowiedzi, ponieważ w obydwu „To zależy” jest pierwszą rzeczą, jaka przychodzi do głowy. Dzisiejszym wpisem chcę rozjaśnić, o co chodzi z tym „To zależy”.
Czy faktycznie to testowanie jest tak skomplikowane i trudne, że wszystko jest niejasne i trzeba się posługiwać tą niejednoznaczną terminologią? Na szczęście nie. Są definicje, które są stałe i przyjęte przez wszystkich.
Moim zdaniem w IT z pojęciem „To zależy” spotkać się możemy w kontekście teorii testowania oprogramowania, kontraktu z klientem i tego, jak my dostosowujemy rzeczywistość do swoich potrzeb.
„To zależy” w wiedzy teoretycznej z testowania oprogramowania
Chcąc przytoczyć przykład tego, jak różne mogą być definicje, przychodzi mi do głowy temat ostatniego wpisu „Scenariusz testowy”. Przeszukując Internet znajdziesz różne wyjaśnienia tego terminu. A przecież to ten sam „twór”, którego używamy na co dzień.
W sieci istnieje wiele miejsc prezentujących informacje na temat testowania oprogramowania: możesz czytać blogi, książki, słuchać podcastów, oglądać filmiki na YouTube. Wiele z tych źródeł wiedzy często przedstawia różne definicje tego samego zagadnienia – czy to źle? Po pierwsze, to zależy!
Zależy to przede wszystkim od tego, jak postrzegamy pewne rzeczy w tej branży. Niestety lub „stety”, jak kto woli, branża ta jest bardzo rozległa i wiele firm/projektów ma bardzo unikalne podejście do tematu testowania oprogramowania. Wiedza, którą osoby z tych firm przyswajają i przekazują, często jest oparta o podejście stosowane w danej firmie. A podejście to niekoniecznie musi być, a wręcz zazwyczaj nie jest książkowe.
Tu taka ciekawostka z mojej piaskownicy. Kiedy miałem dwa lata doświadczenia pracy jako tester, to myślałem, że zjadłem wszystkie rozumy, bo wiecie, dobrze testowałem, było mało bugów zwróconych po release, a nawet często zero bugów, więc WOW! 😉 😉 😉
Potem trafiła się kolejna praca, w której o dziwo musiałem dużo się uczyć, bo okazało się, że w nowym projekcie potrzebna jest wiedza z czegoś, czego nie miałem w poprzedniej pracy (np. Linux). I wiesz? W kolejnej pracy również musiałem się uczyć. Zauważyłem też, że nie pamiętam już wielu rzeczy specyficznych dla projektu w pierwszej pracy, a mam je ciągle w CV. Zrozumiałem, co tak naprawdę umiem, a moje CV z długiej listy wszystkiego, z czym miałem styczność, skróciłem do tego, co umiem.
Zdobyte doświadczenie z kilku firm zobrazowało mi, że podejście do procesów, do testowania i do Agile jest i może być różne oraz zależy od kontekstu, od projektu, od firmy, od zespołu i wreszcie od klienta.
Tu dochodzimy do drugiej kwestii, jest nią klient, a dokładnie kontrakt, jaki zawarł z firmą.
To zależy od podpisanego kontraktu na stworzenie aplikacji
Kontrakt to taka świętość, coś, czego się trzymamy, nie kwestionujemy, jeśli jest podpisany, dostosowujemy się do jego zapisów. Oczywiście chodzi mi tutaj o kontrakt na stworzenie aplikacji, informację, jak ma być wytwarzane oprogramowanie, w jakim języku, jakich technologiach, jakie urządzenia wspieramy/przeglądarki itp., itd.
Firm IT jest w Polsce bardzo dużo, ale wszędzie mamy jedną wspólną cechę dla każdego projektu: kontrakt. Czasami firma podpisuje kontrakt na stworzenie aplikacji z zewnętrznym dostawcą oprogramowania, a czasami kontrakt jest zawierany pomiędzy firmą a zespołem zatrudnionym wewnątrz firmy – czyli tzw. kontrakt wewnętrzny na stworzenie aplikacji.
I znów, od tego kontraktu zależy, jak będziemy postrzegali tworzenie oprogramowania, rozwój oraz dalsze utrzymanie go, jakich narzędzi będziemy używali i czy w ogóle będziemy jakichś używali. Oczywiście poza tym, co w jest zawarte kontrakcie, dzieje się też sporo wewnętrznych rzeczy, czyli to, o czym wspomniałem – indywidualne podejście firmy do tego, jak wytwarzamy oprogramowanie.
To zależy od tego, jakie my wyrobimy sobie podejście do pracy
Ostatnia płaszczyzna odnosi się bezpośrednio do tego, jak w Twojej firmie podchodzi się do poprzednich dwóch aspektów. W tym wypadku przede wszystkim musisz uwzględnić fakt, że na rynku jest wiele firm – małych/średnich/dużych i ogromnych.
Firmy mniejsze i średnie mają często luźniejsze podejście do procesów, reguł oraz ogólnie do wprowadzania innowacji w projekcie. Często wystarczy stwierdzenie „Zróbmy to, bo to jest fajne”, żeby zacząć wdrażać pewne zmiany.
W przypadku dużych firm i korporacji podejście to jest mocno ustrukturyzowane. Trzeba przejść długą drogę, żeby wprowadzić nawet drobną zmianę, a jednocześnie może to dać poczucie odpowiedniego zbadania zagadnienia przed jego wdrożeniem. Do tego dochodzą inne czynniki jak np. kontakt z klientem, który może wyglądać na tym samym stanowisku w dwóch różnych firmach zupełnie inaczej.
Wracając do pytań rekrutacyjnych z początku wpisu…
Jeśli ktoś zapyta mnie „Jak Pan przetestuje włącznik światła?”, nie rzucę się w wir wymyślania przypadków testowych. To, jakie te przypadki będą, zależy od tego, jaka jest specyfikacja dla włącznika. 😊 Proste, prawda? A jednak jest to często pomijane.
Pytający usłyszy ode mnie: „To zależy od tego, jakie są wymagania dotyczące tego włącznika.” I tak dojdziemy do tego, że przed udzieleniem właściwej odpowiedzi zadam kilka prostych pytań. Czy włącznik ma być wodoodporny? Czy włącznik ma działać na głos? Czy włącznik ma być połączony przez wifi z aplikacją? Czy włącznik jest zerojedynkowy czy również przyciemnia światło? Znając te odpowiedzi, będę w stanie dostosować moje testy do wymagań projektu.
W testowaniu pada wiele pytań, na których pierwszą odpowiedzią powinno być: „To zależy”. Jest tez wiele procesów testowych, jak na przykład zawartość raportu z testów, które są dostosowane do tego, jaki jest kontrakt. Są też standardowe procesy wytwarzania oprogramowania dostosowane przez nas po to, by to one nam służyły, a nie my im. Dlatego czasami trudno jest od razu podać jedyną słuszną odpowiedź na zadane pytanie.
Jak widzisz testowanie nie jest takie proste, jakby mogło się wydawać, natomiast daje bardzo dużo frajdy. 😊 Oczywiście o ile Ci się spodoba opisane powyżej podejście do tematu. Pamiętaj o tym przy okazji myśli o przebranżowieniu, jak również podczas zwykłej codziennej pracy.