Andrzej Jarzabek wrote:

> On 20/05/2011 08:35, Michal Kleczek wrote:
>> Andrzej Jarzabek wrote:
>>
>>> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
>>
>> Sek w tym, ze to jest tylko _udawanie_ testowania. Nie da sie _dobrze_
>> przetestowac niebanalnego oprogramowania w czasie jednej iteracji (o
>> dlugosci proponowanej przez "agile").
>
> Dlatego testuje się przez _wszystkie_ iteracje. Np. jeśli masz release
> po trzech miesiącach od rozpoczęcia kodowania, to to, co masz w tym
> release jest już testowane od trzech miesięcy.

Jak mozesz miec "juz przetestowana" calosc skoro wlasnie zakonczyles n-ta
iteracje i dolozyles funkcjonalnosc. To sie da tak robic jak twoj zestaw
testow da sie wykonac w ciagu 15 minut. Taki zestaw testow to sobie w dupe
mozna wsadzic. _Realne_ testowanie to jest takie, ze _automatyczne_ (nie
manualne) testy trwaja na tyle dlugo, ze nie da sie tego robic "na biezaco",
bo wstrzymywaloby to zbyt dlugo prace programistow (np. kilka dni).
Jezeli takie testy maja sie odbywac "non stop", to oznacza, ze release'y
musisz robic w cyklach rownych dlugosci trwania testow. A jesli trafi ci sie
blad tzw. "krytyczny", ktory stopuje testowanie w polowie, to co robisz?
Masz dwa wyjscia:
1) Czekasz na kolejny release (co oznacza, ze przestajesz testowac _ten_
release)
2) Robisz galaz rownolegla do biezacego developmentu i poprawiasz ten blad i
odpalasz testy od poczatku. Tyle, ze wtedy albo
a) nastepna iteracja nie jest testowana (bo pojawia sie zanim testy
poprzedniej sie skoncza) - co de facto oznacza po prostu wydluzenie iteracji
(a co jesli w drugim podejsciu znajdziemy drugi taki blad)
b) testujesz rownolegle dwie (lub wiecej) iteracje-releasy (jesli to w ogole
mozliwe) ze wszystkimi konsekwencjami utrzymywania wielu galezi, mergy,
regresji itd - i tak sie robi, ale zeby nie zapanowal chaos releasy nie moga
byc zbyt czesto

>
> Problem z testowaniem "od A do Z" polega na tym, że metaforycznie masz
> swoje A, swoje Z i jakieś literki pomiędzy, ale nie wiesz ile w ogóle
> jest literek w alfabecie.

To do cholery jak przygotujesz testy jak nie wiesz co masz testowac?

> W dodatku alfabet zmienia się w miarę rozwoju
> oprogramowania. Dlatego też wszystkie literki, o których wiesz,
> testujesz automatycznie za każdą iteracją, a może nawet codziennie,

Patrz wyzej - nie da sie tego porzadnie zrobic "codziennie".

> ale
> cały czas masz równolegle tesowanie ręczne polegające na szukaniu, czy
> są jeszcze jakieś literki między A i Z, o których się nie pomyślało.
>
>> Co wiecej - trzeba sobie zdac sprawe z tego, ze _prawdziwe_ testowanie b.
>> duzo kosztuje (nie tylko ze wzgledu na czas, lecz takze ze wzgledu na
>> zasoby, ktore sa potrzebne do tego).
>
> Jasne.
>
>> I dalej - ze wzgledu na te koszty nie
>> mozna sobie pozwolic na to, zeby robic to zbyt czesto
>
> Jak się robi porządnie, to się ma przeznaczone zasoby tylko do
> testowania danego produktu. Jak go nie testujesz, to te zasoby leżą
> odłogiem i kosztują z grubsza tyle samo.

Normalnie (nie "agile") tobi sie to tak, ze masz oddzielny zespol tzw. QA
(moze byc nawet outsourcing), ktory obsluguje ci kilka produktow. Taki QA
nie kiwnie nawet palcem, jak mu nie dasz analizy wymagan, bo niby na jakiej
podstawie ma przygotowac testy?

>
>> - stad stosuje sie metody pozwalajace _unikac_ bledow (a nie je wykrywac
>> i poprawiac) - to jest po prostu tansze i - co wiecej - pozwala osiagnac
> > jakosc, ktorej nie da sie osiagnac testujac/poprawiajac.
>
> Jak najbardziej. Z tym że jednak wykrywać i poprawiać należy również.
>
> Ale w Agile jak najbardziej zwraca się bardzo dużą uwagę na praktyki
> pozwalające na unikanie błędów: coding standards, refactoring, simple
> design itd.
>
>> Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego
>
> Właśnie niekoniecznie.
>
>> (ew. do powaznego wydluzenia iteracji).
>
> Też niekoniecznie. Shore&Warden proponują iteracjęę trwającą tydzieeń i
> rygoorystyczne trzymanie się tego.
>
>> Np. unikanie bledow w rozpoznaniu wymagan polega na _dokladniejszym_
> > wyspecyfikowaniu tych wymagan i _dokladniejszej_ weryfikacji
> > specyfikacji
>
> Agile proponuje dokładniejszą specyfikację uzyskać w ten sposób, że
> programista jak nie wie co dalej robić, to rozmawia z customerem (lub
> analitykiem) i on mu to specyfikuje.

O! pojawia sie analityk... Czy to nadal jeszcze "agile"?
A skad "analityk" wie, co chce klient? Pewnie robi "analize"? To ja zapytam
- kiedy robi te analize? Bo przeciez musi byc "on site" z programistami,
zeby mogl z nimi "rozmawiac" - znaczy "analize" wykonal wczesniej. Cos mi
pachnie "kaskada".

> Jako metodę dokładniejszej
> weryfikacji proponuje się pokazanie customerowi działającego prototypu i
> spytanie czy właśnie o to chodziło.
>

To "prototypu", czy tez "produktu"? Bo jezeli "prototypu" to po ch... tracic
pieniadze na np. "pair programming" zeby go przygotowac?

> > - nie oplaca sie robic oprogramowania _zanim_ sie skonczy specyfikacje,
> > bo to strata czasu i pieniedzy na robienie czegos, co potencjalnie
> nie jest
> > nikomu potrzebne.
>
> Przecież to, co jest w specyfikacji też potencjalnie nie jest nikomu
> potrzebne. Na szybko z co najmniej dwóch powodów:
> a) było potrzebne w momencie tworzenia specyfikacji, ale już nie jest
> b) nigdy nie było potrzebne, ale analityk popełnił błąd i wpisał, bo
> uznał że potrzebne.
>

Obydwa przypadki sprowadzaja sie do tego, ze popelniono blad w trakcie
analizy wymagan. Oczywiscie - zdarza sie. Ale to nie jest tak, ze skoro
analiza wymagan jest trudna, to po prostu nie robmy analizy wymagan, za to
"robmy produkt i zobaczymy czy bedzie dobry" (co jak rozumiem proponuje
"agile").

> W agile masz tę zaletę, że najdalej na początku danej iteracji, w której
> to coś jest implementowane, customer potwierdził że tak, na pewno jest
> potrzebne, a co więcej jest to jedna z najważniejszych rzeczy, jakie
> zostały do zrobienia.

I projekt trwa bez konca... Ew. konczy jak c2 (tak, tak - pierwszy projekt
XP) - czyli przychodzi ktos z gory i go brutalnie przerywa.

>
>> I to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
>> automatycznie, ze te prototypy staja sie gotowym produktem
>
> Co to znaczy "stają się"? Że są w takiej postaci releasowane? Nikt tego
> nie postuluje. Staje się, w sensie że jest wykorzystywany do tworzenia
> produktu, owszem. Przy wszystkich krytykach do agilee, że to czy tamto
> jest wyrzucaniem pieniędzy, to pisanie działającego programu, który robi
> to co trzeba, po to, żeby go wyrzucić i napisać to samo od nowa też jest
> jednak marnowaniem pieniędzy.
>

Jest roznica, miedzy "prototypem" i "dzialajacym programem". Wytworzenie
"prototypu" jest nieporownywalnie _tansze_ niz wytworzenie "dzialajacego
programu".

>> - a to znowu z
>> tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
>> daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu
>> nawet
>
> Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
> jakości od kodu wysokiej jakości.

Drozej jest?

> Może być tańsze tylko o tyle, że
> możesz do tego wykorzystywać słabszych programistów którym gorzej
> płacisz,

Albo, ze dobry programista robi "na kolanie" prototyp w 15 min, zeby go
pokazac i omowic, po czym wyrzucic.

> ale to raczej nie jest szczególnie dobre podejście do agile.
>
> Poza tym do wyrównywania (w górę) poziomu kodu masz takie praktyki jak
> coding standards, collective code ownership i pair programming (lub code
> review).

Ale po co je stosowac do czegos, co i tak zaraz przepiszemy od nowa?

[ciach]
>
> Oczywiście, że nie. Po to masz refactoring.
>
>> U podstaw "metodyk agile" lezy (mniej lub bardziej jawne) zalozenie, ze
>> da sie tak robic oprogramowanie, ze koszt jego modyfikacji nie wzrasta w
>> miare jego rozrastania sie. Co jest zalozeniem po prostu absurdalnym -
>> jezeli np. na poczatku podejmiemy decyzje o tworzeniu tego oprogramowania
>> dajmy na to w C# (bo zespol uznal, ze tak najlepiej) a potem okaze sie,
>> ze klient zapomnial nam powiedziec o tym, ze to ma dzialac na Solarisie
>> (z jakichs tam powodow), to jak niby mamy zrobic "refaktoring" nie
>> przepisujac tego oprogramowania w calosci???
>
> No moment, ale pracujemy przecież cały czas z klientem. Czyli jest
> powiedzmy wczesne zebranie zespołu, na którym siedzi customer
> representative, i jest rozmowa o tym, w jakiej technologii wykonać.
> Jeśli pada propozycja C#, to raczej padnie pytanie, czy można na pewno
> założyć, że produkt będzie pod .NET, a .NET jest tylko pod Windows
> (istnienie Mono na potrzeby dyskusji pominiemy). Od przedstawiciela
> klienta raczej będzie się w tym momencie wymagało potwierdzenia, że
> można takie założenie poczynić no i oczywiście trafia to do bieżącej
> dokumentacji projektu. Jeśli klient potem zmieni zdanie, to mu można w
> tej sytuacji powiedzieć, że nie zrobimy albo że trzeba będzie to z
> punktu widzenia terminów i kosztóww potraktować jako robienie od nowa.

To byl tylko przyklad _jednej_ decyzji, ktora musisz podjac. Problem nie
lezy w tym, ze kazdy taki problem jest trudny, tylko ze tych problemow jest
duzo.

Bo takich decyzji projektowych, ktore trzeba podjac na poczatku (zeby w
ogole mozna bylo zaczac programowac) i ktorych odwrocenie bedzie pozniej
kosztowne jest cale multum. Czynnikow, ktore je determinuja tez jest cale
multum.
Wiara w to, ze mozna je wszystkie podjac na podstawie lub w czasie
polgodzinnej "rozmowy" z "customerem" jest doprawdy naiwna.

--
Michal