Bolączki testera. Devdebata

Idealny tester to spostrzegawcza, asertywna osoba wyczulona na niuanse, która doskonale zna produkt i wie, jakie są potrzeby jego użytkowników. Niewątpliwie tego typu specjalista pełni bardzo ważną rolę w procesie developmentu. Z jakimi problemami musi zmagać się w swej codziennej pracy? Do devdebaty zaprosiliśmy czynnych testerów i specjalistów z testerskim backgroundem.

W devdebacie udział wzięli:

Magdalena Drechsler-Nowak. QA Engineer, Altium.

Testowaniem oprogramowania zajmuje się od 5 lat, od roku realizuje się również jako Scrum Master. Przebyła długą drogę od aplikacji desktopowych, przez webowe, po to, by w Altium łączyć wiedzę pozyskaną na obu tych polach (i jeszcze kilku innych, wcześniej nieznanych). Głęboko wierzy w jakość totalną, wykraczającą poza techniki i metody. Od dwóch lat prowadzi bloga jakosctobedzie.pl.

Norbert Jankowski. Test Engineer w SDC.

Pracę w IT zaczął ponad 10 lat temu, zaraz po skończeniu Uniwersytetu Medycznego w Warszawie. Ze studiów została mu pasja do jakości, ale postanowił całkowicie zmienić swoją ścieżkę zawodową. Karierę przeszedł od Testera Manualnego poprzez Test Managera, aż do Quality Managera. Obecnie zajmuje się testami w międzynarodowych projektach z sektora bankowego. Prowadzi również podcast poświęcony testowaniu oprogramowania “Testowanie Oprogramowania Podcast”, w którym pokazuje zawód testera od kuchni oraz Szkołę Testera dla tych, którzy chcą zostać testerami.

Ewelina Wielemborek. IT Project Manager w Broad Minds.

Doświadczenie zawodowe zdobywała zarówno w pracy dla startupów, jak i w dużych korporacjach, co dało jej unikalne spojrzenie na potrzeby klienta oraz procesy biznesowe towarzyszące wytwarzaniu oprogramowania. Project Manager IT wspierający zespoły w osiąganiu wyższych poziomów produktywności, jakości i zaangażowania, wykorzystując w pełni wartości Agile. Od 4 lat prowadzi szkolenia IT zwiększające kompetencje testerów i programistów, aktualnie w firmie Broad Minds.

Maciej Wyrodek. Test Automation Community Leader w Objectivity.

“Jam częścią tej siły, która wiecznie zła pragnąc, wiecznie dobro czyni.” Tester z 8-letnim doświadczeniem. Specjalizuje się w automatyzacji, choć jego pierwszą miłością są dalej testy eksploracyjne. Pracował w wielu projektach w Polsce i zagranicą. Od 4 lat udziela się aktywniej w community, prezentując na wielu konferencjach i meetupach. W wolnym czasie prowadzi swój blog thebrokentest.com.

Agata Ostaszewska-Smykała. Java Developer w Future Processing.

Programistka Java z wieloletnim doświadczeniem w testowaniu oprogramowania i programowaniu testów automatycznych. Zawodowo związana z branżą IT od ośmiu lat. Absolwentka informatyki i filologii angielskiej, miłośniczka literatury pięknej i skoków narciarskich.

Damian Wasilczyk. Test Engineer w BEST SA.

Zwolennik podejścia zwinnego i związanego z nim braku nudy. Entuzjasta automatyzacji czynności rutynowych, co za tym idzie uwalniania ludzkiego potencjału i przekierowania go na niezbędne gałęzie gospodarki. W życiu zawodowym stawia na ciągły rozwój i wychodzenie poza ramy obowiązków typowego testera.

1. Lepiej pracuje Ci się z “technicznymi”, czy z “nietechnicznymi” osobami? Czy osoby z wykształceniem technicznym górują nad tymi z innym backgroundem?

Magdalena Drechsler-Nowak, QA Engineer w Altium: Najbardziej lubię pracę z osobami… otwartymi na współpracę. Nie ma tu znaczenia, czy ktoś ukończył techniczny kierunek, bo zawsze marzył o programowaniu, czy może zmienił branżę, wcześniej pracując jako psycholog. Każdy może wnieść coś wartościowego do zespołu pod warunkiem, że jest zaangażowany w pracę, otwarty na doświadczenie i zdanie innych.

Norbert Jankowski, Test Engineer w SDC: Nie lubię porównania osoba techniczna – nietechniczna. Ja jestem nietechniczny, bo nie skończyłem nic związanego z IT, ale udało mi się nauczyć dużo rzeczy samemu. Jeżeli sam potrzebuję wyjaśnienia, to najlepiej od osoby, która tę wiedzę potrafi przekazać – tak samo wolę pracować z osobami, które chętnie się uczą. Techniczny, nietechniczny – to ma mniejsze znaczenie. Chęć nauki – to jest ważne.

Ewelina Wielemborek, IT Project Manager w Broad Minds: W IT liczą się przede wszystkim kompetencje. Dla mnie nie jest istotne czy ktoś skończył studia techniczne, czy ukończył kurs IT i samodzielnie się przygotowywał. Samo posiadanie wykształcenia technicznego nie jest gwarantem dobrej współpracy. Jeśli osoba „nietechniczna” jest w stanie rzetelnie i samodzielnie wykonywać powierzone jej zadania, to będzie mi się z nią dobrze pracowało.

Maciej Wyrodek, Test Automation Community Leader w Objectivity: Zależy, przy czym jeśli jest to techniczna dyskusja, to definitywnie z technicznymi idzie szybciej. Np. jeśli kwestią jest, jak przetestować funkcjonalność i ryzyka są „techniczne”, to taką rozmowę łatwiej się prowadzi. W wypadku ryzyk biznesowych techniczność już niekoniecznie musi być pomocna. Czy techniczni górują? Zależy od kontekstu, każdy radzi sobie lepiej w innym kontekście. Osoby techniczne mają przewagę, jeśli temat wymaga dogłębnego zrozumienia technologii.

Agata Ostaszewska-Smykała, Java Developer w Future Processing: Najlepiej pracuje się z pasjonatami, niezależnie od tego, czy ich pasja idzie w parze z wykształceniem, czy też została odkryta później. Takie osoby są w stanie szybko nadrabiać ewentualne braki techniczne, a umiejętność i chęć szybkiej nauki wydają się w naszej branży istotniejsze niż wiedza posiadana na starcie.

Damian Wasilczyk, Test Engineer w BEST SA: Zdecydowanie lepiej pracuje się z osobami technicznymi. Nie chodzi tutaj o wykształcenie kierunkowe, tylko wiedzę (bynajmniej nie jest to ze sobą tożsame) projektową. Oszczędza to masę czasu i frustracji. Osoby nietechniczne mimo najszczerszych chęci nie są w stanie przeskoczyć pewnych rzeczy.

Wojciech Białasek, Junior Tester w E Net Production: Jakość pracy nie zależy od tego, czy dana osoba jest techniczna, czy też nie. Największe znaczenie ma tutaj podejście drugiej osoby do pracy. Czasami jest tak, że osoba nietechniczna mimo braku wiedzy w danej dziedzinie nadrabia profesjonalizmem.

2. Testerzy reprezentują interesy klienta – w końcu chodzi o jak najlepsze działanie jego produktu. Jednak czy zawsze wrażenia z pracy z klientem są pozytywne? A może czasami wcale nie wygląda to jak gra do jednej bramki?

Magdalena Drechsler-Nowak, QA Engineer w Altium: Jesteśmy tylko ludźmi, posiadamy ludzkie przywary, ulegamy błędom poznawczym. Nic więc dziwnego, że nie zawsze się rozumiemy i często zapominamy lub zdajemy się nie dostrzegać, że nasz cel jest taki sam. Oczywiście, nieporozumienia się zdarzają. W takich sytuacjach staram się zrozumieć drugą stronę i pokazać jej, że gramy do jednej bramki, że nasz konflikt wynika z tego, że obu stronom bardzo zależy. Warto skupiać się na tym, co nas łączy, a nie na tym, co dzieli.

Norbert Jankowski, Test Engineer w SDC: Wszystko zależy od klienta. Jedni chcą mieć szybko i tanio, inni dobrze. Jeżeli klient jest świadomy, iż testy mają zagwarantować jakość produktu, to woli nawet przesunąć datę premiery, niż wydać bubla. Inni traktują testy jako zło konieczne i sprowadzają ich rolę do minimum i akceptują tylko dlatego, że musiały się odbyć. Wiadomo, w jednym podejściu będzie pracować się lepiej, gdzie w drugim obie strony będą chciały zamknąć projekt jak najszybciej i zapomnieć o nim.

Ewelina Wielemborek, IT Project Manager w Broad Minds: Jeśli pracujemy ze świadomym klientem, który rozumie, że testy odgrywają kluczową rolę w dostarczaniu dobrego oprogramowania, to współpraca może być bardzo satysfakcjonująca. Problem pojawia się, gdy klient naciska, aby szybciej wydać oprogramowanie kosztem poświęcenia czasu na testy. W takiej sytuacji ciężko się zgodzić, że interesy testera i klienta są zbieżne.

Maciej Wyrodek, Test Automation Community Leader w Objectivity: Nie zgadzam się ze stwierdzeniem, interes klienta reprezentuje klient i tylko on może powiedzieć, czy coś rozwiązuje jego problem, czy nie. Ja, tak samo jak reszta zespołu, mam jakąś hipotezę na ten temat. Ale ja nie jestem klientem, ja nigdy nie wiem, czy moja hipoteza jest poprawna. Jedyną opcją jest dostarczyć rozwiązanie klientowi jak najszybciej, by zobaczyć, czy to jest to, czego szuka. A co do pracy z klientem, to wszystko zależy od tego, jaki jest klient i jak zbudujemy sobie relacje. Ludzie trudni się wszędzie trafiają. I w zespole, i u klienta.

Agata Ostaszewska-Smykała, Java Developer w Future Processing: Osobiście moje wrażenia z pracy z klientem są w większości pozytywne – jako tester czułam się rzeczywiście traktowana przez klienta jak ktoś, kto może mu pomóc osiągnąć cel. Wiele zależy też od relacji, jaką firma buduje z klientem. Zdarza się, że tester ma okazję pracować na pograniczu roli swojej i analityka, dbając o to, żeby dla wszystkich było jasne, czego oczekuje klient. Taka praca potrafi dać dużo satysfakcji i okazji do rozwoju, oczywiście jeżeli klient jest otwarty na współpracę i komunikację.

Damian Wasilczyk, Test Engineer w BEST SA: Rzadko kiedy wygląda to jak gra to jednej bramki. Głównie wynika to z dynamicznie zmieniających się wymagań, przez co w większości przypadków współpraca z klientem to spacer po linie, zaś osunięcie się z niej oznacza konflikt. Rolą testera jest niedopuszczanie do takich sytuacji, jednak w przypadku kolejnej zmiany każdy może w końcu zobaczyć na horyzoncie granicę swojej cierpliwości.

Wojciech Białasek, Junior Tester w E Net Production: Wszystko zależy od świadomości klienta. Wielu zdaje sobie sprawę z tego jak ważne są testy i jakie konsekwencje niesie za sobą ich brak. Ale zdarzają się i tacy którzy traktują testy jako niepotrzebny i zbędny wydatek. Oczywiście najlepiej współpracuje się z tymi świadomymi.

3. Co najbardziej drażni Cię w podejściu programistów do produktu, klienta, testerów?

Magdalena Drechsler-Nowak, QA Engineer w Altium: Bardzo nie lubię, kiedy programistom zdarza się zapomnieć, po co tak naprawdę robimy naszą pracę, że naszym celem jest sprostać oczekiwaniom klienta. Z tego zwykle wynika zbyt osobiste odbieranie bugów odnajdywanych w kodzie czy ogólnego feedbacku odnośnie produktu.

Norbert Jankowski, Test Engineer w SDC: Sprowadzanie roli testera do tego, co gasi światło po imprezie. Jako jeden z ostatnich elementów cyklu wytwórczego, testing często sprowadza się do roli domykacza. Testerzy mają przetestować i nic nie znaleźć. Oczywiście to skrajne przypadki, które coraz rzadziej się zdarzają, ale nadal gdzieś pokutują. Częściej możemy spotkać się z sytuacją, gdzie tester znajduje rzeczy, których nikt nie przewidział i jest za to chwalony. Chyba że mam szczęście co do ludzi, z którymi współpracuję.

Ewelina Wielemborek, IT Project Manager w Broad Minds: Często programiści realizują daną funkcjonalność bez dodatkowej analizy, czy na pewno spełni ona oczekiwania klienta. Należy zadawać sobie sprawę, że klienci nie zawsze wiedzą jakiego rozwiązania potrzebują, nie są świadomi, czy zaproponowane rozwiązanie faktycznie spełni ich oczekiwania. To zespół developerski, w tym programiści jako eksperci w wytwarzaniu oprogramowania, powinni dobrać najlepsze rozwiązanie. Natomiast w kwestii podejścia programistów do testerów, to obecnie świadomość ważności wzajemnej współpracy jest już tak wysoko rozwinięta, że nie dostrzegam żadnych drażniących aspektów. W zespołach, w których pracowałam, panował pełny szacunek na linii programista – tester.

Maciej Wyrodek, Test Automation Community Leader w Objectivity: Kwestia jest zbyt ogólna, nie mam czegoś, co mnie drażni u wszystkich. Ale jest pewna mentalność, którą widzę czasem u testerów i developerów, która mnie smuci. Myślenie, że jesteśmy najważniejsi. Brak zrozumienia, że tak naprawdę to, co jest najważniejsze, to to, że produkujemy coś, co ma komuś przynieść wartość. I tyle. Użytkownika końcowego nie obchodzi, czy to jest superekstranowoczesny tool. Interesuje go, czy rozwiązujemy jego problem. My nie testujemy/programujemy dla samej w sobie aktywności. My to wszystko robimy, by dostarczyć komuś wartość. Jasne, dobre praktyki i craftmanship jest ważny. Ale trzeba mieć balans.

Agata Ostaszewska-Smykała, Java Developer w Future Processing: Kiedy jeszcze pracowałam jak tester, zdarzyło mi się spotkać z podejściem programistów, że pracę testera może wykonywać każdy i nie wymaga ona żadnych kompetencji. Wpływało to na atmosferę i brak ducha pracy zespołowej – programiści traktowali wtedy testerów jak czynnik utrudniający pracę i trudno było uzyskać od nich informacje potrzebne do przetestowania efektów ich pracy. Na szczęście były to tylko jednostkowe przypadki, a zdecydowana większość programistów uznawała testerów za integralną część swojego zespołu i rozumiała, że testowanie to nie chaotyczne wpisywanie losowych danych i klikanie na oślep.

Damian Wasilczyk, Test Engineer w BEST SA: Do produktu: założenia z góry, że coś nie będzie używane, że użytkownik końcowy na pewno nie wpadnie na te absurdalne pomysły jak te, za pomocą których tester przed chwilą “popsuł” jego dzieło. W stosunku do klienta: często brak cierpliwości i zrozumienia, że to, co z ich perspektywy jest bezsensowne, dla klienta może być podstawą jego działań. Do testerów: coraz rzadziej, ale jednak nadal spotyka się podejście “tester to programista, któremu czegoś zabrakło”. Skrajne podejście, na zasadzie: “tester, czyli ten, co nie wie nic” i tłumaczenie podstaw podstaw, albo wręcz przeciwnie: “tester powinien wiedzieć co najmniej tyle, co ja, więc tłumaczenie mu czegokolwiek nie ma najmniejszego sensu”. Oba te podejścia są błędne, ponieważ tester (podobnie jak np. analityk) to zupełnie inna rola.

Wojciech Białasek, Junior Tester w E Net Production: Jeżeli chodzi o podejście do klienta czy produktu, to nie miałem jeszcze sytuacji, które mnie osobiście by drażniły. Natomiast czasami zdarza się, że testerzy są traktowani z góry. Jako zło konieczne. Zdaża się, że programiści wychodzą z założenia, że skoro coś działa, to nie ma błędów, a potem wychodzą mniejsze lub większe bugi.

4. Czy często zdarza się, że czas i inne środki przeznaczane na testy uważasz za niewystarczające? Czy możesz opowiedzieć o konsekwencjach takich działań, z którymi się spotkałeś/-aś?

Magdalena Drechsler-Nowak, QA Engineer w Altium: Pierwszą rzeczą, jakiej nauczyłam się w IT było to, że jakość zapewniamy tylko na takim poziomie, jaki jest dla nas opłacalny. Oczywiście, możemy zapewnić 100% pokrycie testami. Pytanie, czy nie będzie to kosztowało więcej, niż ewentualne naprawienie szkód. Choć to podejście może wydawać się nieco pragmatyczne, to pozwala skrócić proces testowania i dostarczać szybciej. Mam to szczęście, że wszyscy moi pracodawcy zdawali sobie sprawę z tego, jak ważny jest proces testowania i nie naciskali na jego zbytnie skracanie.

Norbert Jankowski, Test Engineer w SDC: Spotkałem się kilka razy z sytuacją, w której zostałem poproszony o obniżenie wyceny testów dla danego projektu ze względu na zbyt wysoką estymatę. We wszystkich przypadkach pierwotne wyliczenia okazywały się bliższe prawdy, niż te nowe. Wspomniane projekty musiałby być albo przedłużone, albo akcja naprawcza po ich wypuszczeniu przybierała formę nowych projektów.

Ewelina Wielemborek, IT Project Manager w Broad Minds: Niestety często się tak zdarza, ze względu na specyfikę wytwarzania oprogramowania. Najpierw daną funkcjonalność należy zaprogramować, a następnie przetestować. Jeśli podczas fazy programowania dojdzie do opóźnień, to na testy zostaje już za mało czasu. W związku z tym testerzy często pracują pod presją. Nawet jeśli stosujemy podejście iteracyjne, to i tak często testy są realizowane na końcu iteracji. Konsekwencją niewystarczającego czasu na testy jest rezygnacja lub obniżenie kryteriów zakończenia testów, np. zastosowanie mniejszego pokrycia przypadkami testowymi, co może przełożyć się na wdrożenie na produkcję oprogramowania zawierającego błędy.

Maciej Wyrodek, Test Automation Community Leader w Objectivity: Jeśli proces wytwarzania oprogramowania jest zły, testowanie często może wyglądać na wąskie gardło. Bo “jest na końcu” i przez to łatwo je winić za opóźnienia. Tak samo klienci często nie rozumieją wartości testowania „Zaraz, zaraz, czemu ja mam za to płacić? Kupuję od was projekt/produkt, to już w waszej kwestii jest, by był on dobry”. Prawda jest taka że nieważne, czy development, czy testowanie – często pracujemy pod presją i czasu, i kosztów. Nigdy się nie spotkałem z sytuacją, by było „dość”. Kwestią jest, czy potrafimy powiedzieć, jakie są ryzyka i ich prawdopodobieństwa? Jeśli tak, to pytanie do klienta, czy je akceptuje.

Agata Ostaszewska-Smykała, Java Developer w Future Processing: Na początku projektów prowadzonych w Scrumie zdarza się, że zespół bierze do sprintu mniej więcej tyle zadań, ile programiści są w stanie ukończyć, a pod koniec sprintu okazuje się jednak, że nie oznacza to wcale sukcesu, ponieważ do ostatecznego zamknięcia zadań brakuje jeszcze testów, a potem być może i poprawek z ponownymi testami. W dojrzałych organizacjach nie ma raczej problemu z uwzględnieniem czasu czy innych zasobów potrzebnych na testy. Gorzej sprawa wygląda w firmach, które dopiero niedawno wprowadziły zapewnianie jakości. Brakuje czasem mentalnej, a nieraz i finansowej gotowości na inwestycję w czas i pracowników potrzebnych do prowadzenia dokładnych testów.

Damian Wasilczyk, Test Engineer w BEST SA: Zwłaszcza w Scrumie (chociaż nie tylko) jest to bardzo częsty problem. Estymata wygląda ładnie w tabelce, ale potem przychodzi rzeczywistość: coś się wysypało, czegoś nie wzięliśmy pod uwagę, coś nie działa. Czas na te wszystkie niespodzianki w 95% pochodzi z czasu przeznaczonego na testy (pozostałe 5% to opuszczone meetingi), co potem może skutkować skróceniem testów albo niedowiezieniem danej funkcjonalności. Dlatego ważne jest, żeby działać zespołowo i już na etapie implementacji wiedzieć, gdzie mogą wystąpić najpoważniejsze problemy, a potem nie tracić czasu na ich wymyślanie podczas właściwych testów. Dla testera z doświadczeniem nie powinno być to problemem ani rodzić poważnych konsekwencji (oczywiście poza sytuacjami skrajnymi).

Wojciech Białasek, Junior Tester w E Net Production: Zdarzają się sytuacje, w których nie ma już czasu na testy, bo zadania były źle wyestymowane, a sprinty muszą dojechać, albo co gorsza testy nie są brane w ogóle pod uwagę przy estymacji zadania. Mała strata, jeżeli na produkcję wejdą zadania, w których znajdą się jakieś literówki niewpływające negatywnie na funkcjonalność. Ale zdarzają się sytuacje, gdzie błędy mogą słono kosztować i pociągnąć za sobą poważne konsekwencje.

5. Czy firmy działające w Polsce zapewniają testerom odpowiednie warunki do rozwoju?

Magdalena Drechsler-Nowak, QA Engineer w Altium: Nie spotkałam się jeszcze z sytuacją, w której pracodawcy nie zależałoby na moim rozwoju. Z drugiej strony, na rozmowie kwalifikacyjnej staram się upewnić, czy w danej firmie będę miała możliwość robienia tego, co mnie interesuje – to pozwala na uniknięcie problemów w tym zakresie w przyszłości. A jeśli wiem, jaki jest mój plan i co chcę robić, to zwykle udaje się znaleźć obszar w firmie, w którym mogłabym się realizować. Oczywiście, czasem rozwój wymaga kompromisów, na przykład zmiana technologii z dnia na dzień nie jest łatwa i takie sytuacje też należy zrozumieć.

Norbert Jankowski,Test Engineer w SDC: Oczywiście, jak zawsze, to zależy od firmy. Widziałem ogłoszenia, gdzie firmy szkoliły testerów manualnych na automatycznych, testerów na programistów czy UX-owców. Natomiast to, co jest niepokojące, to to, iż nasz rynek jest zdominowany przez kontrakty B2B. W takiej sytuacji szkolenia to rzadkość i o ile samemu nie zadbamy o dalszy rozwój, to gdzieś to może nam umknąć. Należy pamiętać, iż samokształcenie w świecie IT jest bardzo ważne i nie można o nim zapominać.

Ewelina Wielemborek, IT Project Manager w Broad Minds: Najczęściej zależy to od świadomości i stopnia rozwinięcia firmy oraz od budżetu szkoleniowego, jakim można dysponować. Bazując na moich doświadczeniach: w firmach, w których pracowałam, nie było żadnego problemu z pozyskaniem finansowania na profesjonalne szkolenia czy, w przypadku mniejszego budżetu, zorganizowania wewnętrznej wymiany wiedzy lub zakupu odpowiedniej książki. Zazwyczaj firmy IT mocno stawiają na rozwój swoich pracowników i chętnie zapewniają im odpowiednie do tego warunki.

Maciej Wyrodek, Test Automation Community Leader w Objectivity: Nie wiem, nie pracowałem we wszystkich firmach w Polsce. A tak serio, to zależy. Są firmy jak Objectivity, które inwestują w knowledge sharing i to ostro. Są firmy o ogromnych budżetach szkoleniowych. I są firmy typu CebulaCorporation, co nic nie robią. Tak samo są firmy, które mają dużo ekspertów, od których można się uczyć, jak i te, które mają seniorów, którzy zatrzymali się 10 lat temu. Są firmy z ciekawymi projektami i takie, które mają same legacy utrzymaniowe. Ale też jest pytanie, które trzeba sobie zadać: „Czy ja zapewniłem sobie odpowiednie warunki do rozwoju?” Bo po co firma ma nam coś dawać, jeśli sami z tym nic nie robimy?

Agata Ostaszewska-Smykała, Java Developer w Future Processing: Z moich doświadczeń wynika, że większość firm stara się stworzyć jak najlepsze warunki do rozwoju – zarówno, jeśli chodzi o szkolenia i certyfikacje, jak i ewentualne zmiany projektu, a nawet zmiany roli.

Damian Wasilczyk, Test Engineer w BEST SA: Temat rzeka, wszystko zależy, gdzie się trafi. W jednej firmie powtarzalnie wykonujesz zestaw tych samych czynności, w drugiej cały czas coś nowego. Jednak w obu tych wypadkach rozwój następuje, po prostu jest on ograniczony innym pułapem. Ogólny trend zwiększa odpowiedzialność testera, a co za tym idzie, popycha jego rozwój.

Wojciech Białasek, Junior Tester w E Net Production: Jak najbardziej. W tej branży rozwój jest bardzo ważny i wiele firm zdaje sobie z tego sprawę. Obie strony czerpią korzyść z tego rozwoju. Pracownik, bo podnosi swoje kwalifikacje, i firma, bo jest bardziej konkurencyjna na rynku. Na pewno trafiają się wyjątki, jak wszędzie, jednak firmy takie nie utrzymują swoich pracowników zbyt długo przy sobie. Rynek IT jest bardzo dynamiczny i poniekąd to też wymusza na firmach ciągły rozwój.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z