100655266

SpiS treści

4.3.

5.6.

5.5.1.

5.5.2. Testowanie

6.1. Wprowadzenie

6.2.2. Edukacja internetowa

6.2.3.

6.2.4. Edukacja

6.2.5.

6.4.

6.6.

6.7.

7.2.2. Strategia testowania oparta na modelu dostarczania

7.2.3. Podejście negatywne do testów, czyli atak na oprogramowanie .................................

7.2.4. Podejście do testowania w zależności od dostępności specyfikacji ........................................

7.2.5.

7.4.3.

7.4.4.

7.5.

7.5.1.

7.6.

Projekt 3 – aplikacja internetowa z procesem wspierającym wytwarzanie

• Reaguj szybko. Zanim zareaguje konkurencja czy prasa.

• Pokaż, że nie tylko widzisz problem, ale również rozumiesz jego wagę i konsekwencje.

• Kanały komunikacji utrzymuj otwarte. Informuj o postępach prac. Odpowiadaj na pytania.

• Przeproś.

• Powiedz: „To się już więcej nie wydarzy” i zrób wszystko, aby już do tego nie doszło.

Nasza praca polega na szukaniu rozwiązań, które zminimalizują liczbę „uciekinierów”. Powinniśmy wdrożyć analizę przyczyny „uciekiniera” i możliwości narzędziowe, procesowe i ludzkie jego powstrzymania.

Sam temat raportowania o defektach zostanie szerzej opisany w części praktycznej tej książki.

4.3.2. Błędy popełniane przez testerów

Również testerzy oprogramowania popełniają błędy. Typowy dla nich jest tzw. błąd zakwalifikowania działania poprawnego jako niepoprawne, który pojawia się, gdy mimo braku defektu tester zgłasza raport o incydencie. Ten typ błędów jest uciążliwy dla innych członków zespołu, analityków czy programistów, bo zmusza ich do poszukiwania problemu, którego realnie nie ma. Innym typem błędu testera jest nieraportowanie o defekcie, tam gdzie on się pojawił. Istnieje wiele źródeł takiego błędu, takich jak zwykła nieuwaga lub niejednoznaczna specyfikacja produktu. Bez względu na powód przypadki takie mogą być krytyczne dla projektu, ponieważ z jednej strony marnują budżet przeznaczony na testy, a z drugiej dają złudne poczucie poprawności działania, podczas gdy w rzeczywistości pojawia się problem.

Błędy te przekładają się w konsekwencji na wspomnianych już „uciekinierów”. Doskonalenie testera powinno się zacząć od analizy własnych zgłoszeń uznanych przez innych członków projektu za „niedefekt” i tych błędów, które mieliśmy okazję wychwycić, ale z jakiegoś powodu tego nie zrobiliśmy.

4.3.3. d efekty powodują defekty

Czasami zdarza się również, że defekty powodują defekty. Z tym stwierdzeniem wiąże się kilka prawd.

4.3. Błędy, defekty, awarie, incydenty, zdarzenia, bugi…

• Niepoprawne zachowanie aplikacji ogólnie możemy nazwać awarią. Nie wnikamy, skąd wiemy, że zachowanie jest niepoprawne. Ogólnie akceptujemy, że mamy wystarczającą wiedzę, aby uznać coś za „awarię”. Jeśli w aplikacji pojawi się awaria, to może ona mieć wiele konsekwencji dla samej aplikacji, np. może powodować inne awarie. Źródłem awarii jest defekt. O defekcie wynikającym z defektu mówimy wówczas, gdy eliminacja defektu (źródłowego) spowoduje, że również powiązane z nim defekty przestają istnieć.

Przykład: niepoprawna walidacja formularza może powodować, że nie uda się go uzupełnić i zakończyć mimo poprawności danych. Usunięcie defektu walidacji powoduje, że defekt formularza (defekt wynikający z defektu) rozwiązuje się automatycznie.

• Analizując oprogramowanie, czasami widzimy dużą zależność między niektórymi defektami. Część tych zależności wynika ze wspólnego źródła pomyłki, część to konsekwencja stosowania techniki programistycznej kopiuj – wklej. Niepoprawny kod jest kopiowany do wielu miejsc (które czasami wydają się zupełnie niepowiązane). Znalezienie wzorca defektu pomaga wyeliminować go z wszystkich miejsc, w których został „wklejony”.

• Poprawki defektów mogą powodować nowe defekty. Dopóki liczba defektów naprawianych jest większa niż liczba defektów wprowadzanych przez poprawki, dopóty możemy mówić o postępie jakości oprogramowania.

Możemy więc mówić o czymś w rodzaju wzorca defektów. Ich świadomość i zdolność wykrywania będzie kolejnym (ważnym) aspektem rozwoju testera oprogramowania.

z adanie

Przeprowadź prosty eksperyment poznawczy. W dowolnej aplikacji wskaż awarię i spróbuj udowodnić, że naprawdę jest ona warta naprawienia. Na jakie źródła, autorytety czy dokumenty się powołasz? Jak udowodnisz osobie odpowiedzialnej za dany problem, że awaria musi zostać poprawiona.

6. z awód T es T er

6.1. Wprowadzenie

Branża wytwarzania oprogramowania ma się dziś lepiej niż kiedykolwiek i dodatkowo rozwija się bardzo dynamicznie. Biznesy, które funkcjonują krócej niż dekadę, są wyceniane wyżej niż niektóre państwa (np. Uber). Wydaje się, że polski rynek ma niemal idealne warunki wzrostu. Wiele czynników wpływa na to, że jesteśmy ciągle atrakcyjni dla zagranicznych inwestorów pod względem zatrudnienia specjalistów IT. Korporacje zawsze szukają optymalizacji kosztowej, a w Polsce koszty pracy nie są wysokie (w stosunku do Europy Zachodniej). Dostrzegalne jest również rozczarowanie azjatyckimi rynkami pracy, w tym Chinami czy Indiami. Główne problemy to odległości, komunikacja językowa i różnice kulturowe. Wszystko to powoduje, że firmy informatyczne coraz częściej koncentrują swoje działania w Polsce czy Rumunii. Rynkiem rządzą jednak dwie reguły, o których trzeba pamiętać. To, co spada, kiedyś musi urosnąć, a to, co rośnie, kiedyś musi spaść. Potencjalnych okazji do zmiany na rynku pracy jest wiele, np.:

• Otwarcie się tańszego rynku pracy w innej lokalizacji. Biznes, który już dziś ma problem z rekrutacją w Polsce, szybko przeniesie swoje centra w inne miejsce, pod warunkiem spełnienia kryteriów finansowych.

• Zmiana modelu dostarczania oprogramowania. Gdy na rynku pozostanie kilku wielkich dostawców, którzy w swoich rękach będą trzymać większość oprogramowania.

• Pojawienie się w pełni zautomatyzowanych metod tworzenia i testowania kodu i interfejsów.

• Sztuczna inteligencja, która przejmie większość rynku pracy.

Oczywiście dotyczy to również rynku pracy dla testerów oprogramowania. W przeszłości można było zaobserwować okresy, w których zapotrzebowanie było olbrzymie i obejmowało zarówno osoby początkujące, jak i bardziej doświadczone. Bywały też okresy, kiedy rynek nie potrzebował testerów lub potrzeba ta nie była uświadomiona. Aktualnie testerzy z długoletnim stażem oraz właściwym zestawem kompetencji mogą doświadczać jedynie wzrostu swoich wynagrodzeń i stabilności zatrudnienia. Rynek pracy testerów niedoświadczonych podlega bardziej dynamicznym zmianom. Firmy sięgają po nich, aby uzupełnić braki tych bardziej doświadczonych i rozwijać przyszłe kadry. Aby dobrze ocenić, w jakim cyklu koniunkturalnym się znajdujemy, musimy bacznie obserwować i interpretować symptomy.

W mojej opinii testowanie to ciągle zawód, który ma przyszłość i przyszłość ta jawi się w jasnych barwach. Oto pięć pierwszych powodów, dlaczego warto zostać testerem lub też lepszym testerem.

1. Dla testerów jest praca.

2. Testowanie nie jest trudne. Przynajmniej na początku kariery nie tak trudne jak programowanie, a może przynieść porównywalne dochody.

3. Testowanie można mieć we krwi, ale można je w sobie wykształcić. Zdolność do testowania jest raczej zestawem cech i specyficznym nastawieniem niż wrodzoną umiejętnością. Zdolność tę można łatwo wykształcić. Wystarczy być dokładnym i cierpliwym i już połowa drogi do zawodu została pokonana. Przyda się również umiejętność posługiwania się technologią, znajomość angielskiego i zdolność do komunikowania się ze światem zewnętrznym – druga połowa drogi zaliczona. W dodatku podobno każdy może być testerem, bo testowanie wpisane jest w nasze codzienne życie. Ten, kto urodzi się z zestawem właściwych cech, może zostać Van Goghiem testowania, ten, kto zawodu się nauczy, będzie może malarzem pokojowym testów.

4. Testowanie niesie radość. Kiedy znajdujesz defekt, cieszysz się, że uda się go wyeliminować i klient go nie zobaczy. Kiedy nie znajdujesz defektów, cieszysz się, że wszystko działa poprawnie.

5. Testowanie jest po prostu czystym dobrem dla innych. Testerzy są nie tylko linią obrony kontrolującą jakość aplikacji, ale zajmują poważne miejsce w eliminowaniu przeszkód i usprawnianiu nieintuicyjnych funkcjonalności, które mogą wprowadzać użytkownika w błąd.

Trudne aspekty pracy testera

6.6. trudne aspekty pracy testera

Z testowaniem oprogramowania wiąże się wiele przyjemnych elementów, ale może ono być również ciężkim kawałkiem chleba. Właśnie trudne aspekty podnoszone są przez przeciwników osobnej roli testera lub przez osoby, które chcą deprecjonować rolę testów w organizacji. We współczesnych firmach takich trolli antytesterskich jest coraz mniej, ale nie znaczy to, że na nich nie traficie. Część z nich zostało jedynie zagłuszonych przez poprawność polityczną i czeka na swoją okazję, aby wypunktować testerów za brak skuteczności lub jakościowo słabą pracę. W mojej opinii najgorsze, co może spotkać testera w organizacji, to:

• Próba testowania wszystkiego i zawsze, bez względu na zakres zmian w wersji czy bez względu na ograniczenia czasowe.

• Próba ślepego klikania oprogramowania, które samo z siebie nie pozwala nam zrozumieć logiki swojego działania albo po prostu mamy na to za niskie kompetencje.

• Testowanie w zmieniającym się środowisku, gdzie najgorszym przypadkiem jest testowanie czegoś, co właśnie jest modyfikowane, np. przez programistów.

• Wielokrotne testowanie tego samego bez widocznego celu.

• Praca w sytuacji stresowej, gdy próbuje się nam wmówić, że wszystko zależy od nas, a w dodatku niepowodzenie będzie naszą winą.

• Praca w atmosferze obwiniania testera za niską jakość.

Uda się uniknąć przez dłuższy czas złych zadań testerskich, jeśli trafimy na dobrego lidera. Większość problemów testerskich rozwiązuje się po prostu dobrym zarządzaniem. Dobry kierownik testów będzie chronił swoich ludzi przed wykonywaniem „małpiej” (monkey testing) czy monotonnej pracy. Przykładowo, minimalizacja nakładu pracy na regresję jest wynikiem dobrej współpracy testera z programistą. Współpraca ta jest jednak zazwyczaj wbudowana w organizację jako proces lub jako szkielet wzajemnego zaufania.

Wrogiem testera oprogramowania może też być nuda lub nudne zadania. Może to wynikać ze specyfiki pracy testerskiej oraz słabego zarządzania zadaniami. Konsekwencje nudy bywają krytyczne zarówno dla testerów, jak i dla organizacji. Na przykład może ona prowadzić do wypalenia zawodowego lub naturalnego zmęczenia powtarzalnymi zadaniami. Problem nudy

jest mocno powiązany z testowaniem regresji czy też z manualnym testowaniem. Każda organizacja dbająca o motywowanie swoich pracowników powinna dostarczać narzędzia, które są w stanie nudne i powtarzalne czynności automatyzować albo pomóc w ich zredukowaniu. Możliwym rozwiązaniem jest też rotacja zadań wśród większej grupy pracowników.

Nuda jednak może być również wynikiem złego dopasowania zadania do naszych kompetencji. Istnieje ryzyko pojawienia się znudzenia u osób o przeciętnych kompetencjach i dostających łatwe zadania. Rozwiązaniem jest więc dostarczanie zadań dopasowanych do poziomu wiedzy, doświadczenia i kompetencji.

Spotkałem się z przypadkami wymuszania na testerach ręcznego uruchomienia każdego przypadku testowego na każdej nowej wersji oprogramowania. Jest to naturalna droga do zabicia kreatywności i doprowadzenia do zmęczenia pracą testera. Wykonywanie tych samych przypadków testowych bez odpowiedniego uzasadnienia ich uruchomienia może przypominać pracę Charliego Chaplina w filmie „Dzisiejsze czasy”. Ciągłe przykręcanie jednej nakrętki na taśmie, przez którą przewijają się ich tysiące. Jeden popełniony błąd i cała ta misterna (lub szatańska) maszyneria przestaje poprawnie działać. Czy aby na pewno wykonanie każdego przypadku testowego jest złe? Uważam, że tak, ponieważ sygnalizuje poważne problemy organizacyjne. Przykładowo, jesteśmy zmuszani do uruchomienia wszystkich przypadków, ponieważ kierownictwo nie wie, co znajduje się w poszczególnych wersjach oprogramowania. Wykonanie przypadków staje się więc dla niego potwierdzeniem, czy coś w nim jest, czy też nie. Aby tego uniknąć, należy już na poziomie planowania wersji definiować, co ma się znaleźć w oprogramowaniu, a później w notach wydania (release notes) opisywać, co rzeczywiście zostało do oprogramowania wprowadzone. Czasami jesteśmy zmuszani do uruchomienia wszystkich przypadków, ponieważ kierownictwo nie potrafi odpowiedzieć na pytanie, jakie są powiązania wewnątrz oprogramowania. Aby zapewnić, że drobna poprawka nie uszkodzi (nie wpłynie na działanie) jakiegoś istotnego obszaru aplikacji, testujemy wszystko. Wtedy kluczem do rozwiązania jest analiza wpływu realizowana przez wszystkich członków zespołu, od programisty przez architekta, aż po klienta, dzięki której oceniamy, jaki wpływ na poprawność działania będzie miała dana poprawka. Natomiast testerzy muszą opracować zestaw testów regresywnych (różny od zestawu wszystkich przypadków testowych) uruchamianych na każdej nowej wersji. Zestaw ten warto zautomatyzować. W niektórych

Zawód tester

że jest (będzie) łatwo zostać testerem, i zamiast dynamicznie uderzyć w rynek, ciągle czekają. Nie można się zrażać! Porażki będą się powtarzać, ale trzeba wyciągać z nich wnioski. Jeśli wysłałeś już CV sto razy i nie ma żadnego zaproszenia na rozmowę, to znaczy, że może trzeba zmienić strategię? Może trzeba zastanowić się, czy twoje CV jest wystarczająco dobre i szukać miejsc jego poprawienia. Każdego dnia jest szansa na zdobycie nowego doświadczenia i uzupełnienie swojej oferty dla pracodawców. Rynek ciągle potrzebuje setek, a może już tysięcy testerów, ale pracodawcy (częściowo) stracili ochotę na inwestowanie w tzw. świeżaków. Chcą dowodów zaangażowania i woli rozwijania się, która zagwarantuje im krótszy czas wdrożenia i szybsze osiągnięcie testerskiej skuteczności. Jeśli nie pokażecie, że bardzo wam zależy, to nie otrzymacie tej szansy.

6.18. testerskie cV

Opisywałem już, jak ważne jest przesłane do potencjalnego pracodawcy CV. Jest to zazwyczaj pierwszy krok w rekrutacji i jest to ta rzecz, nad którą masz praktycznie 100% kontroli. To jeszcze nie rozmowa, więc nie zostaniesz zaskoczony żadnym trudnym pytaniem i nie ma presji czasu na odpowiedź. Jest za to wymagana umiejętność przekazywania informacji, odrobina kreatywności, szczypta wiedzy i cała gama zasad językowych – od interpunkcji po gramatykę. Przyda się znajomość marketingu i copywritingu oraz znajomość epistolografii i netykiety.

Jest też łatwiejsze rozwiązanie – niekoniecznie przeze mnie polecane: możesz uzupełnić szablon CV z internetu. Jeśli wybrałeś tę opcję, to w tym miejscu możesz zakończyć czytanie tego rozdziału. Jeśli zdecydowałeś się kontynuować, to teraz jesteś ty i pusta kartka, która za chwile powinna zapełnić się twoją historią i planami na przyszłość. Poniżej znajdziesz zalecane przeze mnie elementy edytorskie, wizualne oraz konstrukcje treści. Nie daję sobie prawa do nieomylności, ponieważ sam od lat nie tworzę CV. Tworzę za to oferty do potencjalnych klientów (to są praktycznie moi pracodawcy) i namiętnie czytam (nie tylko) testerskie CV. Nie będzie przesadą, jeśli powiem, że studiowałem ich tysiące.

Zanim zaczniesz tworzyć CV, pamiętaj, że jest ono twoją wizytówką i reklamą jednocześnie, a jego celem jest uzyskanie zaproszenia na rozmowę kwalifikacyjną. Nigdy o tym nie zapominaj, bo pozwoli ci to skoncentrować się na rzeczach ważnych i usuwać te, które nie mają znaczenia.

nie rób błędów w podstawowych informacjach

Czasami wydaje się, że są miejsca, w których nie można popełnić błędu i właśnie tam błędy są najbardziej oczywiste i widoczne. Oto twoje podstawowe dane, które powinny znaleźć się w CV. Oczywiście imię i nazwisko pomijamy, ale ty o nich nie zapomnij.

Miasto. Pamiętaj, by podawać nazwę miasta, w jakim aktualnie mieszkasz, aby pracodawca wiedział, czy „ma cię na wyciągnięcie ręki”, czy może będzie cię musiał realokować. Nazwa ulicy nie wystarczy. Jeżeli miasto nie ma znaczenia, to napisz miejsce, gdzie siedzibę ma Twój potencjalny pracodawca. Jeśli CV ma charakter ogólny albo za pracą pojedziesz wszędzie, to wpisz to miasto, w którym zamieszkujesz, ale dopisz „dostępność na terenie całego kraju” lub „gotowość do realokacji”. Oczywiście tylko pod warunkiem, że naprawdę jesteś gotowy przenieść się za pracą.

Adres e-mail. Uważaj, jakim adresem e-mailowym się posługujesz. Może to i nudny standard, ale adres powinien być skonstruowany w następujący sposób: imie.nazwisko@szanowanadomena.com.

Posługiwanie się kontem pocztowym z domeny @buziaczek.pl lub podobnych od razu odejmuje ci punkty w rekrutacji. Warto zadbać o profesjonalną skrzynkę pocztową. Również używanie nazw użytkownika typu „goraca23”, „jasiop”, „lewy1989” itd. nie świadczą dobrze o autorze. Jeśli do dziś nie masz profesjonalnej skrzynki, to załóż sobie jedną specjalnie na kontakty z pracodawcami.

Profil online. Jeśli masz pełniejszą wizytówkę w sieci w postaci profilu, który chcesz pokazać, to podaj do niego link (np. do profilu na LinkedIN). Możesz na nim zawrzeć więcej informacji o sobie. Koniecznie zadbaj, aby informacje z sieci były spójne z tymi w CV. Pamiętaj, aby był to profil, który pokazuje cię ze strony zawodowej, a nie prywatnej. Twoje komentarze odnośnie do innych osób, półnagie zdjęcia z wakacji, czy też ujawnienie preferencji politycznych lub religijnych może obniżyć twoje szanse na rekrutację. Nigdy nie wiesz, kto czyta twój profil ani jaki jest jej lub jego światopogląd. Co pomijać. Niektórych informacji już nie podaje się w CV, ponieważ nie mają lub też nie powinny mieć znaczenia. Pisanie o stanie cywilnym lub też o uregulowaniu stosunku do służby wojskowej jest zbędne. Rekruterzy nie powinni pytać o plany matrymonialne, a niezgodne z prawem są pytania o macierzyństwo czy o orientację seksualną. Nie pisz o tym! Trzeba również unikać informacji, które mogą nie dotyczyć stanowiska testera. Są to m.in.:

7.6. przykładowe projekty

Wcześniej opisałem praktykę testowania, ale wymaga ona przykładów. Oto zmodyfikowane przykłady projektów testerskich wzięte z mojej kariery testerskiej.

projekt 1 – strona internetowa

Testowanie stron internetowych to domena mniejszych firm testerskich, ludzi z internetowego tłumu (crowd), czyli opisywany crowdsourcing, osoby przyjmujące zlecenia itp. Jest to doskonały poligon dla każdego początkującego testera. Oto najprostszy z możliwych projektów z realnymi założeniami.

Zlecenia testowania przychodzą zazwyczaj z firm, które same nie zatrudniają testerów oprogramowania albo nie mają wystarczającej wiedzy czy odpowiedniego środowiska do testów. Należą do nich: pojedynczy programiści freelancerzy, mniejsze firmy wytwarzające oprogramowanie na zlecenie, agencje interaktywne itp.

zlecenie testów

Klient przysyła następujące wymagania dotyczące strony, które najprawdopodobniej stanowiły również wytyczne do jej wytworzenia.

„Strona będzie miała 6 podstron: S1, S2, S3, S4, S5, KONTAKT. Dostępny będzie przycisk: KUP BILET, który będzie linkował do zewnętrznej strony sklepu internetowego (procesu zakupu nie testujemy). Na stronie głównej będzie odtwarzacz wideo z listą filmów. Na podstronie S2 będą galerie zdjęć. W nagłówku będzie zegar odliczający czas do wydarzenia. Podstrony będą zawierały teksty, przyciski i zdjęcia. Stronicowanie będzie ustawione na sztywno i będzie wynosiło 10 elementów na stronę. Elementy strony dodawane są przez programistów (brak systemu zarządzania zawartością).

Testowanie będzie obejmowało: • stronę na najbardziej popularnych przeglądarkach w systemach Mac i PC, • wersję mobilną na najbardziej popularnych telefonach oraz na tabletach i iPadzie.

Dodatkowo wiadomo, że projekt jest jednorazowy, czyli że strona powstaje na potrzeby wydarzenia i nie będzie modyfikowana. Takie produkty mają bardzo krótki czas życia i relatywnie niewielki zasięg. Ich głównym

celem jest przekazanie informacji. Kiedy informacja się zdewaluuje, projekt zamiera albo umiera. Skreśla to automatyzację.

O stronie wiadomo, że nie ma tam żadnych formularzy z wyjątkiem KONTAKTU.

Ponieważ samo zlecenie nie zawiera wystarczająco dużo szczegółów, należy spróbować skompensować ich brak, analizując kontekst wynikający z naszej wiedzy i doświadczenia. Można to zrobić na wiele sposobów, np. przez plan testów. Dokument ten powinien w pierwszej części pokazywać wydatkowanie budżetu i co można za zdefiniowaną kwotę lub w zdefiniowanym czasie przetestować, np. ile środowisk i jakie. Po uszczegółowieniu zakresu można w planie testów zrezygnować z niektórych wariantów.

plan testów

Zaproponowany plan może być nadmiarowy, ale czasami lepiej napisać trzy słowa więcej, niż później ze zleceniodawcą drzeć koty o szczegóły. Jeśli taki plan zostanie zaakceptowany, znamy zakres naszych obowiązków. Możemy się do niego odnieść na koniec projektu.

PLAN TESTÓW

ID: TP-Strona-12

Wprowadzenie: strona internetowa będąca wizytówką strony wydarzenia. Funkcja raczej informacyjna, więc zakładamy jednorazowe użycie oprogramowania. Strona znajduje się pod adresem: xyz.pl

Testowane elementy:

1. Strona główna.

2. Podstrony ze statyczną zawartością: S1, S2, S3, S4, S5.

3. Podstrona KONTAKT z formularzem kontaktowym.

4. Odtwarzacz wideo z listą filmów.

5. Galeria zdjęć.

6. Zegar odliczający czas do wydarzenia.

7. Stronicowanie (10 elementów na stronę).

Ponieważ jedna technologia obsłuży wszystkie platformy, zakłada się, że będzie to rozwiązanie RWD (strona automatycznie dopasowująca się do rozdzielczości i wielkości ekranu).

Nietestowane elementy:

1. Funkcja Kup bilet.

2. System zarządzania zawartością (administracja).

3. Inne – wcześniej nieokreślone.

4. Charakterystyki inne niż funkcjonalność.