blog.testowka.pl

Automatyzacja

Kurs selenium część 1 – instalacja i setup środowiska

opublikowany przez 09, Lis, 2012, w kategoriach Automatyzacja, Kurs Selenium, Testowanie

Całość kursu dostępna tutaj

Początki są podobno najtrudniejsze…

Poniżej krótki opis tego co będziemy potrzebować by rozpocząć pracę z testami selenium (W środowisku Java).

Co będziemy potrzebować:

  • Java (JDK 1.7)
  • Eclipse
  • Maven
  • Firefox
  • Pluginy do Eclipse

Poniżej krótka instrukcja instalacji poszczególnych narzędzi.

JDK 1.7

Pobieramy najnowsza wersję Java SE JDK ze strony http://www.oracle.com/technetwork/java/javase/downloads/index.html i instalujemy za pomocą instalatora.

Eclipse lub IntelliJ

Pobieramy najnowszą wersję Eclipse IDE for Java EE z http://www.eclipse.org/downloads/. Rozpakowujemy archiwum do jakiegoś katalogu. Uruchamiamy Eclipse poprzez kliknięcie w ikonę eclipse.exe (Windows) lub z konsoli (Linux).

Lub alternatywnie IntlliJ http://www.jetbrains.com/idea/download/ wtedy mamy natywne wsparcie dla Mavena, Gita i innych przydatnych później rzeczy.

Maven

Pobieramy najnowszą wersję Maven z http://maven.apache.org/download.html. Rozpakowujemy archiwum w wybranym katalogu.

Maven Konfiguracja (Windows)

Wchodzimy w Panel Sterowania -> System i Zabezpieczenia -> System – Zaawansowane Ustawienia Systemu -> Zaawansowane ->Zmienne Środowiskowe.

Dodajemy/edytujemy zmienne systemowe :

JAVA_HOME = (Ścieżka do katalogu gdzie zainstalowane jest JDK)

MAVEN_HOME = (Ścieżka do katalogu z Mavenem)

M2 = %MAVEN_HOME%\bin

PATH = %M2%; %JAVA_HOME%\bin (UWAGA! Jeśli zmienna PATH istnieje to nie usuwamy jej zawartości tylko dodajemy to co po lewej na końcu po średniku)

Otwieramy konsolę i sprawdzamy czy Maven działa poprzez wpisanie

 mvn --version 

Firefox

No bez przesady… Dacie radę sami…

Zalecam jednak by wersja przeglądarki była tak 1-2 wersje do tyłu. Twórcy Selenium mają pewne opóźnienie w aktualizowaniu wersji drivera więc może się okazać (i często się okazuje), że nasze testy nie będą działać z najnowszą przeglądarką.

Pluginy do Eclipse

Wchodzimy w Help->Eclipse Market

Wyszukujemy i instaluje kolejno (za każdym razem restartując Eclipse):

– TestNG plugin

TestNG for Eclipse

http://marketplace.eclipse.org/content/testng-eclipse

6 komentarzy więcej...

Nowy Kurs Selenium

opublikowany przez 05, Lis, 2012, w kategoriach Automatyzacja, Kurs Selenium, Testowanie

Jak niektórzy z Was zapewne zauważyli na blogu pojawił się ostatnio nowy kurs Selenium. Postanowiłem zacząć od nowa, gdyż poprzednia wersja kursu mocno się zdezaktualizowała na przestrzeni ostatnich trzech lat. Pierwsze dwa rozdziały dotyczące samej instalacji i konfiguracji środowiska są już dostępne. Następne rozdziały będą ukazywać się wkrótce.

Kurs jest dużym skrótem tego co prezentujemy na naszych szkoleniach z automatyzacji testów, na które zapraszam jeśli chcecie się dowiedzieć więcej.

Dodaj komentarz więcej...

A mury runą, runą, runą…

opublikowany przez 13, Lip, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Scrum, Testowanie, XP, Zarządzanie

…i pogrzebią stary świat…

Tak wiem, że Kaczmarski miał niewiele wspólnego z wytwarzaniem oprogramowania. O jaki mur chodzi? Mur, który od lat budowaliśmy pomiędzy tzw. programistami i tzw. testerami. Często powstawały nawet fizyczne mury i bariery – chociażby odległość liczona w tysiącach kilometrów.

Od dawna już wiadomo, że zarządzanie poprzez konflikt (tutaj konflikt między testerami, a programistami) jest jedynie (o ile w ogóle) efektywne w krótkich okresach czasu – długofalowo niszczy motywacje i powoduje mnóstwo problemów wynikających z komunikacji. Programowanie (wytwarzanie oprogramowania) jest grą zespołową – zespół to nie tylko programiści. Zespół to też testerzy, zespół to także klienci, to czasem też docelowi użytkownicy – stawianie murów pomiędzy nimi powoduje jedynie wzrost złożoności i zwiększoną ilość problemów.

Cały ruch Agile czy metodyki takie jak Scrum, XP, Crystal heroicznie walczą z podziałami i sprowadzają się do zapewnienia odpowiednich interakcji pomiędzy ludźmi wytwarzającymi oprogramowanie. W efekcie powstają produkty wysokiej jakości.

Dlatego proszę oprócz fizycznych, technicznych i psychologicznych barier usuńmy też wszelkie inne spory i kłótnie. Męczą mnie już dyskusje na temat tego jakie testy powinien pisać/wykonywać tester a jakie programista? Czy to  na prawdę ma znaczenie?! Jeśli będziemy pracować razem, to prawdopodobnie osiągniemy dużo lepsze rezultaty. Co złego się stanie jeśli programista siądzie w parze z testerem i razem coś zakodują, albo przetestują?

Testowanie (czy to manualne, czy automatyczne) jest nieodłącznym elementem programowania. Bez testowania (jakiegokolwiek) oprogramowanie najprawdopodobniej nigdy by nie powstało. Bez programowania nie było by co testować. Cała idea inkrementalnego wytwarzania oprogramowania opiera się o nie dzielenie procesu wytwarzania oprogramowania na testowanie i kodowanie – robimy te rzeczy równolegle i ciągle.

Pisanie testów automatycznych jest równoznaczne z tworzenie tzw. kodu produkcyjnego. Gdy byłem na szkoleniu z Clean Code u Uncle Bob’a (Robert C. Martin) z wielkim oburzeniem mistrza spotkało się moje stwierdzenie, że rzadko tworzę kod produkcyjny, gdyż zajmuję się głównie automatyzacją testów. Testy automatyczne są kodem produkcyjnym – często dużo ważniejszym i bardziej wartościowym niż kod funkcjonalności aplikacji.

Nie stawiajmy więc sztucznych barier pomiędzy testowaniem a programowaniem – obydwie te czynności mają na celu dostarczenie produktu wysokiej jakości i na tym powinniśmy się skupić.

2 komentarze więcej...

Dlaczego automatyzujemy testy?

opublikowany przez 21, Cze, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Testowanie, XP

Mamy różne rodzaje testów. Jeśli chodzi o testerów to najczęściej zajmują się oni automatyzacją testów funkcjonalnych GUI czy też testami typu end-to-end.

Warto się zastanowić po co tworzymy takie testy automatyczne? Jeśli robimy to wyłącznie by przyspieszyć testowanie, to nie jest to najlepsza odpowiedź. Celem tworzenia takich testów powinno być poprawianie jakości – może nie bezpośrednio ale ogólnie testy automatyczne powinny przyczyniać się do poprawy jakości. Robię to poprzez dostarczanie szybkiej – dużo szybszej niż tester manualny informacji zwrotnej na temat działania produktu, a przede wszystkim na temat tego czy programista wprowadzając zmiany niczego nie zepsuł. Jest to niezwykle istotne zwłaszcza, gdy mamy do czynienia z systemami typu legacy – kaszana bez wyraźnej, przejrzystej architektury i testów jednostkowych. Systemy tego typu maja to do siebie że bardo trudne, o ile wręcz niemożliwe jest przetestowanie ich przy użyciu testów jednostkowych. Tworzenie unit testów do już istniejącego kodu, napisanego przed testami jest bardzo czasochłonne (swoją drogą to jeden z powodów dla którego niektórzy mówią, że pisanie testów jest strasznie kosztowne i czasochłonne). Kod który nigdy nie był pisany z myślą o testach jednostkowych, które będą go testowały często jest po prostu nietestowalny.

By móc poprawiać jakość naszego produktu musimy być w stanie poprawiać kod i jego jakość. Niestety bez szybkiej informacji na temat tego czy kod działa  – na przykład w postaci unit testów nie mamy nigdy pewności czy nasze zmiany niczego nie popsują, a co za tym idzie brakuje nam  odwagi by cokolwiek zmieniać i poprawiać. Pętla się zamyka – nie możemy zmienić nie testowalnego kodu tak by był testowalny bez obawy o to, ze czegoś nie popsujemy. Błędne koło się zamyka a dług technologiczny ciągle rośnie.

Jednym ze sposobów jest wdrożenie testów typu end-to-end które traktują testowany system jak „black box” lub „gray box”, do którego mają dostęp tylko w odpowiednich miejscach. Takie testy mają niestety kilka wad – na przykład są wolne i trudne w utrzymaniu.

Powyższe problemy to jeden z wielu powodów stosowania w projektach tzw. piramidy testów, która zakłada, że będziemy tworzyć jak najwięcej testów jednostkowych, trochę mniej testów funkcjonalnych i akceptacyjnych, a testów typu end-to-end nie będziemy tworzyć wcale, lub będą to tylko skrajne przypadki.

Takie podejście sprawdza się idealnie, rozpoczynamy projekt od zera i od samego początku postępujemy według wyżej wymienionych zasad. Niestety rzeczywistość jest inna. Na początku projektów informatycznych mało kto przejmuje się automatyzacja w ogóle, o testach jednostkowych i TDD już nawet nie wspomnę. Testy automatyczne wdraża się przeważnie dopiero, gdy zaczyna się już robić na prawdę niedobrze, a dług technologiczny daje o sobie znać na każdym kroku. W ten sposób powstają właśnie systemy typu legacy.

Gdy kilka miesięcy temu na konferencji 33rd degree podczas jednej z prezentacji Uncle Bob powiedział coś w stylu: „Nie piszcie testów end-to-end – one są złe”, a ja zobaczyłem bezmyślnie przytakujące głowy setek programistów siedzących na sali pomyślałem sobie: „Cholera – ostatnie 2 lata prowadzonej przez nas indoktrynacji w dziedzinie automatyzacji testów w naszym kraju właśnie trafił szlag…”. Miałem o to spory żal do Bob’a, który zresztą na niego wylałem w postaci bardzo długiej dyskusji na temat legacy code etc. Bob oczywiście na myśli miał projekty typu green-field, gdzie zaczynamy od zera. Oczywiście bardzo dobrze, że skorzystał ze swojego autorytetu i może przynajmniej kilka osób do tego przekonał, dzięki czemu w przyszłości będzie znacznie mniej systemów przepełnionych legacy code. Ale co z projektami, które już istnieją i które nadal trzeba rozwijać? To właśnie w takich projektach pracuje większość testerów (domyślcie się dlaczego).

Łatwo znaleźć rozwiązanie dla systemów już istniejących, gdy uświadomimy sobie, że celem testowania nie jest tylko testowanie samo w sobie ale też poprawa jakości. Podstawowym celem wdrożenia testów automatycznych jest zapewnienie możliwości wprowadzania bezpiecznych zmian – podobnie jak celem testów regresyjnych (które przypadkiem powstają przy wdrożeniu automatyzacji) jest dostarczenie informacji zwrotnej na temat tego, czy nasze zmiany nie wprowadziły błędów w istniejącej już funkcjonalności. Aby móc cokolwiek zmieniać tworzymy takie testy które dadzą nam przynajmniej ogólna informację na temat tego czy funkcjonalność która zmieniamy nie uległa popsuciu z punktu widzenia użytkownika.

W skrócie tworzymy odwróconą piramidę testów – z dużą ilością testów end-to-end i funkcjonalnych. Dzięki temu możemy zmieniać kod aplikacji i poprawiać jego jakość (refaktoryzować, zmieniać architekturę etc.) sprawiając, że staje się on testowalny także na niższych poziomach. Za każdą zmianą idzie dopisywanie nowych testów jednostkowych (a nawet to zmiany sterowane są pisaniem testów jednostkowych jak w TDD). Po pewnym, czasie mamy testowalny system z przejrzystą architekturą, w której każdą warstwę możemy przetestować oddzielnie, a GUI i logika w nim ograniczone są do minimum. To jest dobry moment by zacząć pozbywać się naszych testów typu end-to-end. Tak! Właśnie tak! Cały czas tworzyliśmy testy typu end-to-end z myślą o tym, że za chwilę je usuniemy. Największym kosztem podczas utrzymywania testów są duplikacje – więc jeśli tworzymy testy jednostkowe, które w przybliżeniu testują to samo co nasze testy end-to-end to oczywistym staje się potrzeba usunięcia tych, które są bardziej kosztowne i mniej wartościowe – end-to-end. W ten sposób stopniowo obracamy naszą piramidę testów i zaczyna ona powoli wyglądać tak jak powinna.

Celem całej naszej pracy nie jest zwiększenie pokrycia testami – co w podanym przykładzie mogło by doprowadzić do pokrycia nawet powyżej 100% (oczywiście zależy jak liczonego) – pytanie czy taka metryka cokolwiek nam mówi poza tym, że straciliśmy dużo czasu? Prawdziwym celem jest poprawa jakości, jakości na najniższym poziomie, zapewnienie poczucia bezpieczeństwa podczas wprowadzania zmian, wydzielenie odpowiednich modułów i domen w naszej aplikacji, odseparowanie modelu o danych, logiki od interfejsu użytkownika, itd.

Powyżej opisałem jeden (jak dotąd z pośród sprawdzonych przeze mnie w praktyce, jedyny działający) z kilku sposobów radzenia sobie z długiem technologicznym.

4 komentarze więcej...

Tester w Agile – sztuka zadawania pytań

opublikowany przez 31, Maj, 2012, w kategoriach Agile, Automatyzacja, Inne, Scrum, Testowanie, XP

Cały czas ludzie pytają mnie o to jaka jest rola testera w zespole pracującym wg Agile/Scrum? Jakie kompetencje powinien mieć taki tester? Czy wystarczy by tester w Agile tylko „klikał”? Jeśli klikanie to za mało to w jaki sposób poszerzać kompetencje testerów?

Rola testera w Agile jest niezwykle istotna! Szeroko rozumiane testowanie jest podstawą zwinnych metodyk wytwarzania oprogramowania. Przez „szeroko rozumiane” mam na myśli oczywiście nie tylko klikanie ale i automatyzację. Tak! Drodzy testerzy dobrze jeśli potraficie automatyzować testy – nie mówię tutaj o regularnym programowaniu, ale o ułatwianiu swojej i innych pracy. Oczywiście nie skreślam nigdy testerów klikających – ich wiedza i umiejętności są niewątpliwie istotne. Tester nie programujący/automatyzujący na co dzień może i powinien pełnić rolę „adwokata diabła” (klienta) – to tester potrafi najlepiej wczuć się w potencjalnego użytkownika testowanej aplikacji i spojrzeć na nią z zupełnie innej niż programiści perspektywy.

W trakcie sprintu/iteracji tester powinien poświęcać jak najwięcej czasu na… uwaga… testowanie. Testowanie to nie tylko wykonywanie scenariuszy czy też ich automatyzacja – to przede wszystkim zadawanie pytań. Pierwsze podstawowe pytanie zadawane, gdy ktoś oddaje coś do testów powinno brzmieć: „Czy to na pewno jest do testów gotowe?”, lub „Co programista rozumie poprzez zrobione?”. Ale czy moment „oddania do testów” jest pierwszą okazją do zadawania pytań? Oczywiście nie – pytać można dużo wcześniej – chociażby siadając z programistami i gdy nawet jeszcze nie przystąpią do swojej pracy zadawać pytania typu: „Jak zamierzasz to zaimplementować?”, „Czy wziąłeś pod uwagę taki scenariusz?”, „Jak to się ma do naszej Definition of Done?”. „Czy to na pewno wszystkie kryteria akceptacji jakie są wymagane by uznać tą funkcjonalność za skończoną?”. Oprócz programistów tester powinien gnębić swoimi pytaniami także klienta – doprecyzowując wymagania i eliminując wszelkie wątpliwości. Efektem ubocznym rozmów z klientem i programistami jest ciągłe poszerzanie wiedzy na temat testowanego produktu co w efekcie drastycznie podnosi jakość testów i przekłada się na produktywność całego zespołu.

Tester w Agile musi się wykazać pewną pro-aktywnością i samemu organizować swoją pracę. To tester powinien zawsze wychodzić na przeciw klientowi, użytkownikom czy programistom i aktywnie uczestniczyć w projekcie od samego początku.

Jeśli programiści korzystają z praktyk Programowania eXtremalnego (XP) takich jak programowanie w parach i Test Driven Development to nie ma lepszego miejsca dla testera niż siedzenie w parze z programistą. Oczywiście tester nie umiejący programować w kwestiach technicznych niewiele pomoże (przynajmniej na początku) ale już na przykład podczas dobierania odpowiednich przypadków testowych w TDD jego wiedza może być niezwykle przydatna. Tester w parze z programistą pełni rolę nawigatora (patrz google + pair programming). Tego typu podejście bardzo szybko sprawi, że tester poprzez najpierw zrozumienie kodu a następnie czynny udział w programowaniu będzie rozwijał swoje umiejętności potrzebne do automatyzacji testów i nie tylko.

Kolejny temat, który ostatnio ktoś poruszył to problem z testerami, którzy uważają, że naturalną ścieżką kariery testera jest w pewnym momencie zostanie (młodszym) programistą. Ogólnie uważam, że nie ma w tym nic złego – jeśli weźmiemy pod uwagę fakt że programowanie to gra zespołowa to posiadanie w zespole programisty z backgroundem testerskim niezwykle ułatwia życie. Taki programista/tester jest w stanie fachowo wspierać kolegów testerów w momencie, gdy akurat zadań dla testerów jest więcej. Ponadto bagaż doświadczeń zdobytych na stanowisku testera sprawia, że taka osoba dużo lepiej rozumie istotę i problemy związane z testowaniem więc wykorzystując swoje umiejętności programistyczne może skutecznie ułatwiać pracę testerów. Z drugiej strony kto by tam chciał być programistą gdy testowanie jest takie ciekawe! 😛

Powyższe to tylko kilka moich pomysłów, a w zasadzie zbiór prywatnych doświadczeń związanych z testowanie w zespole pracującym wg Agile/Scrum. Z chęcią posłucham o Waszych pomysłach a przede wszystkim doświadczeniach co do tego jak pracować w takim zespole – w komentarzach jest dużo miejsca…

7 komentarzy więcej...

Myśleć zwinnie

opublikowany przez 04, Sie, 2011, w kategoriach Agile, Automatyzacja, Scrum, Testowanie, Zarządzanie

Ciarki przechodzą mi po plecach gdy czytam na różnego typu forach, tudzież goldenline i linkedin posty z pytaniami typu: „Jak estymować testowanie w Agile?”, „Jak raportować postępy testów w Agile?”, „Jak dokumentować testy w Agile?”, „Jak organizować pracę zespołu testowego w Scrum?”, „Jak przeprowadzać, planować testy wydajności w Agile?”. Jako, że staram się być pragmatyczny (a w tym przypadku po prostu nie chce mi się odpisywać za każdym razem na wszystkie posty tego typu) postanowiłem odpowiedzieć, a przynajmniej spróbować odpowiedzieć na powyższe pytania tutaj.

Jak estymować testy w Agile?
Testy i testowanie czy to automatyczne czy manualne są integralną częścią procesu developmentu i jako takowa część powinny być estymowane razem z innymi zadaniami developerskimi typu analiza i estymacja. Na przykład gdy estymujemy Itemy (User Stories) w Scrumie to szacujemy estymaty dla całego itemu (chyba, że jest zbyt duży – wtedy dzielimy na mniejsze), zawierając w naszej estymacie trudność wykonania zadania jako całości, czyli zawieramy w tym analizę, implementację, a także testy. Dopiero podczas drugiej części Sprint Planningu (bardziej szczegółowej) rozbijamy Itemy na poszczególne taski, gdzie jednym z zadań może być przetestowanie User Story lub napisanie testów automatycznych. Niemniej jednak należy uważać na to by nie popaść w mini-waterfall w każdym itemie – żeby lista tasków nie wyglądała w ten sposób: 1. analiza, 2. implementacja, 3. testy. Ciężko jest mówić o czymś takim jak „proces testowy” w Agile, dlatego nie można mówić o estymacji testów.

Jak raportować postępy testów w Agile?
Zwinne metodyki wytwarzania oprogramowania stawiają na szeroko rozbudowaną automatyzację. Najlepszym raportem z testów automatycznych (chociaż niekoniecznie doskonałym) jest raport z pokrycia kodu testami (code coverage). Zgodnie z zasadami Definition of Done każde zreleasowane zadanie musi przejść testy, więc raportem z testów jest sam fakt ukończenia zadania.

Jak dokumentować testy w Agile?
Jak wyżej – stawiamy na automatyzację, automatyczne skrypty testowe same w sobie stanowią specyficzną dokumentację do kodu aplikacji. Jeśli natomiast dodamy do tego elementy BDD z wykorzystaniem odpowiednich narzędzi służących do pisania wykonywalnych scenariuszy użycia mamy od razu wykonywalną dokumentację testową wraz z testami. Raporty tworzą się oczywiście automatycznie. W Agile jednym z kluczowych elementów jest zaufanie, jeśli powierzamy komuś zadanie to dlatego, że ufamy, iż wykona to zadanie dobrze (najlepiej jak potrafi), z tego założenia wnioskujemy, że dokumentacja przebiegu testów nie jest potrzebna. Aby to zrozumieć warto się zastanowić po co dokumentujemy testy – ja widzę dwa główne powody:
1. zapewnienie powtarzalności,
2. zapewnienie możliwości sprawdzenia czy testy zostały wykonane dobrze, zgodnie z wymaganiami, ile i jakie wymagania zostały przetestowane,
Ad 1. Jeśli potrzebujemy powtarzalności to automatyzujemy testy i powtarzalność jest zapewniona, nie wspominając o innych korzyściach.
Ad 2. Jeśli ufamy testerowi to nie potrzebujemy weryfikować jego pracy, pokrycie wymagań testami możemy sprawdzić przeglądając testy automatyczne. Dokumentacja testów jest między innymi po to by oceniać pracę testera, w Agile skupiamy się na celu i efekcie końcowym, jeśli aplikacja działa dobrze i spełnia wymagania biznesowe, a błędy nie pojawiają się na produkcji to znaczy, że nie tylko testerzy ale cały zespół spisał się dobrze, jeśli natomiast na produkcja pojawiają się błędy to wina leży po stronie całego zespołu a nie tylko testera.

Jak organizować pracę zespołu testowego w Scrum?
Przepraszam czego? W Scrum nie ma takiej roli jak „Tester” – jest natomiast Developer. Przez „Developerów” mamy na myśli wszystkie osoby dodające do naszego projektu jakąś wartość. Widziałem próby organizacji pracy zespołów testerskich za pomocą Scrum – ale proszę nie nazywajmy tego Scrum. To, że testerzy spotykają się co rano i odpowiadają na trzy pytania, że mają jedną osobę wyznaczoną do usuwania impedimentów, że pracują w iteracjach wcale nie oznacza, że jest to Scrum. W Scrum nie ma zespołów programistów i zespołów testerskich jest jeden Scrum Team w skład którego mogą wchodzić developerzy o różnych umiejętnościach w tym także umiejętnościach testerskich, zespoły tego typu powinny być interdyscyplinarne

Jak planować i przeprowadzać testy wydajności w Agile?
Odpowiednia wydajność jest (powinna być) jednym z kryteriów akceptacji dla poszczególnych itemów czy całych projektów. Powinna się także znaleźć w Definition of Done. Testy wydajnościowe a także inne testy niefunkcjonalne to także integralna część developmentu, więc powinny być wykonywane zawsze wtedy, gdy są potrzebne. Skupiamy się na celu, a dzięki krótkim iteracjom i rozbijaniu zadań na jak najmniejsze możemy bardzo często mierzyć zmiany wydajności (oczywiście w sposób zautomatyzowany) i reagować, gdy tylko zauważymy jej spadek, poprawiając błędy znacznie niższym kosztem niż gdybyśmy testowali wydajność na samym końcu.

Rozumiem, że niektórym (z moich obserwacji wynika, że przerażającej większości, ale to tylko moje obserwacje) trudno jest się przestawić z tradycyjnego myślenia obciążonego procedurami na myślenie zwinne pozbawione ograniczających procedur i oparte na prostych regułach, które nie tylko pozwalają, ale nawet często zmuszają do myślenia „out of the box”, do wykroczenia poza schematy i skupienia się czasem na tym co tak właściwie jest naszym celem. Nie da się ukryć, że „myślenie zwinne” różni się od tradycyjnego, oprócz samego nastawienia na cel ważnych jest kilka innych czynników – chociażby takich jak wspomniane zaufanie, umiejętność współpracy w zespole i pomiędzy zespołami (tak, Agile i Scrum się skalują i czasem mamy więcej niż jeden zespół!). To prawda, że Scrum jest megaprosty, że można opanować jego zasady w kilka godzin, niemniej jednak opanowanie zasad Scrum nie oznacza, że w Scrumie potrafimy pracować, że potrafimy się w nim odnaleźć. Aby być zwinnym potrzebna jest nam praktyka i dobrzy nauczyciele, potrzeba też teorii, ale przede wszystkim musimy być otwarci na zupełnie nowe, czasami dosyć abstrakcyjne spojrzenie na wytwarzanie oprogramowania.

Jeśli macie więcej pytań podobnych do powyższych piszcie, a postaram się znaleźć na nie odpowiedź (jakąś odpowiedź, bo nie na wszystkie pytania da się odpowiedzieć dobrze).

1 komentarz więcej...

Dług technologiczny

opublikowany przez 14, Lip, 2011, w kategoriach Agile, Automatyzacja, Testowanie

„Blog o jakości oprogramowania” – chyba łatwiej mi się pisze ostatnio o brakach w jakości oprogramowania niż o samej jakości.

Rozwój oprogramowania to bardzo złożony proces, na który wpływ ma wiele czynników, jednym z najważniejszych są szeroko rozumiane wymagania biznesowe. Wiadomo, jeśli nie wiadomo o co chodzi to pieniądze – po coś oprogramowanie się tworzy i przeważnie robi się to właśnie dla pieniędzy (nawet oprogramowanie Open Source jest w pewnym sensie tworzone dla pieniędzy, w mniej lub bardzie pośredni sposób ktoś na tym zawsze zarabia). W większości przypadków to tak zwany „Biznes” steruje rozwojem oprogramowania (w odpowiedzi na właśnie takie zapotrzebowanie powstały zwinne metodyki wytwarzania oprogramowania – by Biznes mógł jeszcze częściej i szybciej reagować na zmiany rynkowe). Niestety często bywa tak, że presja ze strony Biznesu jest na tyle duża, że zapomina się o tym by o wspomnianą na początku tej notki jakość dbać. Tworzy się nowe funkcjonalności zapominając o pisaniu testów, dokumentacji, refactoringu, odpowiednim projektowaniu etc. bo przecież nie ma na to czasu, liczy się tylko zwielokrotnianie zysków, dodawanie wartości do oprogramowania (testów, dokumentacji, projektowania nie da się w żaden sposób przeliczyć na wymierne korzyści finansowe) – w ten właśnie sposób tworzy się coś co nazywamy Długiem Technicznym (albo Długiem Technologicznym). Dług Techniczny (Technical Debt) swoją nazwę zawdzięcza podobieństwu do zwykłej pożyczki zaciągniętej w banku. Każdy pominięty test, nieudokumentowany ficzer, dodanie czegoś ad-hoc – bez odpowiedniego zaprojektowania prowadzi do obniżenia ogólnie pojętej jakości projektu, co w rezultacie prowadzi do widocznego spowolnienia rozwoju prac nad projektem.

Pozwolę sobie przytoczyć cytat z pewnego CTO, z którym miałem okazję kiedyś porozmawiać nt. jakości oprogramowania wytwarzanego przez podległych mu programistów: „Rok temu pracowaliśmy kilka razy szybciej, teraz wszystko jakby spowolniło – prawdopodobnie programiści się rozleniwili”. Wspomniany dyrektor był zdenerwowany tym, że rok wcześniej główny projekt firmy rozwijał się 6 razy szybciej niż obecnie. Domniemana przyczyną było „rozleniwienie programistów”,  którzy poczuli się zbyt bezpiecznie na swoich pozycjach – „przecież z tej firmy jeszcze nikogo nie zwolnili”. W odpowiedzi na domysły tego pana zadałem kilka pytań w stylu: Czy piszecie testy jednostkowe? Czy mierzycie pokrycie kodu testami? Jak wygląda wasza dokumentacja? Jak wyglądają wasze środowiska testowe? Czy możecie mi pokazać projekt architektury waszych aplikacji? etc… Na większość z tych pytań odpowiedź była negatywna (w sensie „nie, nie mamy czegoś takiego”). Przyczyną takiego stanu rzeczy była duża presja ze strony klientów, którzy wymagali jak najszybszych dostaw nowych ficzerów w celu zwiększenia zysków (co zresztą udawało im się przez dłuższy czas całkiem nieźle). Niestety nacisk tylko na wytwarzanie wartości biznesowej spowodował zanik takich praktyk jak testowanie, pisanie dokumentacji, czy nawet projektowanie – wszystko działo się ad-hoc, bez planu i spójnej wizji. W ten oto sposób powstał Dług Technologiczny, którego efektem było spowolnienie pracy. Nie wspomnę już o tym, że 80% czasu zajmowało łatanie dziur i naprawianie bugów.

Nazwa „Dług” nawiązująca do kredytu bankowego jest jak najbardziej adekwatna. Wyobraźmy sobie sytuacje w której w celu rozbudowania naszego przedsiębiorstwa i zwiększenie jego zysków zaciągamy kredyt w banku. Za uzyskane w ten sposób pieniądze inwestujemy w nowe maszyny, czy też zatrudniamy więcej ludzi co w pewnym stopniu zwiększa nasze zyski. Po jakimś czasie decydujemy się na jeszcze większe rozbudowanie naszego przedsiębiorstwa, więc bierzemy kolejny kredyt. Znowu zyski rosną. Robimy tak jeszcze kilka razy i nagle okazuje się, że owszem – mamy całkiem pokaźne przychody, ale większość zysków konsumują odsetki z zaciągniętych kredytów.

Sama świadomość tego, że taki dług zaciągamy jest już całkiem pozytywna – jeśli tylko WSZYSCY zdają sobie sprawę z konsekwencji takich a nie innych decyzji. Niestety z moich obserwacji wynika, że w większości organizacji z którymi miałem do czynienia ludzie nie mają pojęcia o czymś takim jak Technical Debt, lub nawet jeśli coś o tym, kiedyś słyszeli to nie potrafią wskazać u siebie miejsc w których taki dług jest zaciągany. Prawdę powiedziawszy to w każdej, nawet najlepiej zorganizowanej firmie zawsze znajdą się miejsca, w których w jakimś stopniu taki dług się nawarstwia.

Podobnie jak normalny kredyt, także Dług Techniczny trzeba w końcu spłacić. O tym jak można to robić napiszę następnym razem.

4 komentarze więcej...