Prostą i dużo wyjaśniającą prezentację nt. różnych "frameworków" do testów automatycznych można znaleźć w prezentacji http://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/ghanakotagayatri.pdf.
Opisuje ona zalety i wady "modular testing", "data driven testing", "keyword driven testing" oraz "hybrid framework testing".
Pokazywanie postów oznaczonych etykietą Testowanie (QC). Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą Testowanie (QC). Pokaż wszystkie posty
wtorek, 19 listopada 2013
środa, 16 maja 2007
Prywatne EuroSTAR :-)
Oprócz amerykańskich konferencji poświęconych jakości oprogramowania STAREAST i STARWEST funkcjonuje ich europejska wersja pod nazwą EuroSTAR. Najbliższa odbywa się pod hasłem "Defining the Profession". Organizatorzy uważają, że do rozwikłania zagadki tego hasła prowadzą odpowiedzi na poniższe pytania:
Mówi się, że dobry tester jest w stanie przetestować wszystko... i rzeczywiście kilka lat pracy w zawodzie formułuje specyficzne podejście charakteryzujące się "testowaniem" otoczenia. Jak słusznie zauważył James Bach, istotne jest umiejętne posługiwanie się sceptycyzmem i krytycyzmem co w mojej ocenie jest wyższym stopniem wtajemniczenia w ten zawód. Łatwo jest bowiem popaść w bezproduktywne narzekanie, że system nie jest doskonałej jakości a bardzo trudno jest ustrzec się przed domniemaniem pewnych oczywistości. I tak np. łatwo jest powiedzieć, że dany obszar funkcjonalny jest źle napisany bo zostało do niego zaraportowanych dużo defektów ale dużo trudniej jest tak skonstruować testy aby przy minimalnym, potrzebnym nakładzie pracy (w sensie czasu i zasobów) przetestować dokładnie ten obszar a następnie efektywnie zweryfikować efekt prac naprawczych.
Jak można zdefiniować profesjonalistę...? Uważam, że profesjonalista to człowiek skupiony na celach, potrafiący je osiągać korzystając z dostępnych środków oraz dobierać nowe środki w sposób optymalny. Ale jednocześnie profesjonalista to taki ktoś, kto dążąc do realizacji tych celów, potrafi dać swój wkład w środowisko pracy... to np. taka osoba, która widzi szerszy kontekst swojej działalności. Osoba, która biorąc cokolwiek od innej osoby (wiedzę, informację, zasoby, czas, itp) potrafi uczynić to we właściwy sposób i jednocześnie dać coś w zamian. To ktoś w towarzystwie kogo przebywając jednocześnie uczymy się, ktoś do kogo ma się zaufanie. To ktoś kto ma misję!
Dla mnie taką misją jest "minimalizowanie ryzyka związanego z realizowanym produktem/projektem". To minimalizowanie realizuję poprzez dostarczanie innym uczestnikom procesu, z jednej strony informacji na temat jak można przy zastanych zasobach i historii projektu zrealizować efektywnie testy a z drugiej strony wiarygodną informację na temat poziomu jakości tego produktu w odniesieniu do czynników zewnętrznych takich jak jakościowe oczekiwania klienta, otoczenie biznesowe, przeznaczenie systemu, itp. W ten sposób chronię zarówno swojego pracodawcę przed utratą renomy a z drugiej strony chronię odbiorcę przed stratami spowodowanymi wadliwym działaniem systemu.
Często spotykam się z mniej lub bardziej jawny antagonizowaniem testera i programisty. Dla mnie takie ujęcie jest zupełnie bezprzedmiotowe. Nie ma znaczenia tak naprawdę kto "bardziej zbawia świat". Znaczenie ma jaki się ma stosunek do wykonywanego zawodu. Testowanie dla osoby zainteresowanej tym zawodem i świadomej możliwości jest takim samym wyzwaniem jak zaprogramowanie testowanego systemu. Co więcej, antagonizowanie działu testów z działem rozwoju w poważny sposób zakłóca komunikację między tymi dwoma działami co w konsekwencji najczęściej powoduje z jednej strony reglamentację wiedzy na temat stosowanych rozwiązań a z drugiej strony nadmierny nakład pracy związanej z testami oraz zbyt detaliczne raportowanie defektów.
Testowanie jako odrębna dziedzina daje duże możliwości wielokierunkowego rozwoju i zdobywania wiedzy weźmy choćby pod uwagę automatyzację testów, projektowanie testów, standaryzację testów, itp.
Do znajdowania, opisywania i klasyfikowania defektów, dysponuje jednocześnie całym wachlarzem narzędzi takich jak techniki testowania, znajomość kontekstu biznesowego, historii system oraz samego systemu.
Nie chcę przez to powiedzieć, że tester jest odpowiedzialny za całość przedsięwzięcia a jedynie chcę podkreślić fakt, iż do obowiązków testera nie należy tylko samo testowanie ale także osadzanie wiedzy o testowanym systemie w jego kontekście w takim zakresie w jakim jest to dla niego osiągalne w zależności od jakości komunikacji w projekcie, zakresu odpowiedzialności (analityk testów, wykonawca testów, lider/manager testów, lider/manager do spraw jakości procesów).
Same umiejętności podzieliłbym na kilka poziomów: warsztatowe, produktowe techniczne, produktowe nietechniczne oraz społeczne.
Umiejętności warsztatowe to przede wszystkim biegła znajomość technik projektowania przypadków testowych. To jest warunek sine qua non bycia testerem. To właśnie od tego zależy to czy wykonujemy testy w sposób kontrolowalny, wiarygodny, weryfikowalny i jednoznaczny. Skonstruowanie i uruchomienie przypadku testowego bez jednej z tych cech często okazuje się pracą bezcelową, nie przynoszącą odpowiedzi na podstawowe pytanie.
Umiejętności produktowe techniczne to wszystkie te informacje, które są związane ze sposobem w jaki dany produkt powstaje. Mam na myśli tutaj technologię, sposób implementacji danych funkcjonalności, znajomość ograniczeń technicznych systemu, itp.
Umiejętności produktowe nietechniczne to generalnie znajomość i zrozumienie celu, dla którego powstaje produkt. Innych funkcji oczekujemy przecież od sytemu księgowego a innych od systemu przetwarzania sygnału telewizji cyfrowej, inaczej będzie działał wygaszacz ekranu na komputerze a zupełnie inaczej na dekoderze telewizji cyfrowej. Bez znajomości kontekstu w jakim osadzony jest produkt trudno jest mówić o "dobrym testowaniu".
Umiejętności społeczne to przede wszystkim umiejętności komunikacji i współpracy. Bardzo istotne jest z punktu widzenia testera zrozumienie chociażby tak prostego faktu, że defekty w oprogramowaniu nie wynikają ze złej woli programisty lub uporu architekta ale z faktu, że każdy z nas jest człowiekiem i popełnia błędy. I oczywiście odwrotnie, ważne jest aby osoba odpowiedzialna za całość przedsięwzięcia była świadoma, że testowanie jest sztuką szacowania opartym na krytycznym podejściu do oprogramowania dostarczonego do testów oraz na sceptycznym podejściu do deklarowanej jakości tego systemu, zakresu zmian, możliwych efektów pobocznych, itp.. (Nad wyraz często spotykam się z sytuacją, w której raporty defektów są po prostu ignorowane lub przetwarzane wsadowo co tak naprawdę przynosi gorszy efekt niż po prostu pozostały by one w statusie początkowym).
Te cztery warstwy "zanurzone" są w czymś co nazwałbym "intuicją testera". Rodzi się ona i rozwija się z czasem i doświadczeniem (udziałem w różnych projektach, w różnych organizacjach, w różnych kontekstach biznesowych itp.). Pozwala ona testerowi na wydajne czerpanie z wszystkich czterech warstw w zależności od etapu procesu testowego (analizy wymagań, projektowania przypadków testowych, wykonywania testów lub raportowania defektów, oraz od etapu produkcji oprogramowania.
Jest ona również bardzo istotna w procesie wyjaśniania wszelkich niejasności jakie powstają w trakcie czytania dokumentacji. Warto tutaj dodać, iż w sytuacji kiedy reputacja testerów jest umniejszana jako "tych co nie programują" to wtedy, bardzo skuteczną bronią jest stawianie odpowiednich pytań przez testerów. Jeśli charakter zadawanych pytań będzie zdradzał ignorancję testera lub niezrozumienie działania i celu systemu, negatywna postawa programisty utrwali się. Jeśli natomiast pytania testera przyniosą tę korzyść programiście, że zwrócą mu lub jej uwagę na szczegóły, które są istotne a nie zostały uwzględnione w analizie, bardzo szybko testerzy staną się ośrodkiem wiedzy na temat całościowego działa testowanego systemu. Testerzy - w naturalny niejako sposób - stają się jedynym ośrodkiem w procesie wytwarzania oprogramowania, który posiada w miarę całościową wiedzę na temat rzeczywistego działania produktu. Wynika to właśnie z faktu konieczności zrozumienia zasady działa i celowości całego systemu a nie tylko jej fragmentu. Konieczność ta, z kolei jest warunkiem istotnym do prawidłowego przetestowania systemu.
Na tej podstawie, jako swoją najbardziej cenną umiejętność w tym zawodzie określiłbym otwartość. Otwartość rozumianą jako rozumienie zarówno potrzeb projektu jak i klienta oraz znajdowanie kompromisu pomiędzy tymi dwoma żywiołami.
Na pewno doświadczenie jest tym co bardzo pomaga w realizacji zadań testowych. Ale to nie jest, żadna myśl odkrywcza gdyż doświadczenie jest wszędzie przydatne. Jeśli natomiast jest to pytanie o profil wykształcenia oraz wynikającego w konsekwencji doświadczenia zawodowego to nie potrafię na to odpowiedzieć. Spotykałem wielu testerów. Byli wśród nich i absolwenci filozofii jak i absolwenci fizyki czy informatyki. Ale nie umiem powiedzieć czy wykształcenie ma jakikolwiek wpływ na to czy jest się dobrym lub złym testerem. Z całą pewnością znajomość i wiedza z zakresu inżynierii oprogramowania, programowania, czy generalnie informatyki jest czymś niezbędnym. Z moich obserwacji wynika, że testerzy o informatycznym profilu wykształcenia doskonale sobie radzą z problemami czysto technicznymi takimi jak zrozumienie działania skomplikowanej funkcjonalności ale z drugiej strony często spotykałem tutaj tendencje do poprawiania a nie testowania tej funkcjonalności co zżerało czas i zasoby. I nie chodzi mi tutaj o to, że doszukiwali się źródeł problemu ale o to, że często zamiast poświęcać czas na identyfikację defektów poświęcali czasz na poszukiwanie odpowiedzi na pytanie "jak to naprawić" co jest powinnością programisty.
Ludzie o wykształceniu nie technicznym są znacznie bardziej wyczuleni na defekty. Powoduje to, że czasami przesadzają z oceną wagi defektu oraz zajmują sztywniejsze stanowisko w procesie weryfikacji naprawionych defektów. Często także - powodowani swoją niepewnością wynikającą ze świadomości braku wykształcenia informatycznego - komplikują zagadnienia w fazie analizy co utrudnia im znacznie zrozumienie podstawowych kwestii.
Nie wiem, która opcja jest lepsza... Ale wiem, że za każdym razem kiedy pracowałem w zespole testerów, to tworzył się inny niż u programistów świat... świat, w którym ludzie otwarci są na wiedzę i dzielenie się nią, w którym czują się spojeni misją, którą mam nadzieję każdy z nich potrafi sobie zdefiniować. Świat który jest jednak mocno sceptyczny. Z drugiej jednak strony powstaje wiele patologii takich jak tworzenie "mitycznej jakości" lub zbyt szczegółowe podejście do zagadnień testowych co powoduje niepotrzebne wydłużenie cyklu testowego.
Reasumując, definiowanie profesji testera z całą pewności jest pożądane. Dobrze, że powstają firmy certyfikujące i standaryzujące. Dobrze, że jest mnóstwo wolnych strzelców i ludzi pracujących na własnymi metodykami. Taka dychotomia jest symptomem tego, że jest to jeszcze bardzo młoda dziedzina. Ale bez względu na to czy pracujemy w środowisku extreme, agaile, V, W, iteracyjnym czy w modelu kaskadowym, z całą pewnością powinniśmy w naszych codziennych obowiązkach testera zapewniać spełnienie podstawowych warunków takich jak kontrolowalność, wiarygodność, weryfikowalność i jednoznaczność przy optymalnym stosowaniu technik testowych.
Ponieważ próba odpowiedzi na te pytania wydała mi się wyzwaniem, postanowiłem zmierzyć się z nim. Ale postanowiłem to zrobić na ogólnym poziomie nie wchodząc w szczegóły, chyba że jest to uzasadnione.
- Czy uważasz siebie za testera i profesjonalistę? Czy inni uważają Cię za takiego?
- Co pozwala Ci na takie stwierdzenie?
- Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?
- Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?
- Czy kwalifikacje mogą określać profesjonalnego testera?
- Czy Twoja organizacja wnosi dobre praktyki do profesji?
Czy uważasz siebie za testera i profesjonalistę?Kto może nazwać siebie testerem...? Czasami jako testera określa się osobę zawodowo zajmującą się weryfikowaniem czy to co miało być zrobione zostało rzeczywiście zrobione! Jednak w mojej opinii nie jest to definicja kompletna. Tester bowiem, to osoba, która nie tyle zajmuje się weryfikowaniem czy to co zaplanowane zostało zaimplementowane - jest to produkt bardzo ważny ale pośredni pracy testera. Tester to osoba, która z pełną świadomością przepuszcza oprogramowanie przez specjalnie w tym celu zaprojektowane procedury, których celem jest weryfikacja czy został osiągnięty określony i zdefiniowany poziom jakości i która to osoba do projektowania procedur testowych korzysta w wielu technik! Gdy poziom jakości nie jest określony i zdefiniowany formalnie to i tak bardzo pomocne jest nieformalne określenie tego parametru.
Mówi się, że dobry tester jest w stanie przetestować wszystko... i rzeczywiście kilka lat pracy w zawodzie formułuje specyficzne podejście charakteryzujące się "testowaniem" otoczenia. Jak słusznie zauważył James Bach, istotne jest umiejętne posługiwanie się sceptycyzmem i krytycyzmem co w mojej ocenie jest wyższym stopniem wtajemniczenia w ten zawód. Łatwo jest bowiem popaść w bezproduktywne narzekanie, że system nie jest doskonałej jakości a bardzo trudno jest ustrzec się przed domniemaniem pewnych oczywistości. I tak np. łatwo jest powiedzieć, że dany obszar funkcjonalny jest źle napisany bo zostało do niego zaraportowanych dużo defektów ale dużo trudniej jest tak skonstruować testy aby przy minimalnym, potrzebnym nakładzie pracy (w sensie czasu i zasobów) przetestować dokładnie ten obszar a następnie efektywnie zweryfikować efekt prac naprawczych.
Jak można zdefiniować profesjonalistę...? Uważam, że profesjonalista to człowiek skupiony na celach, potrafiący je osiągać korzystając z dostępnych środków oraz dobierać nowe środki w sposób optymalny. Ale jednocześnie profesjonalista to taki ktoś, kto dążąc do realizacji tych celów, potrafi dać swój wkład w środowisko pracy... to np. taka osoba, która widzi szerszy kontekst swojej działalności. Osoba, która biorąc cokolwiek od innej osoby (wiedzę, informację, zasoby, czas, itp) potrafi uczynić to we właściwy sposób i jednocześnie dać coś w zamian. To ktoś w towarzystwie kogo przebywając jednocześnie uczymy się, ktoś do kogo ma się zaufanie. To ktoś kto ma misję!
Dla mnie taką misją jest "minimalizowanie ryzyka związanego z realizowanym produktem/projektem". To minimalizowanie realizuję poprzez dostarczanie innym uczestnikom procesu, z jednej strony informacji na temat jak można przy zastanych zasobach i historii projektu zrealizować efektywnie testy a z drugiej strony wiarygodną informację na temat poziomu jakości tego produktu w odniesieniu do czynników zewnętrznych takich jak jakościowe oczekiwania klienta, otoczenie biznesowe, przeznaczenie systemu, itp. W ten sposób chronię zarówno swojego pracodawcę przed utratą renomy a z drugiej strony chronię odbiorcę przed stratami spowodowanymi wadliwym działaniem systemu.
Często spotykam się z mniej lub bardziej jawny antagonizowaniem testera i programisty. Dla mnie takie ujęcie jest zupełnie bezprzedmiotowe. Nie ma znaczenia tak naprawdę kto "bardziej zbawia świat". Znaczenie ma jaki się ma stosunek do wykonywanego zawodu. Testowanie dla osoby zainteresowanej tym zawodem i świadomej możliwości jest takim samym wyzwaniem jak zaprogramowanie testowanego systemu. Co więcej, antagonizowanie działu testów z działem rozwoju w poważny sposób zakłóca komunikację między tymi dwoma działami co w konsekwencji najczęściej powoduje z jednej strony reglamentację wiedzy na temat stosowanych rozwiązań a z drugiej strony nadmierny nakład pracy związanej z testami oraz zbyt detaliczne raportowanie defektów.
Testowanie jako odrębna dziedzina daje duże możliwości wielokierunkowego rozwoju i zdobywania wiedzy weźmy choćby pod uwagę automatyzację testów, projektowanie testów, standaryzację testów, itp.
Czy inni uważają Cię za takiego?Nie jestem w stanie odpowiedzieć na to pytanie! Nie znam myśli innych ludzi. Ale mogę odwrócić to pytanie i sformułować je tak "co powoduje, że myślisz o innych jak o profesjonalnych testerach?" Jako profesjonalnego testera określam taką osobę, która potrafi pomóc kierownikowi projektu lub innej osobie odpowiedzialnej za realizację przedsięwzięcia określając, jak i które obszary powinny być testowane w zależności od takich czynników jak czas, historia produktu/projektu oraz historia testów, dostępne zasoby, jakość tych zasobów, itd. Jednym zdaniem, według mnie profesjonalny tester to taki, który potrafi trafnie i wiarygodnie odpowiedzieć na pytanie "jak powinien być przetestowany" system, program, moduł czy jednostka. "Trafnie" oznacza tutaj sposób pozwalający w świadomy sposób wyeliminować ryzyko czyli taki, który umożliwi znalezienie istotnych defektów. Wymaga to z kolei umiejętności klasyfikowania defektów nie tylko z punktu widzenia systemu ale także całego projektu.
Do znajdowania, opisywania i klasyfikowania defektów, dysponuje jednocześnie całym wachlarzem narzędzi takich jak techniki testowania, znajomość kontekstu biznesowego, historii system oraz samego systemu.
Nie chcę przez to powiedzieć, że tester jest odpowiedzialny za całość przedsięwzięcia a jedynie chcę podkreślić fakt, iż do obowiązków testera nie należy tylko samo testowanie ale także osadzanie wiedzy o testowanym systemie w jego kontekście w takim zakresie w jakim jest to dla niego osiągalne w zależności od jakości komunikacji w projekcie, zakresu odpowiedzialności (analityk testów, wykonawca testów, lider/manager testów, lider/manager do spraw jakości procesów).
Co pozwala Ci na takie stwierdzenie?Przystępując do nowego projektu, jako jeden z moich "prywatnych" celów wyznaczam sobie rolę źródła pomocy kierownikowi projektu w realizacji zadań projektowych. Nie każdy kierownik projektu, jest świadom tego, że "oszczędzając czas i zasoby" na testach tak naprawdę oszczędza na zapobieganiu ryzyka. Dostarczenie oprogramowania z dużym opóźnieniem do testów i następnie wymaganie zrealizowania pierwotnego planu testów, w żaden sposób nie zaowocuje dobrymi rezultatami. W najgorszym wypadku, raport z testów może pokazywać, że wszystkie funkcjonalności zostały przetestowane. Ale żaden raport nie pokaże jakiej jakości były te testy. Nie odpowie na pytanie czy mała liczba defektów jest wynikiem znakomitej pracy programistów, czy testów dokonywanych w pośpiechu i pobieżnie. Dlatego uważam, ze każdy odpowiedzialny kierownik testów dużo uwagi powinien poświęcać monitorowaniu realizacji harmonogramu projektu aby wcześnie reagować na ograniczanie czasu przeznaczonego na testy jak najwcześniej. Jednocześnie powinien być świadom, iż skracanie czasu testów oznacza w swojej istocie zmniejszenie zakresu testów a więc zwiększenie ryzyka związanego z produktem.
Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?Groucho Marx powiedział kiedyś "Zamierzam żyć wiecznie lub umrzeć próbując". Z całą pewnością istnieje podstawowy zbiór umiejętności wyróżniający testera spośród innych inżynierów. Przede wszystkim - u dojrzałego testera - jest to świadomość "że świat nie jest taki piękny jak się wydaje a nawet jeśli jest to należy to sprawdzić".
Same umiejętności podzieliłbym na kilka poziomów: warsztatowe, produktowe techniczne, produktowe nietechniczne oraz społeczne.
Umiejętności warsztatowe to przede wszystkim biegła znajomość technik projektowania przypadków testowych. To jest warunek sine qua non bycia testerem. To właśnie od tego zależy to czy wykonujemy testy w sposób kontrolowalny, wiarygodny, weryfikowalny i jednoznaczny. Skonstruowanie i uruchomienie przypadku testowego bez jednej z tych cech często okazuje się pracą bezcelową, nie przynoszącą odpowiedzi na podstawowe pytanie.
Umiejętności produktowe techniczne to wszystkie te informacje, które są związane ze sposobem w jaki dany produkt powstaje. Mam na myśli tutaj technologię, sposób implementacji danych funkcjonalności, znajomość ograniczeń technicznych systemu, itp.
Umiejętności produktowe nietechniczne to generalnie znajomość i zrozumienie celu, dla którego powstaje produkt. Innych funkcji oczekujemy przecież od sytemu księgowego a innych od systemu przetwarzania sygnału telewizji cyfrowej, inaczej będzie działał wygaszacz ekranu na komputerze a zupełnie inaczej na dekoderze telewizji cyfrowej. Bez znajomości kontekstu w jakim osadzony jest produkt trudno jest mówić o "dobrym testowaniu".
Umiejętności społeczne to przede wszystkim umiejętności komunikacji i współpracy. Bardzo istotne jest z punktu widzenia testera zrozumienie chociażby tak prostego faktu, że defekty w oprogramowaniu nie wynikają ze złej woli programisty lub uporu architekta ale z faktu, że każdy z nas jest człowiekiem i popełnia błędy. I oczywiście odwrotnie, ważne jest aby osoba odpowiedzialna za całość przedsięwzięcia była świadoma, że testowanie jest sztuką szacowania opartym na krytycznym podejściu do oprogramowania dostarczonego do testów oraz na sceptycznym podejściu do deklarowanej jakości tego systemu, zakresu zmian, możliwych efektów pobocznych, itp.. (Nad wyraz często spotykam się z sytuacją, w której raporty defektów są po prostu ignorowane lub przetwarzane wsadowo co tak naprawdę przynosi gorszy efekt niż po prostu pozostały by one w statusie początkowym).
Te cztery warstwy "zanurzone" są w czymś co nazwałbym "intuicją testera". Rodzi się ona i rozwija się z czasem i doświadczeniem (udziałem w różnych projektach, w różnych organizacjach, w różnych kontekstach biznesowych itp.). Pozwala ona testerowi na wydajne czerpanie z wszystkich czterech warstw w zależności od etapu procesu testowego (analizy wymagań, projektowania przypadków testowych, wykonywania testów lub raportowania defektów, oraz od etapu produkcji oprogramowania.
Jest ona również bardzo istotna w procesie wyjaśniania wszelkich niejasności jakie powstają w trakcie czytania dokumentacji. Warto tutaj dodać, iż w sytuacji kiedy reputacja testerów jest umniejszana jako "tych co nie programują" to wtedy, bardzo skuteczną bronią jest stawianie odpowiednich pytań przez testerów. Jeśli charakter zadawanych pytań będzie zdradzał ignorancję testera lub niezrozumienie działania i celu systemu, negatywna postawa programisty utrwali się. Jeśli natomiast pytania testera przyniosą tę korzyść programiście, że zwrócą mu lub jej uwagę na szczegóły, które są istotne a nie zostały uwzględnione w analizie, bardzo szybko testerzy staną się ośrodkiem wiedzy na temat całościowego działa testowanego systemu. Testerzy - w naturalny niejako sposób - stają się jedynym ośrodkiem w procesie wytwarzania oprogramowania, który posiada w miarę całościową wiedzę na temat rzeczywistego działania produktu. Wynika to właśnie z faktu konieczności zrozumienia zasady działa i celowości całego systemu a nie tylko jej fragmentu. Konieczność ta, z kolei jest warunkiem istotnym do prawidłowego przetestowania systemu.
Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?James Bach w jednej ze swoich prezentacji zadaje pytanie; "jaka jest Twoja misja?", "Czy potrafisz opisać ją w 5 minut?" Moją misję zdefiniowałbym jako; "wsparcie kierownictwa projektu w zakresie określania i eliminowania zagrożeń związanych z dostarczeniem wadliwego oprogramowania". Chodzi o to aby mieć świadomość, że kiedy kierownik projektu przychodzi do nas z pytaniem "na kiedy mogę mieć to przetestowane", to tak naprawdę zadaje on pytanie "w jaki sposób - mając do dyspozycji określony czas i zasoby - mogę się dowiedzieć jak najszybciej jakie ryzyko niesie ze sobą wyprodukowane oprogramowanie". To tester musi wiedzieć co, jak długo i w jaki sposób przetestować tak samo jak programista musi wiedzieć co, jak i jak długo będzie programował.
Na tej podstawie, jako swoją najbardziej cenną umiejętność w tym zawodzie określiłbym otwartość. Otwartość rozumianą jako rozumienie zarówno potrzeb projektu jak i klienta oraz znajdowanie kompromisu pomiędzy tymi dwoma żywiołami.
Czy kwalifikacje mogą określać profesjonalnego testera?Na tak postawione pytanie nie da się chyba odpowiedzieć... wszystko zależy od ludzi. Posiadanie certyfikatów nie dowodzi niczego choć na pewno jest pomocą w poszukiwaniu pracy oraz w zdobywaniu zawodowej pewności siebie, co także jest istotne. Czy tester z kilkuletnim doświadczeniem powinien robić certyfikat z testowania? Jeśli chce "ulepszyć" swoje CV to na pewno tak, ale jeśli chce się czegoś nauczyć to nie ma to sensu bo dowie się o podstawowym zakresie stosowania technik, które zna biegle (a jeśli ich nie zna to nie wykonywał pracy testera).
Na pewno doświadczenie jest tym co bardzo pomaga w realizacji zadań testowych. Ale to nie jest, żadna myśl odkrywcza gdyż doświadczenie jest wszędzie przydatne. Jeśli natomiast jest to pytanie o profil wykształcenia oraz wynikającego w konsekwencji doświadczenia zawodowego to nie potrafię na to odpowiedzieć. Spotykałem wielu testerów. Byli wśród nich i absolwenci filozofii jak i absolwenci fizyki czy informatyki. Ale nie umiem powiedzieć czy wykształcenie ma jakikolwiek wpływ na to czy jest się dobrym lub złym testerem. Z całą pewnością znajomość i wiedza z zakresu inżynierii oprogramowania, programowania, czy generalnie informatyki jest czymś niezbędnym. Z moich obserwacji wynika, że testerzy o informatycznym profilu wykształcenia doskonale sobie radzą z problemami czysto technicznymi takimi jak zrozumienie działania skomplikowanej funkcjonalności ale z drugiej strony często spotykałem tutaj tendencje do poprawiania a nie testowania tej funkcjonalności co zżerało czas i zasoby. I nie chodzi mi tutaj o to, że doszukiwali się źródeł problemu ale o to, że często zamiast poświęcać czas na identyfikację defektów poświęcali czasz na poszukiwanie odpowiedzi na pytanie "jak to naprawić" co jest powinnością programisty.
Ludzie o wykształceniu nie technicznym są znacznie bardziej wyczuleni na defekty. Powoduje to, że czasami przesadzają z oceną wagi defektu oraz zajmują sztywniejsze stanowisko w procesie weryfikacji naprawionych defektów. Często także - powodowani swoją niepewnością wynikającą ze świadomości braku wykształcenia informatycznego - komplikują zagadnienia w fazie analizy co utrudnia im znacznie zrozumienie podstawowych kwestii.
Nie wiem, która opcja jest lepsza... Ale wiem, że za każdym razem kiedy pracowałem w zespole testerów, to tworzył się inny niż u programistów świat... świat, w którym ludzie otwarci są na wiedzę i dzielenie się nią, w którym czują się spojeni misją, którą mam nadzieję każdy z nich potrafi sobie zdefiniować. Świat który jest jednak mocno sceptyczny. Z drugiej jednak strony powstaje wiele patologii takich jak tworzenie "mitycznej jakości" lub zbyt szczegółowe podejście do zagadnień testowych co powoduje niepotrzebne wydłużenie cyklu testowego.
Reasumując, definiowanie profesji testera z całą pewności jest pożądane. Dobrze, że powstają firmy certyfikujące i standaryzujące. Dobrze, że jest mnóstwo wolnych strzelców i ludzi pracujących na własnymi metodykami. Taka dychotomia jest symptomem tego, że jest to jeszcze bardzo młoda dziedzina. Ale bez względu na to czy pracujemy w środowisku extreme, agaile, V, W, iteracyjnym czy w modelu kaskadowym, z całą pewnością powinniśmy w naszych codziennych obowiązkach testera zapewniać spełnienie podstawowych warunków takich jak kontrolowalność, wiarygodność, weryfikowalność i jednoznaczność przy optymalnym stosowaniu technik testowych.
piątek, 6 kwietnia 2007
Testowanie rzeczywistości
Dzisiaj przekonałem się na własnej skórze, że (czasami) warto jest testować rzeczywistość. Przez wiele lat chodziłem do jednego i tego samego dentysty. Fachowiec powtarzał, że "aby wyleczyć to musi boleć". Więc bolało jak cholera! Do tego stopnia, że zacząłem unikać dentysty jak tylko mogłem. Ergo, nastąpił paraliż projektu, bo chodziłem tylko wtedy, kiedy rzeczywiście ząb bolał na maksa a to generalnie oznaczało leczonko kanałowe. A to z kolei jeszcze bardziej zwiększało moją niechęć i obawy.
I tak przez lata, wmawiając sobie, że ten dentysta mnie zna, robi co może aby jak najmniej bolało chodziłem do niego. Jednak ostatnio - całkiem przypadkowo - w nagłej potrzebie zmieniłem lekarza. I oczywiście świat się zmienił. Borowanie nie boli, stres jest mniejszy, generalnie jest luks malina.
Tylko ja trochę żałuję, że wcześniej nie rozpocząłem testów lekarzy dentystów. Ale z drugiej strony - jeśli leczenie zębów i obawę przed bólem uznać za system krytyczny - to była to decyzja o podstawach jak najbardziej racjonalnych...
I tak przez lata, wmawiając sobie, że ten dentysta mnie zna, robi co może aby jak najmniej bolało chodziłem do niego. Jednak ostatnio - całkiem przypadkowo - w nagłej potrzebie zmieniłem lekarza. I oczywiście świat się zmienił. Borowanie nie boli, stres jest mniejszy, generalnie jest luks malina.
Tylko ja trochę żałuję, że wcześniej nie rozpocząłem testów lekarzy dentystów. Ale z drugiej strony - jeśli leczenie zębów i obawę przed bólem uznać za system krytyczny - to była to decyzja o podstawach jak najbardziej racjonalnych...
wtorek, 27 lutego 2007
Testowalność - lista kontrolna
Testowalność (testability) jest dosyć dziwnym pojęciem oznaczającym generalnie łatwość bycia testowanym. Jeśli ktoś jest zainteresowany, tutaj znajduje się lista rzeczy które ułatwiają testowanie.
poniedziałek, 26 lutego 2007
Czy czarna skrzynka jest taka czarna?
Czy rzeczywiście czarna skrzynka jest taka czarna? Określenie "czarna skrzynka" jest używane jako metafora testów nie wymagających znajomości wewnętrznych struktur i konstrukcji oprogramowania. Kompetencja czytania i rozumienia kodu nie jest potrzebna.
Założenie jest następujące: wystarczy mieć wymagania klienta, skonstruować na tej podstawie przypadki testowe, sformułować oczekiwane rezultaty i na końcu porównać wyniki testu ze zdefiniowanymi rezultatami.
Tutaj pojawia się moja wątpliwość... Ponieważ testowanie wszystkich przypadków jest niemożliwe, korzystamy z różnych technik celem ograniczenia ich liczby do rozsądnych rozmiarów. Jedną z takich technik jest "klasa równoważności", ale równie dobrze może być tutaj podstawiona każda inna.
Przy stosowaniu klas równoważności (generalizując pewne zbiory parametrów), automatycznie zakładamy (na jakiej podstawie?), że kod jest zaimplementowany zgodnie z założeniami tzw. "dobrych praktyk"...
A co jeśli nie? A co jeśli kod jest pisany przez programistę, który nie ma doświadczenia lub inaczej niż my rozumie to wymaganie? Prawdopodobieństwo popełnienia błędu jest bardzo duże, tak samo jak prawdopodobieństwo, że utworzony w tym miejscu defekt nie zostanie wykryty.
W tej sytuacji istnieją dwie możliwości:
Drugi przypadek także eliminuje czarną skrzynkę, bo przecież zaglądamy do kodu. Ale uważam, że to podejście jest lepsze!
Na przykład:
Programista implementując zestaw wymagań obmyślił sobie, że jego podstawowym bytem będą szklanki. Z góry było wiadomo, że oprócz szklanek potrzebne będą także słoiki i dzbanki. Ale nasz inżynier sobie pomyślał: >>przecież słoiki i dzbanki to to samo co szklanka (służą do przechowywania cieczy) tylko inaczej skonfigurowane. Tak więc słoik i dzbanek to po prostu specjalne przypadki szklanki<<. Niestety... zespół testowy - ze względu na zupełnie inną obsługę dzbanków, inną obsługę szklanek i inną obsługę słoików - potraktował to jako zupełnie osobne byty. Testy zakończyły się pomyślnie a defekty pojawiły się dopiero w produkcji. Gdyby zespól testowy miał świadomość tego jak wygląda implementacja kodu, testy zostałyby dobrze skrojone.
Po pierwsze znając kod wiemy jak go "otestować" przypadkami, po drugie rozumiemy nie tylko jak program ma działać ale także jak działa przez co jesteśmy w stanie identyfikować łatwiej źródła defektów.
Oczywiście wadą jest fakt, iż czasami dostęp do kodu nic nie da bo ze względu na "włoski makaron" lub rozproszenie źródeł, zrozumienie go zajmie więcej czasu niż czas potrzebny na "czarną skrzynkę" plus dodatki. W takim wypadku jednak można zorganizować spotkanie z szefem architektów aby wyjaśnił zamierzenia architektoniczne oraz spotkanie z szefem programistów aby wyjaśnił jak te zamierzenia zostały zaimplementowane.
Założenie jest następujące: wystarczy mieć wymagania klienta, skonstruować na tej podstawie przypadki testowe, sformułować oczekiwane rezultaty i na końcu porównać wyniki testu ze zdefiniowanymi rezultatami.
Tutaj pojawia się moja wątpliwość... Ponieważ testowanie wszystkich przypadków jest niemożliwe, korzystamy z różnych technik celem ograniczenia ich liczby do rozsądnych rozmiarów. Jedną z takich technik jest "klasa równoważności", ale równie dobrze może być tutaj podstawiona każda inna.
Przy stosowaniu klas równoważności (generalizując pewne zbiory parametrów), automatycznie zakładamy (na jakiej podstawie?), że kod jest zaimplementowany zgodnie z założeniami tzw. "dobrych praktyk"...
A co jeśli nie? A co jeśli kod jest pisany przez programistę, który nie ma doświadczenia lub inaczej niż my rozumie to wymaganie? Prawdopodobieństwo popełnienia błędu jest bardzo duże, tak samo jak prawdopodobieństwo, że utworzony w tym miejscu defekt nie zostanie wykryty.
W tej sytuacji istnieją dwie możliwości:
- dopisujemy dodatkowe przypadki testowe
- zaglądamy do kodu
Drugi przypadek także eliminuje czarną skrzynkę, bo przecież zaglądamy do kodu. Ale uważam, że to podejście jest lepsze!
Na przykład:
Programista implementując zestaw wymagań obmyślił sobie, że jego podstawowym bytem będą szklanki. Z góry było wiadomo, że oprócz szklanek potrzebne będą także słoiki i dzbanki. Ale nasz inżynier sobie pomyślał: >>przecież słoiki i dzbanki to to samo co szklanka (służą do przechowywania cieczy) tylko inaczej skonfigurowane. Tak więc słoik i dzbanek to po prostu specjalne przypadki szklanki<<. Niestety... zespół testowy - ze względu na zupełnie inną obsługę dzbanków, inną obsługę szklanek i inną obsługę słoików - potraktował to jako zupełnie osobne byty. Testy zakończyły się pomyślnie a defekty pojawiły się dopiero w produkcji. Gdyby zespól testowy miał świadomość tego jak wygląda implementacja kodu, testy zostałyby dobrze skrojone.
Po pierwsze znając kod wiemy jak go "otestować" przypadkami, po drugie rozumiemy nie tylko jak program ma działać ale także jak działa przez co jesteśmy w stanie identyfikować łatwiej źródła defektów.
Oczywiście wadą jest fakt, iż czasami dostęp do kodu nic nie da bo ze względu na "włoski makaron" lub rozproszenie źródeł, zrozumienie go zajmie więcej czasu niż czas potrzebny na "czarną skrzynkę" plus dodatki. W takim wypadku jednak można zorganizować spotkanie z szefem architektów aby wyjaśnił zamierzenia architektoniczne oraz spotkanie z szefem programistów aby wyjaśnił jak te zamierzenia zostały zaimplementowane.
czwartek, 22 lutego 2007
Przyszłość testów wg. Bacha
Niedawno na amerykańskich stronach "Dr. Dobb's Portal" z cyklu "The book of testing" w ramach bloga Michaela Huntera pojawił się wywiad zatytułowany "Five Questions With James Bach".
W tym krótkim tekście "ojciec założyciel" testów eksploracyjnych zawiera wiele zdań, które mogą być szokujące ale jednocześnie spójne z koncepcją metodyk lekkich. Np. na pytanie co jest najbardziej zaskakujące w testowaniu odpowiada
Dodając wcześniej - muszę przyznać dosyć trywialnie - że:
Jako swoją najcenniejszą lekcję, Bach wspomina defekt - znaleziony przez niego w jego własnym programie - który poprzez nieprawidłową obsługę pamięci powodował przesunięcie wyświetlanej grafiki w prawo. Defekt, zignorowany przez niego na początku, okazał się lekcją trącącą trochę filozofią Georgea Berkeleya, że wszystko jest wrażeniem. Sam Bach streszcza ją w następujący sposób:
Zdanie to wydaje mi się bardzo znamienne w dzisiejszych czasach, kiedy coraz częściej zaczyna liczyć się czas dostarczenia produktu na rynek a nie jego jakość, kiedy najczęstszym kryterium wypuszczenia oprogramowania nie są nomen omen inżynierskie kryteria ale po prostu polecenie zarządu. W kontekście tego stwierdzenia może się okazać, że zaczną pojawiać się na rynku produkty-zombie. Produkty, które w zamierzeniach producentów miały być ulepszone jak tylko "zdobędą" rynek, a nie da się ich ulepszyć ze względu na tą niepewność, omyłkowo wziętą przez zarząd za pewność i w rzeczywistości objawiającą się jako defekt krytyczny.
Dla polskiego czytelnika - gdzie tak naprawdę standaryzacja branży rodzi się dopiero w bólach - szczególnie interesujące może być zdanie:
Osoby głębiej zainteresowane zapewne spotkały się z podobną opinią Kema Kanera na temat certyfikacji i uzasadnienia dlaczego komercyjni "certyfikatorzy" nie spełniają do końca swojej roli sygnatariuszy kompetencji. W polskich i europejskich warunkach wygląda to znacznie bardziej skomplikowanie. Firmy poszukując podstawowego przynajmniej zapewnienia sobie, że zatrudniona osoba jest kompetentna pytają o certyfikaty. Czy jednak otrzymując pozytywną odpowiedź na to pytanie, otrzymują także odpowiedź na swoje pytanie?
Na koniec Bach zapytany o największe wyzwanie stojące przed dziedziną testów w okresie 5 najbliższych lat, wymienia trzy:
Drugie nie wymaga nawet komentarza... Mizeria na tym polu na polskim rynku jest porażająca.
Natomiast co do trzeciego wyzwania to mam mieszane uczucia. Zdaje się, że otwarta forma certyfikacji mogłaby rzeczywiście zapewnić wiedzę "jak testować" na minimalnym poziomie. Lecz tutaj podjęte są słabe próby. Z drugiej strony... tak jak napisałem wyżej, firmy oczekują jakiegoś zaświadczenia, że jesteś testerem i umiesz testować.
W tym krótkim tekście "ojciec założyciel" testów eksploracyjnych zawiera wiele zdań, które mogą być szokujące ale jednocześnie spójne z koncepcją metodyk lekkich. Np. na pytanie co jest najbardziej zaskakujące w testowaniu odpowiada
"[...] zaskakuje mnie, iż prawie cały światek testowy bezwarunkowo akceptuje fakt, iż większość testów powinna być spisana w formie procedury."
Dodając wcześniej - muszę przyznać dosyć trywialnie - że:
"[...] testowanie głównie jest procesem myślenia i wyobrażania sobie [...]"
Jako swoją najcenniejszą lekcję, Bach wspomina defekt - znaleziony przez niego w jego własnym programie - który poprzez nieprawidłową obsługę pamięci powodował przesunięcie wyświetlanej grafiki w prawo. Defekt, zignorowany przez niego na początku, okazał się lekcją trącącą trochę filozofią Georgea Berkeleya, że wszystko jest wrażeniem. Sam Bach streszcza ją w następujący sposób:
"[...] relacja pomiędzy przyczyną i skutkiem w komputerze może być do tego stopnia pogmatwana i skomplikowana, że nigdy nie możemy być pewni, że wiemy na co patrzymy kiedy obserwujemy uruchomiony program."
Zdanie to wydaje mi się bardzo znamienne w dzisiejszych czasach, kiedy coraz częściej zaczyna liczyć się czas dostarczenia produktu na rynek a nie jego jakość, kiedy najczęstszym kryterium wypuszczenia oprogramowania nie są nomen omen inżynierskie kryteria ale po prostu polecenie zarządu. W kontekście tego stwierdzenia może się okazać, że zaczną pojawiać się na rynku produkty-zombie. Produkty, które w zamierzeniach producentów miały być ulepszone jak tylko "zdobędą" rynek, a nie da się ich ulepszyć ze względu na tą niepewność, omyłkowo wziętą przez zarząd za pewność i w rzeczywistości objawiającą się jako defekt krytyczny.
Dla polskiego czytelnika - gdzie tak naprawdę standaryzacja branży rodzi się dopiero w bólach - szczególnie interesujące może być zdanie:
"Myślę, że programy certyfikacji ISEB czy ISTQB są pomyłką. Mam nadzieję, że nikt nie przykłada do nich większej wagi."
Osoby głębiej zainteresowane zapewne spotkały się z podobną opinią Kema Kanera na temat certyfikacji i uzasadnienia dlaczego komercyjni "certyfikatorzy" nie spełniają do końca swojej roli sygnatariuszy kompetencji. W polskich i europejskich warunkach wygląda to znacznie bardziej skomplikowanie. Firmy poszukując podstawowego przynajmniej zapewnienia sobie, że zatrudniona osoba jest kompetentna pytają o certyfikaty. Czy jednak otrzymując pozytywną odpowiedź na to pytanie, otrzymują także odpowiedź na swoje pytanie?
Na koniec Bach zapytany o największe wyzwanie stojące przed dziedziną testów w okresie 5 najbliższych lat, wymienia trzy:
- naukę jak testować
- naukę jak szkolić testerów
- odrzucenie fałszywych profetów certyfikacji
Drugie nie wymaga nawet komentarza... Mizeria na tym polu na polskim rynku jest porażająca.
Natomiast co do trzeciego wyzwania to mam mieszane uczucia. Zdaje się, że otwarta forma certyfikacji mogłaby rzeczywiście zapewnić wiedzę "jak testować" na minimalnym poziomie. Lecz tutaj podjęte są słabe próby. Z drugiej strony... tak jak napisałem wyżej, firmy oczekują jakiegoś zaświadczenia, że jesteś testerem i umiesz testować.
środa, 21 lutego 2007
Czy dane testowe są już test casem i dlaczego nie
Czy szklanka jest od połowy pusta czy do połowy pełna? Tak samo chyba jest z pytaniem czy dane testowe stanowią same w sobie przypadek testowy...?
W codziennej pracy, pisząc przypadki testowe, bardzo często piszemy jedną procedurę a do niej wybieramy kilka zestawów danych. Czy w takim wypadku każdy z tych zestawów jest przypadkiem testowym czy dopiero w połączeniu z procedurą testową stanowią takowy?
Z punktu widzenia kierownika testów oraz projektanta przypadków skłaniałbym się raczej do tego, że jest to jeden przypadek testowy (a raczej jego szczególny przypadek).
Z punktu widzenia inżyniera uruchamiającego testy skłaniałbym się do pierwszej definicji. Każdy zestaw danych wymusza uruchomienie jednej i tej samej procedury ale kilkakrotnie z różnymi danymi więc i wyniki mogą być różne. Do tego możemy jeszcze - w niektórych przypadkach - doliczyć czas potrzebny na czyszczenie środowiska.
Ogólnie rzecz biorąc jest to bardzo częsty przykład stosowania "brztwy Ockhama" w testach. Jakież było moje zdziwienie gdy okazało się, iż żaden z czołowych produktów do zarządzania testami nie wspiera tej prostej funkcjonalności? Okazuje się, iż próba wygenerowania w "run-time" wielu przypadków testowych na podstawie jednej procedury i kilku zestawów danych definiowanych w "design-time" dla tej procedury jest niemożliwe.
Czyli... zamiast ułatwiać utrzymywalność zasobów przypadków testowych poprzez minimalizowanie ich liczby jesteśmy skazani - korzystając z tych narzędzi - na większe nakłady pracy związane z utrzymywaniem środowiska testowego.
A przecież korzyść z takiej implementacji była by oczywista; mniej przypadków testowych do utrzymania.
W codziennej pracy, pisząc przypadki testowe, bardzo często piszemy jedną procedurę a do niej wybieramy kilka zestawów danych. Czy w takim wypadku każdy z tych zestawów jest przypadkiem testowym czy dopiero w połączeniu z procedurą testową stanowią takowy?
Z punktu widzenia kierownika testów oraz projektanta przypadków skłaniałbym się raczej do tego, że jest to jeden przypadek testowy (a raczej jego szczególny przypadek).
Z punktu widzenia inżyniera uruchamiającego testy skłaniałbym się do pierwszej definicji. Każdy zestaw danych wymusza uruchomienie jednej i tej samej procedury ale kilkakrotnie z różnymi danymi więc i wyniki mogą być różne. Do tego możemy jeszcze - w niektórych przypadkach - doliczyć czas potrzebny na czyszczenie środowiska.
Ogólnie rzecz biorąc jest to bardzo częsty przykład stosowania "brztwy Ockhama" w testach. Jakież było moje zdziwienie gdy okazało się, iż żaden z czołowych produktów do zarządzania testami nie wspiera tej prostej funkcjonalności? Okazuje się, iż próba wygenerowania w "run-time" wielu przypadków testowych na podstawie jednej procedury i kilku zestawów danych definiowanych w "design-time" dla tej procedury jest niemożliwe.
Czyli... zamiast ułatwiać utrzymywalność zasobów przypadków testowych poprzez minimalizowanie ich liczby jesteśmy skazani - korzystając z tych narzędzi - na większe nakłady pracy związane z utrzymywaniem środowiska testowego.
A przecież korzyść z takiej implementacji była by oczywista; mniej przypadków testowych do utrzymania.
wtorek, 13 lutego 2007
Filozofia testowania
No to teraz będzie chyba z grubej rury. Większość poznanych przeze mnie ludzi kształconych w naukach ścisłych, słysząc o filozofii czy historii lub sztuce mówi w sposób, który dobrze określa słowo "uczłowieczacz". Czyli generalnie jest to coś co ma być dodatkiem do głównego nurtu wykształcenia...
W tym kontekście polecam wpis James'a Bacha na jego blogu "Philosophers of testing".
Najmocniejsze dwa zdania - oczywiście według mojej oceny to:
W tym kontekście polecam wpis James'a Bacha na jego blogu "Philosophers of testing".
Najmocniejsze dwa zdania - oczywiście według mojej oceny to:
Philosophy doesn’t find bugs for me, but it improves my ability to search for them. I have more patience for the search because philosophy has taught me tolerance for ambiguity, an appreciation for complexity, and a mistrust of appearances.
[...]
Philosophy doesn’t evaluate or report my bugs, but it does make my evaluations and reports better.
poniedziałek, 12 lutego 2007
Czarna szkrzynka +/- biała skrzynka = szara skrzynka
Coraz częściej - chyba dlatego, że programiści zabierają się za testowanie ;-) - można spotkać się z rozumieniem zagadnienia testowania w kontekście rywalizacji pomiędzy białą skrzynką a czarną skrzynką. Trudno jest udowodnić taką tezę! Jest to problem typu "kura czy jajko"!
Przykładem tego jest artykuł "Testing, fun? Really?"! Sam artykuł nie wnika subtelne różnice pomiędzy testami czarnej skrzynki a testami białej skrzynki. I chyba rzeczywiście tak powinno być. Test to test! Dobry tester powinien radzić sobie zarówno z kodem jak i z binarką. Na pewno nie powiem nic nowego stwierdzając, że czarna i biała skrzynka to uzupełniające się sposoby na przetestowanie oprogramowania. Problem polega na tym, że czarna skrzynka znajduje innego typu błędy niż biała skrzynka. Oznacza to oczywiście, że nie znajdziemy pewnych błędów stosując dajmy na to tylko test czarnej skrzynki.
Czy biała skrzynka oznacza konieczność stosowania testów jednostkowych? Według mnie nie! To co jest potrzebne to na pewno znajomość architektury danego rozwiązania oraz generalną strukturę organizacji kodu. W mojej opinii doskonałym rozwiązaniem jest korzystanie z kodu jak z podpowiedzi lub swojego rodzaju przewodnika. Na tej podstawie można w łatwy sposób zlokalizować potencjalne obszary ryzyka. Dodatkowo można spróbować określić techniczną naturę tego ryzyka i w zależności od tego zastosować techniki biało lub czarno skrzynkowe.
Testy jednostkowe to tylko jedno z zastosowań testów przeprowadzanych bezpośrednio na kodzie źródłowym i powinny być wykonywane przez autorów tego kodu. Testerzy natomiast nie powinni być odcinani od kodu. Obcując z nim, czytając, poznając architekturę rozumieją w jaki sposób system działa, są w stanie w łatwiejszy sposób zidentyfikować obszary wymagające bardziej intensywnych testów.
Nie pamiętam kto, powiedział, że prawdziwy haker to taki człowiek, który potrafi - mając zdefiniowane zadanie - określić, który język programowania będzie pasował najlepiej do realizacji tego zadania. Podobnie jest z testerami. Posiadając wiedzę na temat systemu, sposobu jego działania, sposobu w jaki jest budowany, architektury, itp. jest w stanie określić, które metody testowe będą najbardziej wydajne w stosunku do których obszarów (typów defektów).
Oczywiście dostęp do kodu powinien być przeznaczony dla osób, które posiadają odpowiednie kompetencje. Ale czy trzeba być programistycznym guru aby to robić? I znowu, wg. mnie wystarczy podstawowa wiedza dotycząca konkretnego języka, sposobu budowania funkcji, deklarowania i rzutowania zmiennych, tzw. "best practices". Podręcznik do C jest chyba inaczej czytany przez programistę a inaczej przez testera. Programista skupiony jest na zagadnieniu "jak coś zrobić" (przynajmniej tak mi się wydaje), tester natomiast skupiony jest na "obszarach potencjalnie niebezpiecznych".
Przykładem tego jest artykuł "Testing, fun? Really?"! Sam artykuł nie wnika subtelne różnice pomiędzy testami czarnej skrzynki a testami białej skrzynki. I chyba rzeczywiście tak powinno być. Test to test! Dobry tester powinien radzić sobie zarówno z kodem jak i z binarką. Na pewno nie powiem nic nowego stwierdzając, że czarna i biała skrzynka to uzupełniające się sposoby na przetestowanie oprogramowania. Problem polega na tym, że czarna skrzynka znajduje innego typu błędy niż biała skrzynka. Oznacza to oczywiście, że nie znajdziemy pewnych błędów stosując dajmy na to tylko test czarnej skrzynki.
Czy biała skrzynka oznacza konieczność stosowania testów jednostkowych? Według mnie nie! To co jest potrzebne to na pewno znajomość architektury danego rozwiązania oraz generalną strukturę organizacji kodu. W mojej opinii doskonałym rozwiązaniem jest korzystanie z kodu jak z podpowiedzi lub swojego rodzaju przewodnika. Na tej podstawie można w łatwy sposób zlokalizować potencjalne obszary ryzyka. Dodatkowo można spróbować określić techniczną naturę tego ryzyka i w zależności od tego zastosować techniki biało lub czarno skrzynkowe.
Testy jednostkowe to tylko jedno z zastosowań testów przeprowadzanych bezpośrednio na kodzie źródłowym i powinny być wykonywane przez autorów tego kodu. Testerzy natomiast nie powinni być odcinani od kodu. Obcując z nim, czytając, poznając architekturę rozumieją w jaki sposób system działa, są w stanie w łatwiejszy sposób zidentyfikować obszary wymagające bardziej intensywnych testów.
Nie pamiętam kto, powiedział, że prawdziwy haker to taki człowiek, który potrafi - mając zdefiniowane zadanie - określić, który język programowania będzie pasował najlepiej do realizacji tego zadania. Podobnie jest z testerami. Posiadając wiedzę na temat systemu, sposobu jego działania, sposobu w jaki jest budowany, architektury, itp. jest w stanie określić, które metody testowe będą najbardziej wydajne w stosunku do których obszarów (typów defektów).
Oczywiście dostęp do kodu powinien być przeznaczony dla osób, które posiadają odpowiednie kompetencje. Ale czy trzeba być programistycznym guru aby to robić? I znowu, wg. mnie wystarczy podstawowa wiedza dotycząca konkretnego języka, sposobu budowania funkcji, deklarowania i rzutowania zmiennych, tzw. "best practices". Podręcznik do C jest chyba inaczej czytany przez programistę a inaczej przez testera. Programista skupiony jest na zagadnieniu "jak coś zrobić" (przynajmniej tak mi się wydaje), tester natomiast skupiony jest na "obszarach potencjalnie niebezpiecznych".
sobota, 10 lutego 2007
Generyczne przypadki testowe
Każda firma produkująca oprogramowanie dąży do stworzenia zasobów generycznych pozwalających na szybkie i elastyczne generowanie nowych produktów - przynajmniej ich dużą część. W ten sposób powstają przeróżne biblioteki, repozytoria, snippety, interfejsy i inne takie. Po krótkim czasie okazuje się, że tak naprawdę jest to osobny projekt wymagający osobnego kierownika, planu, zdefiniowanych celów itd. Czy automatycznie rzutuje to na dział testów?
Zdecydowanie tak! I to na wielu płaszczyznach które chyba najlepiej wyrazić pytaniami.
Oto prosty przykład: programiści pracują w kontekście projektu specyficznego i generycznego równocześnie, testerzy natomiast pracują tylko w kontekście konkretnego projektu (z przyczyn oczywistych). Tak więc defekty zgłoszone przez testerów do projektu "S" są potem przekierowywane przez programistów do projektu "G", kiedy natura defektu okazuje się generyczna. Następnie naprawione defekty wracają do testerów w celu weryfikacji i weryfikacja wszystkich defektów - nawet tych z projektu "G" - odbywa się na projekcie "S". Wystarczy teraz dodać, że testerzy pracują w swoim środowisku a programiści w swoim. Z systemu zarządzania testami raportowane są defekty do zintegrowanego systemu rejestracji defektów. Problem pojawia się w momencie przepisania defektu z projektu "S" do projektu "G". Po prostu w systemie do zarządzania przypadkami widoczne są defekty tylko dla konkretnego projektu. Więc analityk do spraw jakości nie ma dostępu do pełnej informacji tylko do jej części.
Chciałbym podkreślić w tym miejscu, że opisywany przeze mnie tutaj problem chyba w mniejszym zakresie dotyczy środowisk jednoprojektowych. A przynajmniej w środowisku wieloprojektowym objawia się znacznie intensywniej.
Skoro istnieje już projekt generyczny z generycznym kodem, który prawdopodobnie nie da się skompilować w łatwy sposób, to przed testerem powstaje poważne zagadnienie: "jak przetestować tą generyczność zawartą w generycznym projekcie?"
Odpowiedzi oczywiście jest kilka i pewnie poniższe nie pokrywają całości:
Drugie pytanie dotyczy tak naprawdę zagadnienia; co określa przypadek testowy jako generyczny? Ja jestem gorącym zwolennikiem oddzielenia danych testowych od procedury. Pozwoliło by to na bardzo dużą elastyczność:
Drugie rozwiązanie pozwala na znacznie szerszy zakres testów ale czas do uruchomienia jest znacznie dłuższy.
Odpowiedź na ostanie pytanie: "do kiedy przypadek jest generyczny a od kiedy już nie" jest mocno uzależniona od tego jak zdefiniowana zostanie sama generyczność. Ja po prostu polecałbym zdrowy rozsądek i metodę drobnych kroczków. Najpierw należy zbudować zbiór przypadków, które udowodnią swoją generyczność (przy naprawdę minimalnych zmianach wykorzystywane będą na szeroką skalę). Każdy w miarę doświadczony tester ma podręczny zestaw takich przypadków (obsługujących takie obszary jak logowanie, wylogowywanie, walidowanie danych, itd). Następnie na tej podstawie należy spróbować określić co oznacza w danym wypadku "generyczność" i skorzystać z tego jako z kryterium przy wybieraniu następnych przypadków testowych. Jednak definicja generyczności powinna być nieustannie weryfikowana.
* Właściwie to nie znam systemu przeznaczonego do opisanych zastosowań, który nie używał by projektu jako kontekstu opisującego całość.
Zdecydowanie tak! I to na wielu płaszczyznach które chyba najlepiej wyrazić pytaniami.
- co to znaczy generyczność?
- jak przetestować projekt generyczny?
- czy do generycznego projektu powinny powstać generyczne przypadki testowe?
- co to znaczy, że przypadek testowy jest generyczny?
- do kiedy jest generyczny a od kiedy już nie?
"Istnieje na rynku wiele narzędzi do zarządzania artefaktami projektu takimi jak defekty, przypadki testowe, kod źródłowy, wymagania, specyfikacja czy dokumentacja projektowa. Większość z nich - biorąc pod uwagę przydatność biznesową szeroko rozumianą - kosztuje bardzo drogo. Każdy producent wychwala jak to jest elastyczne i integrowalne ale w rzeczywistości brakuje tym systemom wsparcia generyczności co prawdopodobnie spowodowane jest architekturą opartą o projekt."Większość architektur takich rozwiązań przewiduje projekt jako kontekst projektu*. Z kolei projekt zdefiniowany jest jako jednotorowy - na ogólnym poziomie - proces wytwarzania oprogramowania. I tutaj pojawia się pierwszy problem! W środowiskach wieloprojektowych rozumienie generyczności jest inne niż w środowisku dużego projektu. W pierwszym przypadku oznacza to "zakres" kodu, możliwy do użycia przy założeniu prac konfiguracyjnych do różnych projektów. Natomiast w środowisku dużego projektu lub - dla jasności nazwijmy go jednoprojektowym - generyczność oznacza reużywalność ale nie względem projektów tylko modułów (stąd chyba bliżej do czystej obiektowości!?)
Oto prosty przykład: programiści pracują w kontekście projektu specyficznego i generycznego równocześnie, testerzy natomiast pracują tylko w kontekście konkretnego projektu (z przyczyn oczywistych). Tak więc defekty zgłoszone przez testerów do projektu "S" są potem przekierowywane przez programistów do projektu "G", kiedy natura defektu okazuje się generyczna. Następnie naprawione defekty wracają do testerów w celu weryfikacji i weryfikacja wszystkich defektów - nawet tych z projektu "G" - odbywa się na projekcie "S". Wystarczy teraz dodać, że testerzy pracują w swoim środowisku a programiści w swoim. Z systemu zarządzania testami raportowane są defekty do zintegrowanego systemu rejestracji defektów. Problem pojawia się w momencie przepisania defektu z projektu "S" do projektu "G". Po prostu w systemie do zarządzania przypadkami widoczne są defekty tylko dla konkretnego projektu. Więc analityk do spraw jakości nie ma dostępu do pełnej informacji tylko do jej części.
Chciałbym podkreślić w tym miejscu, że opisywany przeze mnie tutaj problem chyba w mniejszym zakresie dotyczy środowisk jednoprojektowych. A przynajmniej w środowisku wieloprojektowym objawia się znacznie intensywniej.
Skoro istnieje już projekt generyczny z generycznym kodem, który prawdopodobnie nie da się skompilować w łatwy sposób, to przed testerem powstaje poważne zagadnienie: "jak przetestować tą generyczność zawartą w generycznym projekcie?"
Odpowiedzi oczywiście jest kilka i pewnie poniższe nie pokrywają całości:
- Testować niejawnie poprzez implementację fragmentów generycznych w modułach/projektach.
- Zbudować sztuczne projekty - najlepiej na początku fazy stabilizacji kiedy kod jest już gotowy - wygenerowane w głównych mutacjach użycia i przetestować je. Następnie przeprowadzić analizę porównawczą wyników dla poszczególnych projektów. Tam gdzie pokrywają się i wynik jest pozytywny, generyczność jest zaimplementowana.
- Określić wszystkie możliwe konfiguracje modułu/projektu, wygenerować je w postaci binarki i poddać moduły testom integracyjnym a projekty testom systemowym (oczywiście w ograniczonym zakresie) . Oczywiście procedura jest jednakowa dla wszystkich mutacji.
Pierwsze pytanie sugeruje szansę sukcesu ale tak naprawdę poważnie ogranicza zakres pokrycia testami. Oznacza to, sukces ale bardzo maleńki.
- da się go uruchomić na każdym projekcie z rodziny "G"?
- da się go uruchomić bez zmiany parametrów?
- jest reużywalny jako zamknięta część - bez konieczności zmian?
- wskazuje jedynie co powinno być przetestowane?
Drugie pytanie dotyczy tak naprawdę zagadnienia; co określa przypadek testowy jako generyczny? Ja jestem gorącym zwolennikiem oddzielenia danych testowych od procedury. Pozwoliło by to na bardzo dużą elastyczność:
- dynamiczne generowanie przypadków testowych w oparciu o jedną procedurę i wiele zestawów danych, co pokryłoby w łatwy sposób:
- klasy równoważności
- dziedziny
- wartość graniczne
- przepływ danych
- przepływ sterowania
- kontrolę potrzebną głównie na poziomie danych
- dużą przenaszalność samych procedur.
Drugie rozwiązanie pozwala na znacznie szerszy zakres testów ale czas do uruchomienia jest znacznie dłuższy.
Odpowiedź na ostanie pytanie: "do kiedy przypadek jest generyczny a od kiedy już nie" jest mocno uzależniona od tego jak zdefiniowana zostanie sama generyczność. Ja po prostu polecałbym zdrowy rozsądek i metodę drobnych kroczków. Najpierw należy zbudować zbiór przypadków, które udowodnią swoją generyczność (przy naprawdę minimalnych zmianach wykorzystywane będą na szeroką skalę). Każdy w miarę doświadczony tester ma podręczny zestaw takich przypadków (obsługujących takie obszary jak logowanie, wylogowywanie, walidowanie danych, itd). Następnie na tej podstawie należy spróbować określić co oznacza w danym wypadku "generyczność" i skorzystać z tego jako z kryterium przy wybieraniu następnych przypadków testowych. Jednak definicja generyczności powinna być nieustannie weryfikowana.
* Właściwie to nie znam systemu przeznaczonego do opisanych zastosowań, który nie używał by projektu jako kontekstu opisującego całość.
czwartek, 1 lutego 2007
Jak zostać ekspertem od testowania czyli "Becoming a Software Testing Expert" na Google Video
Świetny wykład Jamesa Bacha na temat jak się stać ekspertem od testów. Rzeczywiście zawiera kilka wskazówek, których warto posłuchać.
"Becoming a Software Testing Expert" na Google Video
Opis: Google TechTalks, 13 Lipca 2006, James Bach
"Becoming a Software Testing Expert" na Google Video
Opis: Google TechTalks, 13 Lipca 2006, James Bach
"Pracuję z zespołami projektowymi i poszczególnymi inżynierami aby pomóc im zaplanować proces zapewniania jakości oprogramowania (SQA), kontrolowania zmian oraz procesów testowych pozwalającym im zrozumieć i kontrolować ryzyka związane z niedziałaniem produktu. Większa część mojego doświadczenia związana jest z firmami nastawionymi na rynek z Doliny Krzemowej takimi jak Apple Computer czy Borland, więc techniki, których się nauczyłem i rozwinąłem zostały zaprojektowane tak aby korzystać z nich w warunkach napiętych harmonogramów, wysokiego wskaźnika zmian, technologii opartej na komponentach lub ubogiej specyfikacji."
STRESZCZENIE: "Jesteście doświadczonymi testerami. Wiecie jak zaprojektować testy i raportować defekty. A teraz co? Czujecie się ekspertami? Na nieszczęście, jeśli chcecie stać się bardzo dobrymi w testowaniu, to nie macie wielu kursów lub programów do wyboru, które by wam pomogły. Oznacza to, że musicie edukować się sami. Ten przewodnik jest o tym jak znaleźć przejście z doświadczenia do bycia ekspertem. Bazuje on na szkole metodologii testowania "kierowania się kontekstem" (context-driven). Skupia się na tym co oznacza myśleć jak tester i jak projektować i krytykować praktyki testerskie (bardziej niż na tym aby po prostu kopiować co mówią wam "guru"). Pokażę wam także strategie samouczenia się i metody rozwoju sieci koleżeńskich. Jest to idealny kurs jeśli testowanie jest waszą karierą i zamierzacie się w nim doskonalić."
Bezpośredni link: http://video.google.com/videoplay?docid=6852841264192883219&pr=goog-sl
poniedziałek, 22 stycznia 2007
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:
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.
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:
- Naprawa nieistniejących defektów
- Poprawa funkcjonalności nie wymagających takowej poprawy
- Strata czasu inżynierów rozwoju oprogramowania
- Komplikowanie rozwiązań
- Utrata świadomości lub raczej wyczucia systemu
- 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.
piątek, 5 stycznia 2007
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:
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:
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.
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.
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?
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.
[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.
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.
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.
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.
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:
- trudności z zatrudnianiem studentów
- trudności z zatrudnianiem zewnętrznych konsultantów
- trudności z raportowaniem
- brak wymienności wykonawców testów
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 liderNie 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
Nominalna sekcja II opisuje techniki testowania białą skrzynką. Autor tutaj wymienia tylko dwie:
- testowanie kontroli przepływu
- testowanie przepływu danych
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.
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.
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...
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.
Subskrybuj:
Posty (Atom)