Zawód tester - ebook

PRZEDMOWA DO DRUGIEGO WYDANIA

Pisząc książkę o testowaniu, nie sądziłem, że tak szybko przyjdzie mi ją aktualizować. Wiedziałam, że świat IT pójdzie do przodu, ale nie przypuszczałem, że tak znacząco zmieni się otoczenie samego testowania. Rynek pracy zmienił się na niekorzyść osób początkujących i chcących dopiero poznać tajniki testowania. Co prawda nadal jest wiele ofert pracy, ale oczekiwania dotyczące umiejętności i motywacji pracowników są większe. Sama chęć zostania testerem już nie wystarczy. Trzeba pokazać pracodawcy choćby podstawowe umiejętności i naprawdę duże zaangażowanie.

Aby rzeczywiście pomóc młodym adeptom testowania w zmieniających się okolicznościach, zdecydowałem się dodać do książki elementy opisujące walkę o stanowisko pracy. Oprócz ogólnych porad umieściłem również szczegółowe informacje dotyczące tworzenia dobrego CV oraz pytań, jakie mogą paść na rozmowie kwalifikacyjnej.

Zdecydowałem się również, za namową czytelników, na pokazanie jeszcze jednego oblicza testerskiej edukacji, a mianowicie spotkań, konferencji i szkoleń testerów.

Ponadto zebrałem i przeanalizowałem zgłoszone przez czytelników pierwszego wydania błędy i sugestie. Udało mi się wychwycić i poprawić wiele błędów redakcyjnych i kilka merytorycznych. Książka zawiera także przeróbki edytorskie oraz krótsze i dłuższe teksty uzupełniające i pomagające zrozumieć jej treść.

Chciałbym podziękować wszystkim czytelnikom pierwszej wersji za ciepłe przyjęcie mojej książki i za ich dobre słowa. Jeśli pojawiła się krytyka, to tylko konstruktywna, która pomogła mi opracować wydanie 2.WSTĘP

Przekazuję w tej książce wiedzę, którą sam chciałbym dysponować, kiedy zaczynałem pracować w zawodzie. Część informacji w niej zawartych może się Czytelnikowi wydać znajoma, ponieważ jest to poprawiona, przeredagowana i uspójniona wiedza, jaką od 2005 roku publikuję w prasie branżowej, zamieszczam na blogach i przedstawiam podczas prezentacji i szkoleń. Skoro część informacji można znaleźć w sieci, po co kupować tę książkę? Przygotowałem ją jako kompilację podstawowych informacji dla tych, którzy szukają drogi na skróty, by zostać testerami, i tych, którzy już zrobili pierwszy krok w tym kierunku.

Wciąż wiele osób pyta, jak zostać testerem. Ta publikacja to moja odpowiedź podana w pigułce. W mojej opinii pokazuje ona najprostszą i najkrótszą drogę do zawodu.

Materiał zawarty w książce został „przećwiczony” na początkujących adeptach testowania i testerach z niewielkim doświadczeniem. Chciałem im serdecznie podziękować za recenzje i uwagi oraz za udział w powstawaniu tej publikacji.

Do każdego bardziej praktycznego tematu dodałem zadania. Są opisane skrótowo, a ich rozwiązanie wymaga dużej samodzielności i samozaparcia, a także własnej inicjatywy. Pewną pomocą dla tych, którzy wolą pójść na skróty, zadania, aplikacje i specyfikacje przygotowane na potrzeby Mistrzostw Polski w Testowaniu Oprogramowania TestingCup, dostępne pod adresem mrbuggy.pl. Jest tam wystarczająco dużo materiału dla osób, które chcą szukać defektów, uczyć się je raportować i podglądać pracę najlepszych.PODZIĘKOWANIA

Inspiracji do powstania mojego portalu testerzy.pl oraz w konsekwencji tej książki dostarczyły setki testerskich blogerów i autorów książek opisujących testowanie. Na świecie jest wielu wartościowych testerów, którzy swoją wiedzą dzielą się każdego dnia. Publikują ciekawe pomysły, informują o nowościach i sami tworzą nowe rzeczy. Każdy z nich w jakimś sensie zmusił mnie do myślenia o testowaniu. Z częścią z nich się nie zgadzam i próbuję zbijać ich argumentację. Część z nich otwiera mi oczy albo zmusza do nowego spojrzenia na projekty, w których brałem udział, bądź na strategię testową, którą obrałem. To im chcę szczególnie podziękować, bo mieli wpływ na to, jakim testerem jestem dzisiaj.

Chciałem również podziękować swoim współpracownikom. Jedni z nich czytali i recenzowali fragmenty książki, inni mnie inspirowali i wspierali w trakcie pisania, a sporo naszych wspólnych doświadczeń zostało w bardziej lub mniej oczywisty sposób zaprezentowane w tej publikacji.

W dużej części procesu rozwoju w zawodzie testera i pisania tej pracy musiała biernie uczestniczyć moja rodzina. Wiem, że niekiedy poświęcałem za dużo czasu pracy, a za mało spędzałem w domu. Zbyt często zdarzało mi się być w nim tylko ciałem i rozmyślać o pracy. Może uświadomiłem to sobie odrobinę za późno, ale cieszę się, że dziś udało mi się osiągnąć równowagę. Dziękuję moim najbliższym, że wytrzymali ten czas poszukiwania i odnajdowania. Bez Was ta książka nigdy by nie powstała.1. KONSTRUKCJA KSIĄŻKI

Książkę podzieliłem na dwie części. W pierwszej opisuję zawód testera od strony teoretycznej i omawiam aspekty testowania, z którymi możesz się spotkać w pierwszych miesiącach pracy. W drugiej zajmuję się praktyką i podaję swego rodzaju skróty oraz gotowe rozwiązania dla testerów. Dodałem również kilka przykładów, które pomogą ci się odnaleźć w pierwszej firmie, w jakiej przyjdzie ci pracować. Są to przykłady wzięte z życia i dzięki temu pewnie bardziej przydatne.

Chcąc pomóc „wzrokowcom”, wszędzie tam, gdzie grafika pomaga zrozumieć tekst, starałem się ją umieścić. Zastosowałem również tabele dla zwiększenia czytelności zbiorów danych – nie po to, by je pochłaniać podczas lektury, a raczej by je analizować na konkretnych przykładach. Natomiast te fragmenty, które pomagają zrozumieć szerszy kontekst omawianego tematu, ale nie należą do głównego wątku rozważań (np. definicje czy dygresje), zostały ujęte w ramki.

------------------------
Definicja lub dygresja
Treść
------------------------2. TESTOWANIE W PIGUŁCE

Nie staniesz się testerem tylko dzięki kupieniu tej książki. Jesteś nim i zawsze byłeś. Testowanie jest naturalnym procesem i czy nazwiemy je uczeniem się, czy też eksperymentowaniem, nie ma to większego znaczenia dla samej czynności poznawania i podejmowania decyzji o testowanym obiekcie. Przedmiotem osądu może być wszystko, poczynając od wody i żywności, które są naszą podstawową potrzebą, przez narzędzia i produkty, których używamy każdego dnia, po narzędzie najbardziej skomplikowane, jakim jest oprogramowanie. Oceniamy też rzeczy niematerialne lub niedotykalne: obrazy, spektakl teatralny, film, muzykę. Można by tak wymieniać w nieskończoność. Czy jest to testowanie? Wszystko zależy od przyjętej definicji testowania. Jeśli uznamy, że jest nim doświadczanie i dokonywanie oceny z jednoczesnym opisaniem rzeczy akceptowalnych i nieakceptowalnych, to dlaczego nie?

Nasz osąd może być nie w pełni sprawiedliwy, może być niepoprawny, gdyż wpływa na niego (zbyt) wiele czynników, ale jeśli zadeklarujemy, że jest to nasza subiektywna opinia, to ma ona znaczenie. Umiejętność zobiektywizowania tej opinii i przestawienia jej z uwzględnieniem potrzeb dużej grupy ludzi lub jednej osoby – ważnej w procesie wytwarzania ocenianego przez nas obiektu – jest miarą naszego profesjonalizmu.

Obiekt testów możemy zaakceptować, ale możemy go też odrzucić z informacją, że nie spełnia wymagań. Im bardziej konstruktywnie będziemy go krytykować, tym lepszymi staniemy się testerami.

Nie można być testerem wszystkiego, znać się na wszystkim i powiedzieć, że każdy obiekt umiemy tak samo dobrze. Im większą masz wiedzę wynikającą ze znajomości danego obiektu lub doświadczenia w jego używaniu, tym twoja opinia, również subiektywna, będzie bardziej wartościowa. Ludzie, którzy recenzują książki, sprzęt do biegania czy inwestycje samorządowe, to zazwyczaj specjaliści, których wieloletnie badania danego obszaru upoważniają do wypowiadania się na dany temat. Znalezienie swojej testerskiej niszy jest również wybraniem własnej drogi rozwoju. Możesz się w niej wyspecjalizować, a znając ją lepiej niż ktokolwiek inny, osiągnąć status eksperta. Oczywiście nie musisz być w danej niszy twórcą. Możesz być wyłącznie krytykiem.

Wracając do obszaru testowania oprogramowania, mogę śmiało powiedzieć, że jesteś testerem oprogramowania, jeśli potrafisz:

1. Uruchomić oprogramowanie i go używać.

2. Przekazać opinię na temat jakości oprogramowania, a na twój osąd składają się następujące informacje:

• potwierdzenie, że dany obszar aplikacji działa;

• potwierdzenie, że w danym obszarze znajdują się awarie;

• zasygnalizowanie (na podstawie własnego przekonania), że coś nie działa tak, jak powinno, lub że są problemy, których nie umiesz jednoznacznie uznać za zachowanie poprawne czy niepoprawne.

Co prawda jeśli potrafisz tylko tyle, to jesteś dopiero na początku drogi do osiągnięcia profesjonalizmu w tej dziedzinie, ale z całą pewnością pierwszy krok został wykonany. W książce tej rozwinę wszystkie wspomniane tu elementy i zakładam, że jeśli je zrozumiesz i dodatkowo efektywnie przerobisz zadania, to po zakończeniu lektury możesz o sobie mówić „tester oprogramowania”.

+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Tester |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Tester – wykwalifikowany profesjonalista, zaangażowany w testowanie modułu lub systemu (słownik ISTQB, w polskim tłumaczeniu). |
| |
| Tester (tester) – wykwalifikowany profesjonalista zaangażowany w testowanie modułu, systemu lub innego artefaktu procesu tworzenia oprogramowania (Adam Roman w swojej książce Testowanie i jakość oprogramowania). |
| |
| Tester oprogramowania komputerowego weryfikuje poprawność działania oprogramowania oraz raportuje wykryte błędy i niezgodności ze specyfikacją (Ministerstwo Rodziny, Pracy i Polityki Społecznej, „Klasyfikacja zawodów i specjalności”). |
+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Według mnie zaprezentowane definicje nie oddają w pełni roli testera oprogramowania. Z jednej strony mowa w nich o „wykwalifikowanym profesjonaliście”, czemu staram się zadać kłam w tej książce, pisząc, że „wszyscy jesteśmy testerami”, a część z nas świadomie przyjmie tę rolę. Z drugiej strony definicje te zawężają zakres odpowiedzialności współczesnego testera. Stąd też i moja definicja anno domini 2018:

Tester to osoba kontrolująca produkty procesu wytwarzania oprogramowania i dostarczająca rezultaty testowania (w tym dokumentację testerską).

Zadanie

Czy myślisz: „Potrafię być testerem”?

Wykonaj następujące czynności:

1. Znajdź kogoś, kto tworzy lub dostarcza oprogramowanie.

2. Upewnij się, że ten ktoś (nawet byt wirtualny) chciałby usłyszeć twoją opinię o swoim produkcie.

3. Przekaż swoją możliwie najpełniejszą i konstruktywną opinię o produkcie.

4. (Opcja dodatkowa) Zbierz informację zwrotną o swojej opinii. Czy była potrzebna, wartościowa, konstruktywna itd.?

Na świecie jest wiele osób, które dostarczają oprogramowanie i ucieszą się zarówno z pozytywnych, jak i mniej pochlebnych opinii. Jeśli zawiedziesz w pierwszym i drugim punkcie zadania, zastanów się, czy masz ważną cechę każdego testera, czyli umiejętność identyfikowania potrzeb.3. CYKL ŻYCIA OPROGRAMOWANIA

SDLC (software development life cycle) to w wolnym tłumaczeniu cykl życia rozwoju oprogramowania. Opisuje on kolejne fazy powstawania oprogramowania. Jest to skomplikowany proces przetworzenia potrzeby użytkownika na produkt i utrzymywania tego produktu aż do jego wycofania. W większości faz cyklu życia oprogramowania znajdziemy zadania związane z zapewnieniem jakości i testowaniem. Formalny opis nie zagwarantuje powstania produktu wysokiej jakości, na pewno jednak pomoże usprawnić jego wytwarzanie. Jest to szczególnie ważne w dzisiejszych czasach, gdy od tworzonego oprogramowania pośrednio i bezpośrednio może zależeć ludzkie życie. Dlatego opracowuje się procesy, metody i metodyki wytwarzania oprogramowania i zarządzania nim, które próbują opisać ten skomplikowany mechanizm tworzenia i utrzymania oprogramowania.

Skutki niepowodzenia projektu informatycznego mogą być różne i nie muszą się ujawniać tylko w czasie wytwarzania oprogramowania. Niektóre konsekwencje będą widoczne dopiero w późnych fazach użytkowania oprogramowania. Proces w tym przypadku nie tylko pomaga zadbać o odpowiedni odbiór produktu, lecz ma także zagwarantować niezawodne działanie w długim okresie jego użytkowania.

Mówiąc o procesie wytwórczym, mamy na myśli czynności, które trzeba wykonać, by przekształcić pomysł w produkt, czyli oprogramowanie. SDLC ma szerszy zakres. Jak widać to na rys. 3.1, uwzględnia zadania składające się na proces wytwarzania oraz inne aspekty, takie jak definiowanie pomysłu i jego rozwój, użycie i utrzymanie oprogramowania czy jego wycofanie. W całym procesie możemy wyróżnić dziesiątki faz, zaangażowanych ról, produktów i półproduktów. Przybliżę je, powołując się na popularne w kręgach testerskich źródła wiedzy.

Rys. 3.1. Cykl życia rozwoju oprogramowania

Zdefiniowane metodyki wytwarzania oprogramowania zazwyczaj służą do ujęcia w reguły samej fazy tworzenia oprogramowania i osiągnięcia większej przewidywalności w kwestii czasu i kosztów dostawy oprogramowania. Opisy takich metod jak model kaskadowy, model V, podejścia iteracyjne, DSDM, RUP, RAD, Scrum, XP pomijam. Nigdy w swoim zawodowym życiu nie spotkałem organizacji, która wdrożyłaby metodę w formie zdefiniowanej przez jej twórcę. Każdy z modeli, jaki widziałem, był daleko idącą modyfikacją wersji źródłowej. Czasami była to karykatura oryginału, a czasami praktycznie nowa metoda, będąca kolażem wielu innych podejść. Wychodzę z założenia, że dowolne metody powinny stanowić jedynie inspirację do stworzenia czegoś własnego i dopasowanego do naszych potrzeb. Można powiedzieć, że każda organizacja ma własną metodę i nie da się ich wszystkich opisać. Pewnym uproszczeniem byłoby przedstawienie reprezentantów metod, ale to można znaleźć w dziesiątkach publikacji na temat samych metod. Idąc na skróty, opisuję więc fazy uniwersalnego cyklu życia oprogramowania bez wskazania na konkretną metodę czy metodykę.

3.1. Pomysł (potrzeba)

Stare przysłowie mówi: „Potrzeba matką wynalazków”. Wytworzenie oprogramowania zaczyna się od koncepcji. Głównym celem całego procesu będzie zrealizowanie pomysłu, to znaczy przekucie go na działające oprogramowanie. Dobry pomysł zaspokaja potrzebę dużej grupy ludzi. Czasami jednak dobra koncepcja wywołuje zupełnie nową, nieuświadomioną wcześniej potrzebę lub zachciankę. Jeśli tak nie jest, to aby produkt odniósł sukces, poza powodzeniem samego projektu wytworzenia oprogramowania, konieczne są również reklama i marketing. Czy uda się nam przekonać konsumentów, że produkt, którego nigdy nie widzieli i nie chcieli, jest im naprawdę potrzebny?

Głównym udziałowcem tej fazy SDLC będzie pomysłodawca. Może to być klient, który firmie wytwórczej zleca wytworzenie oprogramowania, lub pracownik firmy odpowiedzialny za rozwój jej portfolio. Jego obowiązkiem jest definiowanie nowych produktów czy usług, które mogą być świadczone na rynku.

--------------------------------------------------------------------------------------------------------------------------------------------------
Klient, zlecający, sponsor
Wymienione terminy, jak i wiele innych, będziemy stosować na określenie osób, które mają pomysł lub pomagają definiować pomysł do implementacji.
--------------------------------------------------------------------------------------------------------------------------------------------------

Pomysł nie bierze się z niczego. Zazwyczaj wynika z doświadczenia i wiedzy pomysłodawcy, jest także pochodną wielu analiz i wcześniejszych prób. Idee – nawet najbardziej rewolucyjne i śmiałe – nie są same w sobie fundamentem przyszłego produktu. Droga od koncepcji do celu jest długa i kręta. Wcześniej zdefiniowany pomysł zostanie zmodyfikowany do tego stopnia, że może w niczym nie przypominać pierwotnej koncepcji.

------------------------------------------------------------------------------------------------------------------------------
Wytwórca, dostawca, producent
Terminy te pojawiają się przy okazji organizacji wytwarzania oprogramowania i określają zazwyczaj firmę, która je dostarcza.
------------------------------------------------------------------------------------------------------------------------------

Musimy jeszcze zastanowić się nad mocą sprawczą i odpowiedzialnością poszczególnych ról w procesie wytwórczym. Czasami mówi się, że użytkownicy psują oprogramowanie. Posługując się jednak systemem na poziomie interfejsu, naprawdę trudno go zepsuć. Prawda jest taka, że system jest już zepsuty, kiedy użytkownik zaczyna z niego korzystać. Zawiera defekty, które ujawniły się po jego uruchomieniu.

Podobnie możemy zdefiniować możliwości pomysłodawców, którzy stanowią siłę napędową projektu. Mamy więc do czynienia z wynalazcami oraz odkrywcami. Odkrywca znajduje rzeczy, które już istnieją i jedynie pokazuje do nich drogę. Wynalazca to z kolei ktoś, kto tworzy coś unikatowego, co do tej pory przez nikogo nie było jeszcze zrealizowane. Te dwie osoby (lub zespoły) przejdą dwie różne drogi do komercyjnych premier swoich odkryć i wynalazków.

Odkrywca opiera się zazwyczaj na gotowych rozwiązaniach i korzysta z narzędzi zdefiniowanych przez kogoś innego znacznie wcześniej. Jego przewaga nad innymi wynika przede wszystkim z umiejętności dostrzegania nowych rozwiązań tam, gdzie pozostali widzą jedynie przeszkody. Przykładem odkrywcy jest Krzysztof Kolumb, który był wystarczająco odważny (głupi?), by zmierzyć się z oceanem i odkryć nowy ląd. Dzięki wysiłkowi, który podjął, pokazał ludziom, że istnieje nowy świat. Czy świat ten powstał, kiedy marynarze Kolumba go dostrzegli? Oczywiście, że nie. Był tam od milionów lat, ale to on miał odwagę po niego sięgnąć.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Odkrywca Ameryki
Osobnym zagadnieniem jest to, czy Kolumb rzeczywiście był pierwszy. Niektórzy historycy kwestionują nawet jego obecność tam. Nie zmienia to faktu, że każdego odkrywcę można zakwestionować i próbować wskazać kogoś, kto był odkrywcą „prawdziwym”. Póki spory historyków nie przycichną, ważne dla nas jest to, kto jako odkrywca funkcjonuje w masowej świadomości.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Projekt prowadzony dla „odkrywcy” nie ma charakteru innowacyjnego i może polegać na wzorcach czy przykładach z przeszłości. Może być realizowany wolniej, ponieważ opiera się na rozwiązaniach już znanych. Poufność danych i ich krytyczność nie są głównymi problemami. Odwrotnie jest w projektach „wynalazców”, gdzie wyprzedzenie konkurencji o dzień ma znaczenie. Liczy się również utrzymanie informacji o projekcie możliwie najdłużej w tajemnicy. Czasami trzeba definiować pewne rzeczy zupełnie na nowo.

Wynalazca telefonu dzięki swojemu pomysłowi wpłynął na losy świata, jego rozwój i globalizację, jaką dziś obserwujemy. Komercyjne zastosowanie wynalazku uczyniło go również człowiekiem bardzo bogatym.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wynalazca telefonu
Do dziś istnieje wiele kontrowersji na temat rzeczywistego wynalazcy telefonu. Wynalazek jednak przypisuje się temu, kto go opatentował, czyli Alexandrowi Grahamowi Bellowi.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

W projektach mamy do czynienia zarówno z odkrywcami, jak i wynalazcami. Ludzie, którzy znajdują sposób optymalizacji w istniejących już produktach, usługach czy procesach, są raczej odkrywcami. Ci, którzy definiują zupełnie nowe koncepcje są wynalazcami. We współczesnym świecie trudno o jednego autora danej koncepcji, więc częściej zdarza nam się mówić o zespołach.

Zespoły lub osoby będące wynalazcami w dużo większym zakresie muszą szukać sposobów, które pozwolą testować pomysły. Jednym z nich jest prototypowanie lub jego uproszczona wersja – pretotypowanie. Jest to tworzenie niskobudżetowego modelu danego produktu (lub usługi), aby zweryfikować jego przydatność i potencjalnych użytkowników. Dzięki takiemu podejściu już we wczesnych fazach definiowania pomysłów możemy wyselekcjonować te z nich, które są skazane na porażkę. Oczywiście często się zdarza, że weryfikacja pomysłu jest pomijana lub zawodzi i wtedy otrzymujemy tak epokowe wynalazki, jak żelazko z funkcją podgrzewania posiłków czy poduszka ze sztuczną ręką do przytulania.

Ta pierwsza faza nazywana jest czasami inicjalizacją. Jej pomyślne zakończenie, czyli zdefiniowanie pomysłu, jest pierwszym krokiem do zamiany bytu niematerialnego na materialny.

3.2. Rozwój koncepcji

Jeśli pomysł wejdzie w tę fazę, zazwyczaj oznacza to, że pojawił się sponsor, czyli człowiek gotowy zainwestować swój czas i pieniądze, by doprowadzić do wytworzenia produktu oraz jego komercyjnej premiery. Sponsor będzie zainteresowany przede wszystkim finansowym zyskiem ze sprzedaży. Aby mu go zagwarantować, potrzebna będzie również szeroka analiza przyszłego produktu.

Podstawowym elementem dla sponsora będzie ROI (return of investment), czyli zwrot z inwestycji. Relacja kosztów wytworzenia do potencjalnych zysków pomaga w podejmowaniu decyzji. Skuteczność działań tej fazy będzie zauważalna dopiero w końcowych fazach procesu wytwórczego. Musimy się pogodzić z faktem, że podjęcie decyzji odbywa się w niepewnych warunkach, gdy jeszcze nie wszystkie informacje ważne dla naszego biznesu są dostępne. Dodatkowo musimy uwzględnić niebezpieczeństwa, które mogą się pojawić w otoczeniu projektu wytwórczego. Wszelkiego rodzaju ryzyko będzie pochodziło nie tylko z zewnątrz (chodzi o takie aspekty, jak rynek czy polityka danego kraju). Głównym źródłem ryzyka w projekcie jest przede wszystkim czynnik ludzki. Decydujące będą dobór osób o właściwych kompetencjach oraz odpowiednie motywowanie do pracy, które stanowią o subtelnej, acz znaczącej różnicy między nieudanym a udanym projektem.

-------------------------------------------------------------------------------------------------------------------------------------------------------------
Start-up
Firma lub projekt, które cechują się niskobudżetowymi działaniami, dużym ryzykiem niepowodzenia przedsięwzięcia, ale też szansą na duży zwrot z inwestycji.
-------------------------------------------------------------------------------------------------------------------------------------------------------------

Absolutnie konieczne w naszych rozważaniach jest zdefiniowanie granic systemu, a przy tym granicy jego wykonalności. Czy produkt, który mamy na myśli, jest możliwy do zrealizowania i czy zadania, które ma wykonać, są osiągalne? Możemy założyć, że wytwarzamy start-up dla 5 mld użytkowników, ale czy nakłady finansowe na jego wytworzenie i zweryfikowanie poprawności nie będą zbyt duże? Zwłaszcza gdy zestawimy je z prawdopodobieństwem powodzenia biznesowego, mierzonego liczbą kupujących nasz produkt lub korzystających z niego. Jeżeli wiemy, że na świecie nie ma nawet tylu aktywnych użytkowników komputerów, to czy rzeczywiście możemy liczyć na aż tak liczną grupę odbiorców? Mówimy tu o zasięgu od najmłodszych po najstarszych przedstawicieli naszego gatunku. Część z nich zamieszkuje co prawda uprzemysłowione tereny, ale część żyje w buszu, nie mając dostępu do elektryczności. Studium wykonalności (feasibility study), które określa realność takiego systemu, powie nam, co jesteśmy w stanie osiągnąć, a czego nie. Nałożone ramy pozwolą nam również na oszacowanie kosztów związanych z wytworzeniem produktu.

3.3. Planowanie

Niektóre czynności w procesie wytwarzania oprogramowania są jednorazowe albo powtarza się je niezmiernie rzadko. Drugą grupę stanowią czynności wielokrotnie powtarzane podczas całego cyklu życia. Teoretycznie zaplanowanie projektu informatycznego jest czynnością jednorazową, ale przeplanowanie, redefiniowanie lub też dostosowanie się do nieoczekiwanych (lub oczekiwanych, acz niepewnych) zdarzeń jest już czynnością ciągłą.

Zakładamy, że produkt wytwarzany jest w rzeczywistym środowisku i mają na niego wpływ niezliczone czynniki zewnętrzne i wewnętrzne. W okresie wstępnego planowania mamy niepełne dane o możliwym przebiegu procesu tworzenia. Dane te będą spływały dopiero w trakcie jego realizacji. Jeśli informacje wymagają od nas zmiany planów, to musi zostać uruchomiony mechanizm pozwalający ponownie oceniać zasoby lub zarządzać czasem dostawy. Napływ informacji będzie ciągły, zmiany w planie również będą ciągłe.

Podczas planowania znany obszar pokrywamy estymatami o dużej dokładności. Dla obszaru nieznanego lub też dla ryzyka przyjmujemy założenia, które są jedynie przybliżonymi szacunkami. Elementami, które jako klienci chcielibyśmy uznać za stałe, są czas dostawy i budżet. Zakładamy datę premiery naszego produktu i do tego dostosowujemy mechanizm marketingowy, promocyjny czy też sprzedażowy. Oczywiste jest również, że raz zdefiniowany koszt produktu będziemy chcieli utrzymać do końca. Nikt nie lubi rozczarowań. Jeśli towar na półce opatrzony jest ceną X, to nie zakładamy, że przy kasie zapłacimy za niego 2X. Co więcej, bardzo się ucieszymy, jeśli otrzymamy rabat. Podobnie jest z projektem informatycznym – gdy sponsor zaakceptuje cenę Y, trudno mu będzie zrozumieć, że mimo naszej głębokiej analizy na końcu przyjdzie mu zapłacić więcej. Oczywiście w uzasadnionych przypadkach, np. losowych, będzie w stanie przyznać dodatkowe środki, ale nie może to być więcej niż założony na początku bufor. Wskazuje on na opłacalność lub nieopłacalność inwestycji.

Sytuację, w której sponsor inwestuje dużo ponad założony wcześniej budżet, można porównać z postępowaniem gracza w kasynie, który im więcej przegrywa, tym bardziej chce się odegrać. Nie ma to nic wspólnego z logiką, a wynika z głębokiego przekonania, że szczęście musi się wreszcie do nas uśmiechnąć. Sponsor może więc przeinwestować, ignorując wstępne i aktualne analizy, i na siłę doprowadzić projekt do niekoniecznie szczęśliwego finału.

Planowanie i poprawa planowania będzie więc umiejętnym żonglowaniem zasobami i terminami, tak by przy założonym budżecie i czasie dostarczyć wartościowy produkt.

Aspekt planowania zostanie szerzej omówiony w odniesieniu do samego testowania oprogramowania.

3.4. Analiza wymagań

Jest to faza, w której analityk (lub grupa) musi przekształcić pomysł w wymagania wobec systemu. Opierając się na wcześniejszych fazach oraz ideach pomysłodawcy, musimy stworzyć model lub dokument opisujący, jak produkt będzie wyglądał i działał po powstaniu. Zazwyczaj mówimy o wymaganiach funkcjonalnych, czyli zestawie funkcji danego produktu. Czasami są to również charakterystyki niefunkcjonalne, takie jak użyteczność (usability) czy wydajność (efficiency).

W fazie analizy wymagań jest nadawany bieg procesom lub czynnościom ciągłym w procesie. Zaczynamy mówić o inżynierii wymagań jako o pozyskiwaniu wymagań i zarządzaniu nimi. Określa się też, przynajmniej wstępnie, mechanizm wprowadzania zmian, nazywany powszechnie procesem zarządzania zmianą.

+--------------------------------------------------------------------------------------------------------------+
| Definicje z zakresu analizy wymagań |
+--------------------------------------------------------------------------------------------------------------+
| Wymaganie to warunek oraz umiejętność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia celu. |
| |
| Proces inżynierii wymagań obejmuje zidentyfikowanie, przeanalizowanie i zatwierdzenie wymagań wobec systemu. |
| |
| Zarządzanie wymaganiami to proces zarządzania zbieraniem i zmianami w wymaganiach podczas tworzenia systemu. |
+--------------------------------------------------------------------------------------------------------------+

Grupa narzędzi możliwych do użycia podczas definiowania wymagań jest bardzo ograniczona. Służą one do pozyskania wymagań przez współpracę ze zleceniodawcą, np. możemy przeprowadzić wywiad z klientem lub poprosić o wypełnienie kwestionariusza. Ale możemy też zorganizować burzę mózgów, podczas której zbierzemy wszystkie wymagania (również dotychczas ukryte).

Notacja wymagań może być bardzo sformalizowana i oparta na normach, takich jak IEEE 1233 czy IEEE 830. Wymagania mogą być również przypadkami użycia lub też historyjkami użytkownika (user stories). Taki zapis zorientowany na użytkownika opisuje za pomocą przykładów lub scenariuszy, w jaki sposób produkt będzie używany przez jego docelowych odbiorców.

Błędy popełniane w tej ważnej fazie prowadzą do wytworzenia produktu, który nie spełnia oczekiwań klienta. Musimy pamiętać, że przekształcenie potrzeb w produkt musi angażować obie strony – klienta i wytwórcę. Zdefiniowanie odpowiedniego kanału komunikacyjnego umożliwi im pełniejsze zrozumienie. Staramy się przez to wyeliminować mnogość problemów, takich jak np. nieprecyzyjne wymagania umożliwiające szeroką interpretację.

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Interpretacja
Największym niebezpieczeństwem w procesie wytwarzania oprogramowania jest możliwość wieloznacznego interpretowania zapisów – w zależności od wiedzy, doświadczenia czy nastroju. Podstawowym zadaniem w całej inżynierii wymagań jest więc wyeliminowanie niejednoznaczności. Uważa się, że jeśli osoba o umyśle ścisłym otrzyma niejednoznaczne zapisy wykonane przez ludzi o podejściu bardziej biznesowym, to ich interpretacja będzie zawsze różna.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Spotkamy się również z wymaganiami, które mogą być wewnętrznie sprzeczne. Dzieje się tak, jeżeli zachowanie produktu jest opisane w różny sposób w różnych miejscach dokumentu. Tworząc takie zapisy, balansujemy na krawędzi przepaści, którą jest niepowodzenie projektu.

Faza analizy wymagań będzie z naszego punktu widzenia istotna dla końcowego zadowolenia klienta. Musimy pamiętać, że nawet gdy funkcjonalność wydaje się skończona i kompletna, to wymagania mogą nie być do końca określone. Zawsze pozostaje margines wymagań niezdefiniowanych, ważnych dla funkcjonowania biznesu zlecającego. Analityk biznesowy musi więc antycypować potrzeby klienta i pomóc mu je określać.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Nazwa odpowiedzialnych za wymagania
Wspomniany analityk biznesowy to tylko jedna z wielu nazw osób odpowiedzialnych za pomoc w określeniu wymagań. W literaturze przedmiotu spotyka się również określenie „specjalista inżynierii wymagań”.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

3.5. Projektowanie

Projektowanie oprogramowania to etap przekładania wymagań funkcjonalnych na dokument projektowy. Właściwym i często używanym porównaniem jest odniesienie do budownictwa. Spisane potrzeby i wymagania klienta architekt musi przełożyć na projekt domu. Oczywiście pomijamy tutaj architektów artystów, mówimy o architektach rzemieślnikach. Ich celem jest sporządzenie szczegółowego opisu domu zgodnie z rządzącymi w tym obszarze regułami, a nie tworzenie nowych wartości. Każdy chce mieszkać w pięknym otoczeniu, a nie każdy chce mieszkać oryginalnie, co często wiąże się z pewnym eksperymentem (również kosztowym). Projekt domu docelowo ma zawierać rysunki techniczne z miarami i informacjami o materiałach. Musi uwzględniać nośność budynku, możliwe naprężenia związane z jego obciążeniem i wiele innych zmiennych istotnych dla powodzenia i bezpieczeństwa inwestycji. Projekt jest więc w tym przypadku technicznym i z punktu widzenia zlecającego mało przydatnym półproduktem. Jeśli nawet klient potrafiłby go zrozumieć, to gdyby nie musiał mieć planu architektonicznego, to zapewne nigdy by go nie kupił. Dobry projekt jest jednak istotny dla budowlańców, by mogli cegła po cegle zrealizować wizję klienta. Mam nadzieję, że czytelnik widzi tutaj analogię: budowlaniec to programista, architekt to projektant, a kierownik budowy to menedżer projektu.

W projektowaniu oprogramowania możemy wyróżnić wiele faz i wiele produktów. Mogą być to fazy powiązane z wytworzeniem półproduktów, takich jak koncepcja projektu (conceptual design), projekt wstępny (preliminary design) czy projekt szczegółowy (detail design). Każdy z nich odgrywa podstawową rolę dla powodzenia projektu. Zła konstrukcja oprogramowania może powodować konieczność jego przebudowania, a to zwiększa koszty wytworzenia. Warto pamiętać, że na tym etapie pojawią się pierwsze przesłanki do zaciągania długu technologicznego pokazanego na rys. 3.2. Oszczędności w tej fazie przełożą się na dodatkowe koszty wytworzenia, a nawet załamanie się całego projektu.

Rys. 3.2. Dług technologiczny wg Philippe Kruchtena

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Dług techniczny (technologiczny)
Dług zaciągamy zawsze, gdy w projektach informatycznych idziemy na skróty, tworzymy rozwiązania nieskalowalne i przeciwstawiamy sobie pojęcia wysokiej jakości i szybkiej dostawy. Budowanie oprogramowania, w którym od początku nie dbamy o architekturę systemową lub o kodowanie, powoduje wzrost naszego zadłużenia. Koszty te zazwyczaj nie są widoczne w aktualnej sytuacji, ale zostaną zdiagnozowane na późniejszych etapach SDLC.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

3.6. Rozwój aplikacji

Elementy zdefiniowane we wcześniejszych fazach są przenoszone do oprogramowania w fazie jego rozwoju, czyli powstawania kodu źródłowego. Oczywiście oprócz przenoszenia funkcjonalności część wysiłku niestety poświęcimy również na nieświadome wprowadzanie do oprogramowania wcześniej popełnionych błędów.

W ramach rozwoju aplikacji tworzymy produkt. Nabiera on realnych kształtów i powoli staje się (mamy nadzieję) oczekiwanym rozwiązaniem. W tej fazie bardzo ważna jest współpraca wytwórców i osób zlecających wytworzenie. Zaangażowanie tych drugich i wola rewidowania produktu na wczesnych etapach jego tworzenia pozwala wprowadzać zmiany i poprawki, które nakierują go na właściwe tory. Na końcu tych torów jest wspólne zadowolenie wszystkich stron. Programiści tworzą dobry produkt, a klient otrzymuje to, czego naprawdę potrzebował.

3.7. Testowanie

W dużym uproszczeniu jest to dogłębna analiza produktu pod kątem dopasowania go do potrzeb klienta – czy klient otrzyma(ł) produkt, który zamawiał. Książkę poświęcam właśnie temu zagadnieniu, więc czytelnik musi jeszcze trochę poczekać na rozwinięcie tego tematu. Należy jedynie wspomnieć, że z testowaniem jest jak z planowaniem. Zacznie się możliwie najwcześniej i zakończy wraz z końcem życia aplikacji.

3.8. Wdrożenie

Przekazanie produktu zleceniodawcy to nie jest tylko prosta seria zadań do wykonania. Nie ograniczamy się do instalacji w środowisku produkcyjnym i szkoleń dla użytkowników oprogramowania. Wiele decyzji musi zostać podjętych i wiele dodatkowych działań zrealizowanych, abyśmy świadomie zdecydowali o wdrożeniu aplikacji. Konsekwencje wcześniej podjętych działań widać właśnie w tej fazie. Wdrożenie to w przypadku wielu projektów jedna z ostatnich czynności, a udany odbiór może rozpocząć celebrowanie sukcesu.

Przejście na nowy system jest ostatnim etapem w cyklu rozwoju oprogramowania. Firma zaczyna korzystać z nowego programu, co może się odbywać jednocześnie z korzystaniem ze starego. Do poprawnego działania systemu niezbędne mogą być pewne zmiany lub aktualizacje, w tym m.in. usuwanie awarii sprzętu, poprawa i korygowanie defektów, właściwe zabezpieczenie oprogramowania oraz szkolenie pracowników i administratorów z obsługi systemu. Od tego momentu system zaczyna stawać się integralną częścią codziennej pracy zleceniodawcy.

3.9. Użycie i utrzymanie

Każdy młody programista wybierając swój zawód, dostrzega daleką perspektywę kreatywnej pracy twórczej, która ma na celu wytworzenie produktu. Jest oczywiste, że duża część z nich będzie tej szansy pozbawiona. Okazuje się, że istotne stają się projekty utrzymania oprogramowania, a nie jego wytwarzania. Faza rozwoju aplikacji to zazwyczaj 10% okresu jej życia. Oprogramowanie jest dużo częściej utrzymywane, co w uproszczeniu można by nazwać dostosowywaniem go do nowych i ciągle zmieniających się potrzeb rynku. Tak więc nie ma tworzenia czegoś od podstaw, a jest jedynie żmudne, odtwórcze zrozumienie pracy innego programisty i próba jej poprawienia.

Ważni w tej fazie są jednak użytkownicy. To oni z radością, przykrością lub obojętnością posługują się dostarczonym oprogramowaniem. Oni są też wyzwalaczem zmian i modyfikacji w oprogramowaniu. Zdarza im się znaleźć defekt, który przeszedł przez sito testów, lub też stwierdzić brak funkcji istotnej dla ich pracy z aplikacją. Oni więc, korzystając z pomocy helpdesku, zgłaszają problemy, które wspomniani tu programiści muszą skorygować. Użytkownicy mogą dostrzegać błędy popełnione w fazie analizy, podczas identyfikowania pewnych potrzeb. Mogą również wskazywać, co można zrobić, by produkt jeszcze lepiej wspierał ich pracę. Tu również, po zatwierdzeniu zmian przez sponsorów, pojawi się konieczność modyfikacji dokonywanej przez programistów.

Użycie i utrzymanie stanowi ważną część życia aplikacji. Jest to także bardzo trudne wyzwanie dla testerów.

3.10. Emerytura. Koniec życia

Wszystko, co ma początek, ma też koniec.

Wyrocznia, „Matrix Rewolucje”

Posługuję się znanym cytatem, by wprowadzić odrobinę patosu na koniec rozdziału o SDLC. Pomysł raz zdefiniowany, rozwijany, implementowany – z sukcesem lub nie – na końcu musi odejść. Koniec życia aplikacji to zazwyczaj także koniec oferowanego dla niej wsparcia lub też wyparcie jej przez nowszą wersję. Przykładów takiego rozwiązania można znaleźć mnóstwo, wystarczy przypomnieć los systemu operacyjnego Windows XP i jego koniec spowodowany pojawieniem się Windows 7 czy późniejszego 8, 10 itd. Być może jest na świecie kilku zapaleńców, którzy uznają, że FireFox w wersji 1.0 nigdy nie zostanie pobity przez nowsze wersje. Stanowią oni jednak nieliczącą się mniejszość, która w końcu będzie musiała migrować do nowszej wersji albo wymrze w sposób naturalny.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Migrować
Migracja jest popularnym w świecie informatycznym pojęciem. Migrujemy do nowszej wersji istniejącego oprogramowania albo do nowego narzędzia. Migrujemy również nasze dane do nowego systemu.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Wycofywana aplikacja z zasady nie powinna być permanentnie usuwana, gdyż nigdy nie wiadomo, czy kiedyś się jeszcze nie przyda. Przechowuje się ją, na wypadek gdyby ta aktualna aplikacja zawiodła.

Oprogramowanie wycofywane zastępowane jest nowszą wersją lub inną aplikacją. W obu przypadkach wyzwaniem dla zespołu wdrożeniowego jest odpowiednia migracja danych do nowego systemu czy zweryfikowanie poprawności działania nowego oprogramowania w porównaniu do starej wersji.

3.11. Inne fazy

W cyklu życia są jeszcze inne fazy, działania i poddziałania, których nie opisałem, co nie zmienia faktu, że w niektórych projektach i dla niektórych osób będą to ich podstawowe zadania w całym procesie. Zaliczają się do nich m.in.:

• negocjacje kontraktu – zdefiniowanie, za jaką cenę produkt zostanie wytworzony i do czego zobowiązują się obie strony;

• zarządzanie ryzykiem – ciągłe definiowanie, monitorowanie i zapobieganie ryzykom lub ich skutkom (minimalizowanie ryzyka jest pracą w ramach szeroko pojętego zarządzania jakością);

• zarządzanie zgłoszeniami – standardowe zarządzanie defektami oraz zmianami;

• zapewnienie jakości – czynność związana z definiowaniem procesów, procedur oraz wzorców dokumentacji.4. TESTOWANIE

4.1. Definicja testowania

Każdy obszar, w którym przyjdzie ci czytelniku kiedykolwiek pracować, powinien zostać przez ciebie zdefiniowany. Definicja pomaga odpowiedzieć sobie na pytanie: „Co należy do moich obowiązków?” Światłe głowy starają się ciągle określić, czym jest testowanie, więc twoja praca powinna być prosta. Tak niestety nie (do końca) jest. Jak w wielu innych obszarach, również w testowaniu są sprzeczne interesy, różne szkoły, organizacje i podejścia do problemu. Każda z nich linę definicji próbuje przeciągnąć na swoją stronę, jednocześnie wmawiając nam, że druga strona kompletnie się myli i nie ma (bo nie może mieć) racji. Co gorsza, niektóre organizacje zrzeszające testerów same sobie przeczą w definiowaniu testowania. Inni z kolei definiują testowanie tak szeroko, że trudno je odróżnić od wytwarzania oprogramowania. Przypomina to nieco targ, na którym przekupki próbują przelicytować konkurencję argumentami, że „Moje jest lepsze od innego, bo ma więcej”. Każdy będzie nam wmawiał, że to jego definicja jest najpełniejsza lub jedyna poprawna. W chaosie komunikacyjnym tester lub adept testowania musi poznać ofertę wielu organizacji definiujących testowanie, aby wybrać własną drogę.

W takim rozgardiaszu ludzie i firmy funkcjonują od lat. W rezultacie niektórzy pracodawcy nie widzą różnicy między testowaniem a definiowaniem procesów, a testerzy w ich firmach są nazywani specjalistami ds. zapewnienia jakości, inżynierami jakości czy też QA-owcami (od ang. quality assurance – czyli zapewnianie jakości).

Testowanie doczekało się pewnego standardu, ale nie doczekało się standaryzacji, co niekoniecznie musi być problemem. Musimy definicję testów wyłuskać z tego, co aktualnie mamy, a także skorzystać z wiedzy pobocznej. Wspomniane zapewnienie jakości, programowanie oraz zarządzanie projektami mają swoje definicje. Testowanie próbuje funkcjonować na styku tych obszarów, możemy więc wykorzystać je do określenia granic testowania.

Każdego z nas prędzej czy później czeka konieczność znalezienia odpowiedzi na pytanie, czym jest dla niego testowanie. Pytań może być wiele, a odpowiedzi nie będą jednoznaczne.

• Czy testowanie jest szukaniem defektów?

• Czy testowanie jest weryfikacją poprawności działania funkcjonalności?

• Czy testowanie jest używaniem i ocenianiem?

• Czy testujemy po to, aby pokazać, że coś działa?

„Ostateczna definicja testowania” jest tworem mitycznym i prawdopodobnie nigdy nie uda się jej sformułować. Przyjdzie dzień, w którym powiemy sobie: „Tak, mam TO! Określiłem definicję testowania”. Niestety, po upływie pewnego czasu, po nowych doświadczeniach uświadomimy sobie, że jednak „Nie, to nie było TO”. Może w takim razie nie warto się męczyć? Może warto popłynąć z nurtem? Każdy kolejny pracodawca przedstawi własne postrzeganie testowania, definiując zakres obowiązków na naszym stanowisku, a my po prostu zaakceptujemy to, co otrzymamy. Jest to jakieś rozwiązanie, konformistyczne do granic, ale zawsze rozwiązanie.

Część z nas zostanie na wysokim poziomie ogólności i uzna, że „testowanie jest czynnością w cyklu życia oprogramowania” albo „testowanie jest procedurą wykonywania testów” lub inną nic nieznaczącą zbitką słów. Definicje ogólne mają mniejszą szansę, by się zdezaktualizować, bo nie niosą żadnej informacji ani niczego konkretnie nie opisują. Mamy też szansę łatwo znaleźć „wyznawców” naszej definicji. Analizując masowego odbiorcę i informacje przekazywane mu przez media, łatwo możemy określić własne zasady formułowania definicji. Musi to być krótki komunikat, zrozumiały i docierający do największego grona. Im więcej w nim konkretów, tym większe pole do negowania i do zwykłej polemiki.

„Testowanie jest ważną częścią każdego procesu wytwórczego”. Lepiej nie mówić „najważniejsze”, bo łatwo zantagonizować środowisko. Ta definicja nie jest realnie definicją, ale skoro my powiemy, że nią jest, to niech nasi oponenci męczą się, by ją negować.

„Testowanie jest jakością” to bzdura dla wszystkich, którzy coś o testowaniu wiedzą, ale dla nieświadomych brzmi jak hasło wyborcze. Nie ma niczego znaczyć, ma być łatwe do zapamiętania.