Jak zmienić karierę z inżyniera ds. kontroli jakości na programistę: historia kodera

Dziś programistą może zostać każdy: menedżer, sprzedawca, kelner czy trener. Jednak programowanie może czasami wydawać się przytłaczające dla niektórych nowicjuszy i z góry czują się zniechęceni szansami na znalezienie pracy jako młodszy programista. Dlatego niektórzy uczniowie wybierają rolę inżyniera ds. kontroli jakości jako bezpieczną opcję. QA to osoba, która testuje oprogramowanie i znajduje w nim błędy. Zawód ten pozwala wejść w złożony świat programowania. Przedstawiamy historię programisty Kyrylo, który rozpoczął swoją podróż w IT od testów QA (zapewnienie jakości), a później został programistą.

Kontrola jakości mi odpowiadała i zacząłem zgłębiać ten obszar

Po szkole nie interesowała mnie kariera programisty. Mimo to rozpocząłem studia na kierunku „Rozwój oprogramowania systemowego”, ponieważ rodzice poradzili mi, abym wybrał tę specjalizację. Rozumiałem programowanie, ale wymagało to pracy. Pomyślnie zdałem prace semestralne, ale ukończyłem je bez solidnej wiedzy programistycznej. Potem próbowałem szukać pracy jako programista; jednak po nieudanych 2-3 rozmowach kwalifikacyjnych, przez które nie wiedziałem jak przejść, zdecydowałem się zostać testerem QA. Któregoś dnia natknąłem się na firmę zajmującą się rekrutacją osób na staże QA. Pomyślnie przeszłam rozmowę kwalifikacyjną, odbyłam staż i zostałam tam, aby pracować jako tester. Wszystko mi odpowiadało i zacząłem zagłębiać się w ten obszar. Po raz pierwszy pisałem test automatyczny w Javie. To był łatwy test: otwierał okno przeglądarki, klikał określone listy i wybierał elementy, ale bardzo mi się podobał. Wydawało mi się, że uprawiam magię. Po pewnym czasie kolega, który pracował w innej firmie, zaprosił mnie na stanowisko inżyniera ds. kontroli jakości. Przyjąłem więc ofertę i zdobyłem duże doświadczenie w kontroli jakości i pracy w zespole. Po zajęciu się testowaniem ręcznym (co nie jest zbyt interesujące) menedżer zapytał naszą grupę, czy jest ktoś chętny do pracy przy testach automatycznych, a ja zgłosiłem się na ochotnika do tej roli. Potrzebowałem dodatkowej wiedzy do zarządzania nowymi zadaniami, dlatego poznałem C#, co pozwoliło mi poradzić sobie z istniejącymi testami automatycznymi i je rozwijać. Później miałem okazję przejść na stanowisko programisty w tej firmie, jednak zdecydowałem się odejść z firmy, ponieważ mój zespół się rozpadł. I tak dostałem stanowisko inżyniera ds. kontroli jakości w firmie z biurem w centrum miasta i kolejką górską w biurze. Wtedy pomyślałem: chciałbym tam zostać do końca kariery. Jednak pracowałem tam przez prawie cztery lata, zanim zdecydowałem się odejść. Zdobyłem duże doświadczenie w pracy w zespole. Często oglądaliśmy filmy z konferencji technicznych lub filmy szkoleniowe na temat działania technologii. Mimo że zajmowałem się testami automatycznymi, studiowałem powiązane technologie i zdobywałem nowe umiejętności. W sumie było to dla mnie wspaniałe przeżycie.

Chciałem więcej programować

Następnie znalazłem wakat na inżyniera kontroli jakości, który wymagał znajomości Pythona. Szybko przeczytałem książkę o Pythonie, aby zrozumieć składnię i wykonałem zadanie testowe, które dała mi firma. Pomimo tego, że nie dotrzymałem terminu, firma przyjęła moją pracę i zaprosiła mnie na rozmowę kwalifikacyjną. Nasza rozmowa była prosta: rozmawiałem z kierownikiem ds. kontroli jakości i kierownikiem projektu na ogólne tematy dotyczące testowania i programowania. I zostałem zatrudniony. Do moich obowiązków należało wykonywanie testów automatycznych i manualnych. Podręcznik nie przypadł mi jednak do gustu, co wiąże się z monotonnością działań i chciałem zająć się więcej programowaniem. Zacząłem więc pogłębiać swoją wiedzę o Pythonie, zapisałem się na kursy i rozmawiałem z menadżerem o moich ambicjach. Ale wtedy nie mieli jeszcze wolnego stanowiska programisty. Pracowałam i jednocześnie studiowałam. Przejście trwało około dziewięciu miesięcy: wiosną zacząłem szkolenie i w grudniu dostałem pracę. Najtrudniejszą rzeczą podczas przejścia nie było nawet to, że natknąłem się na nowe koncepcje w programowaniu, ale raczej to, że byłem przeciążony i spędzałem za dużo czasu z komputerem.

W programowaniu pomaga mi doświadczenie jako inżynier kontroli jakości

Któregoś dnia napisał do mnie kolega z klasy, który pracował w firmie informatycznej. Zaproponował pracę inżyniera ds. kontroli jakości, ale odpowiedziałem, że szukam pracy programisty. Okazało się, że mają wolne stanowisko, więc postanowiłem spróbować. Odbyliśmy trzygodzinną rozmowę na temat różnych technologii (wg tabeli umiejętności), a następnie rozmowę z klientem. Widzieli we mnie potencjał, więc zostałem zatrudniony. Lubiłem tam pracować, ponieważ poznałem wiele nowych technologii. Poza tym firma miała świetnych kolegów, których można było poprosić o radę w sprawie projektu. Wcześniejsze doświadczenie w testowaniu dużych projektów pozwoliło mi zrozumieć procesy powstawania produktu. Na pewno była to zaleta. Moje doświadczenie jako inżynier ds. kontroli jakości pomaga mi teraz w programowaniu. Kiedy wykonuję zadanie, wiem, że moi współpracownicy będą je testować, dlatego opisuję jak najwięcej szczegółów, na które warto zwrócić uwagę. Kiedy inżynierowie ds. kontroli jakości przychodzą z prośbą o pomoc w rozwiązaniu problemu, rozumiem, czego chcą się ode mnie dowiedzieć. Pomagam im więc testować konkretne komponenty, które są opracowywane. Przydała się umiejętność analizowania systemów składających się z wielu elementów. Z łatwością potrafię zapamiętać ogólny obraz nawet złożonego systemu. Do zadań programisty należy także pisanie testów jednostkowych testujących konkretną funkcję w aplikacji. Umiejętność napisania skryptu testowego bezpośrednio pomaga mi w pracy. Gdybym teraz był absolwentem, od początku starałby się o pracę jako programista. Bałem się programować, bo uczyliśmy się C++ na uniwersytecie, gdzie podczas kodowania trzeba brać pod uwagę mnóstwo niuansów. Jednak podczas szkolenia uświadomiłem sobie, że tak nie jest: skomplikowane rzeczy można pisać prosto i przejrzyście.