blog.testowka.pl

Archiwum wiadomości z Luty, 2014

Komentarz do: „Błąd Arystotelesa w IT”

opublikowany przez 26, Lut, 2014, w kategoriach Agile, CI, Scrum, XP

[W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany „Błąd Arystotelesa w IT„, który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu – poniżej… zapraszam do dyskusji]

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!

Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)…

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać… Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.

Samo omawianie od podstaw metod zwinnych w 2014 roku jest już raczej zbyteczne.
Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu…
Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać… Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup (gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań)

6 komentarzy więcej...

Szanse na zmianę organizacji

opublikowany przez 18, Lut, 2014, w kategoriach Agile, Coaching, Kanban, Scrum, Zarządzanie

change1

Upłynęło już sporo wody w Wiśle od momentu, gdy po długiej, motywującej do działania dyskusji Mike Sutton powiedział mi:

If you can’t change organisation probably you need to change organisation…

Te słowa były powodem jednego z myślę, że kluczowych zwrotów w moim życiu. Ale te słowa wymagają również głębszego zastanowienia nad tym co tak naprawdę sprawia, że niektóre organizacje potrafią się zmienić, a inne nie?

Dzięki doświadczeniu jak by nie było w zmienianiu organizacji właśnie, które zbierałem przez ostatnich kilka lat udało mi się zaobserwować kilka czynników, które moim zdaniem w pewnym, znaczącym stopniu determinują czy dana organizacja ma szanse na zmianę.

Z moich obserwacji organizacje dzielą się na trzy typy.

  1. Success Story – Takie które radzą sobie w miarę dobrze. Dla takich organizacji nie ma przeważnie realnych zagrożeń które by zagroziły ich egzystencji (a przynajmniej zagrożenia te nie występują w sposób nagły i nieprzewidywalny). Przeważnie to że te firmy radzą sobie lepiej od innych wynika z tego, że wyrobiły sobie odpowiednie metody szybkiego wprowadzania zmian i reagowania na zmiany w otoczeniu. W takich organizacjach przeważnie wszyscy widzą potrzebę wprowadzania ciągłych zmian i usprawnień jako coś naturalnego, co może sprawić że będzie jeszcze lepiej.
  2. Standard – Organizacje w których nie wszyscy wyrażają chęć zmian czegokolwiek. Organizacje te radzą sobie zazwyczaj przeciętnie, ale nie widzą na horyzoncie (przynajmniej na razie) realnych zagrożeń, które mogły by wymusić jakiekolwiek realne zmiany. W takich organizacjach są oczywiście pojedyncze osoby, które chciały by sprawić by praca była bardziej efektywna i by organizacja wyrosła ponad przeciętną. Osoby te zazwyczaj dostrzegają zmiany na rynku, zmiany w konkurencyjnych firmach i nowe trendy w stosowanych na świecie metodach zapewniające wzrost efektywności.
  3. Tarapaty – Organizacje które są już w poważnych tarapatach. Dla nich zmiana często jest jedynym ratunkiem, a przynajmniej próbą ratunku przed mniej lub bardziej spektakularną porażką. „Poważne tarapaty” nie oznaczają, że organizacja z dnia na dzień przestanie istnieć jeśli nic nie zrobi – to raczej proces długotrwały, niemniej jednak widoczny. W takich organizacjach potrzeby zmian dostrzegane są przez wiele osób bardzo często również na samym szczycie struktury organizacyjnej.

Największe szanse na wprowadzenie realnych zmian mają organizacje z grupy pierwszej i trzeciej. Rozważając dlaczego właśnie tak się często dzieje warto zastanowić się nad tym co wywołuje opór przed zmianą. Prawdę powiedziawszy ludzie po prostu z natury boją się jakichkolwiek zmian, gdyż zmiana zawsze niesie z sobą niepewność, że to co po niej nastąpi będzie gorsze od tego co jest teraz. Oczywiście obawa ta nie jest nieuzasadniona, ale wystarczy w pełni otworzyć się nie tylko na najbliższe zmiany ale także na możliwe (albo raczej pewne) kolejne i strach zaczyna być irracjonalny. Jeśli coś pójdzie nie tak jak powinno to przecież zawsze można znowu coś zmienić.

W organizacjach typu drugiego nie ma realnej potrzeby wprowadzania zmian. Nie ma aspiracji do tego by stać się wybitnie lepszym i obecnie oraz nie ma realnych zagrożeń – przynajmniej chwilowo. Pracownicy takich organizacji, którzy często po prostu chcieli by się rozwijać i poprawiać efektywność swoją jak i swojego otoczenia często cierpią katusze z powodu słabo widocznych efektów ich działań oraz braku docenienia ich starań w kwestii poprawienia stanu obecnego.

Organizacje pierwszej kategorii nie mają problemu ze zmianami. Od pracowników tutaj wręcz wymaga się ciągłego kwestionowania status quo oraz eksperymentowania z różnymi metodami. Nie jest to oczywiście odpowiednie środowisko dla każdego niemniej jednak, ci którzy już się tam znajdą przeważnie nie narzekają na brak motywacji.

Organizacje w tarapatach również czują realną potrzebę wprowadzenia zmian. Jest to dużo trudniejsze niż w przypadku typu nr jeden, lecz opór jest znacznie niższy niż przypadku typu drugiego. Dużo łatwiej jest każdemu zracjonalizować potrzebę wprowadzenia zmian. Ponadto zazwyczaj ludzie i tak w takiej organizacji czują się zagrożeni więc zmiana rzadko kiedy może jeszcze bardziej pogorszyć sytuacje.

Reasumując, aby wprowadzić realne zmiany w organizacji potrzebna jest odpowiednia presja i dobre powody by takowe zmiany wprowadzić. Obecnie za każdym razem, gdy ktoś próbuje mnie zatrudnić do pomocy w transformacji zawsze pytam o konkretne powody wprowadzania zmian. Czasami takie dyskusje wymagają dużej ilości czasu, zastosowania metod coachingowych oraz innych narzędzi by dotrzeć do głównych potrzeb organizacji. Często okazuje się że znając powody potrzeby wprowadzania zmian jesteśmy w stanie dużo lepiej je zaadresować niż w przypadku, gdy klient przychodzi do nas z gotową propozycją rozwiązania swoich problemów i potrzebą zatrudnienia wykonawcy, który takie rozwiązanie wdroży. Zdarzyło mi się już kilkukrotnie odmówić pomocy, gdy widziałem, że jedynym powodem wprowadzania zmian w organizacji była moda lub irracjonalna chęć wykorzystania budżetu szkoleniowego w „jakiś” sposób.

Powyższe to oczywiście tylko moje luźne, subiektywne obserwacje dotyczące kilku organizacji. Nie są to sztywne reguły, które łatwo można dopasować do każdej organizacji. Są to raczej wskazówki pomagające mi i moim kolegom oraz koleżankom z Code Sprinters efektywniej pracować z naszymi klientami od samego początku – w zasadzie współpracować zanim jeszcze rozpoczniemy współpracę.

2 komentarze więcej...

7 Grzechów Automatyzacji Testów

opublikowany przez 13, Lut, 2014, w kategoriach Inne

temptation

1. Wiara w cuda

Zbyt często automatyzacja jest postrzegana jako złote lekarstwo na problemy związane z niską jakością oprogramowania, która przejawia się poprzez dużą ilość defektów. Niektórym wydaje się, że jeśli przyspieszymy proces testowania poprzez jego zautomatyzowanie to od razu auto-magicznie będziemy popełniać mniej błędów. Warto jednak pamiętać o tym, że o ile automatyzacja szybciej pokaże nam widoczne objawy problemów z jakością naszego oprogramowania to tych problemów nie rozwiąże. Jak już pisałem wielokrotnie automatyzacja jedynie na poziomie testów end-to-end to za mało. Takie testy to jedynie początek, wstęp do refaktoryzacji mającej na celu poprawę jakości kodu.

2. Skróty nie zawsze są krótszą drogą

Nagrywanie i odtwarzanie testów automatycznych jest pokusą, której wielu początkującym praktykom automatyzacji ciężko jest się oprzeć. O ile samo wytworzenie takich skryptów może być faktycznie względnie szybkie i łatwe, o tyle ich późniejsze utrzymywanie bardzo szybko przeradza się w koszmar. Przeważnie po zmianie funkcjonalności okazuje się, że łatwiej było by nagrać wszystkie testy od nowa niż poprawić już istniejące. Chciwość nie jest najlepszym doradcą przy wyborze narzędzi do testów, co wcale nie znaczy, że trzeba wybierać te drogie i komercyjne – wręcz przeciwnie, darmowe rozwiązania open source, mocno wspierane przez community często okazują się być bardziej użyteczne od tych płatnych.

3. Kod testów nie jest przecież kodem produkcyjnym

Pisząc testy automatyczne musimy pamiętać o zasadach Clean Code tak samo jak powinniśmy o nich pamiętać pisząc kod funkcjonalności. Należy wziąć pod uwagę to, że kod testów będzie zmieniał się najprawdopodobniej tak często jak kod funkcjonalności o ile nie częściej, dlatego przestrzeganie zasad czystego kodu oraz stosowanie wzorców projektowych z pewnością zwróci się w postaci czasu zaoszczędzonego podczas późniejszych modyfikacji.

4. Testowanie End-To-End to za mało

Automatyzacja testów powinna odbywać się na każdym poziomie. Testowanie tylko na poziomie testów akceptacyjnych end-to-end czyli odwracanie klasycznej piramidy testów bardzo szybko prowadzi do jej destabilizacji i przewrócenia. Pomimo tego co zalecam zawsze podczas refaktoryzacji legacy code należy pamiętać o tym, że odwrócona piramida testów musi być sztucznie podpierana by się utrzymać. Dlatego by nasz wysiłek miał sens należy jak najszybciej wykorzystywać to co dają nam testy wysokiego poziomu i szybko budować podstawy piramidy.

5. Automatyzujmy wszystko

Jak często widzieliście projekty pod tytułem „Automatyzacja wszechświata”? Pamiętajmy, że im więcej testów napiszemy tym więcej będziemy ich musieli później utrzymywać. Co w takim razie testować? Z pewnością krytyczne funkcjonalności biznesowe wymagają pokrycia testami. Warto testować też to co się często zmienia. Oczywiście, że można przetestować wszystko – tylko po co? Im więcej testów tym więcej czasu będziemy czekać na informację zwrotną przy ich uruchomieniu. To co nie jest krytyczne powinno być oczywiście przetestowane na poziomie jednostkowym ale już niekoniecznie w testach end-to-end.

6. Automatyzacja to działka testerów

Klientami i głównymi użytkownikami testów automatycznych – nawet tych na poziomie testów akceptacyjnych są przede wszystkim programiści. Dlatego też powinni być oni zaangażowani w proces tworzenia tychże testów. Testy end-to-end nie mogą istnieć w zupełnym oderwaniu od tego co się aktualnie dzieje w kodzie funkcjonalności. Organizacje opierające swój development na konflikcie pomiędzy działem testów a działem programistów nie mają racji bytu we współczesnym środowisku wytwarzania oprogramowania. Coraz więcej organizacji (także tych dużych i wydawało by się skostniałych) rezygnuje w ogóle osobnych działów testowania i łączy testerów z programistami w zespoły wskroś-funkcjonalne.

7. Testy automatyczne nie wymagają ciągłej pracy

Automatyzacja testów to proces ciągły wymagający ciągłej uwagi i opieki. Podobnie jak wytwarzanie nowych funkcjonalności, automatyzacja testów również potrzebuje innowacji i ciągłych udoskonaleń. Czas poświęcony na dobrze zrobioną automatyzację zawsze się zwraca, ale nie zawsze od razu. Czasem trzeba trochę poczekać aż efekty będą widoczne. Albo właśnie nie będą widoczne efekty braku automatyzacji. Także decydując się na automatyzację testów zapomnij o pochwałach i spektakularnych sukcesach – możesz za to liczyć na minimalizacje ilości spektakularnych porażek.

3 komentarze więcej...