Tester oprogramowania

1. Co najbardziej motywuje Cię do podjęcia pracy jako Tester Oprogramowania?

Świadomość, że moja praca bezpośrednio wpływa na jakość produktu i zadowolenie końcowego użytkownika. Zainteresowanie nowymi technologiami i procesem tworzenia oprogramowania. Postrzeganie tego jako najłatwiejszego sposobu na wejście do branży IT.

2. Wykonujesz ten sam, monotonny scenariusz testowy po raz dziesiąty. Jak reagujesz?

Podchodzę do tego z taką samą uwagą jak za pierwszym razem, szukając drobnych odstępstw. Zaczynam się nudzić, ale staram się dokończyć zadanie poprawnie. Zakładam, że skoro działało 9 razy, to zadziała i teraz – "przeklikuję" to szybko.

3. Kiedy dostajesz nową aplikację do rąk (np. na smartfonie), co robisz w pierwszej kolejności?

Próbuję ją "zepsuć" – klikam w nietypowe miejsca, wpisuję dziwne dane, sprawdzam co się stanie. Używam jej zgodnie z przeznaczeniem, poznając główne funkcje. Oceniam głównie jej wygląd i czy jest intuicyjna.

4. Znalazłeś/aś błąd w aplikacji. Jak go zgłaszasz zespołowi?

Tworzę szczegółowy raport: kroki do odtworzenia, co się stało (actual) vs. co powinno się stać (expected), załączam zrzuty ekranu. Piszę do programisty na czacie: "Hej, logowanie nie działa". Mam nadzieję, że programista sam to zauważy przy okazji.

5. Aplikacja działa, ale bardzo wolno. Specyfikacja techniczna nie mówi nic o prędkości. Co robisz?

Zgłaszam to jako problem wydajnościowy, argumentując to negatywnym doświadczeniem użytkownika (User Experience). Ignoruję to – trzymam się ściśle specyfikacji, a ta jest formalnie spełniona. Uznaję, że mój komputer jest pewnie za wolny i to nie wina aplikacji.

6. Jak ważne jest dla Ciebie myślenie z perspektywy nietechnicznego użytkownika końcowego?

Kluczowe. Dobry tester to pierwszy "adwokat" użytkownika w zespole. Ważne, ale najważniejsze są wymagania techniczne i biznesowe. Nieważne. Moim zadaniem jest sprawdzenie zgodności z dokumentacją.

7. Programista mówi: "U mnie działa" albo "To nie błąd, to funkcja". Twoja reakcja:

Spokojnie dopytuję o szczegóły, sprawdzam w dokumentacji lub u analityka, czy takie działanie jest na pewno zamierzone. Akceptuję jego słowa – w końcu on pisał ten kod i wie lepiej. Uznaję to za wymówkę i nalegam na "naprawę" bez dalszej analizy.

8. Czego oczekujesz po **studiach podyplomowych** z testowania oprogramowania?

Usystematyzowania wiedzy, poznania narzędzi do automatyzacji i zdobycia podstaw pod certyfikację (np. ISTQB). Zdobycia praktycznych umiejętności, które pozwolą mi szybko zacząć pracę. Tylko "papierka", który wpiszę do CV, bo IT jest modne.

9. Czytasz skomplikowaną dokumentację techniczną. Jakie jest Twoje podejście?

Analizuję ją krok po kroku, starając się wyłapać nieścisłości, luki i potencjalne problemy, zanim kod jeszcze powstanie. Czytam ją pobieżnie, żeby mieć ogólne pojęcie; wolę testować gotowy produkt. To nudne, wolę, żeby ktoś mi po prostu powiedział, co mam "przeklikać".

10. Jaki styl pracy preferujesz w kontekście przyszłej pracy jako tester?

Systematyczny i metodyczny, oparty na tworzeniu planów i przypadków testowych. Dynamiczny i elastyczny, oparty głównie na testach eksploracyjnych (dowolnych). W pojedynkę, bez konieczności komunikowania się z resztą zespołu.