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".
wtorek, 19 listopada 2013
poniedziałek, 18 listopada 2013
IEEE 29119 - standard testowania oprogramowania
Na stronie http://www.softwaretestingstandard.org można znaleźć opis normy IEEE 29119 odnoszącej się do testowania oprogramowania w organizacjach. Od września 2013 jego trzy pierwsze części stanowią oficjalny dokument (na pewno ucieszy to sprzedawców certyfikatów).
Samego dokumentu niestety nie widziałem. Natomiast na wspomnianych stronach można znaleźć bardzo ciekawą specyfikację technik testowych (link). Moją ciekawość wzbudziła standaryzacja technika "Random testing" i "Error guessing".
Zastanawiające jest także dlaczego norma nie wymienia jako typu testów, testów regresyjnych. Znaleźć można natomiast "Conversion testing" co jest dla mnie nowością i nazwa nie mówi mi absolutnie nic. Łączę jednak intuicyjnie te testy z testami migracji danych.
Testy wydajnościowe i obciążeniowe zostały zgrupowane w "Performance-Related Testing," co nie ukrywam, ma w mojej ocenie swoją rację bytu. Ciekawy jestem również gdzie poukrywały się testy "high availability" i jakbym miał zgadywać to pewnie w "Disaster Recovery Testing".
W zakresie przypadków testowych, norma proponuje "Keyword-Driven Testing" co znaczy po polsku (tłumacząc ze strony):
Na koniec można się także dowiedzieć, że norma IEEE 29119 definiuje model oceny procesu testowania (Process Assessment Model for software testing) oparty o normę ISO/IEC 33063.
Osobiście bardzo się cieszę, że proces testów doczekał się osobnej standaryzacji. Jestem przekonany, że pomoże to różnym organizacjom we wdrażaniu systematycznego, jednolitego i skalowalnego procesu testów. Oczywiście warunkiem jest zachowanie testerskiego sceptycyzmu w stosunku do normy i zdrowego rozsądku w jej implementacji.
Samego dokumentu niestety nie widziałem. Natomiast na wspomnianych stronach można znaleźć bardzo ciekawą specyfikację technik testowych (link). Moją ciekawość wzbudziła standaryzacja technika "Random testing" i "Error guessing".
Zastanawiające jest także dlaczego norma nie wymienia jako typu testów, testów regresyjnych. Znaleźć można natomiast "Conversion testing" co jest dla mnie nowością i nazwa nie mówi mi absolutnie nic. Łączę jednak intuicyjnie te testy z testami migracji danych.
Testy wydajnościowe i obciążeniowe zostały zgrupowane w "Performance-Related Testing," co nie ukrywam, ma w mojej ocenie swoją rację bytu. Ciekawy jestem również gdzie poukrywały się testy "high availability" i jakbym miał zgadywać to pewnie w "Disaster Recovery Testing".
W zakresie przypadków testowych, norma proponuje "Keyword-Driven Testing" co znaczy po polsku (tłumacząc ze strony):
"Testowanie słowami kluczowymi (Keyword-Driven Testing) jest sposobem opisywania przypadków testowych wykorzystującym zawczasu przygotowany zestaw słów kluczowych. Są to nazwy zbiorów akcji, których wykonanie jest wymagane do realizacji konkretnego kroku przypadku testowego. Korzystanie ze słów kluczowych zamiast z języka naturalnego w opisywaniu kroków testowych powoduje ich łatwiejsze zrozumienie, utrzymanie i automatyzację".Trudno się nie zgodzić z takim twierdzeniem.
Na koniec można się także dowiedzieć, że norma IEEE 29119 definiuje model oceny procesu testowania (Process Assessment Model for software testing) oparty o normę ISO/IEC 33063.
Osobiście bardzo się cieszę, że proces testów doczekał się osobnej standaryzacji. Jestem przekonany, że pomoże to różnym organizacjom we wdrażaniu systematycznego, jednolitego i skalowalnego procesu testów. Oczywiście warunkiem jest zachowanie testerskiego sceptycyzmu w stosunku do normy i zdrowego rozsądku w jej implementacji.
środa, 13 listopada 2013
testowanie ET lub RST vs. złe testowanie
Na blogu Jamesa Bacha przeczytałem ciekawy wpis (http://www.satisfice.com/blog/archives/924) odnoszący się do administrowania w procesie testów. Od dawna mam wrażenie, że w wielu przypadkach idea "agile" jest nadużywana jako wymówka do braku dokumentacji. Brak dokumentacji zaś oznacza - po prostu - brak wiedzy i pomysłu na to w jaki sposób realizować testy.
Dokumentowanie samo w sobie jest po prostu praktycznym sposobem na przeżycie w projekcie. Nie spotkałem się z przypadkiem aby dokumentacja stanowiła słaby punkt. Problemem jest natomiast treść tej dokumentacji oraz oczekiwania z nią związane. Polecam lekturę!
* RST - Rapid Software Testing
** ET - Exploratory Testing
Dokumentowanie samo w sobie jest po prostu praktycznym sposobem na przeżycie w projekcie. Nie spotkałem się z przypadkiem aby dokumentacja stanowiła słaby punkt. Problemem jest natomiast treść tej dokumentacji oraz oczekiwania z nią związane. Polecam lekturę!
* RST - Rapid Software Testing
** ET - Exploratory Testing
wtorek, 5 listopada 2013
Przegląd narzędzi automatyzujących testy aplikacji na Androida.
Po linkiem http://blog.bughuntress.com/automated-testing/useful-tools-for-android-apps-test-automation można znaleźć, krótki przegląd narzędzi do testów aplikacji androidowych.
piątek, 14 czerwca 2013
Test czy nie test case
Od wielu lat mam szczęście pracować ze stałym zespołem ekspertów zajmujących się testowaniem oprogramowania. Oczywiście ludzie w zespole zmieniają się, jednak wiedza i doświadczenie powinny pozostać. Ta właśnie "krzywa uczenia się" jest największą korzyścią z utrzymywania takiego zespołu. Oczywiście obok wielu innych czynników, jak "kuźnia talentów" dla innych działów, elastyczność w realizacji zadań z różnych dziedzin, obsługa zdarzeń ad-hoc, itd.
Obecność stałego zespołu ekspertów pracujących dla klienta wewnętrznego, eliminuje w dużej części konieczność dokumentowania przypadków testowych. Zaznaczam, że przez przypadek testowy rozumiem pełną gębą procedurę ściśle opisującą co i jak (pisałem o tym między innymi tutaj lub tutaj).
Nie ma sensu przeznaczania cennego czasu inżyniera na opisywanie tego co będzie robił. Lepiej jest zachęcić go do zrobienia tego co zrobić ma. Z moich obserwacji wynika, że i tak większość testerów robi notatki i zapiski oraz stara się strukturalizować swoją pracę. Jedynie szczypiorniści w tym zawodzie mają tendencję do rzucania się na głęboką wodę. Ale i tutaj zespół przychodzi z pomocą i szybko wydobywa topielca z topieli problemu wskazując mu sposób na rozwiązanie problemu.
Bardzo pomocne przy tym trybie pracy są wszelkie listy kontrolne i heurystyki wspierające inżyniera w jego pracy. Dobrze jest aby takie narzędzia systematyzować i katalogować wewnątrz zespołu.
Problem szacowania, planowania i raportowania przeniosłem na poziom wymagań. Umożliwia mi to proces wytwarzania funkcjonujący w mojej firmie. Plan testów i raport z testów jest jedynym obowiązkowym dokumentem pracy testera/grupy testerów. Pozostałe elementy są opcjonalne.
Nie ma więc w tutaj przypadków testowych co nie znaczy, że jest bałagan. Formalizujemy te obszary, które podlegają częstej regresji. Te które jest sens automatyzujemy. Jednak w głównej mierze polegamy na znajomości środowiska, doświadczeniu i z własnych potrzeb wytworzonym na własny użytek narzędziach.
W zamian otrzymujemy elastyczność, niski nakład prac administracyjnych, jasny i prosty proces oraz - liczę na to - poczucie odpowiedzialności i autonomii.
Zilustruję to przykładem z niedalekiej przeszłości, kiedy w trybie awarii pojawiła się konieczność sprawdzenia sporego kawałka oprogramowania. Testy szacowaliśmy na dwa tygodnie dla 1 osoby. Harmonogram innych projektów nie pozwalał na zrobienie tego w wymaganym czasie. Podjęliśmy decyzję, że przez 1 dzień (8 godzin) cały zespół (8 osób) wykonana możliwe do wykonania testy. Proces rozdzielania pracy był bardzo krótki i polegał na "poborze ochotniczym". Jedna osoba zajęła się koordynowaniem prac aby się nie dublować.
Efekt był taki, że po przekazaniu na produkcję, awaria został zażegnana a inne defekty nie pojawiły się na w ten sposób przetestowanym releasie.
Obecność stałego zespołu ekspertów pracujących dla klienta wewnętrznego, eliminuje w dużej części konieczność dokumentowania przypadków testowych. Zaznaczam, że przez przypadek testowy rozumiem pełną gębą procedurę ściśle opisującą co i jak (pisałem o tym między innymi tutaj lub tutaj).
Nie ma sensu przeznaczania cennego czasu inżyniera na opisywanie tego co będzie robił. Lepiej jest zachęcić go do zrobienia tego co zrobić ma. Z moich obserwacji wynika, że i tak większość testerów robi notatki i zapiski oraz stara się strukturalizować swoją pracę. Jedynie szczypiorniści w tym zawodzie mają tendencję do rzucania się na głęboką wodę. Ale i tutaj zespół przychodzi z pomocą i szybko wydobywa topielca z topieli problemu wskazując mu sposób na rozwiązanie problemu.
Bardzo pomocne przy tym trybie pracy są wszelkie listy kontrolne i heurystyki wspierające inżyniera w jego pracy. Dobrze jest aby takie narzędzia systematyzować i katalogować wewnątrz zespołu.
Problem szacowania, planowania i raportowania przeniosłem na poziom wymagań. Umożliwia mi to proces wytwarzania funkcjonujący w mojej firmie. Plan testów i raport z testów jest jedynym obowiązkowym dokumentem pracy testera/grupy testerów. Pozostałe elementy są opcjonalne.
Nie ma więc w tutaj przypadków testowych co nie znaczy, że jest bałagan. Formalizujemy te obszary, które podlegają częstej regresji. Te które jest sens automatyzujemy. Jednak w głównej mierze polegamy na znajomości środowiska, doświadczeniu i z własnych potrzeb wytworzonym na własny użytek narzędziach.
W zamian otrzymujemy elastyczność, niski nakład prac administracyjnych, jasny i prosty proces oraz - liczę na to - poczucie odpowiedzialności i autonomii.
Zilustruję to przykładem z niedalekiej przeszłości, kiedy w trybie awarii pojawiła się konieczność sprawdzenia sporego kawałka oprogramowania. Testy szacowaliśmy na dwa tygodnie dla 1 osoby. Harmonogram innych projektów nie pozwalał na zrobienie tego w wymaganym czasie. Podjęliśmy decyzję, że przez 1 dzień (8 godzin) cały zespół (8 osób) wykonana możliwe do wykonania testy. Proces rozdzielania pracy był bardzo krótki i polegał na "poborze ochotniczym". Jedna osoba zajęła się koordynowaniem prac aby się nie dublować.
Efekt był taki, że po przekazaniu na produkcję, awaria został zażegnana a inne defekty nie pojawiły się na w ten sposób przetestowanym releasie.
wtorek, 28 maja 2013
"Nie chcę być członkiem klubu, który chce abym był jego członkiem"
Julius Henry "Groucho" Marx wśród wielu swoich powiedzonek ukuł jedno z moich ulubionych: "I don't want to belong to any club that will accept people like me as a member". Kiedy czytałem maila wysłanego do mnie z adresu "sjsi@sjsi.org" sparafrazowałem w głowie to powiedzenie w sposób następujący "Nie chcę być członkiem klubu, który chce abym był jego członkiem".
Przypuszczam, że list został wysłany przez "Stowarzyszenie Jakości Systemów Informatycznych". Piszę "przypuszczam" bo jest wiele powodów braku mojej pewności.
Poniżej przytaczam pełnego e-maila z wyjątkiem listy adresów e-mail, które SJSI raczyło mi dostarczyć.
Z drugiego akapitu maila dowiaduję się, że zostanę skreślony "z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia". Zajrzałem więc do tego dokumentu i dowiedziałem się, że zostanę usunięty z listy członków SJSI za "zachowanie nie licujące z godnością członka Stowarzyszenia lub sprzecznego z celami Stowarzyszenia".
I tak oto stanąłem przed logicznym problemem: jak mogę zostać usunięty z listy członków Stowarzyszenia, którego członkiem formalnie nie jestem. Ta zagadka mnie rozbawiła bo paradoksalnie wskazuje na bałagan i brak jakości w Stowarzyszeniu, którego statutowym celem jest jakość.
Ponieważ nie życzę sobie aby ktoś publicznie pomawiał mnie o brak godności i długi postanowiłem napisać ten wpis i email (wysłany osobno) do Komitetu Programowego protestując przeciwko takiemu prowadzeniu komunikacji.
Studiując listę adresów dostarczoną mi przez SJSI zorientowałem się, że jakość jest bardzo umowna w tym kręgu, gdyż ze składkami zalegają prezes i dwóch wiceprezesów co jest po prostu czymś obrzydliwym i wskazuje na zaistnienie okoliczności, w których wskazany przez Sekretarza Stowarzyszenia podpunkt 4, punktu 1 paragrafu 15 powinien znaleźć zastosowanie, w przypadku gdyby to nie były pomówienia lub pomyłka - jak to mówią „ryba psuje się od głowy”. Mam nadzieję, że to jednak jest pomyłka i przeoczenie wynikające z "ręcznej" pracy nad listą adresów.
To co mnie jeszcze uderzyło, to brak jednoznacznego wskazania skąd mail pochodzi. W adresie nadawcy jest SJSI. W stopce znajduje się także skrót SJSI rozwinięty jako „Polish Association of the International Software Testing Qualifications Board” a adres pocztowy podany jest w formacie angielskim. Jedyne wskazanie na wprost jest w postaci linka do statutu stowarzyszenia.
Jestem testerem oprogramowania z wieloletnim stażem i na co dzień wiem jak trudno jest zdefiniować jakość i jak łatwo jest ją "pogubić". Dumny jest z wykonywanego przeze mnie zawodu! Tym bardziej jest mi przykro, że Stowarzyszenie, które powstało w celu „wspierania członków Stowarzyszenia w zakresie edukacji dotyczącej testowania i zapewnienia jakości” poległo na tak prostej rzeczy i zapomniało o ludziach. A przecież jakość w systemach informatycznych istnieje przede wszystkim przez ludzi i dla ludzi – parafrazując kolejną postać historyczną.
Reasumując, bardzo się cieszę, że takie stowarzyszenie istnieje i stara się działać w zakresie jakości oprogramowania. Jednak namawiałbym członków i osoby odpowiedzialne za tę organizację aby mniej skupiali się na „sprzedaży słowników” – bo za coś takiego uważam ISTQB – a bardziej skoncentrowali się na realnych wyzwaniach i potrzebach w zakresie testów.
Testowanie oprogramowania – jako jedna z gałęzi informatyki – staje przed wieloma wyzwaniami. Jest coraz więcej platform mobilnych, coraz więcej urządzeń. Integracja oprogramowania i urządzeń postępuje bardzo szybko. Oczekiwania użytkowników rosną w miarę rozwoju – zwłaszcza w zakresie systemów czasu rzeczywistego lub „prawie rzeczywistego”. Funkcjonalność jest implementowana w coraz większym rozproszeniu. Coraz więcej oferowanych jest usług złożonych (np. w "chmurze").
Kilkuletnie doświadczenie z ISTQB wskazuje, że skupianie się na nazewnictwie artefaktów nie przyniesie tutaj żadnej ulgi a sprzedaż certyfikatów nie doprowadzi do rozwoju wiedzy i doświadczenia oraz umiejętności radzenia sobie z rosnącym skomplikowaniem rozwiązań informatycznych. Uważam, że zawód testera polega na umiejętności rozwiązywania problemów "testerskich" i ten kierunek sugerowałbym Stowarzyszeniu.
PS: Dzisiaj przyszedł z SJSI email w tonie bardziej pojednawczym wymuszonym, jak wynika z treści przez reakcję adresatów pierwotnej korespondencji.
Przypuszczam, że list został wysłany przez "Stowarzyszenie Jakości Systemów Informatycznych". Piszę "przypuszczam" bo jest wiele powodów braku mojej pewności.
Poniżej przytaczam pełnego e-maila z wyjątkiem listy adresów e-mail, które SJSI raczyło mi dostarczyć.
Od: Komitet programowyCzłonkiem stowarzyszenia zostałem bardzo dawno temu. Dokładnej daty nie pamiętam ale z całą pewnością było to przed rokiem 2008. Po zapłaceniu pierwszej składki w wysokości - chyba - 50 złotych - i rocznej hibernacji stwierdziłem, że nie chcę być członkiem stowarzyszenia. W statucie przeczytałem, że jeśli nie zapłacę następnej składki to po prostu zostanę usunięty z listy członków po dwóch latach (Paragraf 15, pkt.1, ppkt.3). A więc efektywnie od roku 2011 formalnie i zgodnie ze statutem nie byłem członkiem Stowarzyszenia. Niestety nie pamiętam czy podejmowałem próby rezygnacji w trybie paragraf 15, pkt. 1, ppkt. 1 więc się na to nie powołuję.
Data: 27 maja 2013 14:23
Temat: Zaległe składki SJSI
Do: (jawna lista adresów email wycięta przez TZ)
W chwili obecnej SJSI posiada w swoich strukturach wielu nieaktywnych członków zwyczajnych (osoby nie uczestniczą w pracach SJSI, nie płacą składki członkowskiej, nie ma z nimi kontaktu - dane kontaktowe są nieaktualne). Na spotkaniu Zarządu SJSI, które miało miejsce w Łodzi w dniu 2013.03.23, podjęto decyzję o uporządkowaniu listy członków zwyczajnych.
Do wszystkich członków SJSI zwracamy się zatem z prośbą o uregulowanie składki członkowskiej za rok 2013, co rozumiemy jako chęć pozostania w strukturach Stowarzyszenia. Osoby, które tej składki nie uregulują do końca maja 2013, oraz nie zapłaciły jej w latach 2011-2012 zostaną skreślone z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia.
Przydatne odnośniki:
- Statut Stowarzyszenia Jakości Systemów Informatycznych
- Dane do przelewu
Sebastian Małyska
Member of SJSI Board
e: s.malyska@sjsi.org | skype: sebam6
SJSI – Polish Association of the International Software Testing
Qualifications Board
Str. Poznanska 16 (r. 4), 00-680 Warsaw, Poland
http://www.sjsi.org
Z drugiego akapitu maila dowiaduję się, że zostanę skreślony "z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia". Zajrzałem więc do tego dokumentu i dowiedziałem się, że zostanę usunięty z listy członków SJSI za "zachowanie nie licujące z godnością członka Stowarzyszenia lub sprzecznego z celami Stowarzyszenia".
I tak oto stanąłem przed logicznym problemem: jak mogę zostać usunięty z listy członków Stowarzyszenia, którego członkiem formalnie nie jestem. Ta zagadka mnie rozbawiła bo paradoksalnie wskazuje na bałagan i brak jakości w Stowarzyszeniu, którego statutowym celem jest jakość.
Ponieważ nie życzę sobie aby ktoś publicznie pomawiał mnie o brak godności i długi postanowiłem napisać ten wpis i email (wysłany osobno) do Komitetu Programowego protestując przeciwko takiemu prowadzeniu komunikacji.
Studiując listę adresów dostarczoną mi przez SJSI zorientowałem się, że jakość jest bardzo umowna w tym kręgu, gdyż ze składkami zalegają prezes i dwóch wiceprezesów co jest po prostu czymś obrzydliwym i wskazuje na zaistnienie okoliczności, w których wskazany przez Sekretarza Stowarzyszenia podpunkt 4, punktu 1 paragrafu 15 powinien znaleźć zastosowanie, w przypadku gdyby to nie były pomówienia lub pomyłka - jak to mówią „ryba psuje się od głowy”. Mam nadzieję, że to jednak jest pomyłka i przeoczenie wynikające z "ręcznej" pracy nad listą adresów.
To co mnie jeszcze uderzyło, to brak jednoznacznego wskazania skąd mail pochodzi. W adresie nadawcy jest SJSI. W stopce znajduje się także skrót SJSI rozwinięty jako „Polish Association of the International Software Testing Qualifications Board” a adres pocztowy podany jest w formacie angielskim. Jedyne wskazanie na wprost jest w postaci linka do statutu stowarzyszenia.
Jestem testerem oprogramowania z wieloletnim stażem i na co dzień wiem jak trudno jest zdefiniować jakość i jak łatwo jest ją "pogubić". Dumny jest z wykonywanego przeze mnie zawodu! Tym bardziej jest mi przykro, że Stowarzyszenie, które powstało w celu „wspierania członków Stowarzyszenia w zakresie edukacji dotyczącej testowania i zapewnienia jakości” poległo na tak prostej rzeczy i zapomniało o ludziach. A przecież jakość w systemach informatycznych istnieje przede wszystkim przez ludzi i dla ludzi – parafrazując kolejną postać historyczną.
Reasumując, bardzo się cieszę, że takie stowarzyszenie istnieje i stara się działać w zakresie jakości oprogramowania. Jednak namawiałbym członków i osoby odpowiedzialne za tę organizację aby mniej skupiali się na „sprzedaży słowników” – bo za coś takiego uważam ISTQB – a bardziej skoncentrowali się na realnych wyzwaniach i potrzebach w zakresie testów.
Testowanie oprogramowania – jako jedna z gałęzi informatyki – staje przed wieloma wyzwaniami. Jest coraz więcej platform mobilnych, coraz więcej urządzeń. Integracja oprogramowania i urządzeń postępuje bardzo szybko. Oczekiwania użytkowników rosną w miarę rozwoju – zwłaszcza w zakresie systemów czasu rzeczywistego lub „prawie rzeczywistego”. Funkcjonalność jest implementowana w coraz większym rozproszeniu. Coraz więcej oferowanych jest usług złożonych (np. w "chmurze").
Kilkuletnie doświadczenie z ISTQB wskazuje, że skupianie się na nazewnictwie artefaktów nie przyniesie tutaj żadnej ulgi a sprzedaż certyfikatów nie doprowadzi do rozwoju wiedzy i doświadczenia oraz umiejętności radzenia sobie z rosnącym skomplikowaniem rozwiązań informatycznych. Uważam, że zawód testera polega na umiejętności rozwiązywania problemów "testerskich" i ten kierunek sugerowałbym Stowarzyszeniu.
PS: Dzisiaj przyszedł z SJSI email w tonie bardziej pojednawczym wymuszonym, jak wynika z treści przez reakcję adresatów pierwotnej korespondencji.
środa, 15 maja 2013
Zarządzanie zadaniami w arkuszu kalkulacyjnym
Moje środowisko pracy jest wieloprojektowe. Rodzi to konieczność radzenia sobie z kilkoma projektami na raz. Poniżej chciałem przedstawić i zaproponować prosty sposób w jaki ja staram się kontrolować i planować zadania w przecięciu na osoby i zasoby.
Korzystam w tym celu z arkusza kalkulacyjnego wyprodukowanego przez amerykańskiego potentata ale jestem przekonany, że taki sam efekt można osiągnąć korzystając z produktów innych producentów.
Arkusz składa się z trzech zasadniczych arkuszy:
Na początku potrzebne są pewne nakłady pracy ale dzięki temu uzyskujemy elastyczne narzędzie do planowania.
W komórce "B2" należy wpisać datę początkową. Ponieważ w moim wypadku datą przecięcia jest 1 stycznia to wpisuję jako datę początkową, poniedziałek ostatniego pełnego tygodnia grudnia - aby uzyskać pewien margines.
Następnie ciągnę komórkę aby uzyskać dzienne daty z całego roku. Korzystając z funkcji "DZIEN.TYG" oznaczam weekendy i dopisuję numery poszczególnych tygodni. Nie należy zapominać także o świętach. Jest to praca, którą rutynowo wykonuję na początku roku.
W pierwszej kolumnie wypisuję nazwiska osób. Można także wypisać środowiska testowe. Od tego momentu korzystam z elementów graficznych nazwanych "smartArt" ale równie dobrze mogą to być standardowe kształty. Przypisując zadanie do osoby ustawiam tak kształt aby jego początek zaczynał się pierwszego dnia aktywacji a koniec ostatniego. Następnie można skopiować kształt i ustawić go na środowisku także w odpowiednich ramach czasowych.
W przykładzie poniżej tego nie widać, ale ja używam czterech różnych kolorów na oznaczenia różnych klas aktywności. Wizualnie wyodrębniają mi one:
Ten arkusz wykorzystuję do celów komunikacyjnych w rozmowach z innymi osobami lub działami, planując przyszłe zadania, pokazując status bieżący czy po prostu przygotowując plan prac na nadchodzący tydzień.
Dodatkowo, korzystając z mechanizmów automatyzujących (VBA) można użyć tego arkusza do bardziej wyrafinowanych celów. W moim przypadku najbardziej przydatne funkcje to:
Korzystam w tym celu z arkusza kalkulacyjnego wyprodukowanego przez amerykańskiego potentata ale jestem przekonany, że taki sam efekt można osiągnąć korzystając z produktów innych producentów.
Arkusz składa się z trzech zasadniczych arkuszy:
- arkusz "Ewidencja projektów"
- arkusz "Ludzie i zasoby"
- arkusz "Plan gry"
Arkusz "Ewidencja projektów"
Jest to prosta lista projektów wraz z parametrami takimi jak:- osoba odpowiedzialna za projekt
- szacowana pracochłonność w osobodniach
- testerzy przypisani do projektu
- rekomendacja wdrożeniowa
- testowy cykl życia
Ostatnia pozycja odzwierciedla aktualny etap, na którym - z perspektywy procesu testów - znajduje się projekt. Może to być, planowanie, wykonanie lub zakończenie.
Ostatni etap okazuje się szczególnie "kłopotliwy". Zasada ogólna jest taka, że testy kończą się wraz z wygenerowaniem raportu końcowego. Raport końcowy zaś może być wygenerowany po kompletnym zakończeniu testów rozumianym jako zrealizowanie wszelkich rozpoznanych zadań testowych. W efekcie drobne zadanie, które może być zrealizowane dopiero po uruchomieniu całego projektu może "zablokować" raport końcowy. Dlatego zdecydowałem się na wprowadzenie dwóch raportów końcowych; wstępnego i końcowego.
Raport wstępny, jest dostępny po realizacji zasadniczej części testów, tuż przed "wdrożeniem". Tak jak raport końcowy, zawiera on rekomendację wdrożeniową ale zawiera także informacje o tym co pozostaje do zrobienia. Raport końcowy przygotowywany jest po definitywnym ukończeniu aktywności testowych.
Na marginesie zaznaczę, że "układanie" cyklu życia testów najlepiej jest zacząć od przyjętego modelu a następnie modyfikować go do zastanych potrzeb. Wprowadzenie cyklu życia testów wymaga także zmian po stronie innych partnerów. To z kolei modyfikuje sam proces testowy co właśnie wymusza iteracyjność procesu wdrażania cyklu życia testów.
Obrazek poniżej pokazuje wyimaginowany cykl życia testów.
Tutaj znajduje się zasadnicza część i stąd wynikaja główna korzyść: łatwy dostęp do informacji umożliwiającej planowanie i przeplanowywanie zadań testowych w zależności od oczekiwań developmentu bądź "biznesu". Z założenia jest to informacja szacunkowa. Nie wierzę w planowanie pracy członkom zespołu w godzinach.Raport wstępny, jest dostępny po realizacji zasadniczej części testów, tuż przed "wdrożeniem". Tak jak raport końcowy, zawiera on rekomendację wdrożeniową ale zawiera także informacje o tym co pozostaje do zrobienia. Raport końcowy przygotowywany jest po definitywnym ukończeniu aktywności testowych.
Na marginesie zaznaczę, że "układanie" cyklu życia testów najlepiej jest zacząć od przyjętego modelu a następnie modyfikować go do zastanych potrzeb. Wprowadzenie cyklu życia testów wymaga także zmian po stronie innych partnerów. To z kolei modyfikuje sam proces testowy co właśnie wymusza iteracyjność procesu wdrażania cyklu życia testów.
Obrazek poniżej pokazuje wyimaginowany cykl życia testów.
 |
| Przykład struktury arkusza "Ewidencja" |
Arkusz "Ludzie i zasoby"
Na początku potrzebne są pewne nakłady pracy ale dzięki temu uzyskujemy elastyczne narzędzie do planowania.
W komórce "B2" należy wpisać datę początkową. Ponieważ w moim wypadku datą przecięcia jest 1 stycznia to wpisuję jako datę początkową, poniedziałek ostatniego pełnego tygodnia grudnia - aby uzyskać pewien margines.
Następnie ciągnę komórkę aby uzyskać dzienne daty z całego roku. Korzystając z funkcji "DZIEN.TYG" oznaczam weekendy i dopisuję numery poszczególnych tygodni. Nie należy zapominać także o świętach. Jest to praca, którą rutynowo wykonuję na początku roku.
W pierwszej kolumnie wypisuję nazwiska osób. Można także wypisać środowiska testowe. Od tego momentu korzystam z elementów graficznych nazwanych "smartArt" ale równie dobrze mogą to być standardowe kształty. Przypisując zadanie do osoby ustawiam tak kształt aby jego początek zaczynał się pierwszego dnia aktywacji a koniec ostatniego. Następnie można skopiować kształt i ustawić go na środowisku także w odpowiednich ramach czasowych.
W przykładzie poniżej tego nie widać, ale ja używam czterech różnych kolorów na oznaczenia różnych klas aktywności. Wizualnie wyodrębniają mi one:
- duże projekty
- małe zadania wspierające dewelopment lub testy ad hoc
- szkolenia i inne wydarzenia
- urlopy
 |
| Arkusz monitorujący ludzi i zasoby w czasie |
Ten arkusz wykorzystuję do celów komunikacyjnych w rozmowach z innymi osobami lub działami, planując przyszłe zadania, pokazując status bieżący czy po prostu przygotowując plan prac na nadchodzący tydzień.
Arkusz "Plan gry"
Ten arkusz służy mi do komunikacji z najbliższym otoczeniem. Przygotowuję tutaj listę zadań przypisanych do osób i wysyłam do zainteresowanych (głównie mój zespół, inni kierownicy oraz dyrekcja). Przydzielam także procentowo czas. 20% oznacza 1 dzień roboczy. Jest to wartość umowna pozwalająca przyjąć moim współpracownikom pewne założenia co do organizacji tygodnia pracy.
Pozycja "Urlopy/Święta" oraz "Zasoby" jest stała i pozwala mi alokować czas odpowiednio albo dla nieobecności albo dla zadań typu ad hoc (np. szybkie testy fixów). Staram się też regularnie przeznaczać pewien czas w tygodniu na aktywność nazywaną "wsparciem developmentu". Jest to rodzaj dyżuru. W ramach tej aktywności, przypisana osoba ma za zadanie obsługiwanie małych zadań testowych, których potrzebę doraźnie zgłasza development.
Ukrywając przemijające tygodnie jestem w stanie wysłać prostą tabelkę, pokazującą plan prac per osoba z obciążeniem. Pozwala też na dystrybucję informacji o dostępności poszczególnych ludzi.
Podsumowanie
Podejście przedstawione powyżej wypracowywałem w różnych wariantach przez parę lat. Dla obecnej organizacji i w obecnym trybie pracy wydaje się to wystarczające do realizacji potrzeby planowania, uzgadniania i kontrolowania przepływu pracy.Dodatkowo, korzystając z mechanizmów automatyzujących (VBA) można użyć tego arkusza do bardziej wyrafinowanych celów. W moim przypadku najbardziej przydatne funkcje to:
- Automatyczne monitorowanie czasu
Za każdym razem kiedy w arkuszu ewidencji projektów zmieniam status projektu, w odpowiednich komórkach skrypt VBA wpisuje datę tej zmiany. Pozwala to na zbieranie danych statystycznych pomocnych przy szacowaniu pracochłonności. Mając informację ile średnio zajmuje planowanie i wykonanie jestem w stanie dostarczać prawdziwych szacunków. - Generowanie zadań w Outlooku
Jeszcze do niedawna wykorzystywałem funkcjonalność Outlooka do przydzielania zadań do wykonania. Stworzyłem dodatkowy arkusz, w którym z przygotowywałem spis zadań dla każdego członka zespołu. Taką informację wysyłam do wszystkich zainteresowanych (development, produkcja, zarządzanie produktem).
Następnie stworzyłem macro, które szczytuje wszystkie zadania razem z osobą odpowiedzialną. To samo macro odwołuje się do macra odpowiedzialnego za utworzenie obiektu zadanie w Outlooku. W ten sposób bardzo szybko jestem w stanie generować zadania dla zespołu. - Synchronizowania listy aktywnych projektów pomiędzy arkuszem "Ewidencja projektów" a "Plan gry".
Główną wadą tego rozwiązania jest brak możliwości współdziałania grupowego. Jednak nie taki miał być zasadniczy cel i jak wspomniałem poszczególne zadania definiowane są w systemie zewnętrznym. Aby jednak umożliwić dostęp on-line zainteresowanym, wygospodarowałem w infrastrukturze firmy miejsce na wewnętrznym serwerze www i tam publikuję aktualną wersję tego pliku. Korzystam z wbudowanego mechanizmu, który przy każdym zapisaniu pliku publikuje mi jego wersję na serwer www.
Informacje o tym jak skorzystać z tego mechanizmu, można uzyskać w wbudowanym systemie pomocy, wyszukując frazę "Zapisywanie całości lub części skoroszytu w statycznej stronie sieci Web".
wtorek, 30 kwietnia 2013
Forum jakości systemów informatycznych
Sześć firm i organizacji zajmujących się jakością systemów informatycznych w Polsce organizuje "Forum jakości systemów informatycznych". Wydarzenie odbędzie się pomiędzy 21 a 22 maja 2013 roku w hotelu "Courtyard by Marriott Warsaw Airport" w Warszawie. Pełna informacja dostępna jest pod linkiem http://www.computerworld.pl/konferencja/jakosc2013.
Pierwszy dzień konferencji podzielony został na dwie części: sesję plenarną oraz dwie sesje tematyczne. Sesje tematyczne zajmują się albo zarządzaniem jakością albo zarządzaniem projektem (nie wiem dlaczego organizatorzy zdecydowali się nazwać to z angielska "project management"?) pochylając się następnie nad samym testowania.
Zamknięcie dnia planowane jest 50 minutową dyskusją na temat "Jakość w świecie IT - ideał i cel czy tylko pusty slogan?"
Drugi dzień zaczyna się od sesji plenarnej aby około południa przerodzić się w warsztaty.
Tematyka wydaje się bardzo szeroka, od standardów poprzez metodyki testowania i zapewniania jakości, po zagadnienia związane z przywództwem i rynkiem pracy.
Zdecydowanie jest to inicjatywa, którą warto popierać. Wydarzenia tego typu sprzyjają poszerzaniu wiedzy, zbieraniu inspiracji i weryfikowaniu własnych przekonań zawodowych. I chyba nie jest łatwo zorganizować takie spotkanie (nawet w tej chwili cztery prezentacje mają jeszcze nieustaloną tematykę).
Życzę organizatorom i prelegentom sukcesu i mam nadzieję, że wydarzeń tego typu będzie pojawiać się w Polsce więcej. Może pora uświadomić sobie, że testowanie nie jest oddzielnym "kościołem" ale jednym z etapów łańcucha wytwórczego oprogramowania a zapewnianie i zarządzanie jakością jednym z koniecznych instrumentów pozwalających zapewnić firmom świadome dostarczanie produktu a klientom realizację ich wymagań.
Pierwszy dzień konferencji podzielony został na dwie części: sesję plenarną oraz dwie sesje tematyczne. Sesje tematyczne zajmują się albo zarządzaniem jakością albo zarządzaniem projektem (nie wiem dlaczego organizatorzy zdecydowali się nazwać to z angielska "project management"?) pochylając się następnie nad samym testowania.
Zamknięcie dnia planowane jest 50 minutową dyskusją na temat "Jakość w świecie IT - ideał i cel czy tylko pusty slogan?"
Drugi dzień zaczyna się od sesji plenarnej aby około południa przerodzić się w warsztaty.
Tematyka wydaje się bardzo szeroka, od standardów poprzez metodyki testowania i zapewniania jakości, po zagadnienia związane z przywództwem i rynkiem pracy.
Zdecydowanie jest to inicjatywa, którą warto popierać. Wydarzenia tego typu sprzyjają poszerzaniu wiedzy, zbieraniu inspiracji i weryfikowaniu własnych przekonań zawodowych. I chyba nie jest łatwo zorganizować takie spotkanie (nawet w tej chwili cztery prezentacje mają jeszcze nieustaloną tematykę).
Życzę organizatorom i prelegentom sukcesu i mam nadzieję, że wydarzeń tego typu będzie pojawiać się w Polsce więcej. Może pora uświadomić sobie, że testowanie nie jest oddzielnym "kościołem" ale jednym z etapów łańcucha wytwórczego oprogramowania a zapewnianie i zarządzanie jakością jednym z koniecznych instrumentów pozwalających zapewnić firmom świadome dostarczanie produktu a klientom realizację ich wymagań.
niedziela, 21 kwietnia 2013
Testowanie dokumentacji (nowa wersja mniejsza)
Kilka dni temu, na portalu testerzy.pl pojawiła się nowa wersja (link tutaj) mojego starego posta (link tutaj) na temat konieczności testowania dokumentacji.
wtorek, 16 kwietnia 2013
Plan minimum
Postanowiłem spróbować ponownie uregulować tego bloga... sformułowałem plan minimum. Co najmniej 6 wpisów na rok... . Co pokaże rzeczywistość...? To się okaże.
Tak czy inaczej postanowiłem przekreślić zawieszenie co uczyniłem w nagłówku tego bloga.
Pozdrawiam serdecznie wszystkich wytrwałych i przygodnych czytelników.
Tak czy inaczej postanowiłem przekreślić zawieszenie co uczyniłem w nagłówku tego bloga.
Pozdrawiam serdecznie wszystkich wytrwałych i przygodnych czytelników.
środa, 3 kwietnia 2013
Czy to już Ameryka czy jeszcze Indie czyli słów kilka o śledzeniu pokrycia testowego.
Artykuł ten oryginalnie pojawił się na stronie microtest.pl. Następnie zwrócił się do mnie portal z testerzy.pl czy nie byłbym zainteresowany ponowną publikacją tego artykułu. Po drobnych zmianach i korektach edytorskich ze strony portalu zdecydowałem się na opublikowanie wersji drugiej tego artykułu zarówno na testerzy.pl jak i na tym blogu.
Projekt informatyczny przypomina trochę – nie będę oryginalny – wyprawę żaglowcem przez morza i oceany. Poza celem podróży, większość rzeczy jest nieznana; pogoda, aktualność map, czego oczekiwać na miejscu, itp. Co najgorsze, nie wiemy po czym poznać, czy to już Indie czy Ameryka. Tak na marginesie dodam, Karol Olgierd Borchardt w znakomitej książce „Znaczy kapitan” kilkakrotnie wyjaśniał przyczyny, dla których na żaglowcach nazwę portu przeznaczenia wpisywało się w dzienniku pokładowym po osiągnięciu tego portu.
Właśnie ten "syndrom wyprawy Kolumba", który chciał dotrzeć do Indii a odkrył Amerykę, należy – moim zdaniem – do największych wyzwań w projektach IT. Dzieje się tak przede wszystkim ze względu na materię. Nie jest ona fizyczna i mierzalna więc jedynym sposobem zweryfikowania, czy jesteśmy w "Indiach" czy w "Ameryce", jest weryfikacja pośrednia.
Wiele jest metodyk umożliwiających weryfikację. W tym miejscu jednak, chciałbym uciec do dyskusji o szkołach i wyższości jednych świąt nad drugimi. Chcę zastanowić się nad uzasadnieniem tezy, że warto jest w testach śledzić pokrycie wymagań oraz zaproponować pewien prosty mechanizm.
Z ogólnie pojętych względów „higienicznych” zakładam, że proces testów jest uruchamiany możliwie najwcześniej. Zakładam też – na użytek tego tekstu – że sama jakość pokrycia wymagań przypadkami testowymi - ergo jakość testów - zależy zarówno od jakości samych wymagań, jak również od kunsztu testera projektującego przypadki testowe. A więc odbijamy...
Po co nam mapa... to znaczy po co śledzić pokrycie wymagań? Tak naprawdę udało mi się zidentyfikować dwa twarde cele. Pierwszy i zasadniczy to zapewnienie, że komplet wymagań zostanie przetestowany. Jeśli wykonanie testów ma nam dowieść, że oprogramowanie, które otrzymaliśmy, jest tym, które zamawialiśmy, to ta metoda wydaje się jedną z najbardziej rozsądnych.
Drugim celem wynikającym pośrednio z pierwszego jest przygotowanie i zaprojektowanie przypadków testowych. Tutaj skłaniam się do opinii mówiącej, że dopóki faza projektowania testów nie zostaje osadzona w kontekście konkretnych wymagań, dopóty projektowanie przypadków opiera się o ogólne pojęcie na temat "co to ma robić".
Z drugiej strony można pokusić się o tezę, że jeśli wymagania na oprogramowanie wyczerpują istniejące i nowe ale zdefiniowane procesy biznesowe, to testując te procesy jednocześnie weryfikujemy poprawność dostawy. Moim zdaniem sposób ten nie jest lepszy. Procesy biznesowe są czymś żywym, co nie zawsze odzwierciedla pierwotne oczekiwania i założenia.
Przy zderzeniu z oprogramowaniem „obsługującym” ten proces takie zjawiska trudno przyporządkować do kategorii błędów procesu lub oprogramowania.
Rynek oprogramowania komercyjnego, jak również społeczność oprogramowania wolnego, oferuje przeróżne mechanizmy śledzenia pokrycia. Od prostego pliku tekstowego, przez pakiety biurowe typu arkusz kalkulacyjny, po zaawansowane systemy do zarządzania wymaganiami lub testami, aż po wielkie kombajny do zarządzania całymi procesami wytwórczymi.
Czegokolwiek byśmy nie użyli, w początkowej fazie i tak wszystko opiera się na deklaracji człowieka, że dany przypadek testowy pokrywa dane wymaganie. Żaden system informatyczny na świecie nie potrafi odpowiedzieć na to pytanie sam z siebie. Potrafi natomiast ostrzec nas jeśli zmieni się cokolwiek w jednym lub drugim bycie, wpływając na relację między przypadkiem a wymaganiem, co znakomicie ułatwia pracę.
W takiej sytuacji wielokrotnie sprawdziła się matryca przygotowana w arkuszu kalkulacyjnym, którą nazywam RTM, od angielskiego Requirements Traceability Matrix. Zakładając, że wymagania są spisane w jakiejkolwiek formie, proces przygotowania można przedstawić w następujących krokach:
- Wierne przekopiowanie treści wymagań do drugiej kolumny arkusza. Staram się w tym kroku dzielić wymagania na "atomowe" porcje rokujące szanse na możliwość indywidualnego przetestowania. Staram się także zachować strukturę nagłówków w dokumencie źródłowym.
- Każdemu wierszowi nadaję unikalny identyfikator umieszczony w pierwszej kolumnie.
- Oznaczam te wpisy, których nie da się przetestować. Z reguły są to tytuły rozdziałów, opisy otoczenia, itp.
- Organizuję sobie cykl życia... czyli po prostu robię założenie, że pojedyncze wymaganie może być w jednym ze zdefiniowanych z góry statusów wpisanych do trzeciej kolumny, np.:
- Nie testowalne - opisane powyżej
- Nie pokryte - wymaganie wymaga testowania, ale nie ma żadnego przypadku, który by je pokrywał
- Pokryte - istnieje przynajmniej jeden przypadek testowy, sprawdzający ten konkretny zapis
- Poza zakresem - wymaganie zostało "wyjęte" z zakresu projektu
- Zostawiam miejsce na dane statystyczne.
- W pierwszym wolnym wierszu wolnej kolumny zaczynam wpisywać identyfikatory przypadków. Na skrzyżowaniu przypadku z wymaganiem stawiam literę:
- "P", oznaczający, iż ten przypadek pokrywa to konkretne wymaganie testem pozytywnym
- „N”, oznaczający, iż ten przypadek pokrywa to konkretne wymaganie testem negatywnym
Przygotowanie, a potem utrzymanie takiego pliku, wymaga pracy i cierpliwości, dlatego nie zawsze przygotowanie takiego dokumentu ma sens. Mi udało się określić kilka uzasadniających zastosowanie RTM okoliczności:
- warto to zrobić na zatwierdzonej i ostatecznej wersji wymagań. Inaczej nieustannie będziemy musieli przerabiać nasz plik, a kontrola "zmian do zmian" jest zawsze trudna
- aby ten mechanizm był adekwatny, musi istnieć oficjalny mechanizm kontroli zmian, dostarczający informacji co i jak się zmieniło na poziomie wymagań
- zdecydowanie nie warto stosować RTM jeśli zakres projektu nie jest szeroki i np. da się go przetestować testami regresyjnymi lub mechanizmem "Test to fail"
- nie istnieje bezpośrednia komunikacja pomiędzy dostawcą i odbiorcą oprogramowania i propagacja zmian wymagań jest powolna
Innym oczywistym celem jest kontrolowanie zawartości dostaw. W tym aspekcie przydatność tego mechanizmu jest nieoceniona. Pozwala sprowadzić wszelkie dyskusje o tzw. ograniczeniach technologicznych, projektowych, itp. do twardych konkretów, gdzie podjecie decyzji skojarzone jest z konkretną zmianą i ewentualnym ubytkiem funkcjonalności.
Odseparowanie poszczególnych wymagań ułatwia także wyłowienie tych uwarunkowań, które wymagają testów negatywnych. Testów, które czasami postrzegane są jako nadmiarowe lub zbędne, a które również pozwalają dowieść, że jesteśmy w Indiach a nie w Ameryce.
Konsekwencją pożytków wymienionych powyżej jest ogromne ułatwienie pozwalające kontrolować ekonomię testów, czyli dobrać w efekcie tyle przypadków testowych, ile jest niezbędne do zbadania danego zakresu. Pozwala na bardziej dokładne planowanie.
Inną zaletą rozebrania tekstu wymagań na czynniki pierwsze jest ujawnienie nieścisłości, dwuznaczności lub rozbieżności, które w inny sposób trudniej wychwycić. To z kolei pozwala na przygotowanie wkładu do wymagań od strony jakości. Z tej też przyczyny, uważam, że rozpoczęcie fazy analizy testowej wymagań powinno zacząć się niezwłocznie po ich zatwierdzeniu.
"Światek IT" do znudzenia powtarza tezę, że defekt wcześnie wykryty jest tańszy w naprawie, niż defekt wykryty późno. Śledzenie wymagań także w tym przypadku przychodzi nam z pomocą. Mając informację o tym, co jest pokryte przez przypadki testowe, i które z tych przypadków zostały wykonane z jakim wynikiem - możemy podjąć decyzję, czy dana dostawa spełnia wymagania akceptacji. Jeśli pokrycie jest kiepskie ze względu na zakres lub wyniki wykonania, to łatwo jest dowieść, że nie spełnia ona kryteriów akceptacji. Pozwala to uniknąć zjawiska, które nazywam "eksplozją dostawy", polegającym na „objawieniu się” dużej liczby defektów o wysokiej ważności na poziomie testów akceptacyjnych będących z reguły testami biznesowymi.
W dzisiejszych czasach coraz częściej liczy się koszty. Także w przypadku procesu śledzenia pokrycia one się pojawiają. Przede wszystkim będzie potrzebny czas projektowy dla przygotowania, realizacji i utrzymania takiej procedury. Dotyczy to również zasobów projektowych.
Jeśli z góry wiemy, że mechanizm RTM nie będzie wykorzystywany w dalszych etapach projektu, należy zaniechać go w ogóle. Przestarzała i nieaktualna informacja o pokryciu może stać się bardziej niebezpieczna niż jej brak. Z drugiej strony, aktualizacja takiej informacji wymaga nieustannego śledzenia zmian pochodzących z wszelkich możliwych źródeł (klient, development, zarząd, kierownik projektu, itp).
Nie oceniłbym śledzenia pokrycia jako procesu istotnego z punktu widzenia projektu, jednak jest niezwykle istotny z punktu widzenia ścieżki testowej. Samo śledzenie nie zapewni nam wysokiej jakości w poszczególnych wydaniach. Należy pamiętać, że śledzenie pokrycia odbywa się na linii rezultat oczekiwany w postaci kodu programu komputerowego a zasięg testów. W żaden sposób nie sięga do sposobu i zakresu implementacji, a tym bardziej do sposobu w jaki przygotowane będą testy.
A więc nadal – chcąc przetestować rozwiązanie – potrzebni nam będą wykwalifikowani testerzy z dostępem do wiedzy i dokumentacji oraz wszelkie narzędzia i metody konstruowania poprawnych testów.
Mechanizm RTM nie przyniesie nam także oszczędności w samym projekcie - przynajmniej na początku. Jednak w fazie wykonania testów pozwala ograniczyć zakres wykonywanych testów do niezbędnego minimum, uwzględniając przy tym testy negatywne.
To może - skoro próba śledzenia pokrycia jest tak mozolna - lepiej zrezygnować z takiej metody? Ta decyzja z pewnością otwiera przed nami inny zestaw możliwości definicji pokrycia, o których tutaj nie będziemy szerzej mówić (np. definiowanie zakresu jako zbioru procesów biznesowych (przydatne na końcowym etapie ATP), testy "end-to-end" weryfikujące tylko wejście i wyjście, itp.).
Przy takim jednak podejściu mam wrażenie, sama ekonomia testów jest zagrożona ze względu na ryzyko nadmiarowych lub brakujących przypadków testowych.
Śledzenie pokrycia zdaje mi się także odporne na generowanie fałszywych przypadków - oczywiście przy założeniu, że zajmuje się tym zawodowy tester.
Szczególnie groźna jawi mi się w tym aspekcie tendencja do testowania wymagań całościowo. Zdarzało mi się spotykać wymagania, które brzmiały w sposób następujący "Codzienna sprzedaż kontrolowana będzie raportem". Ponadto brakowało jakiejkolwiek wzmianki na temat tego, jakie informacje mają znajdować się w raporcie, z jakich danych ma korzystać ten raport, jakie są stosowane agregacje, itp. Co gorsze, zadając te pytania ludziom odpowiedzialnym za projekt, widziałem po ich reakcji, że nie widzą w braku tych informacji, żadnego powodu do zmartwienia. Taki drobny brak umknął w dyskusji o bardziej istotnych funkcjonalnościach, co jest naturalne.
Rezygnacja ze śledzenia pokrycia przynosi z drugiej strony korzyści takie jak zaoszczędzenie na zasobach i czasie projektu w obrębie danej fazy projektu. Otwartym pozostaje pytanie, co z takimi oszczędnościami dzieje się w następnych częściach projektu.
Rezygnacja ze mechanizmu RTM w żaden sposób nie eliminuje możliwości przetestowania danego rozwiązania, gdyż nadal dysponujemy innymi metodami szacowania zakresu i weryfikowania dostaw.
Jak wspomniałem powyżej, wyzwaniem w tym mechanizmie wydaje się śledzenie zmian do wymagań - wynika to z bezpośredniego przełożenia zmiany na testy. Właściwie odważyłbym sie postawić tezę, że każda zmiana wymagań wymaga ponownej analizy pokrycia w zakresie zmiany. Należy tutaj pamiętać, iż o ile na poziomie wymagań zmiana przestaje być zmianą w chwili jej akceptacji, o tyle na poziomie testów taka zmiana jest zmianą dopóki jej pokrycie nie zostanie przeanalizowane.
Podsumowując ten przydługi wywód, zastosowanie proponowanej metody stanowi świetny pretekst do szczegółowej dyskusji na temat poszczególnych wymagań. Dostarcza świetnego mechanizmu monitorowania zasięgu zmian dokonywanych na poziomie wymagań. A ponad wszystko, stanowi logiczną i mierzalną platformę projektowania przypadków testowych.
piątek, 8 lutego 2013
World Quality Report 2012-2013
Capgemini, HP i Sogeti - ci od "Test Process Improvement Model" - opublikowali "World Quality Report" dostępny na stronach Capgemini.
W tej samej sekcji "Insights & Resources", można znaleźć także wiele innych ciekawych publikacji na temat jakości.
W tej samej sekcji "Insights & Resources", można znaleźć także wiele innych ciekawych publikacji na temat jakości.
Subskrybuj:
Posty (Atom)