wtorek, 19 grudnia 2006

Testowanie jako oddzielna dyscyplina

Wygląda na to, że w aspekcie szkoleń, testowanie oprogramowania nie jest samodzielną dziedziną ale raczej "przyczepką" do procesu wytwarzania oprogramowania. Nie spotkałem jeszcze szkolenia (może oprócz programu ISTQB a i to przy dużym nakładzie dobrej woli) , które mówiłoby tylko o testowaniu w kontekście testowania. Przeważnie są to szkolenia w dużej mierze o cyklu wytwarzania oprogramowania. Dużo mówi się o technikach kodowania i jako dodatek do tego naświetla się testowanie.

Z jednej strony jest to usprawiedliwione gdyż testowanie oprogramowania nie istnieje w oderwaniu od cyklu wytwarzania oprogramowania. Testowanie zajmuje się produktem programistów. Ale to jest chyba jedyny związek, który według mnie wcale nie usprawiedliwia takiego macoszego traktowania.

Powstaje coraz więcej firm, zajmujących się testowaniem oprogramowania na zasadzie outsourceingu. Nawet sami guru testów tacy jak Rex Black twierdzą, że outsourceowanie jest przyszłością testów. Ergo, wydaje się logiczną konsekwencją, że testowanie będzie musiało stać się bardziej niezależną dziedziną... niezależną od procesu rozwoju oprogramowania.

Ja jestem przekonany, że już się tak jest! Nawet w dużych korporacjach jest możliwe wydzielenie niezależnego działu posiadającego własną metodologię, własne procesy i własny harmonogram realizującego zadania testowe w sposób bardzo efektywny. Paradoksalnie - w mojej opinii - powinno się to przyczynić do podniesienia jakości testów i jakości samego oprogramowania. Wyznaczając sobie samemu termin, dział testów nie będzie mógł tłumaczyć się, że czasu było za mało... ale to na inną dyskusję.

Wracając do głównego wątku..., firmy oferujące szkolenia z zakresu testowania oprogramowania czynią to nie zwracając uwagi na aspekt opisany powyżej, czego konsekwencją jest konsumowanie znakomitej części czasu na opisywanie procesów zarządzania zmianą, tworzenia wymagań, itp. zamiast opisywać meritum czyli na samych testach.

W związku z tym wydaje mi się, że o wiele bardziej wydajną metodą szkolenia własnych testerów jest wdrożenie własnego programu szkoleń opracowanych na podstawie doświadczeń konkretnego zespołu, kompetencji w zespole. Jednak do tego celu niezbędna jest inwestycja w samodzielne poszukiwanie informacji (książki, internet, konferencje, itp.) W takim przypadku uzyskuje się podwójny efekt: poszerzanie kompetencji oraz analizę własnych braków kompetencyjnych w zespole.

Każdy, nawet najbardziej niedoświadczony zespół testerski posiada wyobrażenia związane z kształtem swoich zadań. Dodatkowo każdy inżynier poszukuje sposobów sposobów na rozwijanie własnej wiedzy i własnego warsztatu. Należy wykorzystać te dwa prądy w celu realizacji takiego przedsięwzięcia.

wtorek, 12 grudnia 2006

Testy eksploracyjne - dokumentacja

Istnieje na rynku wiele narzędzi pozwalających dokumentować - w jakikolwiek sposób - testy eksploracyjne. Mają one jednak zasadniczą wadę... generalnie dotyczą tylko wybranego lub kilku wybranych systemów operacyjnych a przecież testy robi się na różnych systemach, różnych urządzeniach (np. tzw. systemy osadzone), w różnych warunkach. Czy istnieje możliwość udokumentowania testów eksploracyjnych w oderwaniu od systemu operacyjnego?

Pierwsze co mi przychodzi do głowy to zwykły magnetofon... ale z drugiej strony nie wyobrażam sobie takiego miejsca pracy gdzie wszyscy siedzą i nagrywają "a teraz klikam guzik "x" na oknie "y"". Poza tym nie wielki byłby zysk z tego bo nie znany byłby ogólny stan testowanego systemu. Powstanie takiego narzędzia to byłoby by wyzwanie...

poniedziałek, 4 grudnia 2006

QA czy QC

Problem, z którym borykam się praktycznie od początku swojego życia zawodowego jest nazewnictwo. Czy „testowanie oprogramowania” to jest Quality Assurance czy Quality Control.

Chciałbym z góry zaznaczyć, że jeśli mówimy tylko o testach oprogramowania (bez znaczenia czy mówimy o białej czy o czarnej skrzynce, czy też o krzyżówce tych dwóch) to jestem zwolennikiem Quality Control.

Quality Control czyli po polsku „kontrola jakości” jest procesem kontrolowania jakości oprogramowania (bo o takim kontekście mówimy). W żaden sposób nie wpływa ten proces nie wpływa na jakość a jedynie kontroluje ją, w znaczeniu mierzy poprzez wykonywanie procedur testowych na danym oprogramowaniu.

Quality Assurance czyli po polsku “zapewnienie jakości”, zapewnia tą jakość poprzez implementację rozmaitych rozwiązań, narzędzi czy procesów. QA ma o wiele większy wpływ na „zwiększanie” lub „zmniejszanie” jakości poprzez nakładanie miar, dokonywanie audytów. Czyli Zapewnianie jakości określa kontrolę jakości ale nie odwrotnie.

Szukając porównania do tych dwóch aktywności doszedłem do takiego wniosku:

Zapewnianie jakości ma się do kontroli jakości tak jak klimatyzacja do termometru. Termometrem możemy jedynie zmierzyć temperaturę powietrza natomiast na podstawie tego pomiaru klimatyzacja może podwyższyć lub obniżyć temperaturę powietrza.

Oczywiście nie wiem czy jest to do końca słuszne spostrzeżenie. Jakkolwiek istotne dla mnie jest aby kierownicy projektów zrozumieli, iż testy w żaden sposób nie „dodadzą” lub nie „dostarczą” jakości do testowanego oprogramowanie. Testy jedynie zmierzą tą jakość przy pomocy miar zdefiniowanych przez dział testów (w mojej opinii gorsze wyjście ale bardziej popularne) lub stworzonych w oparciu o firmowe kryteria i narzucone przez dział „Zapewniania jakości”.

Przy tworzeniu działów testów – co wydaje się pierwszym krokiem w kierunku jakości – w firmach, naturalnym wydaje się wybranie ścieżki „czarnej skrzynki”. Dzieje się tak z różnych względów, których nie będę tutaj omawiał. Ja uważam, ze o wiele elastyczniejszym rozwiązaniem byłoby wprowadzenie działu zapewniania jakości – nawet w postaci komórki jednoosobowej.

Odpowiedź na pytanie „dlaczego” jest bardzo prosta. Jeśli wyposażymy tą komórkę w odpowiednie upoważnienia na poziomie organizacji, będzie ona w stanie wykreować „zachowania testujące” nawet bez konkretnego działu testów.

Nazywanie działów testujących oprogramowanie jest niepoprawne – moim zdaniem – z wielu względów (wymienię tutaj tylko trzy):

  • zamazuje to rzeczywistą potrzebę stworzenia takiego działu w organizacji
  • powoduje, iż osoby wykonujące testy skupiają się na „mitologicznej jakość idealnej” gubiąc w swoich obowiązkach kontekst biznesowy
  • po pewnym czasie zgłaszają aspiracje do kompetencji do których tak naprawdę nie posiadają zdolności.

Niebezpieczeństwo zamazanie prawdziwej potrzeby takiego działu w organizacji objawia się z reguły zwiększonymi oczekiwaniami do działu testów względem „dodawania” jakości. Taki uproszczony schemat, że im więcej testów tym więcej jakości. Wydaje się przy tym pojawiać fenomen przypisywania działowi testów umiejętności, których on nie posiada (np. wpływanie na kształt developmentu, wpływanie na jakość produktów developmentu) co prowadzi o zaostrzania metryk przyjmowania oprogramowania do testów tworzonych przez samych testerów co finalnie spowalnia proces wytwarzania oprogramowania.

Niebezpieczeństwo mitologicznej jakości idealnej objawia się w tym, iż testerzy zaczynają fantazjować na temat cudownych procesów (których nota bene nigdy nie zbudują) zapewniających im komfort spędzania czasu przy projektowaniu bardzo wyrafinowanych i chytrych przypadków testowych, znajdujących głęboko ukryte i bardzo poważne defekty. Powoduje to, odwrócenie ich uwagi od rzeczywistych zadań związanych z projektowaniem i wykonywaniem przypadków testowych w pierwszym rzędzie sprawdzających czy system spełnia wymagania i w drugim rzędzie czy system spełnia normy.

Niebezpieczeństwo zgłaszania nieuprawnionych aspiracji do kompetencji objawia się zaostrzaniem oczekiwań co do jakości oprogramowania, próba kreowania sztucznych procesów w żaden sposób nie sprzęgniętych z logiką biznesową organizacji ani jej potrzebami. Skutkuje to „wyorbitowaniem” zespołu testów poza kontekst biznesowy.

niedziela, 3 grudnia 2006

Historia zmian

Ten wpis jest sztuczny i został utworzony 18 maja 2007 roku. Ma on służyć jedynie jako zapis zmian dokonywanych w tym blogu.

08 luty 2013
  • zmiana szablonu

22 października 2010
  • drobne zmiany związane z wyglądem

18 grudnia 2009
  • dodanie elementu umożliwiającego przeszukiwanie bloga

22 lutego 2008
  • dodanie elementu "Komentarze" pokazującego 5 ostatnio dodanych komentarzy
07 grudnia 2007
  • zmiana wersji z 0.6 na 1.0
  • usunięcie oznaczeń wersji beta
  • zmiana szablonu układu graficznego
  • zmiana celu bloga
  • zmiana nagłówka z "Polski blog o testowaniu oprogramowania" na "Blog o testowaniu oprogramowania"
  • generalnie zmiana charakteru na bardziej osobisty bo taki był w rzeczywistości
18 maja 2007
  • Dodanie Google "Custom Search Engine". Wyszukiwarka, przeszukująca strony poświęcone testowaniu napisane po angielsku.

sobota, 2 grudnia 2006