Kiedy incydent staje się defektem

Co robią testerzy? Każdy machinalnie odpowie, że zgłaszają defekty... ale czy to jest prawda?! A jeśli nie zgłaszają defektów...

Oczywiście wszystko zależy od definicji, których jest mnóstwo w literaturze i internecie. Ale tak czy siak każdy kto choć trochę testował jest w stanie defekt określić jako mniej więcej "podejrzane zachowanie systemu" (1). Problem zaczyna się kiedy zaczniemy wnikać w szczegóły - gdzie zwykle diabeł nocuje.

Mnie zawsze interesowało co oznacza "podejrzane". Na jakiej podstawie stwierdzamy, że to konkretne działanie jest podejrzane a inne nie... oczywiście, że dużo zależy od doświadczenia, wiedzy, rozumienia systemu i reguł biznesowych nim rządzących ale i tak w każdym porządnym systemie ewidencji defektów istnieje flaga "To nie defekt" ("Not a bug") albo "Działa OK" ("Work as designed") lub inne temu podobne.

Wskazuje to na fakt, iż w jakiejś mierze jest to zgadywanie poparte bardziej (większe prawdopodobieństwo) lub mniej (mniejsze prawdopodobieństwo), iż poprzez proces intelektualny opisane przez nas symptomy będą rzeczywiście wskazywać na defekt.

Oznacza to, iż nie można tak zwanych raportów z defektów pozostawić samych sobie czyli systemowi ewidencji i zaszytemu w nim procesowi przetwarzania cyklu życia defektu. Według mnie takie systemy - a zwłaszcza cykle - nie obejmują tylko defektu obejmują także incydent.

Incydent staje się defektem dopiero po potwierdzeniu (czy to przez architekta, szefa działu rozwoju oprogramowania, lub biura do spraw jakości lub kogokolwiek innego władnego w tym zakresie) staje się on defektem. W ten sposób można oszczędzić wiele pracy i czasu przy naprawianiu nieistniejących defektów (efekt "brzydkiego kaczątka") lub poprawianiu funkcjonalności, która działa zgodnie ze specyfikacją.

Niestety, większość firm, z którymi ja miałem doczynienia podchodzi do zarządzania incydentami dosyć spolegliwie. Jedynym wyjątkiem są sytuacje, w których odbiorca zastrzega sobie kontrolę nad procesem dostawy.

Nie będę tutaj przytaczał konkretnych przykładów jednak chciałbym wymienić kilka zagrożeń związanych z takim macoszym traktowaniem defektów:

1. Naprawa nieistniejących defektów
2. Poprawa funkcjonalności nie wymagających takowej poprawy
3. Strata czasu inżynierów rozwoju oprogramowania
4. Komplikowanie rozwiązań
5. Utrata świadomości lub raczej wyczucia systemu
6. Brak zrozumienia natury procesu rozwoju konkretnego produktu

AD #1
To chyba jest oczywiste więc nie będę się rozpisywał. Chodzi po prostu o naprawianie czegoś co nie wymaga naprawy, a co naprawione niepotrzebnie na 100% wygeneruje więcej błędów. Następnie w czasie pomiędzy naprawianiem tego czegoś a wycofaniem tej naprawy, te "wirtualne" defekty zostaną naprawione co w sytuacji wycofania zmiany pierwotnej wygeneruje kolejny poziom defektów... taka baba w babie... a ponieważ nie zawsze da się utrzymać ścisły związek pomiędzy defektami a zmianami w kodzie... to mamy gotowy duży problem.

AD #2
Sytuacja podobna do poprzedniej... choć chyba ma większy wpływ na systemy wbudowane niż serwerowe. Czasami wyżyłowanie jednego parametru może spowodować kolosalne szkody.

AD #3
To chyba też oczywistość... nie chodzi tylko o czas zużyty na naprawę ale potem czas zużyty na "odkręcanie" tego...

AD #4
Jeśli w porę nie zostanie określone czy dany incydent jest, czy nie jest defektem, bardzo często dokonuje się tak zwanej "aktualizacji dokumentacji" poprzez np. żądania zmian (change requests). Jeśli taka nielegalna zmiana zostanie uznana za oficjalną to może się okazać, że implementuje się funkcjonalność do której system nie jest w ogóle przeznaczony... a konsekwencją tego jest oczywiście lawina defektów...

AD #5
Tutaj mam na myśli raczej fakt, wiele zmian "ułatwia" zapomnienie o końcowym celu projektu i "szatkowania" go poprzez problemy bieżące. Choć może z drugiej strony może to pozwala zrozumieć lepiej naturę problemu!?

AD #6
Tutaj chcę podkreślić tezę, że "brak uczestnictwa kierownictwa projektu w takim wydarzeniu jak przegląd defektów pozbawia go wyczucia natury projektu", jego problemów, ograniczeń oraz możliwości rozwoju. Jest to po prostu spolegliwe pozbywanie się ogromnych zasobów wiedzy... wiedzy która nie wynika tylko z raportów o incydentach ale także z komentarzy różnych stron uczestniczących w projekcie. Dodatkowo pozwala w łatwy sposób dystrybuować specyficzną dla danej strony projektu (np. testerów) wiedzę na całą populację projektu co znakomicie ułatwia rozwijanie łańcuchów komunikacyjnych w obrębie projektu.

Reasumując, uważam że raporty zgłaszane przez testerów powinny być traktowane jako raporty z incydentów a dopiero po potwierdzeniu i weryfikacji u programistów, architektów lub innych kompetentnych osób powinien być akceptowany jako bug. Następnym natomiast krokiem powinno być zdecydowanie czy dany defekt naprawiać czy nie... ale to już inna historia.

Testy eksploracyjne wyjaśnione??

James Bach w swoim artykule "Exploratory testing explained" stara się wytłumaczyć czym dokładnie są testy eksploracyjne. I rzeczywiście o ile z punktu widzenia testera wydaje się to bardzo interesującą ideą o tyle z punktu praktycznego narodziło mi się kilka wątpliwości:

Pytanie #1

W opisie karty testów eksploracyjnych (ang. testing charter) Bach zakłada istnienie podręcznika użytkownika.

---

O ile spotykałem wiele projektów - o wiele więcej niż to zwykło się narzekać w literaturze - z całkiem przyzwoitą dokumentacją o tyle nie spotkałem jeszcze projektu, który wyprodukowałby podręcznik użytkownika przed wyprodukowaniem samego systemu. Powoływanie się na podręcznik użytkownika, w zbudza moją wielką wątpliwość. Ale to nawet nie jest istotne... tak czy siak ET potrzebuje jakiejkolwiek dokumentacji aby móc przygotować sobie tą kartę testów. Oczywiście w tej chwili można dyskutować na temat użyteczności takiej karty. Według mnie im skromniejsze rozmiary - w sensie merytorycznym - tym silniejsze będą następujące problemy:

1. trudności z zatrudnianiem studentów
2. trudności z zatrudnianiem zewnętrznych konsultantów
3. trudności z raportowaniem
4. brak wymienności wykonawców testów

AD1: W dużych firmach często stosuje się metodę zatrudniania studentów do prostych prac. Np. do wykonywania testów. Ta czynność przestaje być opłacalna gdyż przy pomocy karty testów, testy wykonać może tylko doświadczony tester znający zagadnienia z dziedziny testowania.
AD2: Ten problem nie jest znaczny - zakładając ze zatrudniamy profesjonalistów - ale zawsze należy doliczyć czas potrzebny na tzw. "rozruch" względem karty.
AD3: Bardzo często w dużych firmach wykonanie czegoś równa się dostarczenie raportu z wykonania tego czegoś. Tak samo jest z testami... bardzo często raport z testów stanowi integralną cześć dokumentacji projektowej przedstawianej kierownikowi projektu, zarządowi czy klientom. Bardzo często od tego dokumentu uzależnione są dalsze kroki w projekcie.
AD4: Ten punkt łączy się z pierwszym. W razie rotacji w zespole ucieka także cała wiedza i nic nie pozostaje na miejscu oprócz karty testów i raportów z defektów.

Pytanie #2

Wydaje się, że znaczna część karty testów może powstać na podstawie dokumentacji (nawet jeśli sama karta jest skromnych rozmiarów).

---

To jest coś co jest napisane między wierszami ale zdziwiło mnie powoływanie się na chociażby wyżej wymieniony podręcznik użytkownika.

Pytanie #3

Testowanie obsługi błędów - skąd wiadomo, kiedy i jakie te błędy mają się pojawić. Mocno związane z zagadnieniem weryfikowalności poprawności wyników.

---

Obiekcja, która rodzi się tutaj jest związana z weryfikowalnością wyników, np. skąd wiemy, że wygenerowaliśmy wszystkie scenariusze obsługi błedów? Dodatkowo skąd wiemy, że akurat ten a nie inny komunikat powinien się pojawić w danym miejscu?

Pytanie #4

"In freestyle exploratory testing, the only official result that comes from a session of ET is a set of bug reports."
Można to przetłumaczyć jako "W swobodnym stylu testów eksploracyjnych, jedynym oficjalnym rezultatem testów jest zbiór raportów defektów"

---

Idea całkiem słuszna. Jednak z praktycznego punktu widzenia mało realizowalna. W dużych firmach istnieje silny nacisk na udokumentowywanie i powtarzalność wykonywanych testów. Jest to pośrednio związane z rotacją kadry ale przede wszystkim z faktem, że firmy świadczą usługi na rzecz innych firm - swoich klientów. Bardzo często klienci zainteresowani są sposobem w jaki dana funkcjonalność zostąła przetestowana. Co więcej bardzo często procedura testów akceptacyjnych przygotowywana przez dostawcę jest częścią produktu przekazywanego klientowi i wchodząca w zakres testów akceptacyjnych wykonywanych przez klienta przy odbiorze produktu.
Tak więc w mojej opinii praktyczne zastosowanie tej zasady jest możliwe przy małych projektach lub przy projektach wewnętrznych gdzie odbiorcą jest rynek a firma jest pewna swoich procesów stymulowania jakości.

Pytanie #5

Tester uprawiający testy eksploracyjne jest zawsze i przede wszystkim projektantem testów. Kazdy może przypadkowo zaprojektować test, jednak profesjonalny tester eksploacyjny jest w stanie zmajstrować testy systematycznie eksplorujące produkt. Wymaga to takich umiejętności jak, zdolność analizowania produktu, szacowanie ryzyka, wykorzystanie narzędzi oraz przede wszystkim krytycznego myślenia"
[oryg.] "An exploratory tester is first and foremost a test designer. Anyone can design a test accidentally, the excellent exploratory tester is able to craft tests that systematically explore the product. That requires skills such as the ability to analyze a product, evaluate risk, use tools, and think critically, among others."

---

Nic dodać, nic ująć... w pełni zgadzam się z tym twierdzeniem! To czego nie rozumiem, to dlaczego jest ono adresowane tylko do testerów uprawiających testy eksploracyjne. Dokładnie takie same przymioty potrzebne są testerom uprawiającym inne metodyki. Zaprojektowanie przypadku testowego wymaga wiedzy o produkcie. Wymaga takrze umiejętności oszacowania w którym miejscu można znaleźć defekty szczególnie groźne dla produktu. Następnie trzeba posiadać wiedzę na temat narzędzi z jakich można skorzystać w trakcie projektowania i/lub wykonywania tego przypadku testowego. A to wszystko jest możliwe kiedy jesteśmy krytycznie nastawieni od testowanego systemu ale potrafimy odrzucić te sugestie krytycyzmu, które nie wnoszą do jakości produktu nieczego oprócz naszej satysfakcji ze znalezienia buga.
Formalne zapisanie przypadku testowego to tylko opcja. I dlatego nie zgodzę sie, że takie ujęcie dotyczy tylko testerów od ET.

Pytanie #6

W praktyce, konkretny tester jest często permanentnie przypisany od jednego zbioru komponentów, aby projekt korzystał z regularnej krzywej uczenia [oryg.] "In practice, a particular tester is often permanently assigned to one set of components, so that the project benefits from an uninterrupted learning curve"

---

Biorąc pod uwagę słowa "permanentnie" i "często" trudno się tutaj ustosunkować bardzo zasadniczo. Ale uważam, że niezbędne jest tutaj słowo komentarza. Po pierwsze chyba każdy - nawet nie bardzo doświadczony manager testów - zdaje sobie sprawę, że komponent testowany w kółko przez tą samą osobą jest narażony na mutację syndromu pestycydów. Wynika to ze zwykłego znudzenia. Jeśli nie bierze tego pod uwagę to ma problemy i to duże bo będzie to rzutowało na morale całego zespołu. Znudzenie bardzo szybo się rozprzestrzenia.
Drugim aspektem tego zagadnienia jest to, że tworzenie unikalnych specjalistów nie jest dobrym sposobem na budowanie zespołu. Wiedza w takim zespole przyrasta znacznie wolniej.

Pytanie #7

[...] regularne spotkania z testerami w celu omówienia postępów, przynajmniej raz w tygodniu [oryg/] "regular meetings with testers to discuss test progress, at least once per week."

---

Bardzo szlachetna idea i na pewno daje doskonałe wyniki w środowisku jednego dużego projektu. Natomiast jest to kompletna klapa w środowisku wieloprojektowym gdzie kierownik projektu prowadzi na raz kilka projektów, a w strukturze projektu istnieje kilka grup (np. integracja, migracja, testy, logika biznesowa, GUI, itp). W takim przypadku nie jest to możliwe. Natomiast tutaj doskonale sprawdzają się raporty omawiające status, wcześniej uzgodnione z kierownikiem projektu.

Pytanie #8

Tester jako samotny lider

---

Nie wiem skąd to się wzięło ale jest to pomyłka i to straszna. Każdy tester działa w środowisku biznesowym i jego "meta-kontekstem" to właśnie środowisko. Ale jednocześnie, aby móc wykonywać swoje zadania sumiennie, nie bada pulsu tego środowiska. Robi to za niego jego kierownik, kierownik projektu, itd. A więc w sytuacji, w której środowisko biznesowe ulegnie zmianie, należy natychmiast zmienić kierunek testowania bez względu na to jak słuszna jest idea testów prowadzonych w chwili obecnej.

Przewodnik dla praktyków

W 2003 roku, po raz pierwszy ukazała się drukiem książka Lee Copelanda, "A Practitioner's Guide to Software Test Design" nakładem wydawnictwa Artech House Publishing. Niestety książka wydana jest w języku angielskim co stanowi duże ograniczenie dla polskiego odbiorcy... ale mam nadzieję nie jest to ograniczenie niedopokonania (w chwili obecnej pracuję nad tłumaczeniem tej książki).

Wydanie

Książka wydana została w twardej oprawie, z foliowaną okładką. Układ druku jest przejrzysty i dosyć duży co na pewno ułatwia czytanie i korzystanie z niej. Każdy rozdział stosuje tą samą strukturę: wstęp, opis techniki, przykłady, opis zastosowania i ograniczeń, podsumowanie, ćwiczenia oraz literaturę referencyjną.

Dodatkowo, najważniejsze treści umieszczone zostały na zewnętrznych marginesach jako punkty kluczowe pozwalające w łatwy sposób znaleźć interesującą czytelnika treść. Ilustracje niestety są czarno-białe i dość kiepskiej jakości ale nie przeszkadza to w ogólnym odbiorze.

Wydawca wyposażył książkę w indeks a autor jako dodatek przygotował spis literatury pomocnej w dalszym zgłębianiu opisywanych zagadnień. Dodatkowo, umieszczono dwa załączniki zawierające studium przypadku: jeden to firma brokerska a druki to internetowy system rejestracji. Większość ćwiczeń zaproponowanych w tej książce odnosi się do tych studiów co w miarę łatwy sposób pozwala na ich wykonanie.

Książka prezentuje 7 technik testowania czarną skrzynką oraz dwie techniki testowania białą skrzynką.

Treść

Struktura książki nominalnie podzielona jest na 5 sekcji, jednak w rzeczywistości zawiera tych sekcji 6 plus dwa załączniki.

Sekcja pierwsza zawiera podziękowania autora dla osób, które przyczyniły się do powstania tej książki. Czytelnik znajdzie tutaj również rozdział poświęcony procesowi testowania wraz z próbą diagnozy współczesnych wyzwań w stosunku do testowania oprogramowania oraz opisem poziomów testowania zapożyczonym od Beizera.

Nominalna sekcja I skupia się na czarnoskrzynkowych technikach testowania i opisuje w kolejności:

• testowanie w oparciu o klasy równoważności
• testowanie wartości granicznych
• testowanie tabelami decyzyjnymi
• testowanie parami
• testowanie przejść stanów
• testowanie analizą dziedzin
• testowanie przypadków użycia

Każda z tych technik opatrzona jest komentarzem metodologicznym oraz rozważaniami związanymi z ich ograniczeniami i wykorzystaniem. W trakcie lektury czytelnik ma możliwość śledzenia całego procesu danego podejścia poprzez wplatanie wielu drobnych przykładów oraz objaśnień. Aczkolwiek, nie pozostawia to niedomówień, których jest mnóstwo ale z którym czytelnik będzie sobie musiał poradzić sam.

Nominalna sekcja II opisuje techniki testowania białą skrzynką. Autor tutaj wymienia tylko dwie:

• testowanie kontroli przepływu
• testowanie przepływu danych

Znakomitą część opisu tych technik stanowi synteza książek Myersa "Sztuka testowania oprogramowania" oraz Bindera "Testowanie systemów obiektowych".

Sekcja III zajmuje się opisem paradygmatów testowych. Tutaj najciekawszym fragmentem określiłbym rozdział 13 opisujący testy eksploracyjne porównując je do gry w 20 pytań (ciekawostkę na gruncie polskim można znaleźć tutaj). Znalazło się tutaj także miejsce aby naświetlić problem planowania testów.

Sekcja IV zajmująca się technologiami wspomagającymi, w rzeczywistości skupia się na taksonomiach defektów oraz kryteriach zakończenia całego procesu testowania.

Uwagi końcowe

Całość napisana jest w stylu, który określiłbym jako "synkretyczny"... w tym znaczeniu, że autor nie potrafi się zdecydować czy adresuje wypowiedź do jednej osoby, liczniejszej publiczności czy też bez osobowo.

W kilku miejscach miałem wrażenie, że autor przedobrzył z upraszczaniem zagadnienia wprowadzając niedomówienia ale z całą pewnością nie jest to błąd poważny. Jednym słowem uważam, że jest to bardzo interesująca pozycja z punktu widzenia czytelnika zajmującego się kontrolą jakości oprogramowania. Pozwala ona zweryfikować dotychczas posiadaną wiedzę oraz poszerzyć ją tam gdzie tego wymaga.

Dodatkowo, książka zawiera wiele odnośników do narzędzi lub stron internetowych wyjaśniających dogłębniej niektóre, bardziej skomplikowane kwestii.

Z pewnością zaliczyłbym tą pozycję do lektur obowiązkowych dla każdego, kto uważa się za profesjonalnego testera.

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.

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...

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.

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.

Na początek

Na początek to nie mam za wiele do powiedzenia... generalnie to chciałem tylko zrobić pierwszy wpis.