blog.testowka.pl

Podczas wytwarzania oprogramowania często mówi się o “Trójkącie Project Managera”, w którym to co chcemy osiągnąć umieszczam gdzieś pomiędzy: budżetem, scopem, a czasem i w zależności od którego z krańców trójkąta jesteśmy dalej tym więcej tego będziemy potrzebowali. W powyższym podejściu nie ma mowy o jakości, jak opisuje to Jurgen Appelo w swojej książce Management 3.0 organizacje mają tendencję do budowania łańcuszków zaufania także w tej dziedzinie – poruszając się w Trójkącie PM klienci zakładają, że to co dostaną będzie wysokiej jakości, managerowie zakładają, że zespół wie jak zbudować produkt wysokiej jakości i właśnie to robi, a zespoły developerów liczą na to, że przecież jeśli to co robią jest niewystarczającej jakość to w końcu ktoś da im jakąś informację zwrotną. Niestety rzeczywistość jest trochę bardziej bolesna – jakość (być może dlatego, że nie znajduje się ww. trójkącie i ciężko jest ja zmierzyć) jest najczęściej obcinanym elementem wytwarzanego systemu.

W przypadku zespołów samo-organizujących się (takich, które nie są bezpośrednio sterowane przez managerów i które mają określony cel i granice, w których mogą się poruszać) jeśli pokażemy trójkąt i powiemy, że naszym celem jest dostarczenie nowej wersji na konkretną datę to zespół z pewnością weźmie to za cel i za wszelką cenę będzie chciał dostarczyć produkt w określonym terminie. Orzez “wszelką cenę” mam na myśli głównie jakość, bo wszystko inne zostało już określone w trójkącie i zespół wie na co może sobie pozwolić.

Pomysłem na rozwiązanie tego problemu jest stosowanie Żelaznego Kwadratu Ograniczeń (Iron Square of Constraints) w poszczególnych rogach mamy: funkcjonalności (scope), czas, jakość, zasoby (budżet) i podobnie jak w przypadku trójkąta im bardziej oddalamy się od któregoś rogu tum większe straty ponosimy w zakresie w tym rogu zdefiniowanym.

Funkcjonalność                      Czas

——————————————-
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
——————————————-

Budżet                                       Jakość

Mam nadzieję, że mój ASCI Iron Square of Constraints jest widoczny

Oczywiście trójkąty i kwadraty to tylko pewien skrót myślowy, który pozwala na wizualizację tego co się dzieje w głowach ludzi pracujących nad produkcją oprogramowania.

Problemy z kros-funkcjonalnością zaczyna się już na etapie definicji zespołu kros-funkcjonalnego. Niestety zadając pytanie o to na czym polega kros-funkcjonalność bardzo często słyszę niepoprawne odpowiedzi.

Zespół jako całość ma posiadać kompetencje do tego by regularnie dostarczać oprogramowanie gotowe do wydania na produkcję – to jest wystarczająca definicja kros-funkcjonalności.

Ciężko jest mówić o kros-funkcjonalnych zespołach, opartych na ścisłej współpracy ich członków, dostarczających działające i przetestowane oprogramowanie na zakończenie każdej iteracji, gdy na przykład testerzy pracują w oddzielnym zespole niż programiści, często siedząc w osobnym pokoju, budynku, mieście, kraju, kontynencie – jak wtedy powiedzieć, że po zakończeniu każdej iteracji mamy działający produkt. “Scrumowy zespół testowy” to nie zespół Scrumowy.

Jeśli trzeba oprogramowanie testować (a gdzie nie trzeba?) to w skład zespołu powinni wchodzić testerzy. Jeśli do konfiguracji i wydania oprogramowania potrzebna jest praca administratora to taki administrator lub developer z odpowiednimi umiejętnościami powinien się w tym zespole znajdować. Warto wspomnieć jeszcze o tym, że taki zespół nie powinien być zbyt duży. Podział na zespoły funkcjonalne powoduje utworzenie silosów, pomiędzy którymi znajduje się ściana przez, którą jedni i drudzy przerzucają problemy na innych zamiast skupiać się na dostarczaniu wartości. Pisałem już wcześniej o probelmach komunikacyjnych, które także dotyczą takich wyspecjalizowanych zespołów zamkniętych w swoich silosach.

Niestety z powyższym wiąże się kilka problemów – np. problem ze znalezieniem odpowiednio wykwalifikowanych osób – często trzeba po prostu członków zespołu kros-funkcjonalnego szkolić od podstaw. Wszelkie protezy typu “Scrumowy Zespół Testowy” wspomniany powyżej nie będę działać tak wydajnie jak dobrze zmotywowane zespoły kros-funkcjonalne, Problem z silosami wynika też często z zaszłości historycznych – wcześniej organizacja musiała mieć określoną strukturę, posiadać poszczególne specjalistyczne działy i kierowników tych działów – niestety dla takich specjalistycznych kierowników w Agile raczej miejsca nie ma. Oczywiście mogą się oni przekwalifikować np. na Scrum Masterów, albo po prostu członków zespołu – niemniej jednak wraz z tym utracą “władzę” i większość mocy decyzyjnej – byćmoże stąd wynika częsty opór przed wdrożeniami Agile.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.

Poprzednio pisałem o długu technologicznym. Skończyłem na tym, że dług technologiczny tak jak każde inne zadłużenie trzeba prędzej czy później spłacić.

W przypadku tego długu odsetki rosną dosyć szybko, więc wydawało by się, że ze spłatą nie należy zwlekać. Niemniej jednak czasem okazuje się, że pomimo wysokiego długu i rosnących odsetek nadal opłaca się dodawać nowe funkcjonalności i rozwijać system bez dbania o jakość – przeważnie wynika to z wysokiego popytu na oferowane przez nasz system usługi – jeśli popyt jest wystarczająco duży to nasi klienci są w stanie wybaczyć niską jakość, a inwestorów nie będzie ona wcale obchodziła póki da się jeszcze coś dodać do naszego systemu tak by koszty/czas wytwarzania tej funkcjonalności nie przewyższyły zysków.

Z czasem każda aplikacja/system wytwarzane w ten sposób osiągają pewną masę krytyczną, w której nawet najmniejsza zmiana może spowodować nieodwracalne straty. Wtedy właśnie inwestorzy decydują się na spłatę zaciągniętego długu technologicznego (lub sprzedają cały biznes komuś innemu, kto od teraz będzie musiał powyższe problemy samemu rozwiązać – taki ktoś przeważnie zacznie od zatrudnienia sztabów QAów).

Nie zrozumcie mnie źle – nie krytykuję startupów za to, że pierwsze ich wersje były kaszaną programistyczną – wręcz przeciwnie, z perspektywy biznesowej takie rozwiązania są wręcz genialne – tworzymy niskim kosztem coś co zaczyna zarabiać – lub nie – i właśnie jeśli okaże się, że nasza idea nie chwyciła i nie zaczyna zarabiać to tracimy znacznie mniej, niż gdybyśmy od początku inwestowali w wysoką jakość. A jeśli nasz pomysł okaże się strzałem w dziesiątkę i zacznie zarabiać pokaźne sumy to przestają nas obchodzić koszty jakości i możemy sobie pozwolić nawet na przepisanie całego systemu od nowa, czy podwojenie liczby zatrudnionych developerów.

“Naturalną” drogą obieraną przez wiele firm podczas zaciągania długu technologicznego jest zatrudnianie coraz większej ilości programistów, których ilość ma rekompensować spadek prędkości rozwijania aplikacji. Niestety samo zwiększenie liczby pracowników nie spowoduje spłaty zaciągniętego długu, mało tego często brak dodatkowych starań w kierunku zapewniania jakości i odpowiedniej presji w tym kierunku może spowodować jeszcze większy wzrost zadłużenia – więcej osób oznacza więcej kodu słabej jakości czyli szybszy przyrost zadłużenia.

Jeśli przez długi czas żyło się na kredyt to aby spłacić zadłużenie trzeba czasem zacisnąć pasa – spłacanie długu spowoduje drastyczne spowolnienie rozwoju naszego biznesu. Wynika to z tego, że teraz dostępne zasoby będziemy przeznaczać na poprawę jakości zamiast na rozwijanie nowych ficzerów. “Poprawa jakości” czegoś co nigdy znamion tejże jakości nie nosiło często oznacza napisanie tego od nowa. Przepisywanie funkcjonalności od nowa nie jest proste. By dobrze to zrobić należy najpierw dokładnie zdefiniować to co napisana wcześniej funkcjonalność tak naprawdę miała robić, jakie były co do niej wymagania i założenia – w przypadku braku dbania o jakość o jakiejkolwiek dokumentacji wymagań przeważnie można tylko pomarzyć.

Jednym ze sposobów na rozwiązanie tego problemów jest pisanie testów funkcjonalnych typu “black box” – tworzymy testy automatyczne, które traktują daną funkcjonalność jak czarną skrzynkę – podają wartości wejściowe i sprawdzają stan na wyjściu nie wnikając w to co dzieje się w środku. Takie testy piszemy na starym systemie (przed przepisaniem) traktując go jak wyrocznie testową – zakładamy, że system działa poprawnie i zwraca prawidłowe wartości – wyrocznia prawdę ci powie. Po napisaniu tego typu testów i maksymalnym pokryciu nimi przepisywanej funkcjonalności możemy przystąpić do przepisywanie czy refaktoryzacji tejże funkcjonalności nie martwiąc się o to, że coś zepsujemy. Oczywiście jest to dosyć naiwne stwierdzenie. Niemniej jednak jest to jedno z najbardziej optymalnych rozwiązań w przypadku wcześniejszego braku jakichkolwiek testów automatycznych czy dokumentacji wymagań. Należy także pamiętać o tym by pisząc nową funkcjonalność od razu zapewniać jej wysoką jakość stosując dobre praktyki programistyczne takie jak np. TDD.

Nawet jeśli uda się uniknąć przepisywania całej aplikacji to koszty “wdrażania jakości” są wielokrotnie wyższe niż gdyby od początku tworzono software wysokiej jakości, co nie oznacza, że w skrajnych przypadkach jest to nawet bardziej opłacalne.

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).

“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.

Coraz częściej zauważam wzrost aktywności wielu firm IT na rynku pracy. Zauważam także więcej ogłoszeń dla testerów i QAów. Pojawia się też coraz więcej firm zajmujących się rekrutacją pracowników dla IT. Powodów może być wiele – czasem jest to spowodowane dynamicznym rozwojem firmy, a czasem jak to zwykle w przypadku testerów bywa próbą ratowania zbugowanego systemu.

Oglądałem kiedyś ciekawą prezentację Ken’a Schwabera wprowadzającą do Scrum. Oprócz samej tematyki Scrum poruszony został tam jeden bardzo ciekawy problem – Ken przedstawił przykładowy (sprawdzający się w większości przypadków) cykl życia start-up’ów. Wygląda to mniej więcej tak:

Kilku pomysłowych gości wpada na świetną, rewolucyjną idee i rozpoczyna pracę w swoim garażu/pokoju w akademiku/wynajętym mieszkaniu etc. Po jakimś czasie pojawia się pierwsza wersja live oferowanego systemu/aplikacji która powoli zaczyna zarabiać – na początku walczymy o to by zwróciły się koszty. Po jakimś czasie, przeważnie w wyniku niesamowitego zbiegu okoliczności start-up staje się bardzo popularny i zaczyna nagle zarabiać coraz więcej pieniędzy, co powoduje że firma się rozwija i zatrudnia więcej pracowników, którzy jak najszybciej produkują coraz to nowsze ficzery by jeszcze bardziej powiększyć zyski. Przeważnie wszyscy będąc na tej fali ciągłego powiększania przychodów nie przejmują się jakością. Po pewnym czasie projekt dociera do punktu w którym dodanie nowego ficzera staje się droższe niż zyski z niego płynące, niemniej jednak są one cały czas dodawane z różnych powodów – często czysto marketingowych nieprzekładających się na wymierne korzyści materialne. Mija jeszcze trochę czasu, po którym ktoś nagle stwierdza, że przepisanie całej aplikacji od nowa zajmie mniej czasu niż dodanie nowego ficzera. W międzyczasie zarząd/właściciele firmy zaczynają się zastanawiać nad tym jak rozwiązać problem zbyt drogich ficzerów. Jednym z rozwiązań jest pozbycie się problemu poprzez sprzedanie go innym – na rynku jest wiele firm typu venture capital, które masowo skupują start-up’y, po to by niektóre z nich przekształcić w prężnie działające przedsiębiorstwa. Zdarza się też tak, że zarząd postanawia wreszcie przenieść nacisk z wyłącznie zarabiania na polepszanie jakości (czasem też na przepisanie systemu od zera). W obydwu tych przypadkach (nieważne czy firmę kupi ktoś nowy, kto będzie chciał polepszyć jakość, czy zarząd sam zdecyduje się to zrobić) potrzebne jest zapewnienie specjalistów. Właśnie wtedy firmy decydują się na zatrudnienie zespołu QAów, którzy ogarną cały ten bałagan i zaproponują rozwiązania problemów. Czasem jest już za późno, niemniej jednak, jeśli tylko nakład na jakość jest wystarczająco duży często udaje się to osiągnąć.

W życiu każdego testera przychodzi czas na zmiany… Czasem bywa tak, że jest to zmiana pracy… Jeśli taki czas nadszedł właśnie dla Ciebie to mam dla Ciebie świetną propozycję! Szukamy testerów/inżynierów testów/QAów do naszego zespołu we Wrocławiu.

Jeśli jesteś zainteresowany/zainteresowana możliwościami dalszego rozwoju w dziedzinie automatyzacji testów, testowania, szeroko rozumianego QA etc. to zapraszam do kontaktu (jeśli napiszecie, że dowiedzieliście się o ofercie pracy z mojego bloga macie +10 do charyzmy ) . Więcej informacji możecie znaleźć tutaj.

Szukamy też programistów PHP i Python.

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.

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!

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.

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.

W tym tygodniu miałem okazję prowadzić w Warszawie dwudniowe szkolenie “Narzędzia w procesie testowym” w ramach programu szkoleń SQAM. Motywem przewodnim wspomnianego szkolenia stało się hasło będące tytułem poniższej notki.

Automatyczny chaos to tylko szybszy chaos…

Jeśli mówimy o automatyzacji testów, zarządzania testami, zarządzania konfiguracją, procedur deploymentu, zarządzania incydentami wszystko to wiąże się z wdrażaniem narzędzi. WDRAŻANIE – bardzo ciekawy termin. Według słownika języka polskiego wyraz “wdrażać” oznacza “wprowadzać coś nowego do użytku”. Ale ta notka nie będzie o samym procesie wdrażania narzędzi testowych, lecz o tym kiedy w ogóle o wdrożeniu narzędzia możemy zacząć myśleć.

Żeby zacząć planować wdrożenie narzędzia wspierającego w jakikolwiek sposób testy czy inną część procesu wytwarzania oprogramowania musi najpierw ten proces zdefiniować. Musimy mieć usystematyzowane pewne procedury, jasno określone i opisane zależności, zdefiniowany workflow etc. Jeśli zaczniemy automatyzować chaos to tylko przyspieszymy nasz marsz ku klęsce. Owszem, niektóre narzędzia służą właśnie do powstrzymywania chaosu, do porządkowania różnych elementów procesu (głównie narzędzia wspomagające zarządzanie) , niemniej jednak zanim zaczniemy używać takiego narzędzia musimy dobrze poznać jego możliwości i zaplanować sposób w jaki będziemy go używać.Powyższe wcale nie jest proste, wymaga odpowiednich przygotowań i odpowiedniego planu. Później jak już rozpoczniemy używanie narzędzia, czy to od razu w całej firmie czy w ramach jakiegoś projektu pilotażowego nadal musimy pamiętać chociażby o zapewnieniu szkoleń i wsparcia dla innych użytkowników. W dodatku musimy pilnować by przypadkiem ktoś nie zaczął używać narzędzia niezgodnie z zamierzonym workflowem.

Osobiście nie lubię narzędzi, które obsługują więcej niż jedno zagadnienie – zgodnie ze starą reklamą proszku do prania:  ” Jeśli coś jest do wszystkiego to jest do niczego”. W narzędziach cenię sobie prostotę i użyteczność, nie chcę czytać kilku tomów instrukcji by nauczyć się zgłaszania błędów, nie chcę marnować kilkunastu dni na szukanie najbardziej optymalnego sposobu używania narzędzia wspierającego zarządzanie projektem. Potrzebuje gotowych kompleksowych rozwiązań.

Bardzo często narzędzia są wdrażane w momencie, gdy pojawiają się problemy, są wdrażane po to by ratować projekt coraz szybciej zmierzający w kierunku przepaści. Wdrażanie narzędzi na miesiąc przed deadlinem to najgorsze co można zrobić. Jest już za późno by narzędzie mogło nam w czymkolwiek pomóc a wręcz przeciwnie zmarnujemy dużo czasu na jego wdrożenie etc. Później czyta się raporty mówiące o tym, że tylko 60% wdrożeń narzędzi kończy się sukcesem.

Rozpoczęcie automatyzacji testów w trakcie trwania projektu a nie na jego początku także wiąże się ze znacznym ryzykiem. Przede wszystkim w takiej sytuacji gdy testy jednostkowe i funkcjonalne nie były pisane od początku istnieje duże prawdopodobieństwo, że niektórych funkcjonalności nie da się już przetestować automatycznie. Pomysłem na rozwiązanie problemu zbyt późnego rozpoczęcia automatyzacji mógłby być refaktoring, niestety refaktoring kodu bez co najmniej 90% pokrycia kodu testami ma bardzo małe szanse powodzenia.

Błędne koło się zamyka. Nie twierdzę, że nie da się wprowadzić narzędzia do już trwającego projektu. Niemniej jednak by to zrobić, trzeba najpierw ogarnąć chaos bez narzędzi, lub przynajmniej mieć konkretny plan jak to zrobić z pomocą narzędzi.

Zapraszam na webinarium które poprowadzę w najbliższą środę (20-10-2010) o godzinie 13.00 w ramach cyklicznych e-seminariów Polskiej Grupy Scrum.

Zapisy na www.scrum.org.pl.

Temat spotkania ponownie związany z automatyzacją testów. Postaram się przybliżyć samą idee automatyzacji oraz zademonstrować kilka dobrych praktyk ułatwiających życie każdego testera. Nie zabraknie również rozwinięcia podstawowych zasad Continous Integration, oraz wskazówek jak testować w projektach Agile’owych.

Ostatnio na jednym ze śledzonych przeze mnie blogów pojawiła się świetna historyjka o smażeniu ryby, postaram się ją tutaj przetłumaczyć.

“Pewnego razu pewna mała dziewczynka, przyglądała się swojej mamie, gdy ta przygotowywała rybę do smażenia. Mama obcięła rybie ogon i głowę po czym położyła ją na patelni. Mała dziewczynka zapytała ją czemu tak właściwie obcięła rybie ogon i głowę. Mama zastanowiła się po czym odpowiedziała: w sumie to nie wiem, ale tak zawsze robiła twoja babcia a moja mama więc i ja tak robię. Mała dziewczynka była bardzo dociekliwa wiec postanowiła spytać się babci, która odpowiedziała: robię tak gdyż moja mama też tak robiła, więc tak też nauczyłam twoją mamę. Dla małej dziewczynki ta odpowiedź również nie była wystarczająca, wiec udała się do swojej prababci, ta zapytana o to dlaczego ucina rybie głowę i ogon przed położeniem jej na patelni odpowiedziała, że pamięta iż jej babcia robiła tak tłumacząc że mają zbyt małą patelnie by zmieściła się na niej cała ryba”

A Wam jak często udaje się odkrywać, że niektóre z Waszych przyzwyczajeń wynikają z tego, że kiedyś patelnie były mniejsze? Mnie dosyć często zdarza się odkrywać w projektach pewne zaszłości wynikające z “martwych” wymagań, które już dawno zostały zmienione. Ponadto języki programowania oraz technologie rozwijają się bardzo szybko i coś co kiedyś było niemożliwe nagle staje się banalnie proste, czasem wystarczy “tylko” trzymać rękę na pulsie by docenić i wykorzystać najnowsze rozwiązania.

W zespołach w których pracowałem/pracuję nierzadko spotykałem się (zwłaszcza, gdy w projekcie pojawiał się ktoś nowy) z sytuacją, w której pomysły “świeżej” osoby były dyskredytowane przez “weteranów” słowami: Tak, kiedyś już ktoś z nas próbował rozwiązać ten problem inaczej, ale to rozwiązanie, które teraz mamy jest najlepsze z możliwych. Moim zdaniem nie można stwierdzić nic bardziej błędnego – w tym przypadku zastosowane rozwiązanie było najlepszym z dostępnych wówczas rozwiązań. Do tego dochodzą jeszcze ograniczenia wynikające chociażby z niepełnej/innej wiedzy rozwiązujących problem. Z doświadczenia wiem, że “nowi” w projektach potrafią bardzo często dostarczyć wręcz oczywiste, proste rozwiązania, których nikt wcześniej nie potrafił dostrzec. Często wynika to z braku zaciemnienia obrazu (całokształtu projektu) przez szczegóły i informacje o ograniczeniach. Wspomnę jeszcze o testerach, którzy wchodząc do projektu po raz pierwszy znajdują w nim najwięcej błędów (zwłaszcza, gdy każe się im samemu eksplorować aplikację w celu jej dogłębnego poznania przed właściwym wykonywaniem scenariuszy testowych – tą metodę sam staram się stosować, czy to wchodząc do nowego projektu, czy też wdrażając kogoś nowego – praktycznie zawsze przynosi niesamowite efekty).

Kiedyś natrafiłem na stwierdzenie że nierozwiązywalne problemy mogą być rozwiązane tylko przez tych, którzy nie wiedzą o tym, że dany problem nie ma rozwiązania – w pełni zgadzam się z autorem i w praktyce kilka razy zdarzyło mi się zaobserwować ten fenomen.

Albert Einstein – znany wszystkim fizyk teoretyczny opracował swoje najważniejsze teorie nie przeprowadzając żadnego doświadczenia fizycznego. Właśnie dlatego, że w swoim rozumowaniu nie nawiązywał do “starej” fizyki Newtonowskiej, która była wynikiem wielu doświadczeń mógł z powodzeniem wymyślić coś zupełnie nowego, co dało początek chociażby dzisiejszym powszechnym zastosowaniom energii atomowej. Warto też wspomnieć, że pod koniec XIX wieku – tuż przed Einsteinem wśród fizyków powszechnie uważano, że w tej dziedzinie nauki już na prawdę niewiele zostało do odkrycia.

Wracając do smażonej ryby niestety czasem jest zbyt wiele ograniczeń pozwalających nam na zwiększenie patelni, więc jak powiedział jeden z moich kolegów z pracy: czasem trzeba poprzestać na łowieniu mniejszych ryb.

Historia o smażonej rybie kojarzy mi się  z moimi ostatnimi przemyśleniami i poszukiwaniami dotyczącymi myślenia lateralnego. Obiecuję wkrótce podzielić się wiedzą, którą zdobywam w tym temacie.

Oryginalny wpis z powyższą historyjką znajdziecie tutaj.

Czy zdarzyło się Wam zakładać kilkadziesiąt kont mailowych tylko po to by testować rejestracje na jakiejś stronie gdzie użytkownik identyfikowany jest przez unikatowy adres email?
Jest bardzo proste rozwiązanie tego problemu – konto na gmail.com. Okazuje się, że gmail nie uznaje kropki w adresie email jako znaku, więc adresy typu testemail@gmail.com, test.email@gmail.com t.estemail@gmail.com a nawet t.e.s.t.e.m.a.i.l@gmail.com to według gmail ten sam adres. Mało tego, możliwe jest także wysyłanie na adresy typu testemail+testsomesufix@gmail.com które także wskazują na ten sam adres co wcześniej.

Jak widzicie wcale nie trzeba zakładać dodatkowych kont mailowych by używać wielu aliasów.

Źródło tych informacji znajdziecie tutaj.

Na wstępie chciałbym w skrócie przedstawić podstawowe zasady CI, a może raczej ACI (Automated Continous Integration):

Trzymaj kod w repozytorium
A nawet nie tyle trzymaj co commituj swoje zmiany jak najczęściej, dzięki temu każdy będzie miał możliwość integrowania swoich zmian z Twoimi. Do tego należy także pamiętać o tym aby także updateować jak najczęściej swoje lokalne repozytorium na którym się pracuje aby integrować swoje zmiany z najświeższymi zmianami kolegów.
Cechy dobrego repozytorium to przede wszystkim:
- przejrzysty widok ostatnich zmian
- możliwość tworzenia rozgałęzień i automatycznego łączenia ich
- system powiadomień o zmianach
- łatwa możliwość odwrócenia ostatnich zmian
Osobiście używam GIT i SVN, jak na razie obydwa spełniają większość moich oczekiwań.

Automatyzuj buildy
Buildy powinny być odpalane automatycznie. Do automatyzacji buildów polecam Hudson lub CruiseControll. Warto też wspomnieć o tym co taki build powinien robić, mianowicie powinien:
- odpalać testy jednostkowe
- odpalać inne testy (jeśli są)
- generować raporty z pokrycia kodu testami
- generować raporty z wynikami testów
- wysyłać powiadomienia, zwłaszcza gdy testy nie przechodzą
- powinien być zintegrowany ze środowiskiem RC do którego commity powinny trafiać jedynie, gdy build przechodzi
- powinien generować inne artefakty, które są w danym projekcie potrzebne.

Stosuj TDD
Tak, by to wszystko miało sens potrzebne są testy do kodu, który piszemy. Jak najwięcej testów. Najlepszą praktyką w tej dziedzinie jest TDD – pisanie testów przed napisanie właściwego kodu (ale o tym może innym razem).

Zasada nie zabierania zakiszonego kodu do domu
Każdy programista commituje przynajmniej raz dziennie. Im częściej tym lepiej.

Każdy commit odpala build
Po każdej zmianie kodu powinny być odpalane testy w celu jak najszybszego wykrycia błędów i ich poprawy,a także w celu łatwiejszego wykrycia przyczyny błędu (zazwyczaj należy jej szukać tylko w ostatnim commicie).

Utrzymuj build szybkim
Buildy powinny być jak najszybsze, by niepotrzebnie nie marnować czasu na czekanie, aż build przejdzie. Obecnie rozwiązuje się ten problem w sposób sprzętowy np stosując chmury obliczeniowe do odpalania testów.

Środowisko testowe powinno być bliźniacze do środowiska produkcyjnego
Chociażby dlatego by uniknąć błędów wynikających z różnicy w tych środowiskach.

W każdej chwili powinieneś mieć dostęp do ostatniej stabilnej wersji oprogramowania
Zgodnie ze wspomnianą zasadą Agile, w każdej chwili powinniśmy mieć pod ręką jakąś stabilną wersję oprogramowania teoretycznie gotową do publikacji.

Każdy powinien mieć dostęp do wyników buildów
Na przykład Hudson ma wbudowany ciekawy plugin, który umożliwia graficzna prezentację wyników ostatnich buildów. Tego typu aplikacje mają zazwyczaj także api, które sprzyja tworzeniu własnych rozwiązań do prezentacji efektów testów etc. My w firmie używamy właśnie Hudsona i specjalnego monitora który stojąc w widocznym dla każdego miejscu prezentuje efekty ostatnich commitów.

Automatyczny deployment
Fajny ficzer zwłaszcza w fazie maintenance projektu, gdy zmiany są dosyć często wgrywane na serwer produkcyjny. Istnieją gotowe narzędzia pozwalające na automatyczne deployowanie aplikacji.

Żeby lepiej zrozumieć na czym polega CI należało by się pierw zastanowić po co właściwie coś takiego jak Ciągła Integracja jest nam potrzebne? Najprościej będzie gdy wrócimy do jednego z podstawowych założeń zwinnego zarządzania projektami a mianowicie: “w dowolnym (odpowiednio zaawansowanym) momencie trwania projektu powinniśmy być w stanie dostarczyć ‘jakiś’ produkt, który spełnia pewne założenia i udostępnia pewną funkcjonalność, produkt ten teoretycznie powinien być gotowy do wypuszczenia na rynek”. Idąc dalej tym tropem można łatwo wywnioskować, że aby produkt był gotowy do publikacji musi spełniać pewne kryteria jakości, które powinny zostać przetestowane. By jeszcze lepiej zrozumieć potrzebę ciągłej integracji w projekcie należałoby się zastanowić nad tym w jaki sposób integrować pracę wielu programistów, którzy pracują nad często zazębiającymi się fragmentami kodu. Może aby lepiej zobrazować strukturę problemu posłużę się przykładem w którym zespół projektowy nie wykorzystuje aspektów CI.

Wyobraźmy sobie zespół składający się z pięciorga programistów i dwojga testerów. Zespół ma dostarczyć jakąś określoną aplikację, która ma trzy podstawowe funkcjonalności. Tutaj pojawia się pierwszy problem – jak podzielić pracę? Może niech każdy programista zajmie się pojedynczą funkcjonalnością, a na koniec spróbują zintegrować to wszystko ze sobą (uwierzcie mi są firmy w których taki model wytwarzania oprogramowania jest stosowany na co dzień). No tak tylko, że funkcjonalności jest 3 a programistów pięcioro. Poza tym są jeszcze testerzy, którzy przez większość czasu będą się nudzić. No dobrze – klasyczny model Waterfall zakłada, że testy powinny być przeprowadzane na końcu, więc niech tak będzie. Żeby jeszcze lepiej wszystko zobrazować dodajmy trochę matematyki. Załóżmy, że wykonanie pierwszej funkcjonalności zajmie około 30 roboczogodzin, drugiej 60 roboczogodzin, trzeciej 15 roboczogodzin. Do tego przetestowanie około 1/3 czasu potrzebnego na implementację czyli odpowiednio 10, 20, 5 roboczogodzin (dość optymistyczne, ale realne założenia). Dobrze – prace ruszyły pierwsza po 15 godzinach zostaje ukończona funkcjonalność nr 3, programista który nad nią pracował teraz odpoczywa. Po kolejnych 15 godzinach została ukończona funkcjonalność nr 1, teraz programiści mogą rozpocząć prace nad integracją funkcjonalności 1 i 3, mają na to około 30 godzin. Po 60 godzinach od rozpoczęcia projektu dostarczono funkcjonalność nr 2, którą teraz trzeba jeszcze zintegrować, na tym etapie okazuje się że popełniono kilka błędów w założeniach, czegoś nie ustalono dokładnie etc. wiec integracja potrwa kolejne 20h. W sumie po 80 godzinach pracy dostarczono produkt do testów. Testowanie wraz z poprawkami zajmie około 40h.

Po 120 godzinach pracy mamy gotowy produkt. Przypomnijmy, że dla dwóch programistów nie było pracy, ciężko jest pracować nad jednym kawałkiem kodu na dwóch różnych komputerach. Co najwyżej służyli oni jedynie pomocą swoim kolegom.

A teraz podobny przykład (ten sam problem do rozwiązania) z tym że zespół wykorzysta większość aspektów CI.

Ponieważ wiemy ile szacunkowo zajmą pracę nad każdą z funkcjonalności i wiemy, że funkcjonalność nr 2 zajmie najdłużej pracować nad nią będzie aż troje programistów, dodatkowo programista, który będzie pracował nad funkcjonalnością nr 3 po zakończeniu prac nad nią wesprze kolegę pracującego nad funkcjonalności nr 1. Praca zespołowa jest w pełni możliwa dzięki temu, że zespół korzysta z systemu kontroli wersji, który pozwala na łatwą dystrybucję najaktualniejszego kodu. Dodatkowo testerzy dzięki środowisku, które roboczo nazwiemy RC (Release Candidate) mogą w każdej chwili testować dostarczane funkcjonalności i zgłaszać błędy, które są dużo łatwiejsze do poprawienie we wcześniejszej fazie. Należy też zauważyć, że integracja całości odbywa się od samego początku, gdyż wszystkie zmiany wrzucane są do jednego repozytorium. Czas implementacji wydłuży się zapewne o około 1/3 ze względu konieczność pisania testów jednostkowych (nie jest to wymóg jeśli w zespole są testerzy, jednak dzięki temu ich praca powinna się skrócić o około połowę). Zobaczmy jak to teraz wygląda. Planowane czasy implementacji po uwzględnieniu dodatkowego pisania testów jednostkowych: F1 – 40 roboczogodzin, F2 – 80 roboczogodzin, F3 – 20 roboczogodzin. Testy: T(F1) – 7 roboczogodzin, T(F2) – 14 roboczogodzin, T(F3) – 4 roboczogodziny. Projekt startuje. Po 10 godzinach pracy rozpoczynają się testy dla funkcjonalności nr 2 (wykonuje je jeden tester). Po 16 godzinach od rozpoczęcia rozpoczynają się testy akceptacyjne dla funkcjonalności nr 3, po 20 godzinach od rozpoczęcia ta funkcjonalność jest już gotowa i przetestowana, programista, który nad nią pracował pomaga programiście pracującemu nad funkcjonalnością nr 1 (do jej ukończenia zostało 20 roboczogodzin, podzielone na dwóch daje po 10 godzin). Trzy godziny później rozpoczynają się testy funkcjonalności nr 1. Po kolejnych 7 godzinach funkcjonalność nr 1 jest ukończona i przetestowana – minęło 30 godzin od rozpoczęcia projektu. W międzyczasie po około 27 godzinach od rozpoczęcia projektu zostaje ukończona i przetestowana funkcjonalność nr 2. Wszystko powinno działać i być już zintegrowane, dla pewności testerzy sprawdzą wszystko jeszcze raz – po 8 godzin każdy.

W sumie daje nam to 38 godzin pracy nad projektem, których efektem jest gotowy, przetestowany produkt, którego dodatkowym gwarantem jakości są test jednostkowe. Dodatkowo od pewnego momentu w z środowiska RC mogliśmy pobrać stabilną – przetestowaną wersję aplikacji zapewniającą pewne funkcjonalności. To raczej znacznie lepszy wynik niż poprzednio. Powyższe założenia są trochę naciągane i wyssane z palca, ale uwierzcie mi już kilkukrotnie widziałem nawet dużo bardziej zaskakujące efekty wprowadzenia CI do procesu wytwarzania oprogramowania.

Powyższy wywód jest również pewnego rodzaju odpowiedzią na często stawiane pytanie: “Czy pisać testy jednostkowe?”. Postaram się w przyszłości poszukać (być może samemu przeprowadzić) jakichś badań na temat czasu wytwarzania oprogramowania z i bez. Ogólnie już teraz mogę wnioskując z doświadczenia jednoznacznie stwierdzić, że niemal zawsze automatyzacja testów znacząco przyspiesza pracę nad projektem, a zwłaszcza pracę w fazie maintenance.

Do tej notki zainspirowały mnie ruch We don’t support IE i jemu podobne, oraz wieści o nadchodzącej premierze Internet Explorer 9. Dla mnie czyli testera między innymi stron internetowych świadomość pojawienia się kolejne przeglądarki spod znaku błękitnego “e” oznacza tylko jedno – więcej żmudnej pracy przy testach cross-browser. IE 9 to najprawdopodobniej jeszcze jeden “badziew”, którego twórcy tylko słyszeli o czymś takim jak standardy W3C, ale o ich przestrzeganiu nie ma mowy. Przecież IE i tak ma 33% rynku w Polsce, a na świecie około 37%  więc kto by się tym przejmował. Na szczęście w ciągu ostatniego roku ilość użytkowników przeglądarek od wuja Billa spadła o około 10% i miejmy nadzieję, że ten trend się utrzyma.

Dobrze, ale dlaczego nie lubię IE? Odpowiedź jest prosta – gdy mam do sprawdzenia kompatybilność jakiejś strony z kilkoma przeglądarkami to wyniki takich testów przeważnie wyglądają mniej-więcej tak:

Załóżmy, że strona była tworzona dla FireFox 3.* (Przeważnie tak jest chociażby ze względu na ilość dostępnych dodatków dla deweloperów do tej przeglądarki), więc zakładamy po przetestowaniu, że ta przeglądarka jest naszym wzorcem – zgodność oczekiwań 100%.

Zaczynamy testy w innej przeglądarce, powiedzmy starsza wersja FF 2.*  zazwyczaj znajdziemy jakieś drobne uchybienia związane raczej z ewolucją standardów (czasem nie do końca przestrzegana jest kompatybilność wstecz) wyniki takich testów utrzymują się przeważnie na poziomie 95%+.

Weźmy inną przeglądarkę niech to będzie Opera w najnowszej wersji – jeśli chodzi o CSS to możemy być prawie pewni, że wszystko jest ok, może czasem wystąpić jakiś błąd, ale to już nasza wina, że zaimplementowaliśmy coś niezgodnie z obowiązującymi standardami (wynika to z tego, że twórcy Opery są mocno związani z twórcami samego CSS i raczej przestrzegają swoich standardów), możemy się spodziewać kilku drobnych problemów z Java Scriptami, ale nic strasznego – wyniki testów około 92%+.

Przejdźmy do naszego ukochanego IE, zacznijmy od IE6 – ludzie nadal tego używają (około 10% rynku). Nawet nie chce mi się opisywać co jest nie tak: Java Scripty częściej nie działają niż działają, nie jest obsługiwana przezroczystość dla obrazków w formacie .png, CSSy dla FireFoxa można wyrzucić i trzeba pisać od nowa itd… Zgodność IE6 z oczekiwaniami 50%-, czasem tych stron po prostu nie da się otworzyć. Odrobinę lepiej jest w IE7 (obcenie największy odsetek wśród użytkowników Internet Explorera), niemniej jednak nadal względnie liczne problem z Java Scriptami. Nie wspomnę o tym, że w IE w ogóle wszystko zawsze wygląda inaczej i jeśli chodzi o CSS to nasze usilne starania by dobrać odpowiednie marginesy, paddingi i grubości ramek by wszystko wyglądało tak jak należy (w FF) w Internet Explorerze 7 będziemy musieli zapewne powtórzyć. Zgodność z oczekiwaniami około 75%+. Obecnie najnowszą wersją omawianej przeglądarki jest wersja nr 8. Tutaj widzimy już znaczącą poprawę, ale nadal czasem występują problemy z Java Scriptami, względnie mniejsze z CSS. Pomimo wszystko dość często zgłaszam błędy związane z tą przeglądarką, więc ogólna ocena na około 85%-.

Tak znaczące różnice oznaczają zwiększenie całkowitej pracy całego zespołu o kilkadziesiąt procent…

Powyższe oceny są dosyć subiektywne i opierają się na moich testerskich doświadczeniach z powyższymi przeglądarkami. Nie wspomnę już o tym, że IE przed wersją 8 był znacznie wolniejszy od pozostałych przeglądarek. Jedynym atutem jest, to że dzięki ładowaniu podczas startu systemu dużo szybciej uruchamia się za pierwszym razem. Niemniej jednak wadą IE jest to, że można go używać jedynie pod Windowsami.

Tak, zdecydowanie nie lubię Internet Explorera. Niemniej jednak ze względu na jedną trzecią udziałów w rynku jesteśmy zmuszeniu dostosowywać nasze aplikacje do pseudo standardów Microsoftu. Pojawienie się kolejnego Internet Explorera oznacza dla mnie zwiększenie ilości testów o jakieś 20% – testów które i tak są już redundante (dla FF2, FF3, IE8 i IE 7). Także wielkie dzięki. Może przynajmniej IE9 wyprze IE6, ale szanse na to są małe, gdyż IE6 jest głównie używane w korporacjach, a tam procedury zmiany narzędzi są dość skomplikowane, a poziom świadomości technicznej osób za to odpowiedzialnych jest raczej niski. Można śmiało stwierdzić, że ze względu na zwiększenie ilości pracym a co za tym idzie czasu, który jest potrzebny by wypuścić jakąś stronę/aplikację na rynek nieprzestrzeganie przez twórców przeglądarek tego typu wszystkich ustalonych wcześniej standardów stanowi świadome lub nie opóźnianie rozwoju Interntetu, co w dzisiejszych czasa oznacza spowolnienie rozwojuz cywilizacyjnego, na który Internet ma dość duży wpływ. Może za tym wszystkim stoją szlachetne idee zmiany świata przez gości z Microsoftu. Przypomina mi się pewne powiedzenie: “Chcesz zmienić świat na lepsze – zacznij od siebie”.

Wiele razy słyszałem (z różnych ust), że testerzy są niepotrzebni… Muszę się z tym zgodzić… (!?)

(…teraz strzelam sobie zawodowego samobója )

Jeśli spojrzymy na współczesne metodologie wytwarzania oprogramowanie (mowa głównie o agile) możemy dostrzec zanik roli testera w projekcie. Zwykłe przeklikiwanie się przez aplikację już nie wystarcza by sprostać wymaganiom stawianym przez współczesnych klientów – aplikacje mają być w pełni modyfikowalne i rozwijalne w dowolnym kierunku (i przeważnie są wielokrotnie modyfikowane i rozwijane), popularność zyskuje nawiązanie do prototypowania, gdzie w celu sprawdzenia czy dana aplikacja/serwis zdoła przyciągnąć uwagę klientów, najpierw wypuszcza się jego okrojoną wersję w celu zdobycia informacji na temat zapotrzebowania klientów, a dopiero później rozwija się serwis w kierunku wyznaczonym przez potencjalnych klientów. Gdy w aplikacji następuje wiele częstych zmian zwykłe klikanie staje się mało opłacalne. Jeśli np. mamy  do czynienia z serwisem społecznościowym w którym zmiany są publikowane co tydzień, ilość potrzebnych testów i możliwych scenariuszy jest tak duża, że wymagane jest zatrudnianie coraz więcej testerów.

W większości zwinnych metodologi podstawą są automatyczne testy, czy to unit testy, czy testy integracyjne zasadniczo pisane przez programistów, więc gdzie tu miejsce dla testera? Oczywiście, tester przydaje się do wykonania testów akceptacyjnych, ale to tak na prawdę szybka robota w porównaniu do długości całego cyklu wytwarzania oprogramowania. Na szczęście mało kto zdaje sobie sprawę z konieczność zapewnienia odpowiedniego – maksymalnego (w granicach rozsądku) pokrycia kodu testami (o tym innym razem),  dzięki temu testerzy mają jeszcze co robić… Testy akceptacyjne, testy sprawdzające warunki odbioru produktów będą zawsze potrzebne, więc zawód testera raczej nie zaniknie, zmienią się, zostaną okrojone jedynie jego zadania i kompetencje. Może to trochę czarna wizja przyszłości niemniej jednak jest to wizja prawdopodobna.

W dobie automatyzacji w każdej dziedzinie życia, praca testera też zostanie zastąpiona przez maszyny, testy automatyczne, konkretniej funkcjonalne testy automatyczne. W przypadku aplikacji www testy mogą być wykonywane np. przy pomocy Selenium lub innych narzędzi, gdy mamy do czynienia z aplikacjami desktopowymi np. przy użyciu TestComplete…  Narzędzia tego typu jeszcze do niedawna niedoceniane coraz bardziej zyskują na popularności i zwiększa się ich ilość. Właśnie przeczytałem o czymś co nazywa się AutoIT (ale o tym też innym razem, jak już to wypróbuje). Dlatego w projektach wzrasta rola kogoś określanego mianem Iżyniera Testów, czyli osoba która potrafi programować na tyle by pisać tego typu testy i je utrzymywać, a jednocześnie posiadająca wiedzę nt testowania aplikacji na poziomie umożliwiającym projektowanie odpowiednich scenariuszy i przypadków testowych.

Jak to mówią “potrzeba matką wynalazków”, więc sygnaturka w moim firmowym mailu zmieniła się na SQA & Test Engineer.  Awans? Raczej nie, w sumie od samego początku się tym zajmowałem, ale dopiero podczas jednej z rozmów przy piwie zostało to w pewnym stopniu sprecyzowane. Cytuje Adama: “Wg mnie każdy tester powinien być także inżynierem testów” – po przemyśleniu nie pozostaje mi nic innego jak zgodzić się z tym stwierdzeniem. Podczas ciągłych zmian samo przeklikiwanie się przez aplikację już nie wystarczy, niemniej jednak same testy automatyczne nie są w stanie wszystkiego sprawdzić, a gdy ich ilość osiąga pewną krytyczna masę ich utrzymanie staje się zbyt kosztowne i “testerzy górą”, dlatego Tester i Inżynier Testów w jednym to idealne rozwiązanie.

Pozostaje mi tylko życzyć powodzenia wszystkim testerom, którzy nie zamierzają uczyć się pisania testów. Moje mroczne wizje prawdopodobnie się nie spełnią chociażby dlatego, że znacząca większość projektów nadal jest rozwijana wg. starych metodologi i pewnie jeszcze długo będzie, a metodologie zwinne mało kto potrafi i chce w pełni wykorzystywać.

Na blogu pojawił się jakiś czas temu kurs Selenium. To dopiero początek! W mitycznych wolnych chwilach postaram się go uaktualniać i dopisywać różne ciekawe rzeczy z tym narzędziem powiązane.

Dlaczego oddzielna strona – a dlatego, że jest to narzędzie na tyle rozbudowane, oraz posiadające na tyle dużo możliwości (często trudnych do odkrycia), że warto mu poświęcić osobną stronę. Jeśli chodzi polskojęzyczny Internet ciężko jest znaleźć cokolwiek na ten temat, więc może komuś przyda się to co tutaj zamieszczę… Na razie jest tego niewiele – kilka podstawowych pojęć i sposób instalacji… Wszystko opisuję raczej z pamięci, więc mogą być tam małe błędy… Gdyby ktoś miał jakieś uwagi piszcie na maila… Gdyby ktoś odkrył coś ciekawego w tym narzędziu także proszę o kontakt…

Jak już pisałem Selenium pomimo tego, że jest to Open Source, jest narzędzie niesamowicie rozbudowany, potrafiącym przetestować prawie wszystko co jest w stanie obsłużyć przeglądarka internetowa, a ponadto umożliwia testowanie w różnych środowiskach… Ale o tym wszystkim wkórtce na stronach kursu…

Selenium jest idealnym narzędziem wspomagającym testowanie aplikacji zarządzanych agile’owo. Świetnie sprawdza się w continues integration. Za jego pomocą można łatwo przetestować większość java script na stronie, do których testy jednostkowe są często traktowane po macoszemu. Jeśłi testy są dobrze napisane i zaplanowane ich utrzymanie wcale nie jest tak kosztowne jak by się to wydawało.

“Testowanie wymagań i chodzenie po wodzie jest łatwe pod warunkiem, że są zamrożone”

Planując testy akceptacyjne staram się oprzeć na wymaganiach, które według klienta powinny zostać spełnione by aplikacja była akceptowalna. To jest oczywiste. Jednak co zrobić, gdy wymagania zmieniają się wraz z rozwojem aplikacji, jak to często w projektach Agile’owych i nie tylko bywa? Standardowy model “V” nie nadaje się tutaj do  zastosowania, gdyż zakłada on planowanie testów akceptacyjnych, a co za tym idzie implementację tych testów w odpowiedniej, stosunkowo wczesnej fazie projektu. Przy takim rozwiązaniu gdy testy są wcześnie zaimplementowane a wymagania nie są do końca sprecyzowana (ulegają ciągłym zmianom) utrzymanie testów staje się zbyt kosztowne.

Testowanie zmieniających się wymagań nigdy nie będzie proste i nigdy nie będzie tanie, chociażby  nie wiem jak te testy były zaplanowane i napisane/zrealizowane. Najbardziej optymalnym rozwiązaniem w takiej sytuacji jest powrót do podstaw i rozbicie aplikacji na poszczególne podsystemy o określonych, zawężonych funkcjonalnościach, maksymalnie oddzielone od reszty aplikacji, po czym doprowadzenie kolejno jeden po drugim każdy z tych podsystemów do oczekiwanego akceptowalnego stanu. W innym wypadku wpadniemy w “Cowoboy Coding” z “Bug Huntingiem”, co obrazuje się w sposób następujący: testerzy znajdują błędy w różnych częściach aplikacji, developerzy je poprawiają, dodają nową funkcjonalność psując coś w innym miejscu, testerzy lub automatyczne testy znajdują te błędy, deweloperzy  znów poprawiają psując coś innego i tak w kółko. Nie da się ogarnąć projektu bez zaplanowanej metodologi działania. Wszelkie poprawki i zmiany powinny być z góry zaplanowane i w odpowiedni sposób przetestowane przed wysłaniem ich na serwer, gdzie następują testy integracyjne. Bardzo istotny jest obieg informacji – co, kto i dlaczego robi, oraz co jeszcze ktoś inny będzie musiał  z tym zrobić. W agile testowanie w dużym stopniu opiera się na testach poszczególnych funkcjonalności, które wykluczają większość błędów nie wynikających z problemów integracyjnych.

Słyszałem o aplikacjach powstających metodą “Wielkiego Wybuchu”, która polega na tym, że wszyscy nagle siadają i coś kodują, starając się nie wchodzić sobie w drogę. Zazwyczaj kończy się to wielkim bałaganem, który czasem nawet działa ale nikt nie jest z niego zadowolony. Najgorsze jednak w tym wszystkim jest to, że jeśli przyjdzie zrobić jakąś zmianę, albo poprawić jakieś błędy to nagle okazuje się, że wiele fragmentów kodu jest zduplikowanych, albo zależy od nich zbyt wiele innych części aplikacji.

Rozwiązaniem większości problemów jest skrupulatne planowanie oraz pozostawienie możliwości przyszłego rozwoju dla każdej części aplikacji w każdym możliwym kierunku. Ważnym jest też dobór odpowiedniej metodologii. Dzięki tym rozwiązaniom nawet najbardziej zmienne wymagania nie są nam straszne. Jeśli wymagania się zmieniają, wracamy do odpowiedniej części aplilkacji i ponownie pracujemy nad nią, aż nowe wymagania zostaną spełnione, nie ingerując w inne części projektu.

Przeczytałem kilka publikacji na temat testowania w metodologiach zwinnych, ale jak do tej pory żadna nie oddaje w pełni tego co ja doświadczyłem podczas pierwszego zetknięcia się z testowaniem w Scrum’ie ( o nim samym może innym razem). Jak ogólnie wiadomo Scrum zakłada iteracyjny model wytwarzania oprogramowania, czyli po każdym sprincie (w moim przypadku co dwa tygodnie) powinniśmy mieć przynajmniej jedną nową, w pełni działającą “funkcjonalność”.

Mądre książki podają, że podstawą takiego wytwarzania oprogramowania są automatyczne testy pisane przed rozpoczęciem implementacji właściwego kodu programu – nie zamierzam z tym polemizować, gdyż jest to działka raczej programisty nie testera. Kolejną rzeczą która powinna zostać zrobiona jest tworzenie i aktualizowanie na bieżąco automatycznych testów funkcjonalnych (Selenium, TestComplete, etc.) – słuszne podejście, moje ostatnie doświadczenia potwierdziły istotność takich testów, a konkretnie potwierdził to ich brak. Utrzymanie automatycznych testów funkcjonalnych jest jednak czasochłonne i kosztowne. Przejdźmy więc do testów manualnych. Jak testować w modelu iteracyjnym?

Działając zgodnie z procedurami opisanym tu i ówdzie testowałem każdą nową funkcjonalność z osobna (tutaj znów spostrzegłem potrzebę istnienia automatycznych testów, gdyż nie sposób było przetestować całą aplikację po każdej małej zmianie), przynosiło to dobre efekty, lecz jedynie na krótką metę, ponieważ jeśli chodzi o nowe, właśnie wprowadzone funkcjonalności mogliśmy z dużym prawdopodobieństwem stwierdzić, że działają poprawnie, lecz niestety aplikacja jako całość w zasadzie nigdy (aż do testów akceptacyjnych) nie została przetestowana. I tu pojawia się właśnie rola testów akceptacyjnych, które zostały zostawione na sam koniec. Czy to złe podejście? Moim zdaniem nie do końca, dzięki temu unikamy zbędnego powtarzania się (zakładając, że nie mamy do dyspozycji automatycznych testów funkcjonalnych), testy akceptacyjne w których z konieczności zawierają się także testy integracyjne, mogą zostać przeprowadzone w środowisku praktycznie identycznym z produkcyjnym. Liczba błędów, które udało mi się znaleźć podczas tych testów jest naprawdę znikoma, co ukazuje wyższość zwinnych testów  każdej poszczególnej funkcjonalności i poprawność odizolowania od siebie poszczególnych części kodu aplikacji (co też powinno być/jest niepisaną zasadą Scrum’a). Błędy które znalazłem wynikały głównie ze środowisk na których aplikacja została zainstalowana.

Lecz to jeszcze nie koniec  – jak wiadomo najlepszymi testerami są zwykli użytkownicy, dlatego głośno i stanowczo postuluje za tym, by wszystkie większe projekty agile’owe były wydawana najpierw w wersji BETA i dopiero po zatwierdzeniu przez grupę testowych użytkowników publikowane jako gotowe finalne wersje produktu. Myślę, że nawet koszty obniżenia ceny pierwszej wersji produktu zostaną zrównoważone jego jakością. Spójrzmy na najlepszych/największych Gmail od pięciu lat jest w wersji beta i pewnie jeszcze długo będzie, jest to typowy przykład projektu rozwijanego iteracyjnie w Agile, testowany przez klientów i cieszący się dużą popularnością oraz względną niezawodnością.

O kosztach testowania postaram się napisać innym razem. Konkluzja: pozostawienie integracyjnych testów na sam koniec wydaje się być w miarę rozsądne, oczywiście jeśli mamy na to czas.