blog.testowka.pl

Archiwum wiadomości z Sierpień, 2011

Spłata długów

opublikowany przez 08, Sie, 2011, w kategoriach Agile, Testowanie, Zarządzanie

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.

Dodaj komentarz więcej...

Myśleć zwinnie

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

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

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

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

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

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

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

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

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

1 komentarz więcej...