blog.testowka.pl

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.

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.

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.

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.