Unit testy

[margonik]

Mam pytanie do osób, które pracują w firmach robiących software. Jak jest u
Was w firmie, czy znane Wam są unit testy i na ile są one powszechne?
Stosujecie? Czy macie to jakoś narzucone odgórnie, czy programiści stosują
lub nie, wg uznania? Co na ten temat sądzicie? Czy w związku z tym stosujecie
daily building? Na ile macie wykwalifikowanych testerów? Czy potrafią coś
ponad klikologię?

Prośba, aby odpowiadając przybliżyć nieco profil firmy.

U mnie nie stosuje się unit testów, ani daily building, choć temat się
pojawia. Testerzy orientują się w bazach danych, czasami pracują w środowisku
debugera, to wszystko. Inne narzędzia są im obce. W kwestii unit testów i
daily building osobiście jestem bardzo za, aczkolwiek w codziennym pośpiechu
i bez odgórnych "dyrektyw" ciężko to wdrożyć.

[dritte_dame]

margonik napisała:

> Mam pytanie do osób, które pracują w firmach robiących software. Jak jest u
> Was w firmie, czy znane Wam są unit testy

Tak.

> i na ile są one powszechne?

Dosc powszechne.

> Stosujecie?

Kazdy odpowiedzialny programista dbajacy o swoje zatrudnienie stara sie
stosowac.

> Czy macie to jakoś narzucone odgórnie,

W wiekszosci przypadkow - nie.
Ale techniczni liderzy zespolow dbaja o to aby testy istnialy i byly rozsadnie
latwo dostepne do uzycia.

> czy programiści stosują
> lub nie, wg uznania?

Wedlug uznania, ale w dobrze pojetym wlasnym interesie raczej tak.

> Co na ten temat sądzicie?

Nieodzowne i bardzo pomocne w pracy.
Zwlaszcza przy "refactoring".
Pozwalaja na odwazniejsze zmiany calej architektury (zamiast ostroznego łatania
to tu to tam) - gdyz mozna latwo sprawdzic czy po takim wiekszym pruciu program
nadal dziala nie gorzej niz poprzednio - a jesli sie okaze ze gorzej - to
natychmiast poprawic w 10 minut zamiast po 3 miesiacach szukac bledu przez
kilka dni i nocy.

> Czy w związku z tym stosujecie
> daily building?

Oczywiscie.
W pelni zautomatyzowany, na 4 OS-ach rownoczesnie, z automatycznym
powiadamianiem e-mailem o wyniku i z automatycznymi raportami o stanie pakietow
instalacyjnych na wewnetrznym web-ie.

> Na ile macie wykwalifikowanych testerów?
> Czy potrafią coś
> ponad klikologię?

Tak.
Sami projektuja i pisza automatyczne testy i maja znaczna wiedze o bazach
danych i o samej metodologii testowania.

> Prośba, aby odpowiadając przybliżyć nieco profil firmy.

Kanada.
Okolo 300 pracownikow R&D.
Oprogramowanie analityczne (OLAP) glownie do uzytku duzych korporacji.

> U mnie nie stosuje się unit testów, ani daily building, choć temat się
> pojawia.

Szczerze zalecam.
*Zwlaszcza* daily building & smoke test.

> Testerzy ... czasami pracują w środowisku
> debugera,

A po co im to?
Testerzy powinni sie koncetrowac wylacznie na "black box" testing.

> W kwestii unit testów i
> daily building osobiście jestem bardzo za,

Popieram, popieram.

> aczkolwiek w codziennym pośpiechu
> i bez odgórnych "dyrektyw" ciężko to wdrożyć.

A jaka test ta Twoja firma?

Te akurat sprawy ciezko jest wdrozyc bez *oddolnego* poparcia.
A poparcie takie powstaje gdy programisci doswiadcza na sobie konkretnych
korzysci.
Jak na przyklad - oszczednosc czasu i wysilku dotychczas marnowanego na
odpluskwianie.

Proponuje zaczac od mozliwie zautomatyzowanego "daily build & smoke test" w
malym zespole, z wprowadzeniem zasady ze poranny kod *musi* dzialac - no mater
what (a osoba winna bledu kompilacji lub upadku testu stawia wszystkim piwo,
pączki, lub cos takiego :)).

Jesli spowalnia to implementacje nowych funkcji programu to nic nie szkodzi -
wszystko sie odzyska z wieeeeelka nawiazka przy "uruchamianiu" - ktorego
praktycznie w tej sytuacji nie ma, gdyz program przeciez *zawsze* dziala!

[Gość: margonik]

Zazdroszczę sposobu pracy. Jak sie domyślam, macie konkretny podział ról. Ja na
przemian łączę rolę analityka, programisty, product managera i kilka innych. 5
minut kodowania - telefon - 5 minut kodowania - telefon... Do tego brak
automatycznych testów w sytuacji, gdy wiele projektów chodzi na wspólnym
kodzie. Wysyłając wersję wysyłasz prawdziwy "black box"!

> > Testerzy ... czasami pracują w środowisku debugera
> A po co im to?
> Testerzy powinni sie koncetrowac wylacznie na "black box" testing.

Nie ma daily building, więc tak jest czasami łatwiej - nie trzeba na bieżąco
robić wersji. A przy okazji w środowisku są lepsze info o błędach, na bieżąco
mozna zaraz podglądnąć zmienne itd. No i programista zamiast zrzutu
ekranu "Runtime error", dostaje czasami namiar od razu na konkretny błąd. To
sie przydaje, szczególnie, jeżeli błąd nie jest łatwy do powtórzenia.

> [testerzy] Sami projektuja i pisza automatyczne testy

Są programistami, czy używacie jakichś kreatorów do unit testów?

> A jaka test ta Twoja firma?

Koło 100 osób, systemy dla biznesu dla dużych klientów, głownie finansowe.

Podział ról

[dritte_dame]

Gość portalu: margonik napisał(a):

> Zazdroszczę sposobu pracy. Jak sie domyślam, macie konkretny podział ról.

Dosc konkretny.
Sa dobrze okreslone grupy, ktore nie wchodza sobie w droge.
Sa konieczne sprzezenia zwrotne dla dotarcia np. wymagan i specyfikacji ale
poza tym to zakres obowiazkow dla kazdego rodzaju pracy i poziomu kwalifikacji
jest zdefiniowany, spisany i opublikowany w wewnetrznych dokumentach firmy.

Kierownicy produktow
Kierownicy projektow
Kierownicy zespolow
Architekci i inzynierowie oprogramowania
Testerzy
Dokumentalisci
Tlumacze
...

Z rozwojem firmy codzienne i produkcyjne budowanie kilkunastu produktow, na
kilku OS-ach, w kilkunastu jezykach i kilku suportowanych wersjach stalo sie
tak zlozone ze okolo 5 lat temu powstal specjalny, obecnie kilkunastoosobowy
zespol zajmujacy sie wylacznie tym.
Oni dbaja o bezpieczenstwo kodu w SCCS i automatyzuja budowanie.

przerwania

[dritte_dame]

Gość portalu: margonik napisał(a):

> Ja na
>
> przemian łączę rolę analityka, programisty, product managera i kilka innych.
5
> minut kodowania - telefon - 5 minut kodowania - telefon...

No, chyba _nieco_ przesadzasz.
Przeciez tak sie nie da w ogole nic porzadnie zrobic.

Wybierz to co bardziej lubisz i lepiej robisz.
A jesli przede wszystkim lubisz wieksza kase to wybierz to co takowa daje.

Analityka i programiste mozna polaczyc (jak w moim przypadku).
Podobnie mozna polaczyc dwie lub trzy funkcje kierownicze.
Ale nie da sie wydajnie polaczyc funkcji technicznej i kierowniczej.
A zwlaszcza w tym samym czasie.

Nasi kierownicy nigdy, przenigdy nie dotykaja kodu - choc orientuja sie
swietnie w jego funkcjach, biezacych wadach, zmianach w toku itp. - ale nie w
jego konstrukcji.
Podobnie, nawet najwieksi techniczni guru nie sa obciazani zarzadzaniem - oni
maja tylko dostarczyc kierownikom informacji potrzebnej do zarzadzania.

Jesli wybierzesz role kierownicza to praca w trybie przerwaniowym bedzie
normalna i spodziewana.

Ale jesli techniczna to.. "5 minut kodowania - telefon..."
Jaki telefon? Zewnetrzny?!
Prawdziwa zgroza.

Ale jesli wewnetrzny to moze masz na to jakis wplyw.

Wylaczaj telefon - niech sie ludzie nagrywaja na voice mail.
Odsluchuj i reaguj 2 do 3 razy dzienie.
Ja gdy akurat cos wiekszego robie to nawet firmowego e-majla nie mam stale
wlaczonego.

Moze podziel swoj tydzien.
Poniedzialek, Wtorek, Sroda - kierownik.
Czwartek, Piatek - technik
Sobota, Niedziela i oficjale swieta - wybierz role rzucajac monete - gdy stanie
sztorcem to masz wolne :))

W najgorszym wypadku - podziel dzien.
Od switu do poludnia kierownik a od poludnia do polnocy technik :)

[Gość: margonik]

> No, chyba _nieco_ przesadzasz.

Nie przesadzam. Dlatego jestem już tym strasznie zmęczona i co raz częściej
myślę o zmianie pracy.

Na dodatek jako kierownik nie mam stałego zespołu. Wyrywamy sobie ludzi
wzajemnie od projektu do projektu. Ludzie przez to nie są zaangażowani, bo nie
identyfikują się z projektem. A ja nie jestem w stanie ułożyć sensownego
harmonogramu, bo nie wiem nigdy, czy daną osobę jeszcze jutro będę miała.

Gdybym miała wybierać, to funkcję kierowniczą odrzuciłabym bez najmniejszego
wahania. Może brzmi to niewiarygodnie, ale wszystkie moje stresy zawodowe,
zmęczenie, zniechęcenie i wszelkie inne negatywne emocje, jakie wiażę z pracą,
sa jej pochodną. Przy projektowaniu i programowaniu relaksuję się.

> Ale jesli techniczna to.. "5 minut kodowania - telefon..."
> Jaki telefon? Zewnetrzny?!

Zewnętrzny. Bezpośrednio obsługuję klienta. Począwszy od supportu i
konsultacjach, kończąc na rozmowach z działem finansowym i udział w
negocjowaniu umów. Wiem, że to chore. Telefonu tez nie mogę do nikogo
przekierować, bo większość rozmów, to rozmowy merytoryczne lub na tematy
finansowe i nie ma za bardzo takiej osoby, która mogłaby je odbierać.

> Ja gdy akurat cos wiekszego robie to nawet firmowego e-majla nie mam stale
> wlaczonego.

Na niewiele by sie to zdało, bo mamy open space :-)
Wiem, wiem, kolejna zgroza. Dlatego chyba poważnie zacznę szukać nowej pracy.

> Od switu do poludnia kierownik a od poludnia do polnocy technik :)

Mniej więcej coś takiego robię. Jak biuro pustoszeje i telefon milknie,
zamieniam się w technika :-)

[dritte_dame]

Gość portalu: margonik napisał(a):

> > No, chyba _nieco_ przesadzasz.
>
> Nie przesadzam. Dlatego jestem już tym strasznie zmęczona i co raz częściej
> myślę o zmianie pracy.

Czy chcesz znalezc lepiej zorganizowana firme IT
czy raczej - zupelnie zmienic branze?


> Wyrywamy sobie ludzi
> wzajemnie od projektu do projektu. ... nie wiem nigdy, czy daną osobę jeszcze
jutro będę miała.

U nas to bylby ewidentny dowod niekompetencji Twojego kierownika - skoro
kieruje kierownikami, ktorym nie potrafi zapewnic stabilnych zasobow na czas
wymonania zadan.
Nasi ludzie przechodza od projektu do projektu - albo na stale - albo
sa "wypozyczani" na jakis ustalony czas ale nigdy w trybie wyrywania sobie.

Jesli jakiemus kierownikowi potrzebny jest ekspert dostepny w innym zespole to
pyta on kierownika tego eksperta czy (i na jak dlugo) moze czlowieka przejac.
Jesli biezacy kierownik uwaza ze tenze ekspert jest w jego projekcie
niezastapiony to uzasadnia *dlaczego* tak jest (i jak dlugo to potrwa) i obaj
kierownicy zwracaja sie po decyzje do ich obu wspolnego szefa.
Wspolny szef moze wtedy zdecydowac ze pierwszy projekt jest aktualnie mniej
wazny i przeniesc czlowieka mimo objekcji jego obecnego kierownika.
Wowczas jednak - musi ustalic z obecnym kierownikiem nowy, odleglejszy termin
wykonania jego projektu.
Nie moze od pierwszego kierownika wymagac dotrzymania oryginalnego terminu
skoro sam zmniejszyl jego zasoby przed zakonczeniem pracy.


> Gdybym miała wybierać, to funkcję kierowniczą odrzuciłabym bez najmniejszego
> wahania. Może brzmi to niewiarygodnie, ale wszystkie moje stresy zawodowe,
> zmęczenie, zniechęcenie i wszelkie inne negatywne emocje, jakie wiażę z
pracą,
> sa jej pochodną. Przy projektowaniu i programowaniu relaksuję się.

Brzmi to calkiem wiarygodnie.
Preferencje techniczne albo kierownicze to sprawa osobowosci.
W naszej firmie nie sklania sie najlepszych ekspertow zeby zostali kierownikami.
Jesli chca, lubia i potrafia - to oczywiscie moga - porzucajac funkcje
techniczne, ale jesli nie chca, to nic nie traca finansowo.
Mamy dwie rownolegle siatki plac dla stanowisk kierowniczych i dla wyzszych
stanowisk technicznych. Najwyzszego stopnia architekci oprogramowania sa w tej
samej kategorii co wiceprezesi firmy.


> > Ale jesli techniczna to.. "5 minut kodowania - telefon..."
> > Jaki telefon? Zewnetrzny?!
>
> Zewnętrzny. Bezpośrednio obsługuję klienta. Począwszy od supportu i
> konsultacjach, kończąc na rozmowach z działem finansowym i udział w
> negocjowaniu umów. Wiem, że to chore. Telefonu tez nie mogę do nikogo
> przekierować, bo większość rozmów, to rozmowy merytoryczne lub na tematy
> finansowe i nie ma za bardzo takiej osoby, która mogłaby je odbierać.

Na razie nic nie bede probowala radzic bo widze ze ryzykuje wymadrzanie si bez
znajomosci realiow z bliska :)
Pewnie podstawowy problem lezy we wzglenie malych rozmiarach firmy.


> > Ja gdy akurat cos wiekszego robie to nawet firmowego e-majla nie mam stal
> e
> > wlaczonego.
>
> Na niewiele by sie to zdało, bo mamy open space :-)

Czy tak ktos zarzadzil pomimo tego ze mozna bylo zorganizowac biuro inaczej?
Czy tez taka jest koniecznosc - bo na przyklad firma wynajmuje kilka duzych sal?

Czy macie mozliwosc zdalnego wejscia do sieci firmy z zewnatrz (z domu) przez
VPN?


> > Od switu do poludnia kierownik a od poludnia do polnocy technik :)
>
> Mniej więcej coś takiego robię. Jak biuro pustoszeje i telefon milknie,
> zamieniam się w technika :-)

Chyba widze.
Po czasie - w ktorym piszesz swoje posty :)

testowanie

[dritte_dame]

Gość portalu: margonik napisał(a):

> Wysyłając wersję wysyłasz prawdziwy "black box"!

Jesli klienci zgadzaja sie u Was pracowac jako testerzy za ujemne wynagrodzenie
(bo jeszcze Wam placa) to taki uklad moze dzialac :))


> > > Testerzy ... czasami pracują w środowisku debugera
> > A po co im to?
> > Testerzy powinni sie koncetrowac wylacznie na "black box" testing.
>
> Nie ma daily building, więc tak jest czasami łatwiej - nie trzeba na bieżąco
> robić wersji. A przy okazji w środowisku są lepsze info o błędach, na bieżąco
> mozna zaraz podglądnąć zmienne itd. No i programista zamiast zrzutu
> ekranu "Runtime error", dostaje czasami namiar od razu na konkretny błąd.

To czemu "tester" od razu kodu nie poprawi podajac proponowana zmiene w kodzie
do zweryfikowania autorowi modulu?

Czy robicie "code review" zmian?
Wszystkich zmian, czy tylko niektorych?
W jaki sposob?

Jakiego rodzaju SCCS uzywacie?
(u nas obecnie - Perforce)


U nas istnieje specjalna baza danych z incydentami bledow.
Tester, jesli uwaza ze znalazl blad to tworzy w tej bazie nowy zapis i
umieszcza w nim wszystkie dane potrzebne programiscie do odtworzenia bledu:
Slowny opis interakcji z systemem prowadzacej do awarii, w jakim produkcie i w
jakiej jego wersji wada wystepuje, na jakim OS, wszystkie binarne i inne dane
wejsciowe, wadliwe dane wyjsciowe (jesli sa) i opis na czym funkcjonalnie
polega blad.

Biarac taki zapis - kierownicy decyduja o stopniu krytycznosci bledu, szereguja
wedlug pilnosci naprawy i planuja kto i kiedy ma sie zajac naprawieniem czego.

Nastepnie biora sie za to programisci.
Kazdy, kto pracuje nad konkretnym incydentem pozostawia po sobie w bazie
komentarze co stwierdzil, co zrobil i z jakim skutkiem.

W rezultacie, incydent moze zostac zamkniety na kilka roznych sposobow:
- Jako rzeczywisty problem, odtworzony i nastepnie naprawiony przez konkretna
zmiane kodowa.
- Jako rzeczywisty problem, ale nieodtwarzalny w nowszej wersji daily build.
Wowczas zamyka sie go jako "fixed during ongoing development"
- Odrzucony jako nie-problem - dziala tak jak powinien a tester po prostu nie
wiedzial ze tak powinien bo specyfikacja funkcjonalna byla niedosc detaliczna
(ze wzgledow praktycznych - nigdy nie jest).

Gdy programista zmieni status incydentu w bazie na "naprawiony" - tester
ponownie powtarza oryginalny test i jesli jest OK i na jego systemie to zmienia
staus na "naprawiony i sprawdzony".

Systemy testerow nigdy nie maja zadnych narzedzi developerskich (kompilatorow,
debuggerow itp.) zeby wykluczyc mozliwy wplyw obecnosci takich narzedzi (DLL-s,
konfiguracje, itp.) na srodowisko systemu i dzialanie programu.
(Klienci przeciez takze narzedzi developerskich nie maja.)


> > [testerzy] Sami projektuja i pisza automatyczne testy
>
> Są programistami, czy używacie jakichś kreatorów do unit testów?

Niezbyt rozumiem.
Czy stwierdzasz, ze nasi testerzy sa programistami?
Czy o to pytasz?

"Kreatorow", czyli - narzedzi?
Nie. (przynajmniej w moim zespole).

Testerzy ani nie projektuja ani nie pisza ani nie wykonuja unit testow.
To robia tylko programisci.
Testerzy robia tylko te trzy rodzaje testow: smoke, acceptance, regression.

[Gość: margonik]

> Jesli klienci zgadzaja sie u Was pracowac jako testerzy za ujemne
> wynagrodzenie (bo jeszcze Wam placa) to taki uklad moze dzialac :))

Nie wiem, jakim cudem, ale akurat mój system sie nieźle trzyma i zgłoszeń
błędów jest stosunkowo mało. Na szczęście! Przed wysłaniem wersji przeglądam
czasami kod, co do którego wiem, że był zmieniany w innych projektach, a więc
nie testowany w moim. Ale zdarzają sie wpadki.

> To czemu "tester" od razu kodu nie poprawi podajac proponowana zmiene w
> kodzie do zweryfikowania autorowi modulu?

Bo nie ma kwalifikacji, jako programista. Już wolę, żeby nie poprawiał :-)

> Czy robicie "code review" zmian?
> Wszystkich zmian, czy tylko niektorych?
> W jaki sposob?

Przeglądam zmiany w SourceSafe - te, których sie nie spodziewałam.
Dokładniejszy code review robię, gdy dostaję nowego człowieka i nie wiem, czego
się moge po nim spodziewać lub, gdy jakaś funkcja jest kluczowa. Ale z reguły
po prostu nie ma czasu.

Bazę z błędami tez mamy. Ale nie wszystko jest w niej zapisywane i nie ma
takiego formalnego przebiegu. Może też nie ma potrzeby, bo kontakty między nami
są bardzo ścisłe (open space).

> Systemy testerow nigdy nie maja zadnych narzedzi developerskich
(kompilatorow, debuggerow itp.) zeby wykluczyc mozliwy wplyw obecnosci takich
narzedzi (DLL-s,...

Takich testerów też mamy.

> Czy stwierdzasz, ze nasi testerzy sa programistami?

Zapytałam, bo myślalam, że masz na myśli to, że testerzy przygotowują unit
testy i się zdziwiłam :-) Nasi niektórzy akurat sa programistami- takimi trochę
gorszymi, którzy się nie bardzo odnaleźli w tym zawodzie. Zresztą jedna
testerka faktycznie nawet koduje drobnostki. Akurat niektórych testerów mamy
naprawdę fajnych.

code reviews

[dritte_dame]

Gość portalu: margonik napisał(a):

> > Czy robicie "code review" zmian?
> > Wszystkich zmian, czy tylko niektorych?
> > W jaki sposob?

> Przeglądam zmiany w SourceSafe - te, których sie nie spodziewałam.
> Dokładniejszy code review robię, gdy dostaję nowego człowieka i nie wiem,
czego
> się moge po nim spodziewać lub, gdy jakaś funkcja jest kluczowa. Ale z reguły
> po prostu nie ma czasu.


Inspekcja to tez rodzaj testu, i to dosc skutecznego, zwlaszcza w sytuacji gdy
z poczatku nie mozna stosowac szerzej unit testow z prostego braku takowych.
Szczegolnie korzystna moze byc dla malego zespolu i wymaga stosunkowo najmniej
organizacyjnego narzutu.

My to praktykowalismy od wielu lat sporadycznie ale dopiero od jakichs trzech
lat mamy naprawde dobrze zorganizowane - poprzez specjalne, automatycznie
generowane e-maile z SCCS.
Bardzo pomoglo w tym przejscie z VSS na Perforce.
Moge podac wiecej szczegolow nastepnym razem, jesli Cie intersuja - dzis juz
dosc pozno.


Domyslam sie ze pracujecie w .NET, C#, C++, Java, Windows-only, czy tak?

Nasze projekty - zwlaszcza nowsze - z reguly sa bardzo zroznicowane narzedziowo
i srodowiskowo. Moj obecny projekt jest w XSLT, Pythonie, Javie, C++, na
Windows i Unixy. Dlatego VSS nie wchodzi w gre i od paru lat uzywany Perforce.

[dritte_dame]

margonik napisała:

> U mnie nie stosuje się unit testów, ani daily building

Taki stan rzeczy moze wlasnie byc w znacznym stopniu przyczyna tego:

> w codziennym pośpiechu