On May 23, 8:55 am, Maciej Sobczak <s...@g...com> wrote:
> On 23 Maj, 08:01, Andrzej Jarzabek <a...@g...com> wrote:
>
> Właśnie dlatego odbiór projektu wcale nie polega na uruchomieniu
> testów "z automata".

Ale też nikt nie mówi, że tak musi być. "Ready to release" nie
oznacza, że klient może sobie wziąć dowolne demo iteracji i używać
jako wersji release. W skrócie chodzi o to, żeby mógł po każdym demo
powiedzieć "robimy z tego release" i nie usłyszeć "ale ten ficzer w
demo nie jest dokończony i nie nadaje się do releasowania,
potrzebujemy jeszcze x tygodni na development." "Ready to release"
oznacza tyle, że po każdej iteracji, jeśli sobie klient tego zażyczy,
możesz uruchomić procedurę "release" z twoim demem jako "release
candidate". Ta procedura, w zależności od potrzeb, może obejmować
jakiś user acceptance testing i trwać tyle, ile koniecznie potrzeba,
żeby trwała i nie dłużej.

Z drugiej strony proces powinien (i różne metodologie agile tego też
wymagają) minimalizować szanse, że release się nie powiedzie. Do tego
służą praktyki mające na celu redukcję ilości bugów, ale do tego też
służy TDD.

> Skoro widziałeś większe produkty komercyjne, to przypomnij sobie, jak
> wyglądał ich odbiór. Dry-runs, "wygrzewanie", mniej lub bardziej
> ochotniczy beta-testerzy, itd. I na koniec jeszcze okres gwarancyjny.
> Te wszystkie rzeczy istnieją i są praktykowane właśnie dlatego, że
> testy z automata to pikuś, nawet jeśli masz 100% pokrycia.

Nie dlatego, że "pikuś", tylko dlatego, że pewnych rzeczy jednak nie
testują. Co do tego się przecież zgadzamy.

Co do gwarancji, to jest to jakby temat kompletnie ortogonalny do
Agile.

> Nikt nie kupuje samochodu na podstawie kwitu z automatycznej stacji
> diagnostycznej.

Stwierdzam, że nie będę dalej dyskutował z metaforami motoryzacyjnymi.

> > A możesz wyjaśnić, dlaczego tych danych, które wizualizujesz nie da się
> > przetestować automatycznie? To, o czym pisałeś nie da się powiązać z
> > jakąś mierzalną np. statystyczną właściwością danych?
>
> Oczywiście, że się da. Z wieloma mierzalnymi miarami, zwłaszcza z ROI
> (Return On Investment). Ta miara mówi, że nie ma sensu tego robić,
> nawet jeśli teoretycznie jest to możliwe. Dlatego nie robię i nie dam
> sobie tego wcisnąć "bo agile tak mówi" (a "Słowacki wielkim poetą
> był").

Agile mówi mniej więcej tyle, że należy pisać testy, które sprawdzają,
czy program działa. To, jakie dokładnie te testy mają być i co
obejmować pozostawia się do decydowania odpowiednim członkom zespołu.

I ja się w tym zgadzam, że _prawie_ zawsze dla każdego większego
programu, który będzie robiony dłużej niż 2 miesiące przez więcej niż
1-2 osoby i ma szanse mieć dodawaną jakąś funkcjonalność, np. w
postaci kolejnych wersji, _jakieś_ testy automatyczne warto napisać.
Niezależnie od tego, czy się akurat stosuje agile, czy nie.

> Inne przykłady:
>
> 1. Jakiś czas temu jeden z naszych grupowych kolegów (Sebastian Biały?
> bardzo przepraszam, jeśli nie pamiętam dokładnie) pokazywał efekty
> swojego programu do wyostrzania zdjęć. Wyniki są fantastyczne.
> Obstawiam, że nie robił tego przez TDD. Nie interesuje mnie, czy
> jakość tych algorytmów da się powiązać z czymkolwiek mierzalnym, bo
> *to nie ma sensu*. Miarą jakości jest tutaj opad szczęki a nie test "z
> automata".
>
> 2. Algorytm pogłosowy dla muzyków. Albo automatyczny aranżer w stylu
> wczesny japoński jazz alternatywny. TDD? Bez jaj.

Ale jeśli taki program ma być stosowany w środowisku produkcyjnym, to
oprócz powodowania opadu szczęki powinien zwykle posiadać odpowiednią
stabilność i niezawodność i do tego właśnie służy TDD. Jeśli wiesz
(dla jakiegoś tam poziomu pewności 'wiesz') że twój program poprawnie
liczy macierze, że się nie wywala po kliknięciu w buttona, że dla
wszystkich kombinacji ustawień generuje poprawny plik JPEG, to możesz
mniej uwagi poświęcić sprawdzianiu takich pierdół, a więcej na
testowanie opadu szczęki.

> Takich przykładów oczywiście jest więcej. A ponieważ informatyka służy
> do poprawiania nam życia, to takich wymagania są praktycznie w każdym
> systemie, może poza projektami studenckimi typu "napisać AVL".
> Oczywiście te wszystkie systemy w skali mikro składają się z
> drobiazgów, które da się pojedynczo objąć przez TDD, ale to jest skala
> mikro i żabia perspektywa. Dla takich wymagań ostatecznym arbitrem od
> strony konsumenta nie są testy z automata, tylko jazda próbna, albo
> paczka czipsów.

Ale są to też rzeczy, które mają mniejszą szansę pierdyknięcia z
tygodnia na tydzień, mimo że wcześniej przez ileś-tam tygodni działały
prawidłowo.

Poza tym w samej naturze takich problemów często leży to, że istnieją
kombinacje ustawień, dla których kopara nie opada. Np. jeśli weźmiesz
dowolny program z funkcją wyostrzania zdjęć przy pomocy "unsharp
mask", to tam masz dwa albo trzy suwaki i dla niektórych ustawień tych
suwaków efekt zdecydowanie nie jest przyjemny. Ale it's not a bug,
it's a feature. Natomiast gdyby dla nirktórych ustawień suwaków
program się wywalał, to byłby bug.

> Są też projekty, które można i warto jak najpełniej formalizować
> (najczęściej ogólnie rozumiane sterowanie procesami fizycznymi) - tam
> nie ma miejsca na elementy psychologiczne w ocenie jakości a działanie
> systemu da się dobrze opisać matematycznie. Ale uwaga, bo to jest
> ciekawe: właśnie w takich projektach waterfall sprawdza się bardzo
> dobrze.

A czasami (często) jest tak, że jesteś gdzieś pomiędzy. Na przykłąd że
wiadomo, że wartość pozycji liczy się w określony sposób, ale zawsze
jest możliwość, że będzie trzeba dodać dodatkowe pole, albo trzeba
będzie obsłużyć nowy rodzaj transakcji itd.

> Paru gości usiłuje pogodzić nurt agile z realiami systemów krytycznych
> (które zwykle dotyczą sterowania), dobre hasło to "Continuous
> Certification":
>
> http://www.open-do.org/
>
> ale z tego co wiem, to bardzo opornie im to idzie.

Dzięki za linka, ale na tej dziedzinie nie znam się kompletnie i nie
mam nic do powiedzenia.

> > Tak, automatyczne testowanie GUI to sprawdzanie czy naciśnięcie
> > przycisku powoduje pokazanie się odpowiedniego okienka, czy w gridzie są
> > odpowiednie dane itd. Pożytek z tego jest duży.
>
> A taki np. mBank nie potrafi nawet zaakceptować wartości, którą sam
> wyświetla (np. jeśli na koncie jest "1 234,56", to nie można tego
> przelać przez copy-paste).
> Może robią automatycznie testy tego "GUI". A może nie robią. Nie ma to
> znaczenia, bo testy tego typu mają złą granulację.

Jeśli wiesz, że masz taki problem, to napisanie testu GUI który to
sprawdzi nie powinno być problematyczne (zakładając że już masz
jakikolwiek sensowny framework do testowania GUI). Do odkrycia, że
masz w ogóle taki problem to służą inne praktyki (w tym wypadku
zapewne exploratory testing).

> > "Display" to monitor do komputera.
>
> "Display" w tym sensie, w jakim to użyłem, to ogół środków
> technicznych służących do wyświetlenia czegoś. JButton należy do tej
> grupy.

Ja użyłem GUI w sensie komponentu, który zawiera te wszystkie buttony
i oprogramowanie reakcji na operacje użytkownika. I tak, chodziło mi o
testy czy jak klikniesz tego czekboksa to się pojawią takie suwaki, a
jak wciśniesz ten przycisk, to wyskoczy taki dialog. I nie, to nie są
niepotrzebne testy, bo brak odpowiedniego zachowania dyskwalifikuje
program do release, natomiast prawdopdobieństwo takich bugów w
większym i dłużej trwającym projekcie jest zdecydowanie nie-
epsilonowe. W dodatku dokładne ręczne przetestowanie rozbudowanego GUI
zajęłoby wieki, więc się testowanie części opcji "pomija milczeniem" -
co się prędzej czy później kończy wypuszczeniem buga do produkcji.

> > Alternatywa jest taka, że klient ufa, że twoi specjaliści rozpoznają
> > jego potrzeby biznesowe i że ty będziesz te potrzeby implementował tak,
> > żeby zmaksymalizować wartość programu dla niego, i to zaufanie też ma
> > odzwierciedlenie w umowie.
>
> No właśnie. Nie mówmy "robimy agile, więc będzie dobrze". Mówmy
> "potrafimy rozpoznać Twoje potrzeby, więc będzie dobrze". Jedno i
> drugie to prymitywny marketing, ale przynajmniej w tym drugim
> przypadku stajemy się odpowiedzialnymi właścicielami końcowego efektu/
> klęski i nie zwalamy tego na jakiś proces.

Jak już pisałem, aspekt marketingowy mnie nie interesuje. Interesuje
mnie, czy te praktyki są dobre.

Osobiście też nie jestem przekonany, czy pełna widoczność procesu jest
zawsze dobrym rozwiązaniem, być może jest tak, że czasem słuszniejszym
podejściem jest "nikt nie chce wiedzieć, jak się robi kiełbasę".
Wydaje mi się, że decydują o tym skomplikowane czynniki kulturowe,
jednego klienta widocznośc uspokoi, inny powie, że oczywiście chce
mieć widoczność, ale jak ją będzie miał, to tylko będzie nerwowy i
będzie przeszkadzał w realizacji celu. I dlatego też wydaje mi się, że
jak się wchodzi w wariant z widocznością, to dobrze klientowi
wytłumaczyć, co się właściwie zamierza stosować. I oczywiście będziesz
miał klientów, których szczegóły nie będą interesować, ale zapytają,
czy ktoś już gdzieś z powodzeniem to zastosował. I tu właśnie wchodzi
aspekt marketingowy "stosujemy popularny proces sixsigma/CMMI/XP/Scrum/
Lean/RUP/wujwijeszczeco", w przypadku niektórych klientów jest to
potrzebne do stworzenia zaufania na początku. Tylko że niezależnie od
tego, uważam, że jak masz proces kijowy, to zaufanie się prędzej czy
później posypie (a raczej prędzej), natomiast jeśli chodzi o taktyki
celowego robienia klienta w bambuko, to mnie one również nie
interesują.