Tester.pl - Numer 7

3,778 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,778
On SlideShare
0
From Embeds
0
Number of Embeds
1,611
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Tester.pl - Numer 7

  1. 1. TESTER.PL Strona 1 z 42
  2. 2. TESTER.PL Drodzy czytelnicy, Witam Was serdecznie na łamach siódmego numeru Testera.pl. We współczesnym świecie niemoŜliwe jest działanie organizacji bez sprawnego sposobu komunikacji. Zwłaszcza w branŜy IT, branŜy w większości opartej na wiedzy, właściwy, harmonijny przepływ informacji gwarantuje sprawną prace zespołową i przekazywanie informacji on-line. RównieŜ i ja spędzam ostatnio sporo czasu nad zagadnieniem „teamworkingu”. W przypadku małych teamów zlokalizowanych „pod jednym dachem” przepływ informacji jest w większości przypadków sprawą prostą, wymagającą jedynie drobnych „nakładów” na koordynację. JednakŜe część z nas pracuje w duŜych firmach zlokalizowanych w wielu oddziałach, często za granicą. W jaki sposób zminimalizować „szumy komunikacyjne”, przekazywać i otrzymywać wystarczającą ilość danych, zwłaszcza, kiedy współpracują z sobą zespoły z kilku kontynentów…? Bardzo interesująca kwestia. Kiedyś byłem zwolennikiem separacji zespołów testowych i developerskich. Ale juŜ mi to przeszło… Wydawało mi się, Ŝe lepiej będzie, jeŜeli developerzy nie będą „namawiać” testerów do swojego punktu widzenia (do własnej interpretacji wymagań itp.). Jednak w profesjonalnych zespołach jest to problem marginalny. Wiem za to ile traci się na braku komunikacji, wymianie uwag, nieformalnym brainstormingu… PodobnieŜ komunikacja w ramach SJSI jest nie lada wyzwaniem. Staramy się jak najlepiej „odczytywać” potrzeby członków SJSI, poprzez Forum dyskusyjne, comiesięczne spotkania na Politechnice Warszawskiej, Testera.pl, itp. Nie byłoby dobrze gdybyśmy my, członkowie Stowarzyszenia działali jako oddzielne zespoły, nie tworzyli wspólnoty. SJSI będzie sprawnie działać tylko wtedy kiedy będziemy współpracować. Dlatego kieruję do Was Drodzy Czytelnicy gorącą prośbę – jeŜeli uwaŜacie, Ŝe moŜna coś usprawnić, mocniej zaktywować lub skupić się nad czymś nowym, proszę komunikujcie to. SJSI jest dla Was i bez Waszego współudziału będzie istnieć jako sztuczny twór. Przy okazji chciałem przypomnieć Wam o dwóch waŜnych imprezach, jakie odbędą się w maju. Są to konferencje: - ICSTEST – organizowana w Dusseldorfie w dniach 10 -12 maja – SJSI jest partnerem tej konferencji, a członkowie mogą liczyć na zniŜki przy rejestracji - III Konferencja Jakości Systemów Informatycznych organizowana wspólnie przez SJSI i Computerworld - 22-24 maja, w Jachrance koło Warszawy. Szczegóły wewnątrz numeru. SERDECZNIE ZAPRASZAMY!!! Miłej lektury Wojciech Jaszcz Prezes SJSI Strona 2 z 42
  3. 3. TESTER.PL Od redaktora I znowu się udało. Mimo róŜnych przeciwności dostarczamy Wam kolejny numer Waszego ulubionego kwartalnika TESTER.PL. W tym numerze trzy – bardzo ciekawe - pozycje: 1. Joanna Droździel o procesach zarządzania dostępnością oraz ciągłością usługi – bardzo ciekawy artykuł o metodyce ITIL 2. Maciej Dusza o czymś bardzo istotnym dla kaŜdego testera – jak porządnie opisać znaleziony błąd, by dokładnie wiadomo było o co chodzi 3. Mariusz Janczewski proponuje, co warto czytać, co kaŜdy tester powinien mieć na swojej półce z lekturami. PoniewaŜ i autor i redakcja ma teŜ inne, niŜ zaproponowano, typy do biblioteki testera, więc moŜe uda się stworzyć cykl publikacji na ten temat. Zachęcam wszystkich czytelników do dodawania swoich typów ☺. Numer otwiera zaproszenie na III Konferencję Systemów Informatycznych, tym razem wspólny „produkt” tygodnika Computerworld i naszego Stowarzyszenia. Zapraszamy wszystkich w dniach 22 – 24 maja 2006. Połączenie wysiłków ze strony tygodnika Computerworld i SJSI zapewnia, Ŝe będzie to konferencja jeszcze ciekawsza od poprzednich. Gorąco wszystkich zapraszam do Jachranki!!. Bierzemy teŜ udział w konferencji ICSTEST w Dusseldorfie. PoniewaŜ ten numer ukazuje się podczas jej trwania, więc więcej o niej w następnym numerze kwartalnika. Ze względu na nasze kontakty międzynarodowe w numerze takŜe zaproszenie do Berlina, na CONQUEST’2006. JeŜeli macie trochę czasu końcem września, warto go zarezerwować i wybrać się na tą konferencję – zapowiada się bardzo ciekawie. PoniewaŜ SJSI jest organizacją wspierającą tej konferencji – moŜemy liczyć na istotne zniŜki wpisowego Równocześnie chciałbym – kolejny raz - gorąco zachęcić wszystkich czytelników tego periodyku do aktywnej współpracy. Cały czas czekamy na Państwa uwagi, artykuły, felietony – wszystko, co Was interesuje, co chcielibyście przeczytać, czego się dowiedzieć. JeŜeli tylko będziemy mogli, postaramy się zrealizować Państwa postulaty. Strona 3 z 42
  4. 4. TESTER.PL Strona 4 z 42
  5. 5. TESTER.PL Strona 5 z 42
  6. 6. TESTER.PL Strona 6 z 42
  7. 7. TESTER.PL Strona 7 z 42
  8. 8. TESTER.PL Strona 8 z 42
  9. 9. TESTER.PL Tekst Sponsorowany Strona 9 z 42
  10. 10. TESTER.PL Tekst sponsorowany FIRMA MERCURY PRZEDSTAWIA NOWE OPROGRAMOWANIE MERCURY QUALITY CENTER 9.0 Nowe moŜliwości w dziedzinie testowania aplikacji SAP® i architektur usługowych SOA Rozszerzenia funkcjonalne platformy Microsoft Visual Studio Team System Mountain View, Calif. - 5 kwietnia 2006 r. - Firma Mercury Interactive Corporation, lider w dziedzinie oprogramowania do optymalizacji systemów dla przedsiębiorstw, przedstawiła nową wersję oprogramowania Mercury Quality Center™, które jest kluczowym element pakietu Mercury BTO Enterprise™. Mercury BTO Enterprise to pierwszy, zintegrowany pakiet rozwiązań do optymalizacji systemów dla przedsiębiorstw, który ma umoŜliwić klientom optymalne wykorzystanie zaplecza informatycznego w działalności biznesowej przedsiębiorstw. Mercury Quality Center to wyspecjalizowane rozwiązanie, dzięki któremu klienci mogą automatycznie zarządzać jakością oprogramowania i wykonywać testy funkcjonalne w wielu róŜnych środowiskach, a takŜe nadzorować projekty związane z kontrolą jakości oraz dostosowywać priorytety działań podejmowanych przez kontrolerów jakości do wymagań przedsiębiorstwa. Nowe oprogramowanie Mercury Quality Center 9.0 pozwala rozwiązać problemy w zakresie jakości, umoŜliwiając klientom: • • • • • automatyzację testowania funkcjonalnego aplikacji działających w oparciu o usługi (w tym architektur SOA i usług WWW) za pomocą nowych funkcji programu Mercury QuickTest Professional™, które pozwalają rozpoznać i przetestować usługi wymagające weryfikacji; zarządzanie skutkami zmian w ramach wdroŜeń aplikacji SAP® za pomocą nowych funkcji programów Mercury TestDirector™ i Mercury Business Process Testing™, które umoŜliwiają automatyczne rozpoznawanie instrukcji testowania, jakie naleŜy uaktualnić bądź wykonać w celu sprawdzenia poprawności zmian dokonanych w aplikacjach SAP; optymalizację jakości w środowiskach zaopatrzenia strategicznego za pomocą nowych, udoskonalonych funkcji programu Mercury Business Process Testing, które ułatwiają definiowanie wykonywanych ręcznie, bądź automatycznie instrukcji testowania w sposób upraszczający przeprowadzanie testów przez rozproszone po całym świecie zespoły testujące; współpracę między programistami i kontrolerami jakości w zakresie korygowania błędów w oprogramowaniu oraz podnoszenia jego jakości dzięki integracji z platformą Microsoft® Visual Studio® Team System; zarządzanie wymaganiami za pomocą nowych funkcji programu Mercury TestDirector, które ułatwiają analitykom i specjalistom monitorowanie wymagań i analizowanie wpływu jakości na potrzeby przedsiębiorstwa. „Nadzorowanie procesu kontroli jakości oprogramowania i sterowanie nim stało się koniecznością. Wynika to z presji, jaką wywiera konkurencja, a takŜe ze stosowania złoŜonych mechanizmów zaopatrzenia oraz nowych technologii takich, jak architektury SOA. Nie bez znaczenia są takŜe wymagania prawne oraz czynniki ryzyka i zaleŜności nieodłącznie związane z aplikacjami o znaczeniu krytycznym” – powiedziała Melinda Ballou, dyrektor ds. programu zarządzania cyklem eksploatacji aplikacji w firmie IDC. „W tych trudnych warunkach przedsiębiorstwa inwestują w platformy zarządzania jakością, które zapewniają Strona 10 z 42
  11. 11. TESTER.PL uzyskanie poŜądanych rezultatów merytorycznych w wyniku wdroŜenia newralgicznych aplikacji oraz usprawniają ogólne zarządzanie jakością”. „Przedsiębiorstwa zaczynają traktować oprogramowanie Mercury Quality Center jako standardowe narzędzie do realizacji strategicznych programów kontroli jakości, umoŜliwiające optymalizację procesu dostarczania aplikacji oraz zapewniające ich wysoką jakość i wydajność” – powiedział Rajesh Radhakrishnan, wiceprezes ds. produktów do dostarczania aplikacji w firmie Mercury. „Nowa wersja oprogramowania Mercury Quality Center pozwoli klientom szybciej, taniej i bezpieczniej wdraŜać coraz bardziej złoŜone rozwiązania techniczne oraz zarządzać rozproszonymi po całym świecie zespołami testującymi”. Oprogramowanie Mercury Quality Center 9.0 jest juŜ dostępne w formie wdroŜenia u klienta lub w ramach usług Mercury Managed Services. Więcej informacji na ten temat moŜna znaleźć pod adresem: www.mercury.com/us/products/quality-center. Pozycja firmy Mercury w dziedzinie dostarczania aplikacji Firma Mercury od 15 lat pomaga tysiącom klientów w optymalizowaniu jakości i wydajności aplikacji. Zdaniem firmy IDC, Mercury jest niekwestionowanym liderem w dziedzinie rozproszonych systemów automatycznej kontroli jakości oprogramowania. Firma osiągnęła udział w rynku wynoszący 58 procent – niemal trzykrotnie więcej niŜ którykolwiek z pozostałych dostawców1. Ponadto została uznana za jednego z liderów w raporcie Gartner, Inc. „Application Quality Ecosystem, 2005: Leaders and Challengers”2. MERCURY I MICROSOFT Firmy Mercury i Microsoft współpracują ze sobą od niemal dziesięciu lat, wspólnie tworząc oprogramowanie i podejmując działania marketingowe. Mercury jest certyfikowanym partnerem Microsoft na poziomie Gold. Oprogramowanie firmy Mercury do optymalizacji systemów dla przedsiębiorstw jest ściśle zintegrowane ze środowiskami Microsoft Visual Studio 2005, Microsoft Visual Studio Team System i Microsoft .NET Framework. INFORMACJE O FIRMIE MERCURY Mercury Interactive Corporation pomaga klientom w optymalizacji wartości technologii informatycznych. ZałoŜona w 1989 roku firma jest jednym z najszybciej rozwijających się producentów oprogramowania dla przedsiębiorstw. Mercury oferuje oprogramowanie i usługi, ułatwiające zarządzanie priorytetami, pracownikami i pracą działów informatycznych; dostarcza aplikacje i zarządza nimi oraz integruje i realizuje strategie informatyczne. Klienci na całym świecie korzystają z produktów firmy Mercury w celu podwyŜszenia jakości i wydajności aplikacji oraz zarządzania kosztami, ryzykiem i zgodnością systemów informatycznych. Więcej informacji o firmie moŜna znaleźć na stronie internetowej: www.mercury.com 1 Raport IDC Worldwide pod tytułem „Distributed Automated Software Quality Tools 2005-2009 Forecast and 2004 Vendor Shares”, 26 lipca 2005 r., identyfikator 33771 2 Raport firmy Gartner zatytułowany „Magic Quadrant for Application Quality Ecosystem, 2005: Leaders and Challengers”, 8 marca 2005 r., identyfikator G00124029 Strona 11 z 42
  12. 12. TESTER.PL Kontakt: Regina Koenig, (22) 528 67 41 Mercury rkoenig@mercury.com http://www.mercury.com/pl Beata Pogorzelska, (22) 810 10 50 ITBC Communication Beata_Pogorzelska@itbc.pl http://www.itbc.pl Strona 12 z 42
  13. 13. TESTER.PL Procesy zarządzania dostępnością oraz ciągłością usługi Joanna Droździel Joanna Droździel Jest studentem 5-go roku Informatyki na Wydziale Elektrycznym Politechniki Warszawskiej. Z pojęciem metodyki ITIL pierwszy raz spotkała się podczas praktyk oraz staŜu w firmie General Motors Poland. Poznała się tylko z częścią procesów kierujących metodyką, głównie z obszaru Service Delivery. Zdobytą wówczas podstawową wiedzę postanowiła w dalszym ciągu rozwijać. Pisze pracę magisterską z tego zakresu. Obecnie pracuje w firmie IMPAQ na stanowisku analityka do spraw zapewnienia jakości, biorąc udział w projektach dla klientów w kraju, jak równieŜ dla klientów zagranicznych. W obecnej pracy wykorzystuje głównie procesy z zakresu Service Support, zarządzania problemem oraz incydentem. Strona 13 z 42
  14. 14. TESTER.PL Procesy zarządzania dostępnością oraz ciągłością usługi Joanna Droździel 1. Zarządzanie dostępnością Bardzo często menadŜerowie IT mają do czynienia z usługami, które trudno w prosty sposób zmierzyć i wycenić. Przykładem moŜe być zakup nowego sprzętu oraz zapewnienie łączności z danym systemem. Są to przecieŜ dwie róŜne usługi. Czynnikiem rozróŜniającym jest dostępność kaŜdej z nich. O ile zakup komputera nie stanowi problemu, o tyle zapewnienie stałego, nieprzerwanego dostępu do systemu, bez pomocy którego praca strony biznesowej byłaby niemoŜliwa, jest juŜ procesem bardzo skomplikowanym. Proces ten jest trudny nie tylko na etapie realizacji, ale przede wszystkim na etapie początkowym, czyli wyliczenia czasu dostępności oraz kosztów takiej usługi. Czym tak naprawdę jest dostępność i zarządzanie dostępnością? Według metodyki ITIL z pojęciem tym spotykamy się nie tylko w świecie usług informatycznych, ale równieŜ w Ŝyciu codziennym. Wystarczy, Ŝe odkręcimy kran lub włączymy światło. Dysponujemy stałym, nieprzerwanym dostępem do usługi, za którą odpowiednio płacimy. Usługi internetowe są świadczeniem związanym z IT, ale cały czas dotyczącym bezpośrednio sfery Ŝycia codziennego. Wiemy, iŜ posiadanie komputera bez dostępu do Internetu jest bardzo dokuczliwe, dlatego dąŜymy by choć przez pewien okres mieć moŜliwość przebywania w sieci. Jedni decydują się na kilkugodzinne połączenia za pomocą modemu, inni wybierają dostęp stały. W obu przypadkach usługodawca musi zapewnić uŜytkownikowi dostęp do usługi, za którą zapłacił. Co by było gdyby uŜytkownik chciał skorzystać z usługi, ale usługa ta byłaby nieosiągalna, niedostępna? W sytuacji jednorazowej przerwy spowodowanej na przykład awarią moŜna zrozumieć powstały problem. Jednak, gdy takie przypadki zdarzają się notorycznie, wówczas usługodawca moŜe stracić swoją wiarygodność na rynku a jakość świadczonych przez niego usług byłaby oceniana na bardzo niskim poziomie. Dlatego z pomocą przychodzi zarządzanie dostępnością, którego zadaniem jest bezkolizyjne zapewnienie uŜytkownikowi deklarowanej w umowie usługi. 1.2 Proces zarządzania dostępnością Większość pracowników pracuje 8 godzin dziennie przez 5 dni w tygodniu. Nie oznacza to jednak, Ŝe z chwilą wyjścia z pracy kończą ją równieŜ wszystkie systemy. Wręcz przeciwnie. KaŜda dynamicznie rozwijająca się firma stawia wysokie wymagania wobec stałego dostępu do informacji i moŜliwości jej nieprzerwanego przetwarzania 24 godziny na dobę przez 7 dni w tygodniu. W praktyce oznacza to, Ŝe dla systemów informatycznych dzień pracy nie kończy się nigdy. Dlatego coraz częściej firmy zaczynają przyglądać się procesowi zarządzania dostępnością oraz sposobowi, w jaki jest on realizowany. Okres świadczenia usługi 24 godziny na dobę przez 7 dni w tygodniu dotyczy przede wszystkim: systemów transakcyjnych w bankach, systemów billingowych w firmach telekomunikacyjnych oraz systemów obsługujących witryny internetowe. Proces zapewnienia dostępności w przypadku tego typu usług przechodzi w proces zapewnienia ciągłości. Problem ten został szerzej omówiony w punkcie 2 („Zarządzanie Ciągłością”). Jednak oprócz systemów pracujących Strona 14 z 42
  15. 15. TESTER.PL nieprzerwanie są teŜ takie, które pracują tylko przez 8 godzin dziennie, czyli w godzinach biurowej pracy pracowników, bądź teŜ w godzinach nocnych. Jak teraz zagwarantować klientowi biznesowemu usługę o jakości jakiej oczekuje? Bardzo łatwo, tak przynajmniej twierdzą autorzy publikacji z zakresu metodyki ITIL. Przebieg procesu zarządzania dostępnością przedstawia rysunek 1. Rysunek 1. Proces zarządzania dostępnością3. Proces zarządzania dostępnością skupia się nie tylko na ciągłym optymalizowaniu dostępności infrastruktury teleinformatycznej, ale równieŜ poddaje przykłady metod przydatnych w podejmowaniu działań doraźnych. W dalszej części opracowania przedstawiona została analiza procesu pod względem dostępności usługi informatycznej, jak równieŜ zasady, jakich naleŜy przestrzegać w metodach: analizy wpływu awarii komponentów infrastruktury IT oraz analizy drzewa awarii. 1.2.1 Obliczanie czasu dostępności usługi Pierwszy krok procesu zarządzania dostępnością polega na zdefiniowaniu wymagań biznesu odnośnie aktywności danej usługi, a następnie przedstawieniu tejŜe stronie modelu kosztowego usług wraz z procentową kalkulacją. Jednak strona biznesowa nie rozumie, co bezpośrednio dla biznesu oznacza dostępność usługi w 98%, 95% czy w 90%. Dlatego naleŜy przedstawić szczegółowe obliczenia, wyjaśniające przedstawione wartości procentowe. 3 Procesy zarządzania dostępnością oraz ciągłością usługi Strona 15 z 42
  16. 16. TESTER.PL Wyliczanie czasu dostępności usługi to tylko jedna z metod ustalenia, kiedy dana usługa będzie aktywna. NaleŜy przede wszystkim pamiętać, Ŝe czas dostępności usługi wylicza się na okres z reguły jednego miesiąca. Dostępność jest elementem kaŜdej umowy SLA oraz jest podstawowym parametrem negocjacyjnym. Po obliczeniu czasu świadczenia usługi wynik procentowy naleŜy zapisać w umowie SLA wraz z karami finansowymi niedotrzymania czasu świadczenia usługi. Konsekwencje finansowe muszą być większe niŜ starty, jakie moŜe przez brak usługi ponieść strona biznesowa. JeŜeli w trakcie świadczenia usługi usługodawca wywiązuje się z uzgodnień zawartych w umowie, natomiast klient jest niezadowolony z czasu, kiedy usługa jest dostępna, wówczas w trakcie renegocjacji umowy ma miejsce ponowne wyliczenie dostępności usługi, tym razem z dokładnymi ustaleniami ze strony klienta. Z reguły w tym miejscu klient przedstawia konkretne przypadki, kiedy brak dostępu do usługi spowodował straty. Dzięki tym przykładom dostępność usługi jest dokładniej określona i w pełni realizuje potrzeby strony biznesowej. Często juŜ w pierwszym etapie potrzeby są dobrze zrozumiane i konieczność dodatkowych renegocjacji jest zbędna. Jednak są teŜ przypadki, kiedy renegocjacja umowy jest konieczna; wówczas klienci bardzo negatywnie przystępują do rozmów, winiąc za całą sytuację dostawcę usługi. Takie nastawienie jest błędne, poniewaŜ tylko strona biznesowa wie jaki czas świadczenia usługi jest dla niej najlepszy i z reguły do renegocjacji dochodzi po upływie jednego miesiąca. Jest to czas konieczny dla poznania potrzeb klienta. 1.2.2 Analiza wpływu awarii komponentów infrastruktury IT – CFIA Metoda ta ma za zadanie zbadanie całej infrastruktury IT w celu wykrycia ewentualnych awarii. Chodzi o zbadanie newralgicznych punktów, czyli elementów infrastruktury, które być moŜe w przeszłości spowodowały awarię, co było równoznaczne z brakiem dostępu do danej usługi. W metodzie tej bardzo duŜe znaczenie odgrywa administrator sprzętu i systemów. WaŜne by była to osoba, która pracuje w firmie klienta przez dłuŜszy okres czasu. JeŜeli firma nie posiada własnego administratora, wówczas warto nawiązać kontakt z osobą, która odpowiadała za administrację w ramach umowy outsourcingowej. KaŜda informacja jest bardzo cenna, poniewaŜ nie ma sensu badać wszystkich jednostek informacyjnych pod kątem ewentualnych awarii. Wystarczy zbadać elementy, które powodowały straty. JeŜeli w przeszłości w kilku komputerach zawiodła karta sieciowa, wówczas warto ją sprawdzić równieŜ w pozostałych. NaleŜy pamiętać, Ŝe im więcej takich przypadków rozpatrzymy, tym ryzyko niedostępności usługi spadnie do minimum. Ale praktycy ITIL zalecają równieŜ ostroŜność i kierowanie się zdrowym rozsądkiem. Metoda ta ma przede wszystkim ułatwić pracę. Sprawdzanie sprzętu, który spowodował awarię w przeszłości, to tylko jeden z aspektów tej metody. Głównym celem jest jednak sprawdzanie jak awaria jednego elementu wpłynie na dostępność usługi oraz na pracę strony biznesowej. Efektem prac jest odkrycie newralgicznego punktu, którego awaria moŜe spowodować największe straty w biznesie. WaŜne by takich miejsc znaleźć jak najwięcej i co jakiś czas poddawać je ponownej analizie, pod kątem ryzyka występowania awarii. 1.2.3. Analiza drzewa awarii – FTA Metoda CFIA odnosiła się tylko do sprawdzania i analizy elementów infrastruktury IT w firmie, natomiast prace związane z analizą drzewa awarii polegają na zdefiniowaniu łańcucha przyczynowo-skutkowego zdarzeń prowadzących do niedostępności usługi informatycznej. Analiza ta jest bardzo istotna w wykrywaniu złoŜonych oddziaływań, które dosyć trudno odnaleźć badając tylko pojedynczy fragment całej konfiguracji. JeŜeli celem firmy outsourcingowej jest zapewnienie dostępu do firmowej poczty, wówczas metoda ta będzie polegała na opracowaniu jak największej ilości scenariuszy, które mogą w mniejszym lub większym stopniu zakłócić dostępność tej usługi. Strona 16 z 42
  17. 17. TESTER.PL Jednak te standardowe metody mierzenia dostępności nie wszystkich klientów biznesowych w pełni zadowalają. Dlatego coraz częściej firmy informatyczne oferujące swoje produkty inwestują w zaawansowane techniki umoŜliwiające spojrzenie na IT w szerszym kontekście biznesowym. W roku 2005 juŜ jedna trzecia organizacji IT wdroŜyła odpowiednie narzędzia 4. Wstępne oszacowanie dostępności to tylko połowa drogi. Następnym krokiem jest przedstawienie kosztów związanych z dostarczaniem danej usługi. W tym celu naleŜy przedstawić koszty ponoszone przez stronę dostawcy usługi i zestawić je z kosztami, jakie poniosłaby strona biznesowa, gdyby danej usługi nie było. Z reguły firmy informatyczne posiadają gotowy cennik świadczenia danej usługi, jednak nie zawsze strona biznesowa jest w stanie taki kosztorys zaakceptować. 2. Zarządzanie ciągłością Zarządzanie ciągłością ma na celu opracowanie strategii, która pozwoli dotrzymać ustaleń dostępności zawartych w umowie SLA. Przede wszystkim polega na identyfikacji zagroŜeń mogących wpłynąć negatywnie na funkcjonowanie organizacji oraz opracowanie scenariuszy postępowania na wypadek wystąpienia któregoś z zagroŜeń. Wiele firm inwestuje w drogie systemy, badające stan aplikacji i sprzętu, aby przed pojawieniem się awarii wykryć ją i wyeliminować. Przedsiębiorstwa, które nie mogą sobie pozwolić na jakiekolwiek straty w biznesie inwestują w działania profilaktyczne. Na takie rozwiązania decydują się wielkie korporacje, które z własnego doświadczenia bardzo dobrze wiedzą, Ŝe wystąpienie awarii jest jednoznaczne z miliardowymi stratami. Jedna minuta przerwy w pracy banku oznacza od 60tys. do 250tys. dolarów strat 5. W celu zminimalizowania ryzyka takich sytuacji, firmy opracowują plany awaryjne. Przewidują w nich wielowariantowe scenariusze wydarzeń zagraŜających ciągłości usługi. WaŜna jest przy tym eliminacja przestojów spowodowanych zarówno planowanymi zdarzeniami - takimi jak wymiana oprogramowania, sprzętu komputerowego, reorganizacja baz danych - jak i tymi nieplanowanymi - jak awarie serwera, poŜar, powódź i wyłączenie prądu. Takie postępowanie motywowane jest dąŜeniem do zapewnienia wysokiej jakości świadczonej usługi biznesowej. Dobrze opracowany system antykryzysowy pozwoli na zachowanie minimalnego poziomu strat. Przedsiębiorstwa, które dotrzymują postanowień zawartych w umowach, stają się bardziej wiarygodne na rynku. Klienci coraz częściej wolą zapłacić więcej za usługę i być pewnymi, Ŝe dostawca sprosta oczekiwaniom, nie naraŜając strony biznesowej na dodatkowe straty. Takimi działaniami kieruje bardzo prosta zasada. Jeśli dostawca IT nie dostarczy usługi na czas, wówczas równieŜ klient nie wywiąŜe się ze swoich kontraktów biznesowych. Według analityków KPMG aŜ 40% firm, które przeŜyły powaŜną katastrofę informatyczną w ciągu dwóch lat wypada z rynku 6. Dlaczego aŜ 40%? Co takiego zrobiły pozostałe 60% firm, Ŝe udało im się przetrwać? Odpowiedź jest prosta, pozostałe przedsiębiorstwa były zabezpieczone przed ewentualnymi awariami. Wiedziały, z jakiego typu ryzykiem mogą mieć do czynienia i dzięki temu łatwiej było im wyjść cało z trudnych sytuacji. Dlatego coraz częściej, juŜ na etapie zapoznawania się z procesem zarządzania ciągłością, firmy zdecydowanie inwestują w dodatkowy sprzęt, pozwalający na przeniesienie aplikacji 4 Bryan Glick, „Measuring up: How to prove IT value”, 23/20/2005, (http://www.computingbusiness.co.uk/ - miesięcznik wydawany w Wielkiej Brytanii poświęcony tematyce biznesu i informatyki), 5 Marek Rzewuski, Jak przetrwać katastrofę? Dobry plan ratunkowy, 01/03/2002, (http://www.pckurier.pl/ - vademecum informatyka i menadŜera), 6 Witryna międzynarodowej firmy, oferującej profesjonalne usługi doradcze. KPMG świadczy usługi audytorskie, doradza w zakresie podatków, finansów, zarządzania ryzykiem i efektywnością przedsiębiorstw, Styczeń 2006, ( http://www.kpmg.pl/), Strona 17 z 42
  18. 18. TESTER.PL analitycznych na maszynę zapasową. Nie szczędzą teŜ nakładów na dodatkowe wsparcie techniczne. 2.1. Proces zarządzania ciągłością Przystępując do prac na procesem zarządzania ciągłością dostawca usług IT ma za zadanie dokładne przeanalizowanie działalności biznesowej organizacji oraz zobowiązań wobec klientów biznesowych. W tym kontekście naleŜy zwrócić szczególną uwagę na procesy biznesowe szczególnie naraŜone na największe ryzyko. Dobrzy konsultanci, posiadający doświadczenie w róŜnych dziedzinach, pomogą wybrać elementy technologiczne, środowiskowe a przede wszystkim biznesowe, na które naleŜy zwrócić uwagę juŜ w pierwszym etapie prac. Rysunek 2 prezentuje wszystkie elementy procesu, które zostaną omówione w dalszej części opracowania 7. Rysunek 2. Zarządzanie ciągłością biznesową- BCM. 2.2. Proces zarządzania ryzykiem Procesu zarządzania ciągłością nie sposób zrozumieć bez poznania podstawowych strategii zarządzania ryzykiem. Dlatego teŜ proces analizy ryzyka powinien być przeprowadzony przez specjalnie wyspecjalizowaną grupę osób. Tylko takie podejście pozwoli uniknąć niepotrzebnych kosztów. By mieć pewność, Ŝe przeprowadzony proces analizy ryzyka przyniesie rezultaty jakich oczekujemy, powinien zostać przeprowadzony zgodnie z określonym planem. Tylko właściwie określony schemat działania da pewność, Ŝe aspekt 7 Service Delivery, Londyn 2001, str. 171. Strona 18 z 42
  19. 19. TESTER.PL analizy ryzyka został sprawdzony i rozwiązany prawidłowo. Proces analizy ryzyka składa się z sześciu elementów przedstawionych na rysunku 3 8. Rysunek 3. Elementy analizy ryzyka. 2.2.1. Planowanie zarządzania ryzykiem Planowanie zarządzania ryzykiem jest waŜnym etapem w całym procesie analizy ryzyka. Na tym odcinku główną rolę odgrywa menedŜer, którego zadaniem jest stworzenie pełnej infrastruktury organizacyjnej. Planowanie zarządzania ryzykiem łączy własności operacyjne, techniczne oraz organizacyjne w spójną całość, odnoszącą się do konkretnego rodzaju ryzyka. W procesie analizy ryzyka główną rolę odgrywają dwa zasadnicze elementy: IDENTYFIKACJA RYZYKA, POMIAR RYZYKA. Wykrycie ryzyka obrazuje się w dwóch głównych etapach. Najpierw musimy zidentyfikować ryzyko, a dopiero później dokonać pomiaru. Ich wyodrębnienie wynika z kluczowej roli, jaką odgrywają na tle pozostałych elementów, dlatego teŜ poświęcam im zasadniczą część swojego opracowania. 8 Carl L. Pritchard, Zarządzanie ryzykiem w projektach, Warszawa 2001, str. 23. Strona 19 z 42
  20. 20. TESTER.PL • Identyfikacja ryzyka Proces analizy ryzyka odgrywa szczególną rolę w sprawnym funkcjonowaniu organizacji dzięki waŜnemu etapowi identyfikacji. Celem tego etapu jest wykrycie obszarów, w których firma naraŜona jest na straty oraz poszczególnych rodzajów ryzyka. Bardzo trudno jest określić wszystkie mogące wystąpić rodzaje ryzyka, dlatego teŜ proces identyfikacji ma na celu ukazanie, z jakiego typu ryzykiem strona biznesowa moŜe się spotkać. Nie chodzi tutaj bynajmniej o wyodrębnienie wszystkich, nawet najdrobniejszych ścieŜek ryzyka; takie działanie mogłoby okazać się zbyt czasochłonnym. Dlatego waŜne jest prawidłowe poznanie rodzajów ryzyka i dokonanie prawidłowej identyfikacji. Proces identyfikacji moŜe odnieść sukces tylko wtedy, gdy będziemy dysponować szczegółową wiedzą na temat podmiotu. WaŜna moŜe okazać się nawet najdrobniejsza informacja, a więc: o zrozumienie celów strategicznych i operacyjnych, o zapoznanie się z rynkiem, na którym działa, o określenie obszarów prawnego, społecznego, politycznego i kulturalnego otoczenia. Po określeniu ryzyka naleŜy ocenić stopień jego złoŜoności. Pomiar ryzyka pozwala określić wielkość ryzyka oraz szanse na to, czy dany zespół osiągnie wyznaczony cel. Dlatego bardzo pomocne okazuje się powstanie tak zwanej listy monitoringowej (watch list), która zawiera informacje o rodzaju mogącego wystąpić ryzyka, skutkach, jakie dane ryzyko moŜe spowodować, oraz metodach reagowania. O hierarchii ryzyka pod względem waŜności decyduje menedŜer. Tylko on w sposób całkowicie obiektywny moŜe określić, na który typ ryzyka powinniśmy w szczególności zwrócić uwagę, a który odsunąć na dalszy plan. • Klasyfikacja ryzyka Klasyfikacja ryzyka to proces sortowania poszczególnych rodzajów ryzyka na podstawie ich ogólnego prawdopodobieństwa oraz skutków tworzących podstawy do szczegółowej analizy 9. Po określeniu listy zagroŜeń musimy określić, które z nich ma największy wpływ na działalność biznesową. Bardzo pomocny okazuje się tzw. Ranking ZagroŜeń (rysunek 4). Rysunek 4. Graf prezentujący ranking zagroŜeń wg G. R. Heerkensa 10. 9 Carl L. Pritchard, Zarządzanie ryzykiem w projektach, Warszawa 2001, str. 9, Gary R. Heerkens, Jak zarządzać projektami, Warszawa 2003, str 139, 10 Strona 20 z 42
  21. 21. TESTER.PL • Planowanie metod reagowania na ryzyko Planowanie metod reagowania na ryzyko ma za zadanie określenie działań, za pomocą których mają być rozwiązywane problemy z danym rodzajem ryzyka. Źródłem informacji są wszystkie dane ustalone w poprzednich etapach analizy ryzyka. W związku z tym wyróŜniamy następujące metody reagowania: Unikanie ryzyka - wybór „mniejszego zła”, czyli ryzyka powodującego mniejsze konsekwencje. Transfer ryzyka - obarczenie ryzykiem inną grupę osób, na przykład klientów. (Jednak takie działanie nie prowadzi do zmniejszenia ryzyka.) Łagodzenie ryzyka - prowadzenie działań i podejmowanie decyzji mających na celu zmniejszenie skutków ryzyka. (Jest to najefektywniejsza metoda reagowania na ryzyko.) Akceptacja ryzyka polega na przyjęciu danego ryzyka wraz ze wszystkimi konsekwencjami w sposób pasywny - bez podejmowania działań, lub w sposób aktywny polegający na utworzeniu określonego planu działania dla rozwiązania problemów 11. • Nadzorowanie i kontrola ryzyka Po pomyślnym zakończeniu wcześniejszych etapów analizy ryzyka przychodzi czas na etap ostatni, czyli wdroŜenie wszystkich elementów wraz z planem strategii organizacji w zakresie ciągłości działania. JeŜeli plany analizy ryzyka są prawidłowo zintegrowane z procesem zarządzania ciągłością, wówczas nadzór odbywa się w sposób automatyczny. Pamiętać naleŜy, Ŝe droga do upragnionego stanu ostatecznego jest bardzo długa i męcząca. 2.2.2. Opracowanie strategii biznesowej Coraz częściej firmy korzystają z usług kilku dostawców, ale usługi jakie otrzymują róŜnią się jakością. Dlatego proces zarządzania ciągłością pomaga nie tylko w opracowaniu planu na wypadek katastrofy, ale przede wszystkim ułatwia nawiązanie współpracy pomiędzy dostawcami. Jest to czas potrzebny do wzajemnego poznania się i wymienienia spostrzeŜeń odnośnie funkcjonowania środowiska informatycznego w firmie, dla której pracują. Gdy wszystkie elementy działalności biznesowej zostaną przeanalizowane, następnym krokiem jest wybór strategii organizacji w zakresie ciągłości działania. Na tym etapie procesu zarządzania ciągłością powinno mieć miejsce spotkanie dostawcy usługi z odbiorcą usługi. Dzięki konsultacjom moŜliwe jest określenie stopnia złoŜoności strategii. KaŜdy plan działania na wypadek kryzysu wymaga nakładów finansowych. W tym celu klient powinien sprecyzować poziom złoŜoności planów ciągłości, planów odtwarzania oraz planów zarządzania kryzysowego. NaleŜy wybrać te procesy biznesowe, które w razie awarii wpłyną w sposób szczególny na dalszą działalność firmy. Oczywiście istnieją organizacje, dla których kwestie finansowe nie stanowią roli nieprzekraczalnej bariery, jednak są to przypadki nieliczne i z reguły dotyczą duŜych przedsiębiorstw. W rzeczywistość strona biznesowa na pierwszym miejscu stawia na inwestycje w dalszy rozwój firmy, a kwestie zabezpieczeń odsuwa na dalszy plan. Tego typu przedsiębiorstwa wybierają kilka podstawowych planów, które według konsultantów są niezbędne. W większości przypadków firmy wybierają najbardziej krytyczne scenariusze, ufając, iŜ szanse na wystąpienie pozostałych są znikome, bądź straty, jakie mogą spowodować bliskie zeru. RównieŜ bardzo popularne wśród odbiorców usługi jest przekonanie, Ŝe przecieŜ w przeszłości nic się nie zdarzyło, nic się nie zdarzy równieŜ w przyszłości 12. Zadaniem doradców jest pełne uświadomienie klienta o konsekwencjach kaŜdej podjętej przez niego decyzji. Główną dewizą metodyki ITIL jest 11 P. Charette, A. Mitchell, E. McSweeney, S. Mazur, Zarządzanie projektem, Poradnik dla samorządów terytorialnych, Kraków 2004, 12 Michael Regester, Judy Lovlin, Zarządzanie kryzysem, Warszawa 2005, str. 134 Strona 21 z 42
  22. 22. TESTER.PL obustronna jawność; równieŜ i w tym przypadku zasada ta powinna szczególnie obowiązywać. 2.2.3. Opracowanie planów kryzysowych, odtwarzania i ciągłości Po wybraniu i zaakceptowaniu przez stronę biznesową stref szczególnego ryzyka następuje etap kolejny, szczegółowe opracowanie planów kryzysowych, odtwarzania i ciągłości. Oczywiście cały proces wymaga nakładu czasu. Dobrze jest, gdy doradcy dostawcy usługi dysponują gotowym planem, który moŜna od razu wdroŜyć u klienta. Jednak są to przypadki sporadyczne, częściej mają miejsce sytuacje, gdy taki plan naleŜy opracować indywidualnie dla otoczenia klienta. By plan awaryjny w przyszłości przyniósł planowane korzyści i uchronił firmę przed dotkliwymi stratami naleŜy skutecznie przeanalizować potencjalne zagroŜenia, zarówno te wewnętrzne, występujące w obrębie organizacji, jak i te zewnętrzne. ZagroŜenia zewnętrzne powinny być analizowane w oderwaniu od podstawowej działalności firmy, a wręcz skupiać się na ocenie środowiska, w jakim organizacja działa. Na szczególną uwagę zasługują czynniki atmosferyczne, społeczne i kulturowe. Gdy takich planów jest kilkadziesiąt, wówczas moŜemy mówić o całym systemie zarządzania ciągłością. 2.2.4 Przekazanie opracowanych procedur Opracowany system zarządzania ciągłością powinien zostać przekazany pośrednio klientowi, a bezpośrednio pracownikom, którzy będą odpowiedzialni za jego dalszą kontrolę i realizację. Strona biznesowa powinna dostać pełną dokumentację wraz z opisem wszystkich procedur, zakazów i nakazów wchodzących w skład planu oraz raport z przebiegu prac wdroŜeniowych. Natomiast w przypadku pracowników kilkugodzinne szkolenie moŜe juŜ nie wystarczyć. Dlatego przekazanie opracowanych planów powinno być poprzedzone całym blokiem ćwiczeń i testów powtarzanych w róŜnych odstępach czasu. Przebieg ćwiczeń i testów powinien być dokładnie dokumentowany, a kaŜde niedociągnięcie od razu naprawiane. Bardzo waŜne jest by po zaprojektowaniu, zaimplementowaniu a następnie wdroŜeniu, tak jak w przypadku pozostałych procesów metodyki ITIL, tak i tutaj następował etap kontroli, nadzoru i udoskonalenia opracowanych planów. Jest to warunek konieczny, aby w sytuacji kryzysowej system ten się w pełni sprawdził. Dobrze opracowany plan i profesjonalnie przeszkoleni pracownicy zapewniają moŜliwość odtworzenia środowiska pracy w ciągu kilku godzin, a nawet minut. Kiedy jest juŜ po wszystkim, naleŜy dokonać szczegółowej oceny organizacji w świetle uzyskanych doświadczeń, poniewaŜ piorun moŜe uderzyć dwa razy w to samo miejsce 13. Po kaŜdej awarii i przywróceniu sprawności operacyjnej firmy zadaniem wyznaczonych pracowników jest opracowanie sprawozdania z przebiegu akcji. W przypadku wykrycia pewnych niedociągnięć cały system zarządzania ciągłością powinien zostać zaktualizowany. Jednak tak wygląda teoria, a droga od teorii do praktyki jest długa i kręta, czego dowodem mogą być wydarzenia w Stanach Zjednoczonych związane ze skutkami huraganów Katrina i Rita. Niestety nie wszystkie organizacje zdają sobie sprawę z wagi tego zagadnienia. Zamiast liczyć na pomoc organów władzy państwowej, przedsiębiorstwa same muszą zaplanować i wdroŜyć plan postępowania w obliczu awarii lub katastrofy. Jednak okazuje się, Ŝe nawet zjawisko huraganu nie zmusiło wielu przedsiębiorstw do odświeŜenia swoich planów awaryjnych 14. Kluczową sprawą jest świadome poczucie odpowiedzialności wobec podejmowanych działań. Część z nas w pełni 13 Michael Regester, Judy Lovlin, Zarządzanie kryzysem, Warszawa 2005, str. 224, 14 George Spafford, Is Your Recovery Plan Good Enough to Save You? 18/11/2005, (http://itmanagement.earthweb.com – portal poświęcony tematyce usług informatycznych), Strona 22 z 42
  23. 23. TESTER.PL odpowiada za swoje czynny, inni tą odpowiedzialnością obarczają innych. NaleŜy zaznaczyć, Ŝe za sukces procesów biznesowych odpowiada przede wszystkim IT 15. Metodyka ITIL zaleca by aktualizacja odbywała się równieŜ po wdroŜeniu kaŜdego nowego sprzętu i oprogramowania, poniewaŜ nigdy nie wiadomo jak nowe elementy wpłyną na działanie systemu zarządzania ciągłością. Dobrze zaprojektowany proces zapewni nie tylko sukces w chwili duŜej awarii, ale równieŜ usystematyzuje i usprawni pracę związaną z rozwiązywaniem małych problemów i incydentów. 2.2.5 Wskazania w procesie zarządzania ciągłością Praktycy metodyki ITIL uwaŜają, iŜ Ŝadna podręcznikowa definicja nie jest w stanie przekazać tylu wskazówek, ile moŜna nauczyć się z przykładów innych organizacji, które przetrwały katastrofę bądź przegrały walkę. WaŜne by z kaŜdego takiego przykładu wyciągać wnioski. Punktem krytycznym jest data 11 września 2001 roku, kiedy to w 22 minuty po ataku na WTC pracownicy działu Ciągłości Biznesu i Usług Odzyskiwana Danych w IBM zaczęli odbierać setki telefonów. Wówczas firma IBM we współpracy z HP i Sun Microsystems przygotowały 20 tys. stanowisk pracy dla klientów, którzy stracili sprzęt i biura. Jednak nie wszyscy działali tak sprawnie. System dostaw Compaq Computer załamał się i firma nie mogła zrealizować zamówień 16. Wniosek w tym przypadku powinien być jeden. NaleŜy sprawdzić system dostaw, bez względu na rodzaj produktów, jakie klient sprzedaje. Być moŜe strona biznesowa utwierdza się w przekonaniu, Ŝe system dostaw działa sprawnie, ale nie wiadomo czy tenŜe system sprawdziłby się, gdyby ilość zamówień zwiększyła się dziesięciokrotnie. Najprawdopodobniej działałby dalej, ale czy z taką samą wydajnością i przepustowością? Chcąc uniknąć tych dylematów naleŜy wszystkie systemy poddawać wielokrotnym testom obciąŜeniowym zanim zostaną wdroŜone w środowisku produkcyjnym. Kierownicy projektów dla zaoszczędzenia środków finansowych w niewielkim zazwyczaj w końcowej fazie projektu budŜecie, rezygnują z przeprowadzenia obciąŜeniowych testów synchronicznych z pozostałymi systemami działającymi w firmie. Słownik BCM - Business Continuity Management CFIA - Component Failure Impact Analysis FTA - Fault Tree Analysis IT - Information Technology ITIL - Information Technology Infrastructure Library SLA - Service Level Agreement WTC - World Trade Center 15 Penny Klein, IT’s Responsibility for Business Continuity, 28/11/2005, (http://itmanagement.earthweb.com portal poświęcony tematyce usług informatycznych), 16 Marek Rzewuski, Jak przetrwać katastrofę? Dobry plan ratunkowy, 01/03/2002, (http://www.pckurier.pl/ -vademecum informatyka i menedŜera) Strona 23 z 42
  24. 24. TESTER.PL Jesteśmy międzynarodową firmą informatyczną z centralą w Szwajcarii. Na rynku polskim działamy od roku 1993, zatrudniamy ponad 100 osób. Dostarczamy rozwiązania informatyczne dostosowane do indywidualnie określonych wymagań. Nasze usługi obejmują m.in.: usługi konsultingowe, usługi outsourcingu, budowę hurtowni danych oraz tworzenie oprogramowania na indywidualne zamówienie. Obecnie poszukujemy do pracy w Warszawie i w Poznaniu kandydatów na następujące stanowisko: Tester Oprogramowania nr ref. QAA/04/06/Tester.PL Zatrudnione osoby pracować będą przy realizacji projektów informatycznych dla polskich i zagranicznych klientów. Niektóre projekty mogą się wiązać z wyjazdami zagranicznymi. Oczekujemy: • • • • • • • • doświadczenia w testowaniu oprogramowania wiedzy z zakresu zapewnienia jakości w projekcie informatycznym dobrej znajomości baz danych (Oracle, MS SQL) oraz umiejętności pracy w środowisku Unix wykształcenia wyŜszego, ew. studenci ostatnich lat informatyki lub kierunków pokrewnych bardzo dobrej znajomości języka angielskiego (zarówno w mowie, jak i piśmie) dobra znajomość języka niemieckiego będzie dodatkowym atutem komunikatywności, dociekliwości, samodzielności i asertywności umiejętności szybkiego uczenia się, pracy zespołowej oraz pracy w stresie Oferujemy: • • • • ciekawą pracę w sympatycznym zespole atrakcyjne warunki zatrudnienia i moŜliwość rozwoju zawodowego bezpośrednie kontakty z europejskim i amerykańskim przemysłem IT dobre warunki socjalne (prywatna opieka zdrowotna) Oferty pisemne (cv i list motywacyjny) z podaniem numeru referencyjnego oraz zgodą na przetwarzanie danych osobowych prosimy przesyłać na adres: IMPAQ Sp. z o.o. Dział Personalny ul. Pruszkowska 17 02-119 Warszawa e-mail: praca@impaq.com.pl http://www.impaqgroup.com/pl/ Strona 24 z 42
  25. 25. TESTER.PL Jak porządnie opisać znaleziony błąd Maciej Dusza Maciej Dusza Jest absolwentem informatyki na wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. W 1993r. obronił pracę magisterską na temat "Tworzenie programów współbieŜnych o sterowaniu zadanym strukturami przyczynowo-skutkowymi". Od tego czasu pracował w kilku firmach w Polsce i USA, pełniąc funkcje programisty, analityka, projektanta i testera, a obecnie od dwóch lat pracuje w IMPAQ Sp. z o.o., na stanowisku Starszego Analityka ds. Zapewnienia Jakości. Kawaler. Jego hobby to nurkowanie. Strona 25 z 42
  26. 26. TESTER.PL Jak porządnie opisać znaleziony błąd Maciej Dusza Pamiętam jak kiedyś, w studenckich czasach, prowadziłem spływ kajakowy. Mieliśmy na nim stary, zardzewiały, opalony setkami ognisk grill, na którym smaŜyliśmy to, co udało się kupić w miejscowych sklepikach. Przed wyruszeniem w kolejny etap spływu, trzeba było opłukać go w wodzie i przetrzeć piaskiem, Ŝeby nie ubrudzić sadzą wszystkiego w kajaku. W czasie pierwszego biwaku, zwróciłem się do jednego z uczestników spływu: „Czy mógłbyś umyć grill ?”. Chłopak zniknął w zaroślach nad wodą, nie było go chyba ze dwie godziny, po czym wrócił niosąc coś błyszczącego w rękach. To był nasz grill, wyszorowany do połysku... Nie ukrywam, Ŝe zrobiło mi się głupio. Ktoś odwalił kawał cięŜkiej, solidnej, i absolutnie niepotrzebnej roboty, tylko dlatego Ŝe nie przekazałem mu odpowiedniej informacji. Nie wziąłem pod uwagę, Ŝe chłopak był pierwszy raz na spływie, i być moŜe nigdy wcześniej nie korzystał z takiego urządzenia. Dla mnie sposób „codziennej konserwacji grilla” był czymś trywialnym i oczywistym, on miał prawo niczego o tym nie wiedzieć. Od tego spływu minęło kilkanaście lat, a jednak tamta sytuacja regularnie mi się przypomina. Przychodzi mi na myśl, kiedy widzę jak ktoś, pełen najlepszych chęci, wykonuje kawał dobrej roboty, która ostatecznie okazuje się do niczego niepotrzebna. Dlatego Ŝe od początku chodziło o coś innego, a rozbieŜność powstała w momencie, kiedy jakiś współpracownik, bynajmniej nie ze złej woli, przekazał niewłaściwą informację, lub przekazał informację w niewłaściwy sposób. Tego typu sytuacje mogą powstać wszędzie tam, gdzie praca wykonywana przez jedną osobę, opiera się na informacjach dostarczanych przez inną osobę. Klasycznym przykładem jest programista, który poprawia błędy w programie, na podstawie informacji otrzymywanych od testera. Jeśli tester pomyli się dokumentując znaleziony błąd, programista moŜe spędzić długie godziny, szukając usterek w poprawnym fragmencie kodu. Jeśli opis okoliczności wystąpienia błędu nie będzie dostatecznie precyzyjny, programista będzie miał większy kłopot ze zlokalizowaniem usterki. Błędy znalezione w oprogramowaniu, moŜna dokumentować na róŜne sposoby, uŜywając róŜnych narzędzi. Istnieje jednak kilka uniwersalnych cech, niezaleŜnych od techniki prowadzenia dokumentacji, które decydują o jakości opisu błędu. To właśnie od nich zaleŜy, czy programista działając na podstawie takiego opisu, „w ciągu dwóch minut doprowadzi grill do właściwego stanu”, czy teŜ przez długi czas będzie wykonywał równie cięŜką co nieefektywną pracę. PoniŜej zamieszczam listę cech, które uwaŜam za kluczowe dla porządnego opisu błędu. Wszystkie przykłady w tekście, pochodzą z jednego z projektów, w których brałem udział. Strona 26 z 42
  27. 27. TESTER.PL Cechy dobrego opisu błędu. 1. Nie zawiera błędów. Po sporządzeniu opisu błędu, zawsze naleŜy bardzo dokładnie przeczytać to, co się napisało, i upewnić się, Ŝe nie ma tam pomyłek. Pomyłki w opisie błędu mogą spowodować stratę czasu przez programistę, który starając się odnaleźć przyczynę błędu, będzie szedł fałszywym tropem. 2. Jest uŜyteczny nie tylko dla programistów. Oprócz długiego opisu błędu, przeznaczonego dla programisty, naleŜy równieŜ sporządzić krótki opis, który umoŜliwi szybkie zorientowanie się, o co ogólnie chodzi. Warto podać równieŜ kategorię (funkcjonalność / moduł / fragment programu), której dotyczy ten błąd. Oczywiście, błędowi naleŜy teŜ przypisać określony priorytet. Wszystkie te informacje (krótki opis, długi opis, kategoria, priorytet) powinny się znaleźć w oddzielnych polach listy błędów. Dzięki temu, taki dokument będzie poŜyteczny zarówno dla programisty tworzącego kod, jak i dla kierownika projektu, który będzie mógł szybko zorientować się, w jakim stanie jest program, bez potrzeby wnikania w szczegóły techniczne. 3. Opisuje tylko jeden, konkretny błąd. Czasem testera moŜe korcić, Ŝeby dla zaoszczędzenia czasu i wysiłku, zawrzeć informacje o kilku błędach w jednym opisie. Jest to zła praktyka, która przysparza problemów. Pierwszy kłopot ma programista, który np. poprawi tylko jeden z tych błędów, i nie wie czy całość ma oznaczyć jako poprawioną, czy zostawić jako otwartą, czy moŜe umieścić jakąś adnotację. Następny problem ma tester, który zweryfikuje, Ŝe nie wszystko zostało poprawione, i musi umieszczać dodatkowe wyjaśnienia, Ŝeby było wiadomo, co działa, a co nie. Dlatego kaŜdy opis powinien dotyczyć pojedynczego, konkretnego błędu – to po prostu ułatwia Ŝycie. 4. Podaje jednoznaczny sposób reprodukcji błędu. Opis w rodzaju błąd taki a taki przy dodawaniu nowego klienta nadaje się do pola krótki opis listy błędów, ale jako długi opis moŜna go uŜyć tylko w przypadku, gdy ten błąd występuje bez względu na to jak wchodzimy w opcję dodawania klientów, bez względu na to jakie czynności po drodze wykonujemy, i bez względu na to jakie dane próbujemy wprowadzić. Jeśli w jakichś okolicznościach błąd nie występuje (lub występuje inny błąd), wtedy taki opis jest juŜ niewystarczający – trzeba dokładnie podać, krok po kroku, jakie czynności naleŜy wykonać, Ŝeby dany błąd uzyskać. Przykład. Kategoria: Korelacje. Krótki opis: Korelacje nie są obliczane w pewnej sytuacji. Długi opis: Scenariusz prowadzący do sytuacji, w której korelacje nie są obliczane: Wybierz kryteria dla pierwszego wykresu, kliknij ‘R’, wybierz produkt (wykres zostaje wyświetlony), wybierz ‘Obszar’ tylko dla drugiego wykresu, kliknij ‘R’, wybierz produkt (wykres nie jest wyświetlany), wybierz ‘Miarę’ dla drugiego wykresu, kliknij ‘R’, wybierz produkt (wykres zostaje wyświetlony), kliknij ‘Korelacje’. Korelacje nie zostają obliczone. 5. Dokładnie informuje, jaki to błąd. Opis błędu powinien wystarczyć do zrozumienia, jaki to błąd, bez konieczności uruchamiania programu i wykonywania reprodukcji. Powód jest oczywisty – oszczędność Strona 27 z 42
  28. 28. TESTER.PL czasu czytającego. Dlatego informacje typu numer błędu, czy wyświetlona na ekranie wiadomość o błędzie, naleŜy zawrzeć w opisie. Przykład. Kategoria: Wiele okien z wykresami. Krótki opis: Przy zamykaniu okien w pewnej kolejności, występują błędy. Długi opis: Wykonałem następujące czynności: Wybrałem bazę danych. W oknie ‘wybór danych’ wybrałem produkt i wyświetliłem dla niego wykres (nazwijmy okno z tym wykresem W1). Zminimalizowałem W1, w oknie ‘wybór danych’ wybrałem inny produkt i wyświetliłem dla niego wykres (nazwijmy okno z tym wykresem W2). Zminimalizowałem W2. Zamknąłem okno ‘wybór danych’. Zamknąłem W1. Otworzyło się puste okno ‘wybór danych’, z komunikatem: ‘wybierz podstawowe kryteria selekcji’. Kliknąłem ‘OK’. Wystąpił błąd AdodcTP: 'Authentification failed'. Kliknąłem ‘OK’. Wystąpił błąd -2147217843: 'Automation error'. 6. Jest dokładny i precyzyjny. Czyli taki, Ŝe programista nie musi, w trakcie poprawiania błędu, przychodzić do testera z pytaniami w rodzaju: co konkretnie miałeś na myśli? o co chodziło ci w tym miejscu? Ponadto, jeśli do opisu dołączone są jakieś dodatkowe elementy (np. kilka plików ze zrzutami ekranów), to w opisie, w odpowiednich miejscach powinny występować odniesienia do tych elementów. Czyli jeśli np. podajemy sposób reprodukcji błędu, i do opisu dołączamy pięć plików ze zrzutami ekranów zrobionymi w czasie reprodukcji, to przy opisie kolejnych czynności reprodukcji, podajemy nazwy odpowiadających im zrzutów. Tak Ŝeby programista miał jasno powiedziane jaki zrzut odnosi się do jakiej sytuacji, i nie musiał się zastanawiać co do czego pasuje. Na zrzutach warto zaznaczyć (np. edytując plik graficzny pod Paint’em), miejsca, na które naleŜy zwrócić uwagę. Przykład. Kategoria: Korelacje. Ekran: 839a, 839b, 839c, 839d Krótki opis: Okresy czasowe są niepoprawne w pewnej sytuacji. Długi opis: Wybrałem produkt w oknie ‘wybór danych’, i kliknąłem ‘korelacje’. Oznaczmy początkową datę dla danych dotyczących tego produktu przez P1, a końcową przez K1 (patrz 839a). Następnie, w oknie ‘korelacje’, wybrałem produkt dla drugiego wykresu. Oznaczmy jego początkową datę przez P2, a końcową przez K2. Patrz 839b: P1 = P2 < K2 < K1. Następnie wybrałem produkt dla trzeciego wykresu. Oznaczmy jego początkową datę przez P3, a końcową przez K3. Patrz 839c: P1 = P2 < K2 < P3 < K3 = K1 A zatem, koniec drugiego wykresu, poprzedza początek trzeciego wykresu. Spójrzmy teraz na tablicę korelacji na ekranie 839d: data początku okresu korelacji jest późniejsza niŜ data końca tego okresu, a wartości korelacji są puste. 7. Jest pełny i kompletny. Oszczędzanie przez testera czasu na sporządzaniu opisów błędów, skutkuje często stratą znacznie większej ilości czasu przez programistę, a następnie – przez tegoŜ testera w trakcie weryfikacji poprawionego błędu. Dlatego (dla zaoszczędzenia czasu własnego i współpracowników), naleŜy opisywać błędy w sposób pełny i kompletny. Strona 28 z 42
  29. 29. TESTER.PL Przykład. Kategoria: Wybieranie danych przy uŜyciu kryteriów selekcji. Ekran: 885a, 885b, 885c, 885d, 885e, 885f, 885g, 885h Krótki opis: Automatyczne przeładowywanie jest czasem wyłączane przez program po zmianie kryteriów selekcji, i pozostaje potem wyłączone. Długi opis: Wykonałem następujące czynności: Wybrałem produkt, i wyświetliłem dla niego wykres (patrz 885a). Wyłączyłem automatyczne przeładowywanie, i wybrałem atrybut (patrz 885b). Włączyłem automatyczne przeładowywanie, i wybrałem nowy atrybut. Ukazała się nazwa produktu, oraz komunikat: ‘brak danych dla tego produktu’ (patrz 885c). Ukazał się komunikat ‘nie znaleziono produktu, odtworzony zostanie poprzedni wykres’ (patrz 885d). Poprzedni atrybut został odtworzony, a automatyczne przeładowywanie zostało wyłączone przez program (patrz 885e). Ponownie włączyłem automatyczne przeładowywanie, i ponownie wybrałem nowy atrybut. Ukazał się komunikat: ‘niepoprawna wartość’, i automatyczne przeładowywanie zostało wyłączone przez program (patrz 885f). Ukazał się komunikat ‘nie znaleziono produktu, odtworzony zostanie poprzedni wykres’ (patrz 885g). Wyświetlony został pusty wykres, a automatyczne przeładowywanie pozostało wyłączone (patrz 885h). 8. Uwzględnia okoliczności. Sporządzając opis błędu, naleŜy brać pod uwagę, kto go będzie czytał. Jeśli np. program wypisuje komunikaty po angielsku, błąd polega na tym, Ŝe jakiś komunikat jest nieprawidłowy, a tak się składa, Ŝe tester zna angielski lepiej od programisty, to warto w opisie błędu zamieścić treść komunikatu taką, jaka powinna być, Ŝeby programista mógł to skopiować i wkleić do programu. Przykład. Kategoria: Import danych. Krótki opis: Mylący komunikat o błędzie. Długi opis: Jeśli uŜytkownik próbuje zaimportować bazę danych, której nazwa jest taka sama jak nazwa juŜ istniejącej bazy, ale identyfikator jest inny, wyświetlany jest następujący komunikat: 'There is a database with this name: ... Please change database name’. To jest mylące, poniewaŜ problem nie polega na tym, Ŝe baza o takiej nazwie istnieje, tylko Ŝe te dwie bazy mają takie same nazwy, i inne identyfikatory. A zatem, komunikat o błędzie powinien raczej brzmieć: 'There exists a database with the same name: ..., and different ID: ... Please remove inconsistency by changing either the name or the ID of the database in the file being imported’. 9. Jeśli trzeba – zawiera uzasadnienie. MoŜe się zdarzyć, Ŝe powód, dla którego trzeba coś zmienić w programie, nie jest oczywisty. Np. programista dobrał długość pola do spodziewanej wielkości danych, a tester zauwaŜył, Ŝe mogą się zdarzyć dane, dla których taka długość nie wystarczy. W takim przypadku, w opisie błędu naleŜy jasno powiedzieć, dlaczego potrzebna jest zmiana. Innym przypadkiem, wymagającym uzasadnienia, jest sytuacja, gdy błędowi przypisujemy priorytet, który wydaje się nieadekwatny. Np. gdy istnieje podejrzenie, Ŝe niegroźny z pozoru błąd moŜe być de facto oznaką jakiejś powaŜnej usterki. Strona 29 z 42
  30. 30. TESTER.PL Przykład. Kategoria: Administracja. Ekran: 1034a, 1034b, 1034c Krótki opis: Baza danych staje się większa po zreperowaniu. Długi opis: Zaimportowałem bazę danych, otworzyłem okno ‘zarządzanie bazami danych’, i zauwaŜyłem, Ŝe rozmiar tej bazy wynosi 23.79 MB (patrz 1034a). Następnie wykonałem reperację bazy (patrz 1034b). Po zreperowaniu, rozmiar bazy wynosił 24.81 MB (patrz 1034c). Przypisuję tej sprawie priorytet 1, poniewaŜ reperacja powinna pociągnąć za sobą zmniejszenie rozmiaru bazy danych, więc jeśli baza stała się większa po zreperowaniu, moŜe to oznaczać, Ŝe nasza procedura reperująca nie działa właściwie. 10. Jeśli to moŜliwe – zawiera propozycje rozwiązań. Jeśli błąd nie jest przyczyną pomyłki w kodzie, lecz wynika z przyjęcia niewłaściwych rozwiązań analityczno – projektowych, a tester potrafi zaproponować lepsze rozwiązanie, to zawsze warto o tym napisać w opisie błędu. Przykład. Kategoria: Import danych. Krótki opis: Liczba zaimportowanych rekordów, róŜni się od spodziewanej liczby. Długi opis: W oknie ‘import danych z serwera’, wybrałem bazę ‘ger_soft’, i zaznaczyłem pole ‘sprawdź daty i liczbę rekordów’. Wyświetlona została całkowita liczba rekordów: 82. Następnie wykonałem import. Po zakończeniu importu, sprawdziłem tablicę ICCE_TRANS w docelowej bazie danych, i okazało się, Ŝe zaimportowanych zostało 58 rekordów. Dowiedziałem się od programisty, Ŝe przyczyną były prawdopodobnie puste rekordy w tablicach słownikowych źródłowej bazy danych. Ze względu na te rekordy, kilkanaście rekordów z tablicy ICCE_TRANS w źródłowej bazie danych, zostało pominiętych przy tworzeniu złączenia. Myślę Ŝe najlepszym rozwiązaniem byłoby utworzenie kluczy na bazie źródłowej, Ŝeby taka sytuacja nie była moŜliwa. Jeśli klucze nie zostaną utworzone, proponowałbym wykonywać złączenie zewnętrzne, a następnie zapisywać do logu rekordy, które nie mogły zostać zaimportowane. Jeśli takie rozwiązanie byłoby zbyt czasochłonne, powinniśmy przynajmniej wyświetlać komunikat, informujący uŜytkownika, Ŝe określona liczba rekordów nie mogła zostać zaimportowana. Dzięki temu uŜytkownik będzie wiedział, dlaczego faktyczna liczba zaimportowanych rekordów, róŜni się od liczby oczekiwanej. 11. Jeśli to wskazane – zawiera dodatkowe informacje. Jeśli tester zauwaŜy coś, co wprawdzie nie ma bezpośredniego związku z błędem, ale moŜe pomóc programiście w wykryciu przyczyny błędu, powinien o tym napisać. Np. jeśli w jakiejś opcji programu jest błąd, ale inna opcja, chociaŜ podobna do tej pierwszej, działa poprawnie. Przykład. Kategoria: Korelacje. Ekran: 867a, 867b, 867c, 867d Krótki opis: Nie moŜna wybrać produktu do korelacji. Długi opis: Wybrałem produkt w oknie ‘wybór danych’ (patrz 867a), i kliknąłem ‘korelacje’. Ukazał się komunikat ‘błędna wartość’ (patrz 867b), następnie kilka innych komunikatów o błędach, i na koniec otworzyło się puste okno korelacji (patrz 867c). UWAGA: nie miałem problemu z wyświetleniem wykresu dla tego produktu (patrz 867d). Strona 30 z 42
  31. 31. TESTER.PL Tekst sponsorowany Strona 31 z 42
  32. 32. TESTER.PL Tekst sponsorowany Strona 32 z 42
  33. 33. TESTER.PL Warto czytać Mariusz Janczewski Mariusz Janczewski Jest absolwentem matematyki Uniwersytetu Gdańskiego. Ukończył Podyplomowe Studium InŜynierii Oprogramowania na Politechnice Gdańskiej oraz Studium Bankowości i Finansów w Gdańskiej Akademii Bankowej. Pracował jako programista i szkoleniowiec. Zajmował się testowaniem, prowadzeniem wdroŜeń i wsparciem uŜytkowników. Brał udział w licznych projektach w sektorze bankowym i ubezpieczeniowym. Interesuje się inŜynierią oprogramowania, szczególnie zaś zagadnieniami zapewnienia jakości. Obecnie pracuje w firmie ATENA Usługi Informatyczne i Finansowe, www.atena.pl, jako Starszy Konsultant Strona 33 z 42
  34. 34. TESTER.PL Warto czytać Mariusz Janczewski Na jednej z konferencji dotyczącej zagadnień IT kilka dni temu natknąłem się na cytat, który poruszył mnie swoja celnością. Z pomocą przyszły „google” i okazało się, Ŝe autorem stwierdzenia jest pan Martin Cobb ze Standish Group (Martin Cobb, (1996). “Unfinished Voyages: a follow-up to the CHAOS Report”, Standish Group Report, http://www.standishgroup.com/sample_research/unfinished_voyages_1.php Viewed Nov 17, 2003). Cytat brzmi: “Wiemy, czemu projekty kończą się niepowodzeniem, wiemy jak przeciwdziałać niepowodzeniom - zatem dlaczego projekty nadal nie udają się?” Cytat nie jest zbytnio optymistyczny, ale za to niesie powaŜny ładunek realizmu. Nasza praca polega na doprowadzaniu projektów do końca i to co waŜne z sukcesem (sukces wiadomo: na czas, w budŜecie, z określonym poziomem jakości). CzyŜbyśmy stali zatem na straconych pozycjach? MoŜe wydawać się, Ŝe tak jest w istocie. Statystyki publikowane przez instytucje badawcze pokazują, Ŝe sytuacja powoli, ale ulega poprawie (to prawda, Ŝe dane pochodzą zwykle z USA, bądź innych krajów zachodnich – ciekawe jak rzecz ma się w naszym kraju?). Coraz więcej projektów kończy się osiągnięciem celu, przynosząc korzyść biznesową Klientom i chwałę dostawcom IT. A jest to osiągane dzięki trudnej i Ŝmudnej nauce na własnych i cudzych błędach. Dzięki stosowaniu dobrych i najlepszych praktyk, dzięki dostosowywaniu metod wytwarzania właściwych do zleconego zadania, dzięki lepszej współpracy z klientem i większej uwadze poświęcanej kwestii zapewnienia jakości. Jednym z narzędzi, które mogą w tym pomóc jest sięganie po wiedzę. Stąd częste pytania na przeróŜnych forach: chcę zostać testerm, od czego zacząć? co tester powinien wiedzieć?, czy testowania moŜna się nauczyć i jak to zrobić? jakie ksiąŜki powinien przeczytać? Wydaje się oczywistym, Ŝe sama lektura nie sprawi z nas lepszych testerów lub innych uczestników projektów IT. Nie kaŜda ksiąŜka moŜe trafić do kaŜdego. Sama lektura to zbyt mało, aby z dnia na dzień stać się dobrym, lepszym pracownikiem. Jak kaŜde dobre narzędzie, lektura ksiąŜek o testowaniu, czy teŜ ogólniej o wytwarzaniu oprogramowania, moŜe pomóc wykonywać nam naszą pracę lepiej. MoŜe pomóc nam w komunikacji z innymi uczestnikami projektu (nie tylko analitykami i programistami, ale takŜe z przedstawicielami Klienta – przecieŜ oni takŜe biorą udział w testowaniu!). Zatem naprawdę warto czytać i starać się wykorzystywać, to, co dobre w codziennej pracy. JuŜ dawno deklarowałem, Ŝe postaram się zebrać kilka tytułów dotyczących testowania i inŜynierii oprogramowania w jednym miejscu. W końcu to czynię. Proszę nie traktować tej listy jako zamkniętej, najlepszej, itp. Jest to moja propozycja tytułów według mnie wartych uwagi. Nie podejrzewam, Ŝe udało się mi zebrać wszystko, co pojawiło się na ten temat na Strona 34 z 42
  35. 35. TESTER.PL polskim rynku. Ale mam nadzieję, Ŝe z Waszą pomocą uda się co pewien czas na (oby regularnie ☺ publikować krótkie opisy ksiąŜek, które mogą być interesujące dla członków SJSI i nie tylko. Przyznam, Ŝe mam juŜ kilka propozycji do kolejnego numeru Testera.pl.17 Moją intencją, wzorowaną na podobnej praktyce, którą podejrzałem w "Professional Tester", było podjęcie próby "klasyfikacji" tytułów pod względem ich "bliskości" względem tematyki testowania. Stąd wprowadzenie skali od 1 – Ŝadne powiązanie z testowaniem do 5 – specjalistyczna pozycja poświęcona testowaniu. PoniewaŜ testowanie, to jakby nie patrzeć jeden z etapów w procesie wytwarzania oprogramowania. Na liście musiały pojawić się nie tylko pozycje ściśle dotyczące testowania, ale takŜe bardziej ogólne pozycje dotyczące inŜynierii oprogramowania czy teŜ konkretnych metod i narzędzi. Autor - zespół pod Janusz Górski Tytuł - InŜynieria oprogramowania w projekcie informatycznym Warszawa 2000, wydanie II 462 stron, format: B5, oprawa: miękka ISBN: 83-7279-028-0 MIKOM www.mikom.pl Nakład juŜ niestety wyczerpany Testowanie: 2 Teoria inŜynierii oprogramowania KsiąŜka obejmuje szeroki zakresu zagadnień związanych z realizacją projektów informatycznych. Materiał obejmuje: budowanie i zarządzanie projektem z zakresu informatyki i inŜynierii oprogramowania, właściwą identyfikację i definicję wymagań oraz opis działań związanych z zapewnieniem odpowiedniej jakości powstającego oprogramowania. KsiąŜka przeznaczona jest dla studentów informatyki, kierowników projektów, projektantów i programistów systemów informatycznych. Niektóre z rozdziałów nie są łatwe w lekturze ze względu na swój akademicki styl i charakter. Całość jest jednak warta uwagi. ChociaŜ obecnie juŜ niedostępna na rynku. 17 Redakcja zaprasza wszystkich Czytelników do dodawania swoich do zaproponowanej w tym numerze Biblioteki Testera. TeŜ mamy kilka propozycji. Strona 35 z 42
  36. 36. TESTER.PL Autor – pod red. Stanisława Szejko Tytuł - Metody wytwarzania oprogramowania Warszawa 2002, wydanie I 328 stron, format: B5, oprawa: miekka ISBN: 83-7279-283-6 MIKOM - www.mikom.pl 29.5 zł Testowanie: 3 Teoria inŜynierii oprogramowania KsiąŜka omawia kluczowe zagadnienia wytwarzania oprogramowania – tradycyjne i współczesne cykle Ŝycia, strukturalne i obiektowe technologie wytwórcze oraz metody przekształcania projektu w działający program. Prezentowane są środowiska wspomagające wytwarzanie programów sekwencyjnych i równoległych oraz zasady organizacji i zarządzania procesem wytwórczym. KsiąŜka prezentuje nowoczesne strukturalne i obiektowe metody programowania, zagadnienia związane z projektowaniem oraz narzędzia wspomagające pracę zespołu deweloperskie. Za wadę moŜna by uznać to, Ŝe jest to ksiąŜka bardzo teoretyczna – trudno jednak nie zgodzić się z zasadą, Ŝe bez teorii nie ma mowy o praktyce. Autor - Pressman Roger S. Tytuł - Praktyczne podejście do inŜynierii oprogramowania Tłum. z ang. B. Klin 2004, 185 x 235, s. 866, rys. 210, tabl. 7, oprawa twarda Seria „InŜynieria Oprogramowania” ISBN 83-204-2933-1 Cena 139 zł Testowanie: 4 Teoria inŜynierii oprogramowania Wydawnictwa poleca tę ksiąŜkę architektom i projektantom oprogramowania, programistom, ludziom zajmującym się wdraŜaniem oprogramowania, szefom przedsięwzięć programistycznych i menedŜerom firm informatycznych, a takŜe studentom informatyki, którzy przed podjęciem pracy zawodowej powinni wiedzieć, na czym w praktyce polega inŜynieria oprogramowania. Jak mówi tytuł ksiąŜka zajmuje się wytwarzaniem oprogramowania. Jest napisana w bardzo dostępnym stylu. To jeden z moich ulubionych tytułów. Strona 36 z 42
  37. 37. TESTER.PL Autor - Sommerville Ian Tytuł - InŜynieria oprogramowania Tłum. z ang. K. Stencel 2003, B5, s. 686, rys. 379, oprawa twarda Seria „Klasyka Informatyki” ISBN 83-204-2795-9 Cena 69 zł Testowanie: 4 Teoria inŜynierii oprogramowania KsiąŜka jest znakomitym podręcznikiem. KaŜdy rozdział kończy się krótkim podsumowaniem poruszanych w nim zagadnień, opisem zalecanej literatury i zestawem ćwiczeń do samodzielnego rozwiązania. Wydawnictwa polecają ją studentom informatyki, a takŜe ludziom uczestniczącym w duŜych przedsięwzięciach programistycznych – architektom systemów, projektantom, programistom, wdroŜeniowcom. Skorzystają z niej równieŜ kierownicy tych przedsięwzięć, od których zaleŜy organizacja pracy. Autor - Ron Patton Tytuł - Testowanie oprogramowania Warszawa 2002, wydanie I przekład Bogdan Bereza-Jarociński Seria: Biblioteka programisty 390 stron, format: B5, oprawa: miękką ISBN: 83-7279-239-9 44.4 zł Testowanie: 5 Teoria inŜynierii oprogramowania Co tu duŜo wspominać, to chyba pierwsza ksiąŜka na naszym rynku poświęcona w całości testowaniu, recenzja ksiąŜki trafiła juŜ kiedyś na witrynę sjsi.org. KsiąŜka moŜe się podobać, bądź nie. Jej zawartość moŜe nie satysfakcjonować bardziej doświadczonych czytelników, ale bez względu na to jest to według mnie pozycja z serii „must read”. Strona 37 z 42
  38. 38. TESTER.PL Autor - Binder Robert V. Tytuł - Testowanie systemów obiektowych. Modele, wzorce i narzędzia Tłum. z ang. Z. Płoski 2003, 185 x 235, s. 1250, rys. 240, tabl. 158, oprawa twarda Seria „InŜynieria Oprogramowania” ISBN 83-204-2764-9 Cena 239 zł Testowanie: 5 Zajmujesz się testowaniem systemów obiektowych. Ba zajmujesz się testowaniem w ogóle – powinieneś sięgnąć po tę pozycję. Autor omawia w niej róŜne aspekty modelowania systemu. Wiele uwagi poświęca przy tym językowi UML. Udziela praktycznych rad projektantom testów, wykorzystującym metodykę obiektową. Opisuje róŜne narzędzia programistyczne wspomagające testowanie. Jest to znakomity podręcznik, z wieloma wskazówkami i przykładami (w C++, Javie i Adzie), a takŜe z wyczerpującą bibliografią. Wprawdzie objętościowo straszna cegła, ale „must read” koniecznie. Autor: Joseph Schmuller Tytuł - UML dla kaŜdego Tłumaczenie: Krzysztof Masłowski ISBN: 83-7361-107-X Tytuł oryginału: Teach Yourself UML in 24 Hours Format: B5, stron: 376 Data wydania: 06/2003 Cena ksiąŜki: 45.00 zł Testowanie: 1 Teoria inŜynierii oprogramowania UML jest narzędziem do tworzenia obiektowo zorientowanych systemów. Jest to język modelowania wizualnego. UML dostarcza teŜ mechanizmy ułatwiające efektywną wymianę informacji i przekazywanie projektów innym. KsiąŜka uczy tworzenia diagramów za pomocą tego języka modelowania. Proste wyjaśnienia i metoda prowadzenia za rękę krok po kroku w kaŜdym rozdziale, pozwalają na poznanie podstaw tego języka i zrozumienie jego zastosowań Strona 38 z 42
  39. 39. TESTER.PL Autor - Kent Beck, Cynthia Andres Tytuł - Wydajne programowanie - Extreme programming Tłumaczenie: Piotr Nowakowski Wydawnictwo MIKOM Warszawa, 2006 r. ISBN: 83-7279-508-8 Wydanie: Drugie Objętość: s. 176 Format: 16,5x24 cm Oprawa: Miękka MIKOM – http://mikom.pwn.pl/ 39,90 zł Testowanie: 3 Teoria inŜynierii oprogramowania KsiąŜka jest kolejnym wydaniem podręcznika Kenta Becka opisującego zasady tworzenia oprogramowania według zaproponowanej przez autora metodyki XP. W ksiąŜce moŜna teŜ znaleźć wiele innych konkretnych metod pracy opartych na filozofii, która kładzie nacisk na jednoczesne zwiększanie efektywności i ludzkiego podejścia do pracy zespołów w tworzeniu oprogramowania. Autor - Bays Michael E. Tytuł - Metodyka wprowadzania oprogramowania na rynek Tłum. z ang. Bartosz Klin 2001, s. 248, rys. 84, tabl. 22, oprawa twarda ISBN 83-204-2631-6 Cena 60 zł Testowanie: 3 Teoria inŜynierii oprogramowania KsiąŜka napisana juŜ nieco czasu temu (omawiana są jeszcze dyskietki 5¼ cala jako mediów dystrybucji oprogramowania), zawiera jednak wiele nadal obowiązujących wskazówek dotyczących m.in.: kontroli kodu źródłowego, kompilacji, testowania (jeśli ktoś poszukuje propozycji schematu obiegu zgłoszenia błędu w firmie, to tu ją właśnie znajdzie ☺, integracji kodu , numeracji wersji, dystrybucję oprogramowania. Strona 39 z 42
  40. 40. TESTER.PL Autor - Brooks Frederick P., Jr. Tytuł - Mityczny osobomiesiąc. Eseje o inŜynierii oprogramowania Tłum. z ang.A. Ehrlich 2000, B5, s. 295, rys. 26 oprawa miękka Seria "Ludzie - Komputery - Informacja" ISBN 83-204-2467-4 Cena 45 zł Testowanie: 2 Teoria inŜynierii oprogramowania To światowy bestseller z dziedziny inŜynierii oprogramowania i zarządzania. Składają się nań eseje dotyczące wytwórstwa wielkich systemów informatycznych. Poruszone są sprawy jednorodności systemów i problemów na linii projektant - wykonawca. Autor przeprowadza analizę nakładów pracy na powstanie systemu; porusz sprawę kosztów, właściwej dokumentacji i modyfikacji systemu. Uwzględnia więc wszystko, co dotyczy tworzenia systemu - od koncepcji do dokumentacji i wdroŜenia. Podkreśla teŜ znaczenie pracy zespołowej. KsiąŜka jest przeznaczona dla studentów informatyki. Skorzystają z niej jednak takŜe projektanci systemowi, ekonomiści i kadra zarządzająca. Strona 40 z 42
  41. 41. TESTER.PL Autor - Cooper Alan Tytuł - Wariaci rządzą domem wariatów. Dlaczego produkty wysokich technologii doprowadzają nas do szaleństwa i co zrobić, Ŝeby tego uniknąć Tłum. z ang. J.Bloch 2001, B5, s.302, rys.60 Seria "Ludzie - Komputery - Informacja" ISBN 83-204-2605-7 Cena 55 zł Testowanie: 3 Teoria inŜynierii oprogramowania Autor-Twórca języka Visual Basic - staje w obronie zwykłego człowieka, czyli uŜytkownika, o którym zupełnie się nie pamięta podczas tworzenia kolejnych cudów elektronicznych. Stawia teŜ tezę, Ŝe przemysł oprogramowania przeŜywa kryzys spowodowany dwoma czynnikami: pędem firm do częstego wypuszczania na rynek nowych wersji programów, co wiąŜe się z walką konkurencyjną, i obniŜeniem kosztów opracowywania oprogramowania przez wyeliminowanie etapu badania potrzeb klienta. Dogłębnie analizuje proces powstawania oprogramowania - zarówno takiego, jakie powinno być, jak i takiego, jakie zwykle jest. Podkreśla, jak waŜną sprawą jest włączenie do procesu tworzenia produktów oprogramowanych oddzielnego etapu projektowania, poprzedzającego sam proces programowania. Uświadamia nam źródła patologii, której skutki odczuwamy na co dzień, i radzi, jak się z nimi uporać. KsiąŜka jest przeznaczona dla szerokiego kręgu odbiorców. Strona 41 z 42
  42. 42. TESTER.PL Autor - DeMarco Tom, Lister Timothy Tytuł - Czynnik ludzki. Skuteczne przedsięwzięcia i wydajne zespoły Tłum. z ang. A. Ehrlich 2002, B5, s. 260 Seria „ Ludzie – Komputery – Informacja” ISBN 83-204-2718-5 Cena 45 zł Testowanie: 1 Teoria inŜynierii oprogramowania Powodzenie przedsięwzięcia programistycznego zaleŜy od ludzi biorących w nim udział. Wielkie znaczenie ma więc umiejętne zarządzanie nimi i praca zespołowa. O tym właśnie traktuje ta ksiąŜka. Praca programisty jest uciąŜliwa, ale moŜe dawać zadowolenie, a w konsekwencji zapewnić sukces. Czytelnik dowie się, jak utworzyć dobry zespół programistów, co zrobić, by był wydajny, jakie stworzyć mu warunki pracy. Zrozumie, jak waŜna jest praca zespołowa, która daje więcej satysfakcji niŜ praca indywidualna. Dowie się, jak utworzyć zgrany zespół, gwarantujący sukces, jak dobrać ludzi, jak motywować ich do pracy. Uwaga: Autor Tim Lister ma być gościem zbliŜającej się konferencji III Konferencja Jakości Systemów Informatycznych !!! Autor - Tom DeMarco Tytuł - ZdąŜyć przed terminem - opowieść o zarządzaniu projektami wydawnictwo: Studio Emka, Marzec 2002 ISBN: 83-88931-08-3 liczba stron: 287 wymiary: 145 x 205 mm okładka: miękka tłumaczenie: Witold Turopolski Testowanie: 1 Teoria inŜynierii oprogramowania KsiąŜka barwnie opisuje podstawowe zasady oraz absurdy rządzące pracą zespołu zajmującego się tworzeniem oprogramowania. DeMarco w formie sfabularyzowanej, zajmująco i dowcipnie, opisuje proces tworzenia sześciu programów komputerowych. Pozycja było juŜ opisywana na witrynie sjsi.org. Jest to jedna z moich ulubionych ksiąŜek. Strona 42 z 42

×