blog.testowka.pl

Archiwum wiadomości z Luty, 2011

QA vs Tester

opublikowany przez 17, Lut, 2011, w kategoriach Praca, Testowanie, Zarządzanie

Przeglądając ostatnio oferty pracy zauważyłem, że większość firm szuka QAów a nie testerów. Co jest grane? Czyżby nagle wszyscy zaczęli zapewniać jakość zamiast testować oprogramowanie? Było by cudownie… Niestety, jak przyglądam się bliżej tym ogłoszeniom, to jasne staje się, że owe firmy nie szukają Quality Asurance Engineer’ów tylko zwykłych testerów, w najlepszym wypadku inżynierów testów. Nadużywanie tytułu Quality Assurance Engineer albo Specialist prawdopodobnie wynika, z tego iż mało kto tak naprawdę wie co się pod tą nazwą kryje, jednocześnie wszyscy chcą być trendy i przyciągnąć większą uwagę potencjalnych kandydatów. Wcale się nie dziwię – samemu mi było trudno znaleźć wartościowe informacje na temat QA. Często te informacje są sprzeczne lub niekompletne.

Problematyczne może być także przetłumaczenie tego terminu z języka angielskiego na polski – próby typu „Inżynier Jakości”, „Inżynier Zapewniania Jakości” nie brzmią zbyt dobrze, dlatego osobiście wolę pozostać przy QA.

W takim razie czym jest Quality Assurance? Na pewno Quality Assurance nie jest tożsame z testowaniem oprogramowania. W najlepszym wypadku proces testowy może być zaliczany jako część procesu Quality Assurance. Głównym celem QA jest zapobieganie powstawaniu błędów, w przeciwieństwie do testowania oprogramowania, którego głównym zadaniem jest detekcja błędów – weryfikowanie jakości. QA wykorzystuje wiele narzędzi w celach prewencyjnych, między innymi zajmuje się organizacją i kontrolą procesu wytwarzania oprogramowania, buduje środowiska oraz narzędzia wspierające testowanie i kontrole jakości, poszukuje i wprowadza „dobre praktyki” by zwiększać efektywność i poprawiać jakość i dopiero jako jeden z wielu elementów pojawia się weryfikacja jakości produktu, która może zostać przeprowadzona poprzez testowanie oprogramowania.

Z pojęciem Quality Assurance związanych jest bardzo wiele innych niezmiernie istotnych terminów takich jak CMMI czy normy ISO. To właśnie zapewnienie osiągnięcia wspomnianych norm jest dosyć często głównym celem procesu QA.  Quality Assurance to także praca z ludźmi, zarządzanie wiedzą, organizacja pracy, doskonalenie umiejętności pracowników etc.

Powyżej starałem się wyjaśnić podstawowe różnice pomiędzy QA a testerami – jest to tylko moja własna interpretacja tego co znajduje się w encyklopediach, poradnikach, normach itp. niemniej jednak czytając różne artykuły, blogi etc. powyższa interpretacja coraz bardziej się weryfikuje i klaruje także postanowiłem się nią podzielić.

Jeśli ktoś ma inne zdanie na temat QA to zapraszam do dyskusji.

8 komentarzy więcej...

No i gdzie ta jakość?

opublikowany przez 16, Lut, 2011, w kategoriach Agile, Testowanie, Zarządzanie

Złapałem się na tym, że ostatnimi czasy piszę głównie o zarządzaniu projektami, agile, procesach wytwarzania oprogramowania itp., a coraz mniej skupiam się na testowaniu. W podtytule tego bloga jak zapewne zauważyliście jasno jest napisane: „Blog o jakości oprogramowania”. Gdzie ta jakość?

Odpowiedź jest prosta – wszędzie. To, że skupiam się głównie na procesach wytwarzania oprogramowania, zarządzania tymże wytwarzaniem oprogramowania oraz aspektach bardziej miękkich z tym związanych wynika z tego, iż doszedłem do wniosku, że szukanie bugów jest bez sensu. Tak! (Jak ja lubię strzelać sobie zawodowego samobója – najpierw, że testerzy są niepotrzebni, teraz, że szukanie błędów jest bez sensu…). Testowanie oprogramowania nie tworzy żadnej wymiernej wartości w projektach informatycznych, wynika to między innymi z tego, że jakości samej w sobie nie da się zmierzyć – często ciężko jest nawet zdefiniować jakość. Znalezione błędy muszą być poprawione – i przeważnie zostają poprawione, po czym powinny zostać sprawdzone i dopiero wtedy produkt może ujrzeć światło dzienne, ot i cała filozofia.

Błędy kosztują – wszyscy doskonale o tym wiedzą, ale większość komentarzy skupia się na kosztach błędów, które nie zostały wykryte. Warto czasem spojrzeć na temat z drugiej strony – znalezione błędy też kosztuję. Każdy znaleziony błąd wymaga opisania, zgłoszenia, debugownia, poprawienia oraz ponownego sprawdzenia, do tego dochodzą jeszcze inne zróżnicowane w zależności od projektu i innych czynników czynności takie jak oczekiwanie na zbudowanie nowej paczki czy mergowanie zmian. To wszystko zajmuje pewną ilość czasu, a jak powszechnie wiadomo czas to pieniądz.

Skoro już wiemy, że znalezione błędy też kosztują i wiemy ile kosztują to zastanówmy się co zrobić by zmniejszyć koszty. Najprostsze rozwiązanie – nie popełniać błędów. Istnieje wiele teorii na temat tego skąd biorą się błędy, większość z nich ma wspólne elementy takie jak np. „to człowiek jest źródłem błędów”, „niepełne wymagania powodują błędy”, „ograniczona wiedza i możliwości technologiczne zwiększają prawdopodobieństwo powstawania wad”, „coraz większe skomplikowanie projektów powoduje wzrost prawdopodobieństwa pojawienia się błędów, wynikający z większej ilości możliwych scenariuszy użycia” itd.. Próbując znaleźć najprostsze rozwiązanie dochodzę, do wniosku, iż kluczem do osiągnięcia sukcesu w tym przypadku jest skupienie się na procesie i zarządzaniu tymże procesem. Zapobieganie błędom jest dużo tańsze niż ich wykrywanie i poprawianie – nie wspomnę już nawet o tym, że jeszcze droższe jest nie znalezienie błędów i ich niepoprawienie.

Dlatego właśnie ostatnio moje myśli i poszukiwania skupiają się wokół zarządzania projektami i zapewniania jakość a nie weryfikacji jakości jaką jest testowanie oprogramowania samo w sobie.

Mam to szczęście (a może właśnie pecha), że podczas swojej stosunkowo krótkiej (kilka lat) „kariery” w IT, miałem okazje pracować z kilkoma bardzo różnymi zespołami i uczestniczyć w wielu bardzo zróżnicowanych projektach dzięki czemu mam spory zasób doświadczeń na podstawie których mogę wyciągać trafne (czytaj: „sprawdzające się w praktyce”) wnioski.

Jeśli zadbamy o jakość od samego początku i każdy z członków zespołu (a także klient, zarząd etc.) będzie zaangażowany w zapewnianie jakości to możemy być pewni, iż ta inwestycja się nam zwróci.

Zapytacie pewnie o liczby, dane, w jaki sposób mogę zagwarantować, że tak właśnie jest? Nie mogę niczego zagwarantować – nie da się tego zbadać doświadczalnie, nie można zmierzyć ile pieniędzy czy czasu zaoszczędziliśmy dzięki podejściu skupiającemu się na jakości. Musicie mi uwierzyć na słowo – to działa. Zresztą nie tylko ja tak uważam. Jak pogooglujecie, poczytacie książki na temat testowania oprogramowania, zarządzania projektami etc. sami prędzej czy później dojdziecie do podobnych wniosków.

W jaki sposób dbać o jakość? Odpowiedzi są na wyciągnięcie ręki – czytajcie tego bloga, a także szukajcie innych. Ludzie i ich doświadczenia to najlepsze źródła wiedzy. Dzielcie się swoją wiedzą i przemyśleniami po to by je zweryfikować i skonfrontować z przemyśleniami innych. Na prawdę warto!

1 komentarz więcej...

Shu-Ha-Ri

opublikowany przez 07, Lut, 2011, w kategoriach Agile, Kanban, książki, Praca, Scrum, Zarządzanie

Tajemniczy tytuł Shu-Ha-Ri to zaczerpnięte z kultury japońskiej trzy poziomy doświadczenia, często używane w kontekście sztuk walki takich jak aikido. Piszę o tym, gdyż nauka sztuk walki ma zaskakująco wiele wspólnego z wdrażaniem metodologi w organizacji. Trzy poziomy doświadczenia, trzy poziomy wtajemniczenia wymuszają na uczniu stopniową, systematyczną naukę dzięki czemu eliminuje się większość błędów.

Shu – przyswojenie, zachowanie, pielęgnacja
Jest to pierwszy etap nauki, w której uczeń skupia się na opanowaniu podstawowych technik i zachowań. Termin ten oznacza także lojalność wobec jednego nauczyciela. Podczas tego etapu najważniejsze jest przyswajanie wszystkiego z największa dokładnością bez możliwości wprowadzania jakichkolwiek zmian. W tej fazie nieistotne są powody stosowania technik, najważniejsze jest opanowanie do perfekcji podstaw. (Przypomina mi się scena z „Karate Kid” w której dzieciak uczy się podstawowych ruchów myjąc samochody 😛 ). Nie wszyscy zdają sobie sprawę z tego jak ważne jest zbudowanie podstaw, by móc z powodzeniem dalej rozwijać swoje umiejętności. Na poziomie Shu okazuje się, że do osiągnięcia celu jakim jest efektywne wykorzystanie umiejętności wystarczająca jest jedna droga, stąd też wymóg lojalności do nauczyciela i posłuszeństwo. Ta stara zasada jasno pokazuje, że mieszanie różnych technik a w naszym przypadku metodologi wprowadza chaos i doprowadza do sytuacji, w której mamy dużo różnych umiejętności ale nie reprezentują one żadnej wartości praktycznej ani technicznej jako całość. Według tradycji to nauczyciel decyduje o tym kiedy uczeń może zakończyć ten etap i przejść na poziom Ha.

Ha – odłączenie, zerwanie z tradycją
Drugi etap nauki polega na uwolnieniu się do pewnego stopnia od klasycznych metod. W tej fazie ważne jest by odnaleźć i zrozumieć powody technik nauczonych na poprzednim etapie. Tutaj zaczyna się sztuka, odłączenie od codziennie powtarzanych czynności i stopniowe rozwijanie technik. Na tym etapie uczeń rozpoczyna własne eksperymenty, powinien być gotowy na to by samodzielnie analizować i myśleć nad powodami wykorzystywania niektórych technik po to by w przyszłości samodzielnie je rozwijać i dołączać nowe. Cała dostępna wiedza została zdobyta, teraz uczeń musi nabyć doświadczenia.

Ri – uwolnienie
Ostatni etap, w którym uczeń staje się mistrzem, uwalnia się od tradycji, przechodzi poza granice. Uczeń posiadający duże doświadczenie i wiedzę może je wykorzystywać w życiu codziennym. Na tym etapie uczeń już nie uczy się sztuki walki od innych tylko tworzy swój własny niepowtarzalny styl. Dopiero tutaj możliwe jest całkowite uwolnienie od standardów i podstaw. Tutaj uczeń/mistrz może pozwolić sobie na niekonwencjonalność, która dzięki zdobytej wcześniej wiedzy i doświadczeniu ma bardzo duże szanse na sukces.

Jak to wszystko ma się do wdrażania metodologii? Miałem nie do końca przyjemną okazję kilkukrotnego obserwowania prób wdrożenia metodologi/narzędzi (Scrum, Kanban) w różnych organizacjach, które zakończyło się porażką. Porażka ta według moich obserwacji wynikała między innymi z tego, że wdrażający zakładali, iż członkowie zespołu i oni sami są co najmniej na poziomie Ha, z tym że wielokrotnie brakowało im wiele do osiągnięcia Shu – nie znali, bądź nie potrafili stosować podstaw. Ponadto wdrożenia typu „weźmy planowanie ze Scrum, tablicę z Kanban ale nie stosujmy na niej limitów, do tego eliminujmy waste za pomocą narzędzi Lean i nazwijmy to wszystko Agile to może nam coś tego wyjdzie” ciężko jest nazwać wdrożeniem. Jak już pisałem w notce o automatycznym chaosie jeśli wdrażamy coś w organizacji to przede wszystkim musimy wiedzieć co wdrażamy i mieć jakiś, co najmniej ogólny plan wdrożenia. Pisałem też już kiedyś o teorii i jej zestawieniu z praktyką, moje doświadczenia jasno pokazują, że teorie sprawdzają się w przygniatającej większości przypadków jeśli tylko spełni się jeden zasadniczy warunek – postępuje się według jednej teorii od początku do końca.
Miałem okazję jakiś czas temu wspierać jeden mały zespół podczas wdrażania Scrum, postanowiłem zastosować zasadę Shu-Ha-Ri. Na początku pokazałem im wszystkie artefakty, pokazałem jak powinno wyglądać planowanie, jak rozbijać zadania, jak rozmawiać podczas spotkań typu stand-up oraz wyjaśniłem klientowi w jaki sposób opisywać wymagania. Po dwóch sprintach, podczas których na prawdę sumiennie starali się przestrzegać wszystkich zasad, praktycznie nie musiałem już tłumaczyć po co to wszystko było – sami dobrze wiedzieli co zyskali porównując sytuację obecną z poprzednimi projektami i z łatwością potrafili wskazać przyczyny stosowania takich a nie innych technik. Obecnie po trzech miesiącach zespół skutecznie wprowadza własne usprawnienia do stosowanej metodologi – starają się używać TDD, programują w parach, robią regularne przeglądy kodu. Wielce pomocne okazały się retrospekcje, które dosyć szybko definiowały problemy, a metoda systematycznego wprowadzania poprawek do procesu owocuje polepszeniem jakości pracy a także lepszą atmosferą i motywacją wynikającą każdorazowo z sukcesu jakim jest eliminacja błędów z procesu.

Po raz pierwszy o Shu-Ha-Ri przeczytałem w książce Alistera Cockburn’a „Agile Software Development – Gra Zespołowa”, którą polecam. Lektura zachęciła mnie do dalszego drążenia tematu, którego efektem jest ta notka

1 komentarz więcej...

O motywacji słów kilka.

opublikowany przez 04, Lut, 2011, w kategoriach Praca, Zarządzanie

Zastanawiałem się ostatnio nad czynnikami, które wpływają na to, że jedne projekty kończą się sukcesem, a inne niestety porażką. Po analizie kilku przypadków doszedłem do wniosku, że jednym z ważnych czynników sukcesu jest odpowiednie motywowanie pracowników. Oczywiście nie jest to jedyny warunek, który trzeba spełnić, niemniej jednak warto zastanowić się co nas motywuje do pracy? Pierwsza odpowiedź jaka się nasuwa zdecydowanej większości pytanych to „pieniądze”. Ale czy na pewno? Z doświadczenia wiem, że pieniądze owszem motywują na początku kariery, zwłaszcza wtedy, gdy się tych pieniędzy nie miało, a tu nagle co miesiąc na konto spływają regularne całkiem pokaźne sumy. O takiej motywacji możemy mówić jedynie w kontekście pracowników niedoświadczonych, przeważnie młodych, zaczynających swe kariery. Co innego, gdy mamy do czynienia z pracownikami doświadczonymi, wysokiej klasy specjalistami czy też ekspertami. Specjalistów rzadko motywują pieniądze, a jeśli już to jest to motywacja krótkotrwała. Nie wiem jak w innych dziedzinach ale jeśli o IT chodzi to obecnie w Polsce specjaliści są bardzo poszukiwani i wiele firm jest w stanie zapłacić na prawdę duże pieniądze za ich usługi, tym samym dla pracodawców zwiększa się ryzyko tego, że ktoś podbierze (podkupi) ich najlepszych pracowników oferując wyższą pensję.

Co zatem zrobić? Jak inaczej niż za pomocą pieniędzy motywować pracowników?

Okazuje się, że wspomniani ‚specjaliści’ pracują głównie po to by osiągać satysfakcję z wykonanej pracy. Jeśli pracownik jest dumny z wykonywanej pracy samoistnie przekłada się to na jego wysoką motywację, co skutkuje wysoką produktywnością. Zastanawiając się nad tym co sprawia, że jesteśmy dumni z wykonywanej pracy możemy dojść do trzech wniosków.

Możemy być dumni z produktu naszej pracy. Jeśli oprogramowanie, które wytwarzamy jest dobre, dobrze napisane, spełnia wszystkie wymogi jakościowe to możemy być dumni ze swojego dzieła. Jako anty-przykład podam system, który ogólnie rzecz biorąc działa, marketingowcy z powodzeniem sprzedają go klientom dzięki czemu firma zarabia, niemniej jednak jakość kodu i sposób jego wytwarzania są na tak niskim poziomie, że żaden programista nie chciałby tego systemu pokazywać w swoim portfolio wiedząc, że potencjalny pracodawca mógłby ten kod przejrzeć. W takiej sytuacji pracownik może powiedzieć: „OK, cieszę się że system działa, ale po powrocie do domu nie czuje satysfakcji z wykonywanej pracy – system jest ok, ale tak na prawdę to jeden wielki śmietnik owinięty ładnym papierkiem”.

Kolejny rodzaj dumy to duma z osiągnięć. Pracownicy odczuwają satysfakcje, gdy ich praca przyczynia się do osiągnięcia sukcesu – sukcesu firmy, sukcesu projektu, czy nawet samego wybicia się zespołu ponad szeregi innych pracowników. Żeby motywować pracowników za pomocą tej metody wystarczy definiowanie odpowiednio małych celów, których osiągnięcie w krótkim czasie oznacza sukces, który następnie powinien być celebrowany w odpowiedni sposób. Dobrym przykładem zastosowania takiego rodzaju motywacji może być nagradzanie i ciągłe powtarzanie zespołowi, który pracuje nad wytwarzaniem nowych funkcjonalności frontendowych, które są potem sprzedawane klientom, że to oni generują większość zysku w firmie, która zatrudnia także programistów backendowych nie mających bezpośredniego wpływu na zyski firmy.

Oprócz powyższych jest jeszcze jeden ważny aspekt motywowania pracowników. Pracownicy są dumni z uczestnictwa w czymś dużym. Człowiek jest istotą stadną, dlatego łączymy się w grupy, społeczeństwa etc. Podobnie jest w przypadku wykonywania pracy im bardziej pracownik czuje się częścią małej społeczności w zakładzie pracy tym bardziej wpływa to na jego motywację. Ponadto znaczący wpływ na motywacje ma świadomość skali tego co jest produkowane. Zupełnie inne podejście w tej kwestii ma pracownik firmy takiej jak Google, Microsoft czy Apple, który ma świadomość tego, że z produktów jego pracy korzystają codziennie miliony użytkowników, a zupełnie inaczej swój udział w przedsięwzięciu ocenia pracownik małej firmy tworzącej sklepy internetowe, które może w najlepszym wypadku dojdą do kilku tysięcy wejść dziennie. Sam udział w przełomowych projektach dużej skali bywa często wystarczająco motywujący by pracownicy wykonywali swoją pracę najlepiej jak to tylko możliwe.

Powyżej opisałem trzy podstawowe czynniki mające wpływ na motywację pracowników. Oczywiście takich zależności jest znacznie więcej, chociażby sama atmosfera pracy, szef, wygodne krzesło, troska firmy o pracownika, rzetelne kierownictwo, które dotrzymuje słowa, społeczne aspekty wykonywanej pracy itd.

7 komentarzy więcej...

Znalazłem wąskie gardło – i co dalej?

opublikowany przez 03, Lut, 2011, w kategoriach Agile, Programowanie, Testowanie, Zarządzanie

Bardzo często na wszelkiego rodzaju szkoleniach z metodyk i zarządzania projektami mówi się o tak zwanych wąskich gardłach, niestety bardzo rzadko ktokolwiek wspomina o tym co należy zrobić, gdy takie wąskie gardło już znajdziemy.
Żeby lepiej ugryźć ten temat przeanalizujmy potencjalny sposób przyspieszenia prac w projekcie – próba zwiększenia efektywności na każdym z etapów wytwarzania oprogramowania. Wielu managerów skupia się na tym by poszczególne zespoły, członkowie zespołów zwiększały swoją efektywność przez co dążą do zwiększenie efektywności całkowitej pracy nad projektem. Jeśli praca na wszystkich etapach przebiega równomiernie (nie mamy istotnych wąskich gardeł) zwiększenie wydajności w każdym etapie spowoduje zasadnicze przyspieszenie prac w całym projekcie. Niestety wystarczy już jedno wąskie gardło by pomimo zwiększenia efektywności na wszystkich innych etapach skutecznie spowolnić pracę w całym projekcie (zakładając względnie równomierny wzrost efektywności na każdym etapie, zwiększenie efektywności na etapie będącym wąskim gardłem niczego nie zmieni, gdyż nadal będzie to wąskie gardło).

Zastanówmy się może skąd się biorą wąskie gardła. Najczęstszą przyczyną powstawania wąskich gardeł jest niedobór zasobów (pracowników, technologi, wiedzy) na jednym z etapów projektu i/lub nadmiar w innych częściach zespołu/projektu. Niektóre zadania po prostu wymagają znacznie więcej czasu niż inne – np. wymyślenie i zaimplementowanie skomplikowanego algorytmu szyfrującego jest trudniejsze i bardziej czasochłonne niż zdefiniowanie wymagań dla takiego algorytmu.

Istnieje wiele różnych sposobów wykrywania wąskich gardeł, jednym z nich jest np. tablica kanbanowa z wprowadzonymi limitami zadań znajdujących się w poszczególnych fazach produkcji. Różne inne sposoby monitoringu, nadzoru pracy, monitorowania postępów, mierzenia czasu pracy etc. także bywają pomocne przy lokalizowaniu wąskich gardeł.

Dobrze dajmy na to, że już znaleźliśmy wąskiego gardło:
Załóżmy że mamy zespół składający się z 4 programistów i jednego testera. Zastosowaliśmy tablicę kanbanową z limitami odpowiedni 4 zadania w develompencie i 1 zadanie w fazie testowania w tym samym czasie (przydział naturalny – badania pokazują, że ludzie są najefektywniejsi gdy pracują nad jednym zadaniem – jednowątkowo). Okazuje się, że programiści (jako zespół) znacznie szybciej kończą swoje zadania niż tester jest w stanie je przetestować. Średnio czas zaprogramowania funkcjonalności okazał się dwukrotnie dłuższy niż czas jej przetestowania co w efekcie spowodowało, że tester miał dwa razy więcej zadań niż mógł przetestować.
Pobawmy się w dosyć śmieszną pseudo matematykę, żeby lepiej zobrazować problem.

Na tym etapie dokonano pewnych zmian, które miały na celu zwiększyć wydajność pracy każdego z członków zespołu o 50% – wdrożenie się udało. Zobaczmy więc jak wygląda sytuacja po zwiększeniu efektywności. Dzięki temu rozwiązaniu teraz tester mógł przetestować trzy zadania w tym samym czasie co wcześniej dwa, niestety tym samym programiści byli w stanie dostarczyć o połowę więcej zadań do testów niż poprzednio przez co wąskie gardło nadal pozostało wąskim gardłem.

Poszukajmy więc alternatyw…
Niestety mamy ograniczony budżet i nie możemy pozwolić sobie na zatrudnienie większej liczby osób.
Widzimy, że mamy za dużo programistów a za mało testerów, może więc powinniśmy jednego z programistów w razie potrzeby wykorzystywać jako testera, chwilowo zmniejszy to ilość dostarczanych funkcjonalności i tym samym pozwoli na przyspieszenie etapu testowania – wąskie gardło będzie odrobinę szybsze, może nawet całkowicie zniknie – super – udało się. Ale zaraz, teraz jeden z programistów stał się testerem – coś tu jest nie tak – przecież płacimy temu gościowi za programowanie a nie za testowanie, on sam pewnie też to dosyć szybko zauważy i zapewne jego morale spadną, a w rezultacie może nawet zmieni pracę bo nikt nie chcę pracować dla pracodawcy, który nie wywiązuje się z zawartych umów, a w jego umowie jasno było napisane, że jest programistą a nie testerem. (evil: A niech się zwalnia – w jego miejsce zatrudnimy testera 😉
Kolejnym sposobem na zlikwidowanie wąskiego gardła mogło by być spowolnienie pracy programistów. TAK – SPOWOLNIENIE! Ale jak to?! Przecież w zarządzaniu chodzi o zwiększanie efektywności, przyspieszanie, dostarczanie produktu na czas etc. Otóż nie zawsze, efektywność okazuje się być bez znaczenia w miejscach nie będących wąskim gardłem [Cockburn 2008]. Jeśli już mamy wąskie gardła, to zwiększenie efektywności w innych miejscach w niczym nam nie pomoże, wręcz przeciwnie może spowodować jeszcze większe straty np. wzrost frustracji testerów spowodowany nadmiarem zadań i nierealnymi terminami, konflikty pomiędzy testerami a resztą zespołu spowodowane naciskami ze strony tych drugich na szybsze wykonywanie zadań testerskich, mniejsza dokładność testów w celu przetestowania większej ilości funkcjonalności itd.

Co zatem należy zrobić?
Jeśli mamy już sytuację jak opisaną powyżej to warto zastanowić się nad tym dlaczego praca testerów zajmuje tyle czasu i co zrobić by ją przyspieszyć. Żeby przeanalizować ten problem trzeba by sięgnąć do korzeni – po co jest testowanie? Testowanie służy odnalezieniu błędów. Dlaczego testujemy? Testujemy, gdyż zakładamy że dostarczona funkcjonalność zawiera błędy. Z powyższej toku myślowego wynika, że jednym ze sposobów rozwiązania problemu wąskiego gardła z powyższego przykładu mogło by być dostarczanie do testów funkcjonalności o wyższej jakości. Jak to zrobić? Sposobów jest wiele – począwszy od dbania o jakość od samego początku np. poprzez zastosowanie TDD co także zwiększy pokrycie kodu testami automatycznymi dzięki czemu zmniejszy się czas testów regresyjnych, skończywszy na poświęceniu większej uwagi planowaniu i zrozumieniu wymagań przez programistów, czy też zastosowanie wielu innych dobrych praktyk programistycznych takich jak na przykład Code Review. Zastosowanie któregoś z powyższych rozwiązań niesie ze sobą podwójne korzyści: programiści muszą poświęcić więcej czasu na pisanie testów, planowanie, analizę, dzięki czemu wąskie gardło testerskie nie zapycha się, a także wzrasta jakość kodu i funkcjonalności, przez co zmniejsza się ilość poprawek i re-testów, dzięki czemu tester ma więcej czasu. Kolejnym bardzo ważnym aspektem takiego rozwiązania jest także wzrost zaufania testerów do produktów dostarczanych przez programistów (czasem bywa to zgubne, niemniej jednak w większości przypadków skutkuje polepszeniem atmosfery, lepszą komunikacją i ostatecznie większą ilością sukcesów).

Powyższy opis problemu i propozycja jego rozwiązania dotyczyły wąskiego gardła na etapie testowania, ale zasada jest dosyć ogólna – nie należy zwiększać efektywności w miejscach które nie są wąskimi gardłami (może to np. dotyczyć sytuacji gdy 7 programistów okupuje jednego DBA – wtedy też należy programistów zmusić do przeprowadzania analizy problemów po ich stronie, a do DBA kierowania tylko próśb o podjęcie ostatecznych decyzji w rozpracowanych wcześniej problemach, lub próśb o pomoc w sytuacjach krytycznych). Oczywiście jeśli nie ma wąskich gardeł, lub wszystkie zlikwidowaliśmy możemy dalej pracować nad równomiernym wzrostem efektywności pamiętając o tym by nie stworzyć kolejnych newralgicznych punktów w naszym procesie.

Warto też pamiętać o wąskich gardłach przy budowaniu budżetu projektu, czy też zatrudnianiu nowych pracowników.

3 komentarze więcej...

„Dane testowe – teoria i praktyka” – Recenzja książki

opublikowany przez 02, Lut, 2011, w kategoriach książki, Testowanie

Ostatnio wpadła w moje ręce książka autorstwa Radka Smilgina i Anny Piaskowy „Dane testowe – teoria i praktyka”. W zasadzie to dostałem ją od Radka w prezencie :), także po to by napisać kilka słów o tym co myślę na jej temat.
Z tego co wiem jest to pierwsza publikacja na temat danych testowych na polskim rynku i to już samo w sobie daje jej dużego plusa. Moje pierwsze odczucia po przeczytaniu książki były raczej mieszane. Po pierwsze jest dosyć cienka – przeczytałem ją w jeden wieczór. Całość składa się z dwóch części – pierwsza to ogólna teoria na temat danych testowych i ich wykorzystania oraz przykłady typowych danych testowych wraz z normami prawnymi i obowiązującymi standardami, druga część to w zasadzie instrukcja obsługi generatora danych testowych – bardzo praktyczna aplikacja, ale o tym może innym razem.
Po przeczytaniu wszystkiego pozostał pewien niedosyt – czegoś mi tutaj brakowało, ale może takie właśnie było założenie autora – żeby nie lać wody a skupić się na suchej analizie, która sama w sobie jest dosyć treściwa, (a w wykonaniu Radka na bardzo wysokim poziomie), książka na pewno zachęca do samodzielnego poszukiwania dalszych informacji. Czytając zastanawiałem się komu sam bym polecił przeczytanie tej pozycji – doszedłem do wniosku, że książka jest skierowana, głównie do osób początkujących w testowaniu czy programowaniu, stanowi także świetne uzupełnienie materiałów uniwersyteckich dla studentów informatyki. Mi osobiście treść książki przypomniała o kilku ważnych aspektach dobierania danych testowych w zależności od rodzajów testów, oraz o zasadach definiowania przypadków testowych. Jeśli mowa o przykładach i teorii zawartych w książce to niestety (albo może właśnie to jest jej największy atut) książka jest mocno zlokalizowana na rynek polski, dane są specyficzne dla naszego kraju. Z drugiej strony czytając przykłady i omówienie zasad tworzenia np. imion w języku polskim znalazłem bardzo wiele interesujących ciekawostek, o których wcześniej nie miałem pojęcia.
Nie będę tutaj streszczał treści, wszystkich zainteresowanych odsyłam do księgarni (książkę wydał Helion, więc można ją nabyć przez internet 😉 ).
Ogólna ocena: „dobry”.
Warto przeczytać chociażby po to by podsumować swoją dotychczasową wiedzę, a początkującym na pewno książka ta pomoże w trafny sposób dobierać dane testowe, oraz poszerzy horyzonty wskazując miejsca skąd można dane do testów uzyskać.
Ponadto jak wspomniałem na początku wielki plus za to, że wreszcie pojawiła się jakaś pozycja tematyczna na naszym krajowym rynku autorstwa naszych rodzimych specjalistów. Mam nadzieję, że to nie koniec twórczości Radka i że jeszcze nie raz będziemy mieli okazję przeczytać wiele interesujących publikacji na temat testowania i nie tylko autorstwa naszych kolegów i koleżanek po fachu.

Dodaj komentarz więcej...