Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Mateusz Kurleto:
Dużo wnosi. TDD to koncepcja, która mówi - zanim zaczniesz pisać kod napisz testy, które zweryfikują jego zgodność z wymaganiami.

Co tu nazywamy wymaganiem?

A to zależy o jakim poziomie testów mówimy. Na poziomie testów jednostkowych to projekt klasy. Na poziomie testów funkcjonalnych to scenariusze przypadków użycia.

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

Co tu nazywamy wymaganiem?

A to zależy o jakim poziomie testów mówimy. Na poziomie testów jednostkowych to projekt klasy. Na poziomie testów funkcjonalnych to scenariusze przypadków użycia.

i oba to "TDD" bo mnie właśnie nie pasują dwie rzeczy:
- rozciąganie TDD na "wszelkie testy"
- testowanie przypadków użycia to scenariusze biznesowe (procesy biznesowe) a nie implementowane w kodzie "testy", owszem są programu symulujące prace użytkownika ale to raczej testy wydajności itp. a nie zachowania ludzi...Jarek Żeliński edytował(a) ten post dnia 23.10.12 o godzinie 08:41

Temat: TDD, testowanie i inne takie

Przepraszam ale czy to kolejny z tych tematów który będzie się ciągnął na 30 stron gdzie 2-3 osoby będzie się ciągle sprzeczać o detale ?

Testy jednostkowe zawsze są przydatne, niezależnie jak powstaje aplikacja. Główny powód to sprawdzenie jak największej części naszego kodu przewidując różne scenariusze (osobiście wierzę że interfejs każdej klasy powinien radzić sobie zarówno w wypadku prawidłowych jak i nieprawidłowych danych wyrzucając odpowiednie wyjątki). Im więcej sprawdzimy tym mniej miejsca zostaje na popełnienie błędów.
TDD to nie tylko testy jednostkowe swoją drogą. Problemem TDD jest to że nie jest to wygodna metoda kiedy projekt podlega ciągłym zmianom i trzeba mieć właściwie dedykowanego programistę (czasami nie jednego) w projekcie tylko od testów. I musi on nadążać tak by zespół owe testy miał gotowe. Fakt że w początkowej fazie cały zespół musi się nimi zająć ale ogólnie to zła praktyka by ten sam programista pisał zarówno testy jak i później kod pod nie.
A z ewangelistami TDD jest ten problem że wielu z nich (niektórych znam osobiście i o TDD rozwodzą się gdzie tylko można) nigdy tak na prawdę TDD nie stosowało. Można powiedzieć że dla nich to odległe marzenie i czasami mają zbyt wyidealizowane pojęcie o TDD.

Nie wiem jak inni widzą testy akceptacyjne ale dla mnie to zestaw testów które pokrywają tylko prawidłowe zachowanie programu (czyli test przewidzianych scenariuszy) by potwierdzić że to co zostało zamówione, rzeczywiście zostało wykonane. I wg mnie nijak mają się do testów jednostkowych. Fakt, będą powielać część tego co prawdopodobnie sprawdziliśmy ale też będą robić o wiele więcej. Nie sprawdzą też wszystkiego co sprawdzają testy jednostkowe.

Nie wiem czy jest jakaś sytuacja gdzie nie opłaca się pisać testów a decydować się powinniśmy na nie zawsze. Szczerze powiedziawszy najczęstszym argumentem na brak testów jest brak czasu lub pieniędzy co jest wg mnie nielogiczne.

Miałem okazję poznać z pierwszej ręki efekty braku testów współpracując z jedną firmą (pomagałem przy 2 projektach). Szef firmy twierdzi że na testy jednostkowe mają brak czasu i pieniędzy więc wg nich projekt wystarczy tylko "przeklikać". Jego pracownicy twierdzą odwrotnie bo na dzień dzisiejszy w miesiącu 30-50% czasu spędzają na poprawianiu błędów w obecnych i poprzednich projektach.Dariusz Półtorak edytował(a) ten post dnia 23.10.12 o godzinie 09:01

Temat: TDD, testowanie i inne takie

Dariusz Półtorak:
Przepraszam ale czy to kolejny z tych tematów który będzie się ciągnął na 30 stron gdzie 2-3 osoby będzie się ciągle sprzeczać o detale ?

to zależy czy rozmowa będzie polegała na wymianie poglądów czy udowadnianiu wyższości któregokolwiek ;)) (co też uczy ;))

Nie wiem jak inni widzą testy akceptacyjne ale dla mnie to zestaw testów które pokrywają tylko prawidłowe zachowanie programu (czyli test przewidzianych scenariuszy) by potwierdzić że to co zostało zamówione, rzeczywiście zostało wykonane. I wg mnie nijak mają się do testów jednostkowych.

po latach pracy zaryzykuję tezę, że:
- jeżeli program robi do czego powstał to jest dobrym programem,
- testowanie przypadków, dla których program nie powstał jest kosztowne i niczego nie wnosi (poza może satysfakcja testera), są tańsze metody (informacje pewnych "błędach" przechodzą do instrukcji obsługi): kubek kawy w McDonadzie ma napis "uwaga gorące" i pozwala się jednak wziąć do ręki (nie tworzymy testowalnej metody blokującej wzięcie go do reki gdy temperatura przekroczy 40stopni), strzykawki jednorazowe nie są testowane na wielokrotne ich użycie bo nie to było celem zamawiającego......itd.
- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Nie wiem czy jest jakaś sytuacja gdzie nie opłaca się pisać testów a decydować się powinniśmy na nie zawsze.

pisanie testów jako takie - tak, ale co powinno być testowane to już inna kwestia...

Szczerze powiedziawszy najczęstszym argumentem na brak testów jest brak czasu lub pieniędzy co jest wg mnie nielogiczne.

argumentem na brak "niektórych testów" może być zwykły rozsadek...

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
- rozciąganie TDD na "wszelkie testy"

Ale co tu jest rozciągane. TDD wskazuje jedynie aby pisać testy przed implementacją. To naprawdę nie jest wielka filozofia.

- testowanie przypadków użycia to scenariusze biznesowe (procesy biznesowe) a nie implementowane w kodzie "testy", owszem są programu symulujące prace użytkownika ale to raczej testy wydajności itp. a nie zachowania ludzi...

No ja się absolutnie nie zgodzę. Po pierwsze nikt nie powiedział, że testy muszą być "implementowane w kodzie" - cokolwiek by to miało znaczyć.
Po drugie testy funkcjonalne jak najbardziej mogą być automatyzowane.
Po trzecie automatyczne testy funkcjonalne wykorzystywane np. jako testy regresyjne lub integracyjne są doskonałym obszarem do stosowania TDD.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Nie wiem jak inni widzą testy akceptacyjne ale dla mnie to zestaw testów które pokrywają tylko prawidłowe zachowanie programu (czyli test przewidzianych scenariuszy) by potwierdzić że to co zostało zamówione, rzeczywiście zostało wykonane. I wg mnie nijak mają się do testów jednostkowych.

po latach pracy zaryzykuję tezę, że:
- jeżeli program robi do czego powstał to jest dobrym programem,

Testy powinny to udowodnić

- testowanie przypadków, dla których program nie powstał jest kosztowne i niczego nie wnosi (poza może satysfakcja testera), są tańsze metody (informacje pewnych "błędach" przechodzą do instrukcji obsługi): kubek kawy w McDonadzie ma napis "uwaga gorące" i pozwala się jednak wziąć do ręki (nie tworzymy testowalnej metody blokującej wzięcie go do reki gdy temperatura przekroczy 40stopni), strzykawki jednorazowe nie są testowane na wielokrotne ich użycie bo nie to było celem zamawiającego......itd.

Kompletnie bezsensowny przykład. Mylisz testy z narzutami na safety. Testowanie weryfikuje działanie systemu w obszarze jego zastosowań - ale także w obszarze obsługi błędów. Tj. w ramach testów powinniśmy sprawdzić również co się stanie w systemie jak wartość pozycji na fakturze wpiszę słownie - czy system się wysypie i będzie wymagał manualnego restartu - czy może wyskoczy ładny komunikat, że wartość musi być liczbowa.

- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Bardzo naiwne podejście do projektu. Gdyby tak było skrócił bym czas wykonania wszystkich swoich systemów najmniej o 50%.

Szczerze powiedziawszy najczęstszym argumentem na brak testów jest brak czasu lub pieniędzy co jest wg mnie nielogiczne.

argumentem na brak "niektórych testów" może być zwykły rozsadek...

To jakaś kompletna abstrakcja. Przecież nikt nie testuje czy system do zarządzania flotą samochodów poprawnie steruje elektrownią atomową.

Temat: TDD, testowanie i inne takie

Dariusz Półtorak:
Przepraszam ale czy to kolejny z tych tematów który będzie się ciągnął na 30 stron gdzie 2-3 osoby będzie się ciągle sprzeczać o detale ?

Wiesz jak to jest z tymi detalami. Często to nie są "tylko" detale, ale "aż" detale. Z drugiej strony, mnogość detali, to już istotna rzecz:)

Nie wiem czy jest jakaś sytuacja gdzie nie opłaca się pisać testów

No, jak jakiś skrypcik w bashu dla siebie piszesz, to testy możnesz sobie podarować :P

a decydować się powinniśmy na nie zawsze. Szczerze powiedziawszy najczęstszym argumentem na brak testów jest brak czasu lub pieniędzy co jest wg mnie nielogiczne.

Jeżeli osoba, która decyduje się na taką "oszczędność" wyciągnie wnioski na przyszłość, to jest pouczające, w innym wypadku można tylko "pozazdrościć" nieumiejętności patrzenia w przód.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Pod warunkiem, że testujemy wszystkie pożądane zachowania tzn. nie tylko scenariusze zapewniające sukces, ale również jak najwięcej tych generujące błędy, które powinny być obsłużone.

pisanie testów jako takie - tak, ale co powinno być testowane to już inna kwestia...

Wszystko co nie jest trywialne:)

argumentem na brak "niektórych testów" może być zwykły rozsadek...

Argumentem na brak niektórych testów może być ilość możliwych scenariuszy, których testowanie byłoby po prostu nieopłacalne. W takim wypadku wybiera się te najistotniejsze, a resztę (świadomie) pomijamy.

Mateusz Kurleto:
Kompletnie bezsensowny przykład. Mylisz testy z narzutami na safety. Testowanie weryfikuje działanie systemu w obszarze jego zastosowań - ale także w obszarze obsługi błędów. Tj. w ramach testów powinniśmy sprawdzić również co się stanie w systemie jak wartość pozycji na fakturze wpiszę słownie - czy system się wysypie i będzie wymagał manualnego restartu - czy może wyskoczy ładny komunikat, że wartość musi być liczbowa.

Ale z drugiej strony takie komunikaty i walidacja to również część wymagań (bo dane muszą być spójne i poprawne), więc takie testy również nie sprawdzają niczego nadmiarowego, a jedynie to, co jest wymagane.
Przykład @Jarka Żelińskiego był dobry, cholernie przejaskrawiony:), ale dobry.
Zdarza się, że tester, sprawdzając jakąś funkcjonalność chce przetestować ją pod każdym możliwym względem, a prawda jest taka, że to jest niemożliwe. Dlatego powinien się skupić tylko i wyłącznie na zachowaniach, które mają być obsługiwane.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
to zależy czy rozmowa będzie polegała na wymianie poglądów czy udowadnianiu wyższości któregokolwiek ;)) (co też uczy ;))

Z doświadczenia wiem że na ogół to drugie :) Dlatego zapytałem.

po latach pracy zaryzykuję tezę, że:
- jeżeli program robi do czego powstał to jest dobrym programem,

Coś co uczą na studiach. Program to coś co działa. Dobry program to coś co działa i robi to do czego został stworzony.

- testowanie przypadków, dla których program nie powstał jest kosztowne i niczego nie wnosi (poza może satysfakcja testera), są tańsze metody (informacje pewnych "błędach" przechodzą do instrukcji obsługi): kubek kawy w McDonadzie ma napis "uwaga gorące" i pozwala się jednak wziąć do ręki (nie tworzymy testowalnej metody blokującej wzięcie go do reki gdy temperatura przekroczy 40stopni), strzykawki jednorazowe nie są testowane na wielokrotne ich użycie bo nie to było celem zamawiającego......itd.
- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Ale kubek kawy w McDonaldzie jest jednorazowego użytku i raczej jest mało skomplikowany. Równie dobrze mogę zapytać czemu nie ma na nim napisane że nie jest jadalny. To nie ma nic do tematu. Programy z natury takie nie są bardzo często (proste bądź jadalne). To że scenariusz sklepu przewiduje że użytkownik wykona 3 kroki, wybierze przedmioty, poda dane i potwierdzi zakup to jedna rzecz ale zwłaszcza sklepy o dużym ruchu powinny być przygotowane na przykład na to (realny przypadek, poprawiałem sklep u znajomego przedsiębiorcy) że administrator usunie / zmodyfikuje jakiś przedmiot w sklepie pomiędzy jego wybraniem do koszyka a potwierdzeniem zamówienia.

Ogólnie zabawa polega na tym że jeżeli użytkownik MOŻE coś zrobić to należy to sprawdzić. Flagowy przykład gdzie z kolegą przygotowaliśmy automatem koszyk z zakupami który kwotą przekroczył 1/100 inta. Dodam że chodziło o int bo ktoś postanowił zamiast używać funkcję z rodziny bc*, operować na groszach. Więc wartości na jakich operował sklep były x100.

No to dokonaliśmy automatem zakupów na kwotę dokładnie 214748365,10 zł. Potwierdziliśmy zamówienie i zaznaczyliśmy że chcemy fakturę. Zarówno zamówienie jak i faktura opiewały na kwotę 30 zł. Wszystko dzięki temu że ktoś wpadł na pomysł by 21474836510 (php traktuje już te wartości jako float) rzutować na inta...

Nie wiem czy jest jakaś sytuacja gdzie nie opłaca się pisać testów a decydować się powinniśmy na nie zawsze.

pisanie testów jako takie - tak, ale co powinno być testowane to już inna kwestia...

Szczerze powiedziawszy najczęstszym argumentem na brak testów jest brak czasu lub pieniędzy co jest wg mnie nielogiczne.

argumentem na brak "niektórych testów" może być zwykły rozsadek...

Mówiłem o braku jakichkolwiek testów powyżej "przeklikania". Jest Pan na rynku wystarczająco długo. Nie wiem jak duże firmy ale niemal wszystkie małe i średnie z którymi miałem do czynienia testów prawie nie przeprowadzają. Może w moim regionie jakaś czarna dziura występuje więc się za wszystkich nie wypowiem.Dariusz Półtorak edytował(a) ten post dnia 23.10.12 o godzinie 11:55

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

Jarek Żeliński:
- rozciąganie TDD na "wszelkie testy"

Ale co tu jest rozciągane. TDD wskazuje jedynie aby pisać testy przed implementacją. To naprawdę nie jest wielka filozofia.

to rozumiem i OK, w zasadzie dobrze opisane przypadki użycia to nic innego jak testy napisane przed implementacją

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

po latach pracy zaryzykuję tezę, że:
- jeżeli program robi do czego powstał to jest dobrym programem,

Testy powinny to udowodnić

tak, testujemy to sprawdzając, czy system spełnia wymagania: scenariusze testowe (albo odbiorowe jak zwał)

- testowanie przypadków, dla których program nie powstał jest kosztowne i niczego nie wnosi (poza może satysfakcja testera), są tańsze metody (informacje pewnych "błędach" przechodzą do instrukcji obsługi): kubek kawy w McDonadzie ma napis "uwaga gorące" i pozwala się jednak wziąć do ręki (nie tworzymy testowalnej metody blokującej wzięcie go do reki gdy temperatura przekroczy 40stopni), strzykawki jednorazowe nie są testowane na wielokrotne ich użycie bo nie to było celem zamawiającego......itd.

Kompletnie bezsensowny przykład. Mylisz testy z narzutami na safety. Testowanie weryfikuje działanie systemu w obszarze jego zastosowań - ale także w obszarze obsługi błędów.

Przykład moim zdaniem sensowny, obsługa błędu może być "tania" a może być "kosztowna" a zależy to od tego co jest celem obsługi błędu? Czasem wystarczy, że oprogramowanie nie "zawiesi" całego systemu operacyjnego (tania obsługa błędu) , a czasem błąd staje się wręcz przypadkiem użycia i jego "obsługa: jest kosztowna w implementacji.

- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Bardzo naiwne podejście do projektu. Gdyby tak było skrócił bym czas wykonania wszystkich swoich systemów najmniej o 50%.

może faktycznie się mylę, podaj przykład

argumentem na brak "niektórych testów" może być zwykły rozsadek...

To jakaś kompletna abstrakcja. Przecież nikt nie testuje czy system do zarządzania flotą samochodów poprawnie steruje elektrownią atomową.

ale przyznasz, że bez sensu jest autocasco droższe od samochodu...

Temat: TDD, testowanie i inne takie

Dariusz Półtorak:
Mówiłem o braku jakichkolwiek testów powyżej "przeklikania". Jest Pan na rynku wystarczająco długo. Nie wiem jak duże firmy ale niemal wszystkie małe i średnie z którymi miałem do czynienia testów prawie nie przeprowadzają. Może w moim regionie jakaś czarna dziura występuje więc się za wszystkich nie wypowiem.

ano tu jest pies pogrzebany: jeżeli menadżer uzna, że koszt (skutki) "awarii" to wg. niego 1000zł, to nie da na testy, które z jakimś prawdopodobieństwem uchronią go przed ta awaria, więcej niż te 1000zł skorygowane o prawdopodobieństwo wystąpienia, i developer musi z tym sobie poradzić.

Moje "lata pracy w terenie" potwierdzają także to, że większość menedżerów gra w LOTTO rezygnując z testów (ludziom się sypie bo mieli pecha, u mnie nie ....)

Ja nauczony doświadczeniem:
- rozpisujące wyceny projektu na drobne, jest tam np. pozycja testy (ale to znaczy, że do wyceny musi być projekt a nie wizja ;))
- opisuję proces wytworzenia i staram wskazać ryzyka pominięcia każdego etapu tego procesu
- klient sam, teraz świadomie, skreśla co uzna za stosowne,
- czasami (jak za dużo poskreśla) rezygnuje z projektu.

od wielu klientów wiem, że gdy dostana ofertę "System CRM napiszemy za 1000tys.zł" i to jest cała jego wiedza, zaczyna "na czuja" obniżać budżet nie mając pojęcia o ryzyku każdego z tych skreśleń, bo ich nie widzi i nie rozumie. Dobra informacja: powolutku przybywa świadomych klientów ;)

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Mateusz Kurleto:

Jarek Żeliński:
- rozciąganie TDD na "wszelkie testy"

Ale co tu jest rozciągane. TDD wskazuje jedynie aby pisać testy przed implementacją. To naprawdę nie jest wielka filozofia.

to rozumiem i OK, w zasadzie dobrze opisane przypadki użycia to nic innego jak testy napisane przed implementacją

Nie prawda. Testy to nie tylko scenariusze to także dane wprowadzane i odbierane na każdym kroku. Scenariusze PU mogą być co najwyżej podstawą do stworzenia testów.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:
Przykład moim zdaniem sensowny, obsługa błędu może być "tania" a może być "kosztowna" a zależy to od tego co jest celem obsługi błędu? Czasem wystarczy, że oprogramowanie nie "zawiesi" całego systemu operacyjnego (tania obsługa błędu) , a czasem błąd staje się wręcz przypadkiem użycia i jego "obsługa: jest kosztowna w implementacji.

Jaka by nie była należy to uwzględnić w wymaganiach i testować czy działa zgodnie z nimi. To jakaś erystyka. Argumentujesz nie to co jest przedmiotem dyskusji. Ja nie przeczę, że błędy można obsługiwać tanio lub drogo. Przeczę, że możliwość poparzenia się gorącym kubkiem jest tematem do dyskusji w kwestii testowania. Pytanie czy wymagania stwierdzają:
- kawa ma mieć minimum 90 stopni a maksimum 95 stopni celsjusza
jeśli tak to w ramach testów trzeba wziąć 100 kaw i sprawdzić, czy wszystkie mieszczą się w przedziale
jeśli wymaganie stwierdza dodatkowo
- temperatura zewnętrzna kubka z kawą o temperaturze z zakresu 90-95 stopni celsjusza nie będzie przekraczała 40 stopni celsjusza
wtedy należy jeszcze zmierzyć temperaturę po wlasniu kawy i okresie nagrzewania się kubka
a Ty mówisz, ze aby sprawdzić czy kawa jest dość gorąca, trzeba stworzyć mechanizm chłodzenia kubka i że to drogie i się może nie opłacać - to kompletnie nie ma nic wspólnego z testami; test ma zweryfikować czy coś spełniono, czy nie - a nie cokolwiek modyfikować.

- jeżeli program przejdzie testy z pomocą zdefiniowanych na początku projektu, przypadków użycia , "jest dobry", jeżeli jednak okaże się w przyszłości coś jest nie tak to obstawiam, że zły był projekt a nie testy.

Bardzo naiwne podejście do projektu. Gdyby tak było skrócił bym czas wykonania wszystkich swoich systemów najmniej o 50%.

może faktycznie się mylę, podaj przykład

Istnieje jakieś 50 online-owych systemów do wystawiania faktur. Gdyby było tak jak mówisz wszystkie byłyby identyczne, bo wszystkie pozwalają na wystawienie poprawnej faktury. Niemniej jednak różnią się od siebie i inwestor zlecający wykonanie infakt-u pewnie nie przyjąłby wykonania wfirmy - i odwrotnie.

argumentem na brak "niektórych testów" może być zwykły rozsadek...

To jakaś kompletna abstrakcja. Przecież nikt nie testuje czy system do zarządzania flotą samochodów poprawnie steruje elektrownią atomową.

ale przyznasz, że bez sensu jest autocasco droższe od samochodu...

Jarek - znowu Schopenhauer? Przecież to nie ma żadnego związku.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Dariusz Półtorak:
Mówiłem o braku jakichkolwiek testów powyżej "przeklikania". Jest Pan na rynku wystarczająco długo. Nie wiem jak duże firmy ale niemal wszystkie małe i średnie z którymi miałem do czynienia testów prawie nie przeprowadzają. Może w moim regionie jakaś czarna dziura występuje więc się za wszystkich nie wypowiem.

ano tu jest pies pogrzebany: jeżeli menadżer uzna, że koszt (skutki) "awarii" to wg. niego 1000zł, to nie da na testy, które z jakimś prawdopodobieństwem uchronią go przed ta awaria, więcej niż te 1000zł skorygowane o prawdopodobieństwo wystąpienia, i developer musi z tym sobie poradzić.

Moje "lata pracy w terenie" potwierdzają także to, że większość menedżerów gra w LOTTO rezygnując z testów (ludziom się sypie bo mieli pecha, u mnie nie ....)

Ja nauczony doświadczeniem:
- rozpisujące wyceny projektu na drobne, jest tam np. pozycja testy (ale to znaczy, że do wyceny musi być projekt a nie wizja ;))
- opisuję proces wytworzenia i staram wskazać ryzyka pominięcia każdego etapu tego procesu
- klient sam, teraz świadomie, skreśla co uzna za stosowne,
- czasami (jak za dużo poskreśla) rezygnuje z projektu.

od wielu klientów wiem, że gdy dostana ofertę "System CRM napiszemy za 1000tys.zł" i to jest cała jego wiedza, zaczyna "na czuja" obniżać budżet nie mając pojęcia o ryzyku każdego z tych skreśleń, bo ich nie widzi i nie rozumie. Dobra informacja: powolutku przybywa świadomych klientów ;)

Przypadek który opisałem to zewnętrzna firma która wykonuje projekty dla innych (wykonawca) i bierze na siebie również utrzymanie projektów z naprawianiem błędów włącznie.
Nawet jeżeli koszt jednego błędu to będzie kilkaset złotych to trzeba brać pod uwagę że:
- błędów może być więcej jak jeden (to raczej pewne)
- mogą nam wystąpić pojedynczo lub na raz (ktoś będzie miał urwanie głowy albo będzie panika w firmie)
- będą się kumulować z różnych projektów (bo przecież to nie tak że tylko w jednym serwisie się pojawią)
- i nie wiadomo czy firma nadąży z ich poprawianiem w stosunku do nowych projektów i nowych błędów (nie mówiąc o tym że w firmach korzystających z własnych rozwiązań błędny kod może się przenosić z projektu na projekt wraz z nowymi elementami które są tworzone).

Biorąc pod uwagę że przez ostatnie 2 lata owa firma spędza na poprawkach coraz więcej czasu w skali miesiąca to kiedy można się spodziewać że ten trend ustanie ? Myślenie w kategorii błędu za 1000zł jest troszkę ograniczone wg mnie (chodzi o przypadkowego menedżera) bo może jeden grosik to nie dużo ale co się stanie jak zacznie się ich pojawiać więcej i więcej ?
Jak tak dalej pójdzie będą musieli zatrudnić nowego programistę/ów. Co najgorsze - nie do tego by zwiększyć moc przerobową firmy tylko po to by poradzić sobie z problemami które sami stworzyli.

Ja tu opisuję niestety prawdziwy przypadek firmy która na rynku jest ponad 10 lat i podejście do testów mają takie że "wystarczy porządnie przeklikać".

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

to rozumiem i OK, w zasadzie dobrze opisane przypadki użycia to nic innego jak testy napisane przed implementacją

Nie prawda. Testy to nie tylko scenariusze to także dane wprowadzane i odbierane na każdym kroku. Scenariusze PU mogą być co najwyżej podstawą do stworzenia testów.

racja, pominąłem: scenariusze przypadków użycia można uzupełnić testowymi danymi wejściowymi i wyjściowymi ...

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

Jarek Żeliński:
Przykład moim zdaniem sensowny, obsługa błędu może być "tania" a może być "kosztowna" a zależy to od tego co jest celem obsługi błędu? Czasem wystarczy, że oprogramowanie nie "zawiesi" całego systemu operacyjnego (tania obsługa błędu) , a czasem błąd staje się wręcz przypadkiem użycia i jego "obsługa: jest kosztowna w implementacji.

Jaka by nie była należy to uwzględnić w wymaganiach i testować czy działa zgodnie z nimi. To jakaś erystyka.

nie Mateusz, to nie jest erystyka, to zwrócenie uwagi na coś o czym zapomina wielu programistów: kupujący oprogramowanie może mieć inny system wartości niż jego twórcaJarek Żeliński edytował(a) ten post dnia 23.10.12 o godzinie 16:03

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Mateusz Kurleto:

to rozumiem i OK, w zasadzie dobrze opisane przypadki użycia to nic innego jak testy napisane przed implementacją

Nie prawda. Testy to nie tylko scenariusze to także dane wprowadzane i odbierane na każdym kroku. Scenariusze PU mogą być co najwyżej podstawą do stworzenia testów.

racja, pominąłem: scenariusze przypadków użycia można uzupełnić testowymi danymi wejściowymi i wyjściowymi ...

Co więcej musisz to rozpatrywać nie per przypadek użycia tylko per każdy krok scenariusza.

Temat: TDD, testowanie i inne takie

Jarek Żeliński:

Mateusz Kurleto:

Jarek Żeliński:
Przykład moim zdaniem sensowny, obsługa błędu może być "tania" a może być "kosztowna" a zależy to od tego co jest celem obsługi błędu? Czasem wystarczy, że oprogramowanie nie "zawiesi" całego systemu operacyjnego (tania obsługa błędu) , a czasem błąd staje się wręcz przypadkiem użycia i jego "obsługa: jest kosztowna w implementacji.

Jaka by nie była należy to uwzględnić w wymaganiach i testować czy działa zgodnie z nimi. To jakaś erystyka.

nie Mateusz, to nie jest erystyka, to zwrócenie uwagi na coś o czym zapomina wielu programistów: kupujący oprogramowanie może mieć inny system wartości niż jego twórca

Ale mówisz o jabłkach a wnioskujesz z gruszek. To nie dowodzi poprzedniej tezy. Bottom line - ja się zgadzam, że wiele niepożądanych dla użytkownika systemu reakcji systemu możemy obsłużyć tanio lub drogo - to nie ma jednak wpływu na zasadność testowania czy korzyści płynące z TDD.
Jeśli klient wymaga taniej obsługi - trzeba sprawdzać czy obsługujemy tanio - jeśli drogiej to sprawdzać czy drogo - ale sprawdzić trzeba.

Temat: TDD, testowanie i inne takie

Mateusz Kurleto:

racja, pominąłem: scenariusze przypadków użycia można uzupełnić testowymi danymi wejściowymi i wyjściowymi ...

Co więcej musisz to rozpatrywać nie per przypadek użycia tylko per każdy krok scenariusza.

no fakt...