blog.testowka.pl

Archiwum wiadomości z Sierpień, 2013

Kurs Selenium część 7 – Asynchronicznie doładowywane elementy na stronach

opublikowany przez 26, Sie, 2013, w kategoriach Kurs Selenium

Całość kursu dostępna tutaj.

Kilka razy zgłaszaliście się już do mnie z pytaniami odnośnie problemu z asynchronicznym doładowywaniem poszczególnych elementów na stronach internetowych, które testujecie.

Problem ten objawia się często niedeterministycznym zachowaniem testów, które raz na jakiś czas nie przechodzą. Oczywiście może to być objaw także wielu innych problemów, niemniej jednak najczęściej spowodowane jest to właśnie tym, że niektóre elementy na stronie są doładowywane asynchronicznie już po załadowaniu całej strony.

Jak wcześniej pisałem WebDriver opiera się na działaniu silnika przeglądarki. Przeglądarki internetowe po załadowaniu i wyświetleniu kodu strony (kodu html) otrzymują od serwera status „200 OK”. To właśnie na podstawie tej informacji Selenium uznaje, że strona się już załadowała więc pora na rozpoczęcie kolejnych akcji.

Coraz częściej jednak załadowanie samego kodu html z serwera to dopiero początek renderowania strony internetowej. Po potwierdzeniu statusu od serwera następuje jeszcze szereg asynchronicznych wywołań, które doładowują do strony poszczególne elementy. Często też różne efekty graficzne jak płynne wyłanianie się poszczególnych elementów, dzieje się już po załadowaniu strony, a elementy te nie są jeszcze przez chwile widoczne.

Podsumowując czasem Selenium zobaczy taki element (jeśli wyświetli się on dostateczni szybko) a czasem nie. Brak deterministycznego zachowania testów zasadniczo obniża ich jakość i wartość.

Oczywiście można próbować wstawiać różnego rodzaju pauzy w naszych testach – niestety takie podejście po pierwsze brzydko wygląda a po drugie zasadniczo spowalnia nasze testy.

Jest na to lepszy sposób. Selenium (od niedawna0 dostarcza wbudowanej funkcji, która oczekuje na pojawienie się elementu:

WebElement myDynamicElement = (new WebDriverWait(driver, 10))
  .until(ExpectedConditions.presenceOfElementLocated(By.id("login")));

Powyższe sprawdza, czy element jest widoczny w strukturze html oraz widoczny na stronie (to nie zawsze to samo).

Możemy też sprawdzić, czy element jest na przykład klikalny:

WebDriverWait wait = new WebDriverWait(driver, 10);
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")));

Dzięki takiemu podejściu unikamy brzydkich opóźnień w naszych testach. Powyższe kawałki kodu oznaczają, że test będzie czekał maksymalnie 10 sekund na to aż element się pojawi, sprawdzając co kilka milisekund czy być może się już pojawił. Gdy tylko element stanie się widoczny skrypt oczekujący przerwie czekanie i nasze testy ruszą dalej.

Pozostaje pytanie czy zawsze stosować tego typu podejście? Możemy nawet ten kawałek kodu dodać bezpośrednio do metod typu „insertText” czy „click”, które sobie stworzymy. Należy jednak pamiętać, że tego typu podejście będzie o 10 sekund opóźniało wykonanie każdego testu zanim test nie przejdzie, jeśli jakiś element faktycznie się nie wyświetla.

17 komentarzy więcej...

Kolejny post o diecie

opublikowany przez 21, Sie, 2013, w kategoriach Agile, Kanban, Scrum, XP, Zarządzanie

Dieta

I po raz kolejny będę pisał o diecie. O diecie dla organizacji. Tym razem zainspirował mnie artykuł, który Dion Almaer opublikował na portalu medium.com (swoją drogą sporo fajnych tekstów na tym portalu, sam też powoli zaczynam tam publikować – polecam).

Wróćmy na chwilę do poprzedniego wpisu w tym temacie oraz odpowiedzi nadesłanej przez Michała Gozderę. Ciekawą dyskusję wywołały powody przejścia na dietę. W przypadku diety mojej własnej może to być na przykład chęć lepszego samopoczucia czy też uzyskanie możliwości patrzenia w lustro bez odrazy do samego siebie. Może to być idea zdrowego i długiego życia, na które szans nie mamy, gdy mamy nadwagę i źle się odżywiamy. A może po prostu chcieli byśmy uzyskać lepszą sprawność fizyczną i wypracować lepszą kondycję by nie umierać po przebiegnięciu kilkunastu metrów w pogoni za odjeżdżającym autobusem.

Podobnie jeśli chcemy zmienić (odchudzić) naszą organizację również musimy mieć do tego dobry powód. Na tyle dobry byśmy sami byli do niego wystarczająco przekonani i byśmy mogli przekonać innych. Często będzie to już niepokojący stan obecny naszej firmy (nie możemy spokojnie spoglądać w lustro).

Dion w swoim artykule napisał coś bardzo istotnego – należy zacząć od restrykcyjnej diety, gdyż uprawianie sportu przy dużej nadwadze wcale nie sprawia przyjemności. Podobnie w przypadku organizacji, gdy cierpi ona na „nadwagę” nie sposób wdrożyć w niej pewnych metod takich jak na przykład TDD czy chociażby automatyzacja testów. A już na pewno nie będzie to przyjemne i łatwe.

Jak już wcześniej pisałem metody takie jak Kanban czy Scrum są swego rodzaju dietą dla naszej organizacji. Same w sobie nie wystarczą do tego, by już na zawsze być zwinnym. Do tego potrzeba długotrwałych zmian nawyków żywieniowych czyli w naszym przypadku zmiany kultury organizacyjnej.

Czy to znaczy, że z pewnymi praktykami i metodami musimy poczekać? Nie, czekać nie musimy, a nawet nie powinniśmy – wspomniane praktyki dodatkowo wzmacniają dyscyplinę i poprawiają efekty naszej „diety”. Niemniej jednak należy pamiętać o tym, że w pewnych sytuacjach będzie to bolesne i może nawet prowadzić do „uszczerbku na zdrowiu”. Bieganie przy dużej nadwadze może skończyć się problemami z kręgosłupem i/lub stawami u nóg, dlatego taki trening musi być dobrze dopasowany do naszych możliwości.

Zasada numer jeden: „mniej jeść” – a w zasadzie jeść rozsądniej i bardziej świadomie. Czy nie na tym właśnie bazuje Scrum czy Kanban? Mamy jeden backlog i ograniczone możliwości realizacji zadań więc musimy wybrać to co jest na tym backlogu najbardziej wartościowe.

Wyobraźmy sobie, że nasze codzienne menu jest zapisane w postaci backlogu – dodajmy limit kalorii (czyli nasze velocity) i teraz możemy uporządkować backlog tak by osiągnąć największą wartość (wartość odżywczą i jednocześnie przyjemność z jedzenia). Nie, nie próbowałem tego – to tylko taki eksperyment myślowy (ale w sumie kto wie…).

Jeszcze jedno wartościowe przesłanie z wspomnianego artykułu – bardzo ważne są widoczne efekty. To właśnie one wzmacniają naszą motywację do dalszego działania. Dlatego też warto zwłaszcza na początku obrać strategię małych zmian dających widoczne efekty.

1 komentarz więcej...

Kilka „prawd” o życiu i nas samych

opublikowany przez 13, Sie, 2013, w kategoriach Agile, Coaching

Poniżej prezentuję kilka wybranych prawd/wierzeń co do natury człowieka i natury naszego życie, którymi od kilku lat staram się kierować. O wielu z nich już wspominałem na blogu, wydaje mi się jednak, że zebranie ich razem w jednym poście może być wartościowe.

Ludzie zawsze podejmują najlepsze w danym momencie decyzje – decyzje, które podejmujemy w naszym życiu czy w pracy zależą od wielu czynników. Niemniej jednak zawsze podejmujemy decyzje, które w danym momencie wydają nam się najlepszymi. Właśnie to, że tak nam się wydaje świadczy o tym, że są najlepszymi. Ich faktyczna poprawność zależy tak naprawdę od ilości i jakości informacji, które w momencie posiadania decyzji posiadamy. To właśnie dlatego jest nam tak łatwo krytykować nasze własne decyzje z perspektywy czasu, kiedy to posiadamy już więcej informacji na dany temat.

Ludzie zawsze mają dobre intencje – może raczej ludzie przeważnie maja dobre intencje. Prawda jest taka, że statystycznie ludzie źli trafiają się bardzo rzadko. Na tyle rzadko, że w ogóle można by to pominąć. Niestety nasze przeświadczenie o możliwych konsekwencjach błędnego założenia, że osoby, które spotykamy na swojej drodze mają zawsze dobre intencje sprawia, że przeważnie mamy problemy z uwierzeniem w powyższe stwierdzenie. Warto pamiętać o tym, że ludzie zwłaszcza w swojej własnej ocenie zawsze mają dobre intencje co wcale nie znaczy, że obiektywnie (albo raczej subiektywnie, z naszej perspektywy) oceniając ich działania ocenimy je jako pozytywne. Tutaj znowu pojawia się kwestia informacji, wiedzy i edukacji na temat tego, co jest „właściwe”.

Ludzie zawsze pracują (wykonują zadania) najlepiej jak potrafią (najlepiej jak mogą) – należało by dodać najlepiej jak „w danej chwili” mogą/potrafią. Na nasze możliwości wpływ ma wiele różnych aspektów takich jak motywacja, samopoczucie, nastrój i wiele innych. Jeśli ktoś wykonuje swoją pracę w sposób w naszej ocenie niewłaściwy nie powinniśmy szukać przyczyn takiego stanu rzeczy w tej osobie ale raczej w jego otoczeniu i jego relacjach z tymże otoczeniem. Często ludzie po prostu nie wiedzą jak/że można zrobić coś lepiej i w ich ocenie to jak wykonują powierzone im zadania jest najlepszą możliwością. W takich przypadka potrzebna jest dodatkowa edukacja.

Zmiana jest niezmienna – jedyną rzeczą której możemy być pewni jest to, że nic nie jest pewne. Ciągłe zmiany zachodzące wokół nas i w nas są ciągłym, nieprzerwanym procesem. Jedyne co możemy z tym zrobić to zaakceptować zmiany i nauczyć się jak się z nimi obchodzić.

Zawsze otrzymujemy to co jest wzmacniane – to jest temat na dłuższą dyskusję, wspomniałem też o tym w książce „Mity i problemy w Agile”. W dużym skrócie jeśli prosimy innych by coś dla nas zrobili zawsze dostajemy to czego od nich chcemy. Jeśli wyznaczamy w naszej organizacji KPI to ludzie będą pracować tak by ten KPI był spełniony, ale najprawdopodobniej zaprzestaną pracy w innych płaszczyznach i nad innymi celami. Z drugiej strony wzmacnianie ma też aspekt mocno personalny – jeśli będziemy skupiać się wyłącznie na problemach to nawet mimo szczerych chęci i ciężkiej pracy cały czas będziemy pozostawać na etapie rozwiązywania problemów.

Ludzie są „work in progress” – wydaje mi się, że wiele zostało by utracone przy tłumaczeniu tego stwierdzenia. To nie prawda, że ludzie się nie zmieniają. Jak wyżej jedyne co się nie zmienia to, to, że wszystko się zmienia – również, a w zasadzie zwłaszcza ludzie się zmieniają. Cały czas mamy możliwości i okazje do pracy nad samym sobą i do zmian naszych zachowań, możliwości, natury etc. Mamy też możliwość wpływu na rozwój i zachowania innych.

Wszystko co się dzieje ma jakieś znaczenie – nie ma rzeczy bez sensu. Wszystko co w naszym życiu się dzieje ma jakieś znaczenie. Nie, nie chodzi mi o to, że wszystko zostało w jakiś sposób z góry zaplanowane i przewidziane… Wszystko co w naszym życiu się do tej pory wydarzyło wywarło na nas jakiś wpływ. Jesteśmy sumą naszych doświadczeń.

Każdy człowiek jest nauczycielem – jesteśmy nie tylko sumą naszych doświadczeń ale także sumą doświadczeń innych osób które na naszej drodze spotkaliśmy. Uczymy się cały czas od każdego kogo spotykamy. Robimy to mniej lub bardziej świadomie. Nawet idąc ulicą i mijając drugiego człowieka, gdy mimowolnie spoglądamy na niego oceniamy to jak wygląda, jak jest ubrany, jak się porusza etc. Na tej podstawie kształtujemy nasze własne decyzje i działania w przyszłości.

Nie ma czegoś takiego jak błędy – jeśli przyjmiemy, że zawsze podejmujemy najlepsze możliwe decyzje to eliminujemy możliwość popełniania błędów. Przecież błąd to właśnie nic innego jak zła decyzja. Decyzje, które po czasie okazują się, że mogły być lepsze są niczym innym jak tylko wartościowymi lekcjami i doświadczeniami, z których możemy czerpać w przyszłości.

I na zakończenie coś czego nauczyłem się ostatnio: każdy z nas jest ekspertem od naszego własnego życia – bez względu jakie fajne, pełne, ciekawe  i wartościowe jest moje życie to w kwestii Twojego życia to właśnie Ty, a nie ja jesteś ekspertem w dziedzinie swojego życia. Oczywiście mogę Ci doradzać, dawać przykład, pokazywać ogólne prawdy (jak te opisane w tym poście) ale w ostatecznym rozrachunku to Ty wiesz lepiej co jest najwłaściwsze w Twoim życiu. Oczywiście mogę pomóc Ci to odkryć ale nadal to będą Twoje odkrycia, Twoje decyzje i Twoja odpowiedzialność.

Nawet to jak wykorzystasz ten artykuł zależy wyłącznie od Ciebie…

8 komentarzy więcej...

David Evans w Warszawie

opublikowany przez 10, Sie, 2013, w kategoriach Agile, Automatyzacja, Testowanie

23 Września 2013 roku w Warszawie odbędą się pierwsze Mistrzostwa Polski w Testowaniu Oprogramowania. Wydarzenie zapowiada się ciekawie.

Również i ja będę miał przyjemność opowiedzieć Wam podczas Mistrzostw o tym w jaki sposób efektywnie automatyzować testy i stosować BDD!

Natomiast jeszcze ciekawiej zapowiada się szkolenie „Testowanie w Agile” prowadzone przez Davida Evansa – jednego z głównych propagatorów technik takich jak Specification by example.

Osobiście liczę na to, że będę miał okazję wymienić swoje doświadczenia związane z tworzeniem wymagań i kryteriów akceptacji z autorytetem w tej dziedzinie. Kto wie – może dowiem się czegoś nowego, a już na pewno będę chciał zweryfikować swoje pomysły oraz to, jak do tej pory wykorzystywałem narzędzia takie jak Impact Mapping czy Story Mapping.

Was też zachęcam do wzięcia udziału w spotkaniu z jednym z najbardziej doświadczonych praktyków testowania w Agile.

Więcej o samym szkoleniu możecie znaleźć tutaj.

1 komentarz więcej...

Zmiany w Scrum

opublikowany przez 07, Sie, 2013, w kategoriach Agile, Scrum

Człowiek wraca sobie jak gdyby nigdy nic z wakacji, patrzy a tu zmienili mu Scrum. TAK – zmienili Scrum! Co prawda nie było jakiejś wielkiej rewolucji ale nowa wersja Scrum Guide zawiera kilka istotnych zmian wartych omówienia.

Pierwszą zasadniczą zmianę widzimy w opisie Sprintu, gdzie zniknął punk dotyczący zabraniania zmian składu zespołu w trakcie Sprintu. Zamiast tego zmianie uległ podpunkt mówiący o wprowadzaniu zmian. Zabronionym było zmienianie czegokolwiek co mogło „wpływać” na Cel Sprintu w tej chwili mowa jest o zmianach, które mogą „zagrozić” Celowi Sprintu. Na ile jest to istotna zmiana pozostawiam Waszej ocenie.

Obserwując to jak Scrum ewoluuje podejrzewam, że usunięcie podpunktu dotyczącego składu zespołu mogło być spowodowane tym, że coraz częściej zespoły korzystają z pomocy zewnętrznych ekspertów i specjalistów co daje bardzo dobre efekty. Dzięki tej zmianie w Scrum Guide teraz „legalnym” będzie dołączanie takich osób w miarę potrzeb do zespołu.

Druga zasadnicza zmiana w Scrum to usunięcie proporcji dla timeboxes w Sprintach krótszych niż jeden miesiąc. Tak na przykład Sprint Planning ma teraz timebox maksymalnie 8 godzin bez względu na długość Sprintu (chociaż zapisana została sugestia, że dla krótszych Sprintów czas ten powinien być krótszy). Osobiście tutaj obawiam się największych problemów – tak jak pisałem w „Mitach i problemach w Agile” wcześniej stosowany timebox, proporcjonalny do długości iteracji sprawdzał się w mojej ocenie bardzo dobrze. Był  minimalny i jednocześnie wystarczający. Obecne wydłużenie timeboxów dla krótszych Sprintów będzie w mojej ocenie polem do nadużyć, a w efekcie dla tygodniowej iteracji może pozostać nam zaledwie 2 i pół dnia na pracę…

Poczekamy zobaczymy. Może takie podejście pozwoli niektórym zespołom jeszcze lepiej planować i dzięki temu pracować efektywniej.

A jak już jesteśmy przy planowaniu to usunięty został sztywny podział czasowy Sprint Planning na dwie części. Teraz mamy jedno spotkanie podczas którego ustalamy co i jak będziemy robić w najbliższej iteracji, oraz po co będziemy to robić czyli Cel Sprintu.

Osobiście podoba mi się takie podejście – zresztą mówiło się o tym już od dawna i w praktyce właśnie tak wyglądały planningi zespołów którym pomagałem. Wcześniejszy podział na dwa timeboxy po 50% czasu na planowanie narzucał dużo ograniczeń i często był przyczyną marnotrawstwa.

Wzrosło też znaczenie samego Celu Sprintu. Do tej pory w Scrum skupialiśmy się na wykonywaniu pracy na zadanym poziomie jakości. Teraz istotnie podkreślone z punktu widzenia procesu zostało także wskazanie sensu wykonywanej pracy.

Wokół Celu Sprintu zostały także zbudowane nowe trzy pytania na Daily Scrum. W nowej wersji brzmią one następująco:

  • Co zrobiłem wczoraj by pomóc zespołowi developerskiemu w osiągnięciu Celu Sprintu?
  • Co będę robił dzisiaj by pomóc zespołowi developerskiemu osiągnąć Cel Sprintu?
  • Czy widzę jakieś przeszkody, które stoją na drodze mnie lub zespołowi i mogą nam przeszkodzić w osiągnięciu Celu Sprintu?

Według mnie ta zmiana ma duże znaczenie – być może takie podejście pomoże zespołom szybciej zrozumieć prawdziwy sens codziennych spotkań. Dzięki temu może wreszcie te spotkania przestaną być raportowaniem a staną się wspólną refleksją na temat tego dokąd zmierzamy i jaki jest nasz cel, oraz czy jesteśmy w stanie go osiągnąć. W wielu przypadkach wymusi to też na organizacjach regularne opracowywanie tychże celów (uwierzcie nie wszyscy mają Cel Sprintu)…

Również w celu zapobiegnięciu przeistaczania się Daily Scrum w spotkanie raportowe usunięte zostało zdanie mówiące o tym, że każdego dnia Development Team powinien być w stanie wytłumaczyć Product Ownerowi i Scrum Masterowi w jaki sposób zamierzają osiągnąć Cel Sprintu. Teraz mowa jest o tym, że zespól developerski powinien rozumieć to w jaki sposób zamierzają to osiągnąć.

Optymalizacja wartości – to kolejna istotna zmiana. W ogóle pojęcie wartości dopiero teraz pojawiło się w Scrum Guide. W nowej wersji pojawia się zwłaszcza w kontekście Sprint Review, gdzie to właśnie dostarczona wartość oraz plany dostarczenia jej jeszcze więcej powinny być głównymi tematami spotkania.

Scrum coraz bardziej wskazuje na transparencje. Nie tylko na przejrzystość tego jak pracuje zespół ale także na przejrzystość informacji na temat produktu i rynku. Dlatego też podczas Sprint Review wskazane jest omawianie także tego w jaki sposób stworzony właśnie Inkrement może zostać wykorzystany oraz tego jak wygląda budżet, najbliższe plany produktowe  i możliwości.

Kolejna wzmianka o wartości biznesowej pojawia się w kontekście Product Backlogu.  Twórcy Scrum sugerują to co ja opisywałem już miedzy innymi w „Mitach i problemach…” – elementy na Product Backlogu powinny oprócz estymatów mieć jeszcze określoną wartość biznesową. Dzięki temu transparentność zachodzi w obie strony.

Słowo Backlog Grooming zostało zamienione na Backlog Refinement z powodów o których nie warto wspominać :). Poza tym nic w tym kontekście zasadniczo się nie zmieniło.

W nowym Scrum Guide jeszcze bardziej podkreślona jest rola Scrum Mastera związana z zapewnianiem transparentności wszystkich artefaktów Scrum.

I to już w zasadzie chyba wszystkie istotne zmiany jakie udało mi się znaleźć w nowym Scrum Guide. Jeśli znaleźliście coś ciekawego o czym nie wspomniałem to w komentarzach jest dużo miejsca.

A i byłbym zapomniał – Scrum Guide ma teraz swoją własną, osobną stronę – www.scrumguides.org.

7 komentarzy więcej...