blog.testowka.pl

Archiwum

Pytaliście o następny Agile Coach Camp PL?

opublikowany przez 09, Lut, 2016, w kategoriach Agile, ALE

Gdy opublikowałem pierwszą relację z pierwszego ACCPL dopytywaliście o to, skąd można się dowiedzieć o następnych? Odpowiedziałem, że warto śledzić mojego bloga i twittera 😉 więc aby nie być gołosłownym… Rejestracja rusza jutro  (jak tylko będę coś więcej wiedział, to będe twittował)!

Kiedy?
22-24 kwietnia 2016 r.

Gdzie?
Hotel Podklasztorze w Sulejowie.

Ile jest miejsc?
60

Cena:
600 PLN

Więcej szczegółów tutaj: https://accpl.wordpress.com/

 

W imieniu organizatorów zapraszam. Ostatnio bilety rozeszły się w dwa dni więc nawet nie próbujcie się zastanawiać nad rejestracją tylko klikajcie i wpłacajcie kasę – warto! Do zobaczenia!

Dodaj komentarz więcej...

Gemba Walk w IT – robimy to źle?

opublikowany przez 25, Sty, 2016, w kategoriach Inne

Ostatnio wdałem się przypadkiem w bardzo ciekawą dyskusję z Michaelem Feathersem na Twitterze. Micheal sprowokował mnie do dyskusji stwierdzeniem:

Gemba is the place where value is created. In manufacturing the genba is the factory floor. In a software org, it’s the code.

Gemba Walk to sposób na odkrywanie problemów. Zgodnie z definicją chodzi o to, by osoby decyzyjne przebywały od czasu do czasu w miejscu gdzie tworzona jest wartość – w miejscu pracy, wśród ludzi (lub maszyn) wytarzających tą wartość. W ten sposób osoby decyzyjne poznają naturę problemów z jakimi boryka się ich organizacja i są w stanie je skutecznie rozwiazywać  W fabryce miejscem takim jest hala produkcyjna. Pozostaje pytanie co jest takim miejscem w organizacji bazującej na wytwarzanym oprogramowaniu?

W całym tym naszym Agile ciągle powtarzamy, że chodzi o to, żeby zbliżyć IT do biznesu. Wynika to między innymi z potrzeby przezwyciężenia  Prawa Conwey’a, które mówi o tym, że organizacje projektujące systemy, budują rozwiązania, które są odzwierciedleniem struktur komunikacyjnych tych organizacji. Jak zatem to robimy i dlaczego źle? Wszystkie te nasze Scrumy i inne metody zakładają, że trzeba zbliżyć developerów do biznesu. Trzeba rozmawiać z biznesem na temat produktów i domeny biznesowej, tak aby developerzy lepiej rozumieli biznes.

Jako Agile Coach czy Scrum Master moja praca sprowadzała się zazwyczaj do sprawienia by developerzy zobaczyli trochę szerszą perspektywę niż ich kawałek kodu i jednocześnie by biznes zrozumiał o co chodzi w tym developmencie. I zazwyczaj to wystarczało by znacząco poprawić efektywność stosowanych procesów.

A co jeśli to jest niewystarczające? A co jeśli można by osiągnąć znacznie więcej? A co gdybyśmy spróbowali zrobić to wszystko w drugą stronę, a najlepiej w obie i nie tylko ciągać developerów do biznesu, ale też biznesowi pokazać kod? W końcu w Gemba Walk chodzi o to, by to osoby decyzyjne poruszały się po miejscu, gdzie tworzona jest wartość. O ile developerzy owszem mają wpływ na wiele decyzji i sporo ich mniej lub bardziej świadomie podejmują to jednak przeważnie więcej decyzji podejmowanych jest w biznesie.

Co by się stało gdybyśmy pokazali biznesowym osobom decyzyjnym nasz kod, albo przynajmniej architekturę aplikacji? Co by było gdybyśmy co tydzień poświęcali godzinę na przeprowadzenie naszego CEO przez kawałek kluczowego dla naszej aplikacji kodu?  Ile problemów mogli byśmy w ten sposób wykryć?

No dobra, może nie od razu CEO ale może ktoś inny z biznesu powinien od czasu do czasu przejrzeć nasz kod… Jak często zdarza się wam, że nazewnictwo klas czy metod użyte w kodzie nijak się ma do języka stosowanego w biznesie? Jak często coś takiego prowadziło do nieporozumień? Jak często mówicie, że czegoś nie da się zrobić w waszej aplikacji, gdyż model aplikacji zupełnie nie odpowiada modelowi biznesowemu waszej organizacji?

 

 

 

 

Dodaj komentarz więcej...

Jeśli nie wiadomo o co chodzi…

opublikowany przez 10, Lut, 2015, w kategoriach Praca, Programowanie, Testowanie, Zarządzanie

…to chodzi o pieniądze…

Konkretnie o stawki w widełkach płacowych w ogłoszeniach o pracę. Już któryś raz spotkałem się z opinią, że ogłoszenia o pracę dla developerów/testerów/etc. powinny zawierać widełki płacowe. Oczywiście się z tym zgadzam. Ale ostatnio na grupie poświęconej testowaniu oprogramowania na Facebooku pojawił się też pomysł by widełki te nie były zbyt szerokie. Z perspektywy (dosyć świeżego) pracodawcy to mnie to troszeczkę ukłuło.

Co jeśli ktoś płaci ludziom faktycznie pomiędzy 2k a 10k PLN i to faktycznie zależy od umiejętności danej osoby? W Pragmatic Coders szukamy zarówno doświadczonych wymiataczy jak i osób ambitnych lecz jeszcze z niewielkim doświadczeniem, które maja duży potencjał. Ponadto zdarza się, że sporo osób z najwyższymi oczekiwaniami finansowymi (pytamy o to zanim zaprosimy kogoś na rozmowę) wypada dużo słabiej na rozmowach niż osoby z oczekiwaniami z pierwszej połowy widełek.
 
Sami zatrudniamy ludzi i stawki są naprawdę różne (może nie aż tak rozjechane, ale jednak) i faktycznie jest to w dużej mierze zależne od ich umiejętności. A raczej od tego jak dobrze wypadną na rozmowie/podczas rozwiązywania zadań rekrutacyjnych.
Jeśli chciałbym wrzucić widełki typu 8-10k to musiał bym podziękować większości kandydatów, których zatrudniliśmy bo najzwyczajniej ich umiejętności nie były dla nas tyle warte. Nie wiem też ile osób doszło by do wniosku, że są po prostu „za słabe” na takie pieniądze i by do nas nie napisało. Niemniej jednak dzięki temu, że nasze widełki są szersze pracujemy teraz z ludźmi z dużym potencjałem, których pensje odpowiadają ich umiejętnościom.
 
To co proponuję wszystkim malkontentom, którzy narzekają na brak czy niedokładność widełek to aby podawali swoje oczekiwania finansowe w przesyłanych CV. Wystarczy zrobić tam dopisek, żeby pracodawcy nie zawracali nam głowy jeśli uważają, że na podstawie CV/profilu na linkedIn/20 minut rozmowy przez telefon nasze umiejętności nie są dla nich tyle warte, lub jeśli w ogóle nie są w stanie tyle zapłacić komuś na tym stanowisku. Z mojego doświadczenia – takie coś w zasadzie eliminowało temat pieniędzy podczas dalszych rozmów lub było to dogadywane z różnym skutkiem na samym początku komunikacji. I pisze to zarówno z perspektywy kandydata jak i pracodawcy. 
 
Oczywiście moja propozycja nie wyklucza potrzeby widełek w ogłoszeniach. To tylko pewna propozycja rozszerzenia netykiety dla wspólnego dobra pracodawców i kandydatów. 
 
Z trzeciej strony jeśli dla kogoś jedynym powodem do tego by z nami współpracować miała by być kasa, to nie jestem przekonany czy wszyscy będziemy docelowo z takiego układu zadowoleni.
Osobiście gdy, kiedyś szukałem pracy to uważałem, że podanie moich oczekiwań płacowych na początku kontaktów (w CV, pierwszym mailu, przez telefon) to po prostu pragmatyczna oszczędność czasu osoby rekrutujące ale także przede wszystkim MOJEGO… Także szczerze polecam taki sposób komunikacji – także z nami gdybyście programowaniem w Pythonie byli zainteresowani.

4 komentarze 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...

Kurs Selenium część 4 – Pierwszy Test

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

Całość kursu dostępna tutaj
Potrzebujemy zaimportować odpowiednie zależności:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.Test;

Powyższe powinno wystarczyć
Aby nasze testy mogły korzystać z selenium driver potrzebujemy zainicjować obiekt WebDriver oraz potrzebujemy adnotacji @Test.

@Test
public AppTest(String testName) {
	WebDriver driver = new FirefoxDriver();
	driver.get("http://blog.testowka.pl");
        driver.close();
}

Teraz wystarczy trochę posprzątać. Przede wszystkim wyciągamy inicjację drivera do metody setUp() oznaczoną adnotacją @BeforeClass.

@BeforeClass
public void setUp() {
	driver = new FirefoxDriver();
}

Następnie zamykanie przeglądarki do metody tearDown() oznaczonej adnotacją @AfterClass

@AfterClass
public static void tearDown() {
	driver.close();
}

Nasz test powinien wyglądać tak:

import org.testng.annotations.AfterClass;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.testng.annotations.BeforeClass;
import org.testng.annotations.Test;

public class AppTest {

	static WebDriver driver;

	@BeforeClass
	public void setUp() {
		driver = new FirefoxDriver();
	}

	@Test
	public void ShouldTestowkaPlPageBeOpenable() {
		driver.get("http://blog.testowka.pl");
	}

	@AfterClass
	public static void tearDown() {
		driver.close();
	}
}

Jak zapewne zauważyliście nasz test jeszcze niczego nie testuje, gdyż nie ma w nim asercji. Dodajemy więc asercje sprawdzającą czy tytuł strony jest poprawny.

Importujemy bibliotekę z asercjami:

import static org.testng.Assert.*;

Dodajemy asercje do testu:

@Test
public void ShouldTestowkaPlPageBeOpenable() {
	driver.get("http://blog.testowka.pl");
	assertEquals(driver.getTitle(), "blog.testowka.pl");
}

 

6 komentarzy więcej...