Wysoka Dostępność Windows Server 2008 w kontekscie umów SLATobias Koprowski
To trzecia prezentacja w cztero-częściowym cyklu omawiającym znaczenie wysokiej dostepności w kontekście umów SLA. Prezentacje przeznaczone są dla odbiorców z kręgu ITPro, a publikowane na zywo na portalu VirtualStudy.pl
***
This is third part of my four-parts cycle about Service Level Agreement for ITPros. It a session for Virtualstudy.pl education portal.
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...Mikolaj Leszczuk
Zapewnianie nie tylko wysokiego poziomu tradycyjnej jakości usług (ang. Quality of Service, QoS), ale także jakości doświadczanej (ang. Quality of Experience, QoE) jest wyzwaniem dla dostawców usług internetowych, usług audiowizualnych, nadawców oraz nowych dostawców usług Over-The-Top (OTT). W celu monitorowania i rozwiązywania problemów, a także analizowania i ustanawiania wzorców jakości dla aplikacji treści pracujących w czasie rzeczywistym lub offline często są realizowane obiektywne metryki treści audiowizualnych. Od 2000 roku prace związanie z pojęciem QoE w kontekstach różnych aplikacji nabrały tempa i zyskały szerokie uznanie biznesowe. Roboczą definicję QoE podaje biała księga sieci QUALINET: „QUALINET White Paper on QoE Definitions” z 2012 roku:
„Quality of Experience (QoE) jest stopniem zadowolenia lub irytacji użytkownika aplikacji lub usługi. QoE wynika z realizacji oczekiwań użytkownika względem użyteczności i/lub zadowolenia z aplikacji lub usługi w świetle aktualnych preferencji użytkownika.”
Prezentacja z webinarium: Rodo: 5 wyzwań dla audytu wewnętrznego
W jaki sposób audyt wewnętrzny powinien wspierać przygotowania do RODO?
Więcej: https://pwc.to/2K9gUHW
Prezentacja zawiera informacje o standardzie standard pomiaru widowni internetowej w Polsce na lata 2016-2020. Pokazuje historię konkursu ofert, kryteria wyboru wykonawcy oraz koncepcję nowego badania. Prezentacja została wygłoszona przez Andrzeja Garapicha i Matthiasa Hartmanna podczas Forum IAB 2015.
To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language.
Model-based testing is an increasingly popular trend in the world of quality assurance. The aim of such an approach is to focus on a working system model and automatically generate test cases. However, how can it become useful in the work of a business or system analyst? The essence is in the model. It is called an executable specification. In this approach, it can take the form of code, gherkin syntax or UML graphs and diagrams. The latter is something that analysts use every day. In my presentation, I would therefore like to show how model-based testing can be used in the work of analysts. And how this approach can improve the work of the project team.
Wysoka Dostępność Windows Server 2008 w kontekscie umów SLATobias Koprowski
To trzecia prezentacja w cztero-częściowym cyklu omawiającym znaczenie wysokiej dostepności w kontekście umów SLA. Prezentacje przeznaczone są dla odbiorców z kręgu ITPro, a publikowane na zywo na portalu VirtualStudy.pl
***
This is third part of my four-parts cycle about Service Level Agreement for ITPros. It a session for Virtualstudy.pl education portal.
Badanie i implementacja aspektu QoE (ang. Quality of Experience) w aplikacjac...Mikolaj Leszczuk
Zapewnianie nie tylko wysokiego poziomu tradycyjnej jakości usług (ang. Quality of Service, QoS), ale także jakości doświadczanej (ang. Quality of Experience, QoE) jest wyzwaniem dla dostawców usług internetowych, usług audiowizualnych, nadawców oraz nowych dostawców usług Over-The-Top (OTT). W celu monitorowania i rozwiązywania problemów, a także analizowania i ustanawiania wzorców jakości dla aplikacji treści pracujących w czasie rzeczywistym lub offline często są realizowane obiektywne metryki treści audiowizualnych. Od 2000 roku prace związanie z pojęciem QoE w kontekstach różnych aplikacji nabrały tempa i zyskały szerokie uznanie biznesowe. Roboczą definicję QoE podaje biała księga sieci QUALINET: „QUALINET White Paper on QoE Definitions” z 2012 roku:
„Quality of Experience (QoE) jest stopniem zadowolenia lub irytacji użytkownika aplikacji lub usługi. QoE wynika z realizacji oczekiwań użytkownika względem użyteczności i/lub zadowolenia z aplikacji lub usługi w świetle aktualnych preferencji użytkownika.”
Prezentacja z webinarium: Rodo: 5 wyzwań dla audytu wewnętrznego
W jaki sposób audyt wewnętrzny powinien wspierać przygotowania do RODO?
Więcej: https://pwc.to/2K9gUHW
Prezentacja zawiera informacje o standardzie standard pomiaru widowni internetowej w Polsce na lata 2016-2020. Pokazuje historię konkursu ofert, kryteria wyboru wykonawcy oraz koncepcję nowego badania. Prezentacja została wygłoszona przez Andrzeja Garapicha i Matthiasa Hartmanna podczas Forum IAB 2015.
To explore strange new worlds, to seek out new life and new civilisations, to boldly go where no man has gone before.” Just like the crew of the USS Enterprise, we explore the IT universe – seeking out new solutions, new technologies, and frameworks – from which we can learn to help us work better and more efficiently. We do this to create more functional and usable software for our customers, to put a big smile on their faces, and maybe – if we do our job really well – to make them stand back and admire what we have crafted. I was lucky enough to work in BDD (Behaviour Driven Development) quite early in his career, but I also had the misfortune to see how this great idea so often tends to fail. In my presentation I wanted to show what it is like working with BDD and what value can it give to business people. Finally I would like to propose an effective, alternative solution for well-known BDD tools, which is „Spock” – a convenient, lightweight framework, based on the Groovy language.
Model-based testing is an increasingly popular trend in the world of quality assurance. The aim of such an approach is to focus on a working system model and automatically generate test cases. However, how can it become useful in the work of a business or system analyst? The essence is in the model. It is called an executable specification. In this approach, it can take the form of code, gherkin syntax or UML graphs and diagrams. The latter is something that analysts use every day. In my presentation, I would therefore like to show how model-based testing can be used in the work of analysts. And how this approach can improve the work of the project team.
Did you know, that 65% of our average workday is COMMUNICATION with our colleagues? Communication is really essential in our daily life. It can make or break a project we are working on! Bad communication makes us not only lose valuable time, but money and resources as well. Let’s have a look at the style different people use to communicate, and on the different approaches we can use to make our communication more effective, and stop wasting time in meetings, that we never needed to have if we communicated properly. I will teach you the best tips and tricks to succeed in communication with your colleagues and partners to make your project great again!
Jakakolwiek komunikacja odbywa się w relacji. Wywieranie wpływu, perswazja, przekonywanie odbywa się w ramach relacji. Praca analityka biznesu z klientem odbywa się w ramach utworzonych relacji. Kto opanuje sztukę perswazji zyskuje niezwykłą przewagę w procesie kontaktu z klientami. Przewaga ta jednak nie polega na znajomości jakiejś techniki, z którą wchodząc do klienta doprowadzamy go do współpracy i uzyskujemy niezbędne informacje. To nie jest technika, to idealne dopasowanie się do klienta, odkrycie jego potrzeby i zaspokojenie jej. Najważniejsze jest to, że liczą się niuanse, drobne szczegóły, a jednocześnie całość.
Wiele lat temu podczas rozmowy rekrutacyjnej prezes jednej firmy powiedział do mnie: błędy popełniane na etapie analizy są najdroższe dla firmy. Wtedy była to dla mnie teoria, którą rozumiałam, ale za dużo na sobie nie doświadczyłam albo też nie potrafiłam ocenić skali czy wczuć się w powagę tych słów ☺ Każdy projekt, w którym brałam udział, każde doświadczenie dokładał kolejny kawałek do pewności co robię dobrze, a co źle, przyczyniał się do zmniejszenia ryzyka popełnienia błędu. Zazwyczaj uczymy się na własnych błędach, ale wiemy też, że najtaniej uczyć się na cudzych. Tylko nie zawsze to działa ☺ Zapraszam do edycji drugiej mojego wystąpienia „Błędy w analizie, co robić, i czy da się ich uniknąć” ☺ Opowiem o kilku kolejnych typowych potknięciach, które się zdarzają każdemu i o tym, jakie ja mam sposoby na przeciwdziałanie pojawieniu się podobnych kolejnych.
The 7 Skills model helps IT projects to become more successful by addressing the key success factor of all teams: the soft skills of the team members. The model starts from two assumptions: (a) true success is a matter of good teamwork and (b) good teamwork is based on emotional interactions between individuals. The model is aligned along two axes: the ‘Customer facing’ - ‘Team facing’ axis and the ‘Problem facing’ – ‘Solution facing’ axis. In the center is ‘Communication’ as the fundamental skill that is the starting point for all interactions. Arranged around this core you find six key skills that are important for every IT project: ‘Empathize’ (customer/problem), ‘Explore’ (team/problem), ‘Collaborate’ (team), ‘Ideate’ (team/solution), ‘Tell’ (customer/solution) and ‘Sell’ (customer). The 7 Skills model serves as a road map to improve human interactions in development projects. To implement it, each skill has been substantiated by one or more simple but proven techniques. To mention some: communicate – Shannon-Weaver model; empathize – Personas; Explore – goal trees; Collaborate – Belbin team roles; Ideate – Wallas’ creativity model; Tell – storyboarding; Sell – Cialdini’s principles. These techniques of the 7 Skills model can easily be presented and explained. However, to make them work, one should exercise them. Therefore, a workshop is an excellent way to transfer the concept: you will learn most by actually doing it. In this workshop, you will work with other participants in a small team to design the outlines of a simple IT system. We will explain all techniques and give you some practical exercises with a challenging selection of them.
As Business Analysts we encounter difficult customers every day. That is why we need a specific toolset to deal with such people and create win-win situations for our projects. The main goal of this workshop is to give you such an arsenal. The whole workshop will be divided into three parts: 1. How to identify different type of customers and how to negotiate with them – you will get familiarized with several different types of personalities and learn how to analyze your own stakeholders with these properties. For each type we will define the specific set of tools to be used during meeting and in day-to-day work. Afterwards I will ask you to characterize some of the people that you are working with to seek out the best approach to negotiate with them 2. Visualizing goals as a part of creating interactive meetings – you will learn how to create impact maps and how to use them in your work. As Impact Maps may be used not only in IT projects it’s a viable tool to be used even in your personal life. On this part we will also talk about design thinking and how it can be used to make your kick-offs/discoveries better. Therefore during this part of the workshop we will: a. Learn how to create good business goals b. Draw our own impact map (based on a created goal) c. Learn how to validate requirements using impact mapping technique d. Transform impact map into a backlog e. Learn about design thinking approach and how to use it in your work 3. Case studies and discussion – I will present several complex cases that I’ve encountered during my career and will describe business analysis techniques that I used. Afterwards we will analyze your own cases and try to find the appropriate solutions together.
Although there are few absolute truths in software development, I have discovered several requirements principles that apply almost universally to software projects. These principles emphasize the critical contribution that excellent requirements make to a project's success, and the critical contribution that customer involvement makes to excellent requirements. You'll hear several suggestions for practices that can help any team build a more effective customer-developer partnership. These cosmic truths can help your organization produce and manage accurate, consistent, and unambiguous sets of requirements.
Zagraj w zaangażowanie czyli jak dzięki grywalizacji angażować zespół projektowy. Graczy nie trzeba dodatkowo motywować do tego by chcieli osiągać kolejne poziomy w grze – dlaczego więc nie wykorzystać mechanizmów z gier do angażowania naszych zespołów projektowych by ułatwić im osiąganie celów? Możesz to zrobić dzięki grywalizacji, która w Polsce staje się coraz bardziej popularna. Fabuła, punkty, ranking, odznaki – to tylko niektóre ze stosowanych mechanizmów, które z codziennych zadań pracowników tworzą ich zawodową przygodę. Jak wpleść je w pracę naszego zespołu projektowego? Podczas wykładu nie tylko dowiecie się więcej o grywalizacji, ale będziecie mieli okazję sami zbudować koncepcję gry. Jakiej? Przyjdź i przekonaj się.
Analityk biznesowy analizuje biznes? W większości przypadków – nie. Projekty wypadają nam jak z czarnej skrzynki. Czy mają sens? Czasem trafiają jak kula w płot. Czasem są jak armata na muchę. Czasem nie rozwiązują właściwego, najbardziej naglącego problemu. A czasem decydent chce zabawkę lub awans, zapominając o klientach i rozwoju firmy. Czy to problem analityka? Czy Twój projekt jest właściwy dla firmy? Przyjrzyjmy się temu, co dzieje się ponad projektem - analizie prawdziwie biznesowej, analizie organizacji i analizie strategicznej. Rozwikłamy zagadkę - skąd biorą się sensowne projekty i dowiemy jak definiować potrzebne firmie inicjatywy.
If Internet of Things is all about connectivity and cooperation then Industry 4.0 is based on data. In fact - lots of data! We are no longer talking about GigaBytes or TeraBytes but rather such abstract ideas and units like ExaBytes. And that's the main topic of this presentation - how huge is IoT, what is the value of switching from reactive to predictive company and why we use lambda architecture in the first place. And even if the concept of security, ethics, rules and regulations regarding data itself is also interesting on its own, this time we will focus directly on Industry 4.0 itself. Fast paced and intense presentation dedicated for Analysts and people loving and caring about IoT.
Accessibility is a legal requirement in almost every country in the world. WCAG 2.1, Section 508 of the Rehabilitation Act, Equality Act 2010 these are examples how serious accessibility is. Accessibility means the ability of everyone regardless of their condition to have access to digital product, transport, physical products. The web and internets in whole is an increasingly resource in many aspect of our life, so it is important that the digital product be accessible to everyone in order to provide equal access and opportunity. Accessible is easy & low-cost if you as BA think about it on the early stage
The spread of Agile raises demanding challenges. If you’re a BA who’s faced with the situation when your organization is undergoing “agile” transformation, you might be looking for information about what this transformation means. There are some misconceptions about agile adoption and even more hype. The lecture introduces my personal experience of reaching organization’s Agile maturity from a Business Analyst perspective.
Biznes się zmienia. IT się zmienia. Ale czy narzędzia i metody pracy analityka i architekta zmieniają się lub powinny zmienić się - w szczególności w czasach coraz powszechniejszej robotyzacji procesów? W prezentacji będę starał się spojrzeć na relacje występujące między analitykiem-architektem a robotami z dwóch różnych perspektyw – tj. czy musimy inaczej niż do tej pory podejść do analizy i architektury zrobotyzowanego biznesu i jak roboty mogą pomóc w pracy analityka/architekta. Okazuje się bowiem, że coraz częściej wiele firm patrzy na analityków/architektów jako koszt (który może i przynosi korzyści, ale mocno odroczone w czasie) i zastanawia się, czy jest jakieś podejście umożliwiające podniesienie efektywności pracy tych ról.
Każdy nowy pomysł, który chcemy zrealizować korzystając czy to z zasobów firmy czy też wsparcia inwestorów, musimy umieć skutecznie przedstawić. Najczęściej decydenci nie mają zbyt dużo czasu, aby zapoznać się ze wszystkimi szczegółami projektu. Jak ich przekonać w ciągu 5 minut? Co ich najbardziej zainteresuje? Jak powinna wyglądać skuteczna prezentacja? Im lepiej ją przygotujemy, tym większą mamy szansę na decyzję zgodną z naszymi oczekiwaniami. Zapraszam do wspólnego przyjrzenia się modelowi krótkiego, skutecznego przedstawiana pomysłów, który przydaje się w kontaktach z decydentami korporacji, z klientami czy z inwestorami.
Despite years of efforts to improve the professional approach to developing software systems, many of these projects continue to fail. Investigations into these failures invariably denote poor interactions between humans, both within development teams and with customers and users, as a key factor. Recent evolution in development approaches, like human-centered design and extreme programming, try to address this problem, but until now, an overall view was missing. In this presentation we integrate these initiatives into a simple model, that arranges six key skills along two axes (customer–team and problem–solution) around communication as a core. Many techniques are available to implement these skills in development teams, so failure will no longer be the usual outcome.
Każdy z nas słyszał termin „testowanie techniczne”. Wielu z nas mówi o sobie z dumą „tester techniczny”. Rynek potrzebuje „testerów technicznych”. Czy jednak wszyscy zgadzamy się w rozumieniu tych terminów? Kto i na jakiej podstawie powinien decydować co jest, a co nie testowaniem technicznym?
Prezentacja na pograniczu filozofii i technikaliów próbuje usystematyzować terminologię i zamieszać w głowach słuchaczy.
Przychodzi tester do lekarza…
Można by tak rozpocząć opis tej prelekcji. Nie o lekarza jednak tu będzie chodziło, a o rozmowy rekrutacyjne i to, co na nich można usłyszeć. Jestem członkiem grupy rekrutacyjnej w mojej firmie. Przeprowadziłem naprawdę sporo takich rozmów. Jedne bardziej udane, inne trochę mniej. Zauważyłem jednak jeden trend, który ostatnio coraz częściej zaczął się pojawiać na rozmowach - chęć do rozwoju w kierunku automatyzacji testów. Czy jednak wiecie z czym to się je?
Prelekcja skierowana jest do ludzi mniej doświadczonych, którzy po okresie okrzepnięcia w zawodzie dopiero zaczynają zastanawiać się nad swoją przyszłością, nad ścieżką swojej kariery. Jako lider spotkałem się też z osobami, które nie były świadome, w jakich kierunkach może rozwijać się tester. A możliwości jest naprawdę wiele. Tylko co wybrać?
Sam przeszedłem bardzo ciekawą drogę. Zdobyłem bardzo różnorodne doświadczenie, miałem przyjemność obserwować ludzi, ich rozwój, wybory, które czasem nie były trafne. Chciałbym się zatem podzielić z wami moim doświadczeniem liderskim, pokazać jak wygląda droga w kierunku managera, test leada, jakie wyzwania czekają na tej drodze.
Chciałbym także opowiedzieć o tym, jak zostać testerem, który automatyzuje; pokazać jak wygląda dzień z życia takiego testera, jakie wyzwania czekają nas po drodze i czego potrzebujesz droga koleżanko, drogi kolego, aby być w tej działce kimś ciekawym, na kogo rekruter zwróci uwagę.
Chciałbym również porozmawiać trochę o motywacji, która sprawia, że ludzie wybierają właśnie tę drogę.Czy to tylko podążanie za modą? Wszak nie wszyscy będziemy automatyzować.
Powiem także kilka słów o innych ścieżkach kariery testerskiej, może mniej oczywistych, ale z życia wziętych, z pracy w moim zespole.
Wystąpienie to skierowane jest do ludzi dopiero rozpoczynających swoją karierę, lecz być może, że coś ciekawego znajdzie dla siebie doświadczony wędrowiec.
Mikroserwisy to słowo, wokół którego cały świat IT kręcił się w ostatnich latach. Nowe podejście do architektury miało zapewnić szybkie oraz wygodne budowanie modularnych, niezawodnych, a przede wszystkim łatwo skalowalnych systemów. Wszystko wskazuje na to, że faktycznie się udało. Idea mikrousług, która jeszcze kilka lat temu brzmiała jak odświeżone SOA (które przecież absolutnie się nie przyjęło), dziś nie jest już niczym dziwnym i jest powszechnie stosowana w wielu organizacjach.
Faktycznie, mikroserwisy zrobione dobrze rozwiązują wiele problemów, które pojawiały się w przypadku monolitycznych systemów. Niestety zrobione źle, o co nietrudno, mogą przynieść więcej problemów niż korzyści. Mimo że mamy coraz więcej doświadczenia z tym podejściem do architektury, cały czas spotykamy się z nowymi wyzwaniami, dla których rozwiązania sprawdzające się przy monolitach okazują się niewystarczające, nie tylko w przypadku samego kodu czy designu, ale także w obszarze zapewniania jakości.
Sprawdzenie wydajności pojedynczej aplikacji nie jest proste. Sprawdzenie wydajności dwustu aplikacji, które działają razem, zależą od siebie i komunikują się ze sobą, jest po prostu bardzo trudne. W swojej prezentacji chciałbym opowiedzieć, jak podchodzimy do tego tematu w Ocado oraz przedstawić narzędzie do automatycznych testów wydajnościowych - Gatling.
Dobry system musi być przetestowany pod względem wydajnościowym. Takie testy są zupełnie inne niż testy funkcjonalne: zamiast binarnego rezultatu (pass, fail), mamy ogromne ilości danych do zebrania, zaprezentowania i zinterpretowania. Podczas wystąpienie prelegent omówi cały cykl testów wydajnościowych: od przygotowania warunków testu, środowisk i danych testowych, poprzez przeprowadzenie testów, zebranie danych, ich prezentację i interpretacje, aż po przeprowadzenie procesów decyzyjnych wynikających z danych.
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
1. TESTER.PL
Rozpoczął się nowy rok, który winien przynieść nowe pomysły i perspektywy. Każdy
z nas stawia sobie kolejne cele i wyzwania.
Podobnie SJSI postawiło sobie cele na ten rok. Pod koniec lutego wspólnie z IIR
organizujemy II edycję warsztatów Certyfikowany Test Manager. W drugiej połowie maja
mamy zamiar zorganizować II edycję konferencji SJSI.
Jesteśmy partnerem dla dużej i prestiżowej konferencji ICSTEST, która odbędzie się
w dniach 6-8.04.2005 w Dusseldorfie. W Państwa ręce oddajemy trzeci numer kwartalnika
TESTER.PL. Wszystko wskazuje na to, że ukażą się kolejne.
Spójrzmy przez chwilę na to, co udało się nam osiągnąć w ubiegłym roku.
Aktualnie w szeregach Stowarzyszenia jest prawie 100 „zadeklarowanych” członków,
przy czym stale korespondujemy z ponad 200 osobami. Kilka dużych firm jest naszymi
członkami wspierającymi. Kolejnych kilka zadeklarowało chęć współpracy. Cześć członków
Stowarzyszenia aktywnie uczestniczy w pracach International Software Testing Qualification
Board. Co miesiąc spotykamy się na ciekawych wykładach na Politechnice Warszawskiej.
Z sukcesem zorganizowaliśmy I konferencję SJSI (sprawozdanie na www.sjsi.org oraz
w niniejszym wydaniu kwartalnika).
Korzystając z okazji, wszystkim członkom, współpracownikom i naszym
„dobrodziejom” składam w imieniu Zarządu Stowarzyszenia życzenia sukcesów i wszelkiej
pomyślności w 2005 roku.
Z pozdrowieniami
W imieniu Zarządu
Wojciech Jaszcz
Prezes SJSI
Strona 1 z 49
2. TESTER.PL
Od redaktora
Wraz z początkiem Nowego Roku (w połowie lutego ☺) dostajecie kolejny – już
trzeci - numer kwartalnika TESTER.PL.
W tym numerze cztery pozycje:
1. Bogdan Bereza Jarociński o certyfikatach w testowaniu, ich rodzajach, zaletach
i wadach
2. Wywiad z James Bachem, guru lekkich metodyk testowania - dzięki uprzejmości
Mariusza Janczewskiego
3. Piotr Kałuski o narzędziu L- Report, open source’owym projekcie ułatwiającym prace
testerom
4. Robert Rzeszotek o BadBoy’u – kolejny artykuł o automatach wspomagających
testowanie
Numer otwiera sprawozdanie Wojciecha Jaszcza z I Konferencji Stowarzyszenia
Jakości Systemów Informatycznych, która odbyła się w Zegrzu, w dniach 18 – 19 listopada
2005. Jako jej uczestnik, pozwolę sobie stwierdzić, że była to bardzo udana impreza
i z radością witam informację o kolejnej jej edycji.
W numerze także zaproszenie na System & Software Quality Conferences
w Dusseldorfie. Jeśli ktoś ma tylko możliwość, by tam być na początku kwietnia, gorąco
polecamy. Nasze Stowarzyszanie jest jedną z organizacji wspierających dla tej bardzo
ciekawej konferencji, a właściwie trzech konferencji przeprowadzanych równocześnie. Jeżeli
ktoś z Państwa będzie uczestniczył w System & Software Quality Conferences, będziemy
wdzięczni za przekazanie nam swych wrażeń, wskazania nowych kierunków w teorii
i praktyce zwiększania jakości oprogramowania.
Chciałbym także zwrócić uwagę na informację o konferencji (z warsztatami)
Certyfikowany Test Manager, które nasze Stowarzyszenie przeprowadza wspólnie z IIR.
Szkolenie odbędzie się w Warszawie, w drugiej połowie lutego.
Chciałbym 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.
Na „pokładzie” redakcyjnym witamy równocześnie nowego członka, p. Kamilę Dec
z Poznania. Dzięki jej istotnemu wkładowi w działalność redakcyjną dostajecie dziś, Drodzy
Czytelnicy, ten numer TESTERA.PL
Strona 2 z 49
3. TESTER.PL
I Konferencja
Stowarzyszenia Jakości Systemów Informatycznych
W dniach 18-19 listopada 2004, nad Zalewem Zegrzyńskim koło Warszawy odbyła się
I konferencja SJSI. Pomimo, że pogoda nie rozpieszczała (przypomnę – był pierwszy atak
zimy i jazda przez Warszawę trwała do 2godziny), to w Hotelu 500 w Zegrzu zebrało się
prawie 70 osób.
Pierwszym punktem programu był panel o wiele mówiącej nazwie „good enough
quality”, który poprowadziła Lilianna Wierzchoń. Debata trwała prawie dwie godziny, co
świadczy z jednej strony o burzliwej dyskusji wśród uczestników konferencji, a z drugiej
o rzeczywistej potrzebie dialogu w tej materii. W „komisji” panelowej, obok prowadzącej
Lilianny Wierzchoń, zasiedli: Tomasz Byzia, Wojciech Jaszcz, Lucjan Stapp oraz Piotr
Wąsikowski.
Pomimo jesienno-zimowej, ponurej aury, wykłady, które odbyły się pierwszego dnia
wzbudziły niemałe zainteresowanie. Wśród tematów, jakie zostały poruszone warto wymienić
prelekcje dotyczące najnowszej normy ISO/IEC 90003:2004 (Bolesław Szomański), wdrożeń
standardów jakości w organizacji (Maciej Bodych), metody wyboru miar GQM (Joanna
Nowakowska), sposobu projektowania przypadków testowych przy wykorzystaniu analizy
biznesowej w UML (Lucjan Stapp) oraz warsztaty z organizacji procesu zarządzania
zespołem QA (Marcin Stachura). Pierwszy dzień zakończyła uroczysta kolacja, dyskusje
kuluarowe zaś trwały do późnych godzin nocnych.1
Drugi dzień konferencji był w większości poświęcony narzędziom związanym
z automatyzacją procesu testowania. Swoje rozwiązania przedstawiła firma Compuware
(Główny Sponsor konferencji). Sposób, w jaki skutecznie i opłacalnie wykorzystać
profesjonalne narzędzia w dużej korporacji, zaprezentowała firma ComputerLand S.A.
Kolejne, niezwykle ciekawe wykłady dotyczyły sposobu na integrację nazywanego
Continuous Integration (Jan Topiński), narzędzi do automatycznego tworzenia dokumentacji
(Michał Rowicki, Piotr Krachel), sposobów generowania danych testowych (Jan Sabak),
sposobu przeprowadzania testów wydajnościowych aplikacji (Tomasz Wodziński,
Wawrzyniec Żurowski) oraz narzędzi do raportowania wyników zapytań – LReport (Piotr
Kałuski).
Wszystkim uczestnikom, prelegentom i sponsorom, bez których zorganizowanie tej
konferencji byłoby niemożliwe, chcielibyśmy bardzo podziękować.
Liczymy na Waszą obecność i wsparcie kolejnych inicjatyw Stowarzyszenia Jakości
Systemów Informatycznych!
Zarząd Stowarzyszenia Jakości Systemów Informatycznych
1
Jako uczestnik Konferencji, pozwolę sobie stwierdzić, że jest to pewne niedomówienie – dyskusje
kuluarowe trwały do wczesnych godzin rannych (Redaktor)
Strona 3 z 49
5. TESTER.PL
Podziękowania:
Szczególne podziękowania należą się Joannie Nowakowskiej, Wojciechowi
Jaszczowi, Adamowi Suskiewiczowi i Jankowi Sabakowi, bez których zaangażowania,
profesjonalnego podejścia i niezwykłej umiejętności radzenia sobie w sytuacjach
kryzysowych ta konferencja nie doszłaby do skutku, a także Joannie Wiśniewskiej i Sylwii
Wicik oraz wszystkim życzliwym tu niewymienionym za pomoc w organizacji konferencji.
Zapraszamy na drugą edycję konferencji, która odbędzie się w dniach 20 – 21
maja 2005 roku.
Wszystkich chętnych zapraszamy do nadsyłania propozycji tematów referatów
na adres: sjsi@sjsi.org.
Strona 5 z 49
6. TESTER.PL
Certyfikowany Test Manager
23-24-25 lutego 2005 r., hotel Bristol, Warszawa
Program seminarium
Dzień pierwszy
Wprowadzenie
Ogólne zasady budowy systemu informatycznego
Przykładowe metodyki stosowane przy realizacji projektów informatycznych
Klasyczna metodyka "kaskadowa"
Metoda "spirali"
Lekkie metodyki na przykładzie XP
Zasady i praktyka budżetowania projektów informatycznych - Jak powstaje budżet projektu
Zarządzanie wymaganiami
Współpraca niezbędnym czynnikiem sukcesu
Zarządzanie ryzykiem
Testowanie w różnych metodykach wytwarzania oprogramowania
Związek testów z etapami realizacji projektu: modele V i W
Test Driven Development
Zakres, przygotowanie oraz metody prowadzenia podstawowych poziomów testów
Testy modułów
Testy integracyjne "małe"
Testy systemowe
Testy integracyjne "duże"
Testy akceptacyjne
Testy pielęgnacyjne
Zakres, przygotowanie oraz metody testów właściwości
Testy wydajnościowe
Testy architektury i koncepcji
Testy użyteczności
Testy bezpieczeństwa
Inne
Testy regresji i ich rola w procesie testowania
Przeglądy
Przegląd wybranych norm związanych z jakością i testowaniem
Strona 6 z 49
7. TESTER.PL
Dzień drugi
Zarządzanie procesem testowym
Planowanie prac
Szacowanie pracochłonności
Struktura dokumentacji testowej
Przeprowadzenie testów
Rejestrowanie wyników testów
Kontrola postępu prac
Zarządzanie zgłoszeniami problemów i zmian
•
•
•
Zarządzanie wersjami oprogramowania i danych
Definicja testware ("testaliów")
Zarządzanie wersjami
Metody opisu i przechowywania przypadków i scenariuszy testowych
Dzień trzeci
Zarządzanie procesem testowym - cd
Zarządzanie środowiskami o Struktura środowiska testowego o Testy w projekcie rozproszonym
Testowanie a zmiany wymagań
Jakość procesu testowego
Kryteria oceny jakości systemu informatycznego
Narzędzia
Egzamin
Kierowanie zespołem testów
Budowanie zespołu
Role w zespole
Cechy dobrego testera
Zadania szefa zespołu
Przywództwo
Zarządzanie konfliktem
Sztuka kompromisu
Podsumowanie
Wręczenie certyfikatów
Strona 7 z 49
9. TESTER.PL
Międzynarodowe i krajowe certyfikaty w dziedzinie zapewnienia jakości
i testowania oprogramowania
Bogdan Bereza-Jarociński
bbjTest
Bogdan Bereza-Jarociński
Psycholog
z
Uniwersytetu
Warszawskiego
i Londyńskiego, informatyk z uniwersytetu w Lund. Testował,
zarządzał, automatyzował, koordynował lub ulepszał procesy
testowe
zarówno
w
zastosowaniach
wbudowanych
(telekomunikacja – Ericsson, sygnalizacja kolejowa –
Bombardier), jak i otwartych (bazodanowe, Java). Lubi
udzielać się na międzynarodowych konferencjach i prowadzić
szkolenia z dziedziny testowania. Od 2002 roku prowadzi
w Polsce szkolenia m. in. na certyfikat ISEB.
Strona 9 z 49
10. TESTER.PL
Międzynarodowe i krajowe certyfikaty w dziedzinie zapewnienia jakości
i testowania oprogramowania
Bogdan Bereza-Jarociński
Niniejszy artykuł zawiera sporo informacji szczegółowych na temat certyfikatów
w dziedzinie zapewnienia jakości i testowania oprogramowania, takich jak: wymagania na
poszczególne certyfikaty, ich dostępność w Polsce itp. Są to dane, które mogą się zmieniać
w czasie. Informacje zawarte w artykule odpowiadają stanowi na maj 2004 roku.
„Many software vendors, training companies and vendor-independent groups have
created their own brand of certification since the 1960s. When the rapidly emerging field of
computer technology began to experience exponential growth in the 1980s more than 200
different certifications emerged. Computing professionals now face a complex and confusing
array of choices for determining and demonstrating competence.” (IEEE Computer Society)
Sens certyfikacji w przemyśle informatycznym
Informatyka: duża zmienność w czasie i w przestrzeni
W wielu branżach – nie tylko w informatyce – istnieją – oprócz dyplomów uczelni –
rozmaite formy certyfikatów, potwierdzających określone zawodowe umiejętności.
W informatyce i produkcji oprogramowania certyfikaty mają do spełnienia rolę
szczególną, a to z dwóch powodów.
Po pierwsze, zmiany w tej branży dokonują się szybciej i dynamiczniej niż
w większości przemysłów „tradycyjnych”, toteż dyplom uczelni sprzed – powiedzmy – 20 lat
potwierdza kwalifikacje o treści raczej historycznej niż aktualnej. Stąd nieustanne kształcenie
się i nabywanie nowych umiejętności stało się koniecznością dla każdego programisty,
analityka systemów czy kierownika informatycznych projektów.
Po drugie, między produkcją oprogramowania a innymi branżami konstrukcyjnymi
czy produkcyjnymi istnieje pewna zasadnicza różnica. Branże tradycyjne wytwarzają pewne
dobrze zdefiniowane, niezbyt - w porównaniu z oprogramowaniem - zróżnicowane produkty:
na przykład domy, mosty albo samochody. Proces wytwórczy daje się tam zdefiniować
względnie precyzyjnie i "testowanie" - wszelkie czynności kontrolno-weryfikacyjne - są
z tym procesem w sposób ścisły zintegrowane, zrośnięte.
Inżynierię oprogramowania można zaś nazwać "inżynierią robienia wszystkiego",
tyle, że przy użyciu - zamiast betonu czy stali - "materii" instrukcji wykonywanych przez
mikroprocesory komputerów. System bazodanowy, rozbudowany portal internetowy, gra
komputerowa, oprogramowanie sterujące centralą telefoniczną, system wbudowany kierujący
silnikami samolotu, hamulcami ABS czy pralką, system operacyjny, kompilator - to wszystko
jest "oprogramowaniem". Stąd wyniesione z uczelni ogólne umiejętności rychło muszą zostać
uzupełnione nowymi, dostosowanymi do zakresu wykonywanej pracy, co powoduje
zasadność istnienia potwierdzających takie umiejętności certyfikatów.
Strona 10 z 49
11. TESTER.PL
Certyfikacja w dziedzinie zapewnienia jakości i testowania
Zapewnienie jakości i test są w informatyce o tyle szczególne, że nie do końca są
dziedziną skodyfikowaną, gdzie umiejętności mają charakter precyzyjnych, dających się
wyuczyć zasad i algorytmów. Mówi się niekiedy, że test oprogramowania to w jednej trzeciej
dająca się sprawdzić i przeegzaminować wiedza, w jednej trzeciej – nabywane wraz
z doświadczeniem umiejętności rzemieślnicze, a w jednej trzeciej – po prostu sztuka.
Nie wnikając, na ile powyższa definicja jest precyzyjna, przyznać trzeba, że wiele
istotnych do zapewnienia jakości i skutecznego testowania programów umiejętności nabywa
się raczej w praktyce projektowej niż w uczelnianej ławce. Widać to zresztą wyraźnie, kiedy
przyjrzymy się programom studiów informatycznych: niezależnie od profilu, zapewnienie
jakości (podobnie jak – z analogicznych powodów – np. zarządzanie projektami) zajmuje
w nich marginalną pozycję. Zagadnienia zapewnienia jakości pojawiają się w szerszym
zakresie dopiero w ramach prowadzonych przez niektóre uczelnie podyplomowych studiów
z inżynierii oprogramowania.
Ta sytuacja powoduje, że np. „dyplomowanych testerów” po prostu nie ma
i przypuszczalnie nie będzie, co oczywiście stanowi dodatkowe uzasadnienie dla istnienia
certyfikatów.
Rodzaje certyfikatów
Każdy szanujący się producent narzędzi - sprzętowych i programowych – służących
do budowy systemów komputerowych, sieci i oprogramowania lub wspierających
projektowanie i wytwarzanie sprzętu i oprogramowania, wystawia własne certyfikaty. Taki
certyfikat poświadcza, że jego posiadacz jest fachowcem od określonego programu lub
narzędzia.
W tym opracowaniu nie będziemy się tego rodzaju certyfikatami zajmować, a to
z dwóch powodów. Po pierwsze, jest ich wielka obfitość i różnorodność, a po drugie – ich
tematyka i zakres są jednoznaczne i precyzyjnie określone.
Natomiast interesujące są certyfikaty o szerszym zakresie, mające przynajmniej
deklarowane ambicje obiektywności i ogólności, pozwalającej na zastosowanie potwierdzonej
certyfikatem wiedzy w wielu różnorodnych sytuacjach. Nie ma ich tak wiele. „Zapewnienie
jakości”, a zwłaszcza „testowanie”, choć w rzeczywistości wykonywane, a nawet opisywane
w podręcznikach informatyki od co najmniej 40 lat, jako odrębne i świadome swej odrębności
dziedziny są znacznie młodsze, co najwyżej 15-letnie. Toteż zawodowa certyfikacja w tych
dziedzinach także jest zjawiskiem względnie nowym.
Pożytki z certyfikatów
Dla zawodu testera czy specjalisty w zakresie zapewnienia jakości istnienie
certyfikatów podkreśla odrębność tej dziedziny i umiejętności, co z kolei przyczynia się do
podniesienia jej statusu – z którym, jak wiemy, nie zawsze jest najlepiej.
Stworzenie
certyfikatu
wymaga
uprzedniego
usystematyzowania
i ujednoznacznienia wiedzy w danej dziedzinie, z czego korzyści są niezaprzeczalne. Przy
okazji powstaje również zdefiniowana terminologia. W ten sposób ułatwia się komunikację
między uczestnikami projektu informatycznego, a także między klientami a dostawcami
i producentami.
Dla pracodawców certyfikat może ułatwić proces rekrutacji pracowników
z określonym profilem umiejętności. Oczywiście, wymaga to zarówno znajomości
certyfikatu, jak i poprawnego zrozumienia przez obie strony procesu rekrutacji jego treści
Strona 11 z 49
12. TESTER.PL
i roli. Jeśli np. pracodawca poszukuje doświadczonego kierownika zespołu testowego,
a zatrudnia początkującego testera, mającego 4-miesięczne doświadczenie i legitymującego
się świeżo uzyskanym dyplomem „ISEB Software Testing Foundation Certificate” [patrz
poniżej], to oczywiście popełnia poważny błąd.
Dla osób wykonujących pracę w danej branży poprzedzające egzamin certyfikacyjny
szkolenia mogą stać się znakomitą okazją do usystematyzowania swej wiedzy
i doświadczenia, a także do uzupełnienia wiadomości tam, gdzie zakres certyfikatu wykracza
poza dotychczasową praktykę. Ponadto certyfikacja stanowi niejednokrotnie formę
drogowskazu, wskazującego możliwy kierunek dalszego zawodowego rozwoju. Niekiedy
może się także przydać w trakcie negocjacji płacowych...
Zagrożenia
Certyfikat to kawałek papieru, którego zdobycie poprzedził trwający 1-3 godziny
egzamin (zwykle testowy), a ten z kolei poprzedził okres dość intensywnej zwykle nauki.
Certyfikat nie jest więc gwarancją doświadczenia, ani nie zapewnia umiejętności sprawnego
wykorzystania nabytej wiedzy w praktyce. I na pewno nie zastąpi myślenia i umiejętności
organizacyjnych!
Nie wszyscy są zgodni, jakie umiejętności dany certyfikat powinien obejmować. Np.
popularny „ISEB Software Testing Foundation Certificate” krytykowany jest przez
niektórych znawców przedmiotu za zbyt szeroki zakres, (po co „zwykłemu” testerowi
szczegółowa wiedza na temat różnych typów inspekcji i przeglądów oraz na temat
zarządzania testami, mówią krytycy) i niedostateczne uwzględnienie wielu konkretnych,
dobrych praktyk projektowania i wykonywania testów.
Dobrze, jeśli certyfikat opiera się na znanej i dostępnej normie, międzynarodowej lub
krajowej. Kiedy tak nie jest, programowi certyfikatu zagraża chaotyczność i niespójność.
Z drugiej strony, tworzenie norm jest bardzo czasochłonne, zaś certyfikat będący egzaminem
z zakresu normy przypuszczalnie stanie się zbyt obszerny, zbyt sformalizowany i teoretyczny.
Sporo zarzutów kierowanych jest pod adresem form egzaminu. Wiele egzaminów
certyfikacyjnych to egzaminy testowe, co budzi niekiedy wątpliwości, na ile umiejętność
rozwiązania w krótkim czasie kilkudziesięciu czy kilkuset pytań-zagadek jest trafnym
miernikiem czyichś faktycznych umiejętności?
Jak już zostało powiedziane wyżej, mówi się niekiedy, że zapewnienie jakości i test to
w 33% dająca się zweryfikować wiedza, w 33% to rzemiosło i w 33% - sztuka. Podobnie,
skuteczny tester czy szef testów musi, owszem znać metody i techniki testowe, ale ponadto
również dziedzinę, w której działa testowany system (np. bankowość, ubezpieczenia,
zarządzanie przedsiębiorstwem) oraz platformę systemu. Tych umiejętności, odmiennych dla
różnych produktów i projektów, żaden certyfikat nie potwierdzi.
ASQ Certified Reliability Engineer
American Society for Quality (ASQ) jest właścicielem rozpowszechnionego
w Stanach od wielu lat certyfikatu ”Certified Reliability Engineer”. Tłumacząc tę nazwę na
język polski, chyba zręczniej będzie brzmiało określenie ”Certyfikowany Inżynier Jakości”
niż ”Certyfikowany Inżynier Niezawodności”.
Egzamin na certyfikat jest testowy, składa się ze 150 pytań, trwa 4 godziny. Dostępny
wyłącznie w języku angielskim.
Egzamin certyfikacyjny obejmuje następujące dziedziny.
Strona 12 z 49
13. TESTER.PL
Zarządzanie niezawodnością (zarządzanie strategiczne, zarządzanie procesem
kontroli niezawodności, bezpieczeństwo produktów i odpowiedzialność prawna).
Teoria prawdopodobieństwa i statystyka (podstawowe pojęcia, wnioskowanie
statystyczne).
Niezawodność w projektowaniu i programowaniu (techniki projektowania
niezawodności, dobór materiałów, zarządzanie komponentami i systemem).
Modelowanie i przewidywanie niezawodności.
Testowanie niezawodności (planowanie testów
w procesie wytwarzania, testowanie ukończonego produktu).
niezawodności,
testowanie
Utrzymanie i dostępność systemu (zarządzanie utrzymaniem i dostępnością, analiza
łatwości i skutków zmian).
Pozyskiwanie i wykorzystanie pomiarów (pozyskiwanie
i wykorzystanie danych, narzędzia i metody do analizy danych).
danych,
analiza
IEEE Certified Software Development Professional
Organizacja IEEE (Institute of Electrical and Electronics Engineers) powstała w 1884,
początkowo nosiła nazwę AIEE (American Institute of Electrical Engineers). Obecnie zrzesza
ponad 380 000 członków w 150 krajach, jest jedną z największych na świecie organizacji
standaryzujących: wyprodukowała prawie 900 aktywnych standardów, prowadzone są prace
nad ponad 700 nowymi.
IEEE składa się z 37 stowarzyszeń. Największe z nich to IEEE Computer Society,
założone w 1946 roku. Liczy 100 000 członków.
Koncepcja, na której opiera się certyfikat CSDP (Certified Software Development
Professional), przedstawiona jest na poniższej ilustracji.
Rozwój
jednostki
Edukacja
początkowa
Certyfikaty,
licencje
Doskonalenie
umiejętności
Kodeks
etyczny
Pełny
status
profesjonalny
Doskonalenie
CSDP jest pierwszym z serii przygotowanych przez IEEE CS certyfikatów, których
celem będzie stworzenie społeczności profesjonalnych twórców oprogramowania (Leading
Software Development Professionals and Practitioners). Na razie jest to jedyny tego typu
certyfikat przyznawany przez IEEE Computer Society. Certyfikat jest dostępny od połowy
2002 roku.
W celu otrzymania certyfikatu trzeba spełnić następujące warunki:
•
wykazać się doświadczeniem zawodowym (minimum 9000 godzin przepracowanych
w przynajmniej 6 z 11 obszarów wiedzy, w przeciągu ostatnich 4 lat co najmniej 2 lata
przepracowane z inżynierią programowania)
Strona 13 z 49
14. TESTER.PL
•
•
•
posiadać odpowiednie wykształcenie: co najmniej tytuł licencjata z informatyki lub
dziedziny pokrewnej
zobowiązać się do przestrzegania Software Engineering Code of Ethics and
Professional Practice
zdać egzamin potwierdzający opanowanie Body of Knowledge (11 obszarów wiedzy,
180 pytań testowych, 3 godziny)
Tematyka CSDP obejmuje dziedziny:
Inżynieria oprogramowania i społeczeństwo („kryzys oprogramowania”,
ekonomika inżynierii oprogramowania, normy inżynierii oprogramowania, profesjonalne
praktyki).
Proces inżynierii oprogramowania (znaczenie procesów, modele procesów, model
CMM dla oprogramowania).
Wymagania dla oprogramowania (proces inżynierii wymagań, pozyskiwanie
i analiza wymagań, specyfikacja wymagań oprogramowania, zarządzanie wymaganiami
oprogramowania).
Projektowanie oprogramowania (główne pojęcia, strategie
oprogramowania, architektura oprogramowania, metodyki specjalne).
projektowania
Konstruowanie oprogramowania (komponenty konstrukcji, projekt – organizacja –
dokumentacja, integracja i wdrożenie systemu).
Testowanie oprogramowania (przegląd tematyki, projektowanie testów, poziomy
testów).
Pielęgnacja oprogramowania (co to jest pielęgnacja, proces pielęgnacji
oprogramowania, pomiary łatwości pielęgnacji, zarządzanie i dokumentacja pielęgnacji).
Zarządzanie inżynierią oprogramowania (funkcje i tryby zarządzania, proces
zarządzania, planowanie projektu, zarządzanie projektem – proces, monitorowanie, zmiany).
Pomiary w produkcji oprogramowania (podstawy, wybór miar, pozyskiwanie
danych).
Procesy wspierające inżynierii oprogramowania (zarządzanie konfiguracją,
weryfikacja i walidacja, zapewnienie jakości, przeglądy i audyty).
QAI Certified Quality Analyst oraz Certified Software Test Engineer
QAI (Quality Assurance Institute)
QAI rozpoczął działalność w roku 1980, zrzeszając osoby zajmujące się
zapewnieniem jakości w branży informatycznej. Prace nad wprowadzeniem certyfikatów
rozpoczęto w roku 1985, a pierwsze egzaminy odbyły się w 1990 roku. Dziś na świecie działa
ok. 10 000 osób mających (jeden z trzech) certyfikatów QAI w krajach głównie
pozaeuropejskich (Australii, Belgii, Brazylii, Kanadzie, Indiach, Izraelu, Korei, Meksyku,
Nowej Zelandii, Arabii Saudyjskiej, Singapurze, RPA, Wielkiej Brytanii i w USA).
Certified Quality Analyst
Wymogi certyfikacyjne: minimum licencjat i dwa lata doświadczenia w branży
informatycznej (lub – jeśli ktoś nie ma licencjatu – minimum sześć lat doświadczenia
Strona 14 z 49
15. TESTER.PL
zawodowego), referencja – rekomendacja od innej osoby z branży oraz zobowiązanie do
przestrzegania kodu etyki zawodowej. Ponadto trzeba oczywiście zdać egzamin z zakresu
Body of Knowledge (podstawy jakości, procesy wytwarzania, zakupu i użytkowania
oprogramowania, modele jakości, ocena jakości, zarządzanie jakością, zapewnienie jakości,
monitorowanie jakości, metody definiowania, konstruowania, wdrażania i usprawniania
procesów, metody ilościowe).
Certified Software Test Engineer
Wymogi pozamerytoryczne takie same jak dla CQA (z tym, że wymagane
doświadczenie musi dotyczyć branży testowej).
Body of Knowledge: podstawowe zasady i pojęcia testowe, rola testerów
w wytwarzaniu i zakupie oprogramowania, zarządzanie testami, konstrukcja środowiska
testowego, analiza ryzyka, planowanie testów, projektowanie testów, wykonywanie testów,
śledzenie i naprawianie błędów, testy akceptacyjne, śledzenie statusu testów, raportowanie
testów.
BCS/ISEB: SW Testing
Practitioner Certificate
Foundation
Certificate,
SW
Testing
BCS (British Computer Society) jest brytyjską organizacją o profilu podobnym do PTI
(Polskiego Towarzystwa Informatycznego). BCS składa się z wielu grup zainteresowań
(Interest Groups). Osoby zajmujące się testowaniem oprogramowania i systemów
informatycznych zrzeszone są w prężnie działającej grupie testerów (Special Interest Group
In SW Testing, SIGIST).
BCS jest merytorycznie odpowiedzialne za szereg certyfikatów z różnych dziedzin
branży elektronicznej, komputerowej i informatycznej. Praktyczną realizacją tych
certyfikatów (administracja, publikowanie i archiwizacja materiałów merytorycznych,
akredytacja
dostawców
szkoleń,
przygotowanie
materiałów
egzaminacyjnych,
przeprowadzanie i sprawdzanie egzaminów, dystrybucja certyfikatów) zajmuje się firma
ISEB (Information Systems Examination Board), w której radzie nadzorczej zasiada
przedstawiciel ISEB.
Najnowszym produktem BCS/ISEB jest seria trzech certyfikatów w dziedzinie
testowania oprogramowania:
SW Testing Foundation Certificate (dostępny od 1998 roku, egzamin poprzedzony
3-dniowym - nieobowiązkowym – szkoleniem, ponad 18 000 certyfikowanych testerów
w całej Europie oraz w Australii, Izraelu i Meksyku).
SW Testing Professional Certificate (dostępny od 2002 roku, poprzedzony minimum
8-dniowym – nieobowiązkowym – szkoleniem, dotąd uzyskało go kilkaset osób, głównie
w Wielkiej Brytanii oraz w Irlandii).
SW Testing Professional Diploma (trwają prace nad jego przygotowaniem).
Certyfikat podstawowy ISEB (SW Testing Foundation Certificate) „wstrzelił” się
w istniejące zapotrzebowanie idealnie – tym należy tłumaczyć jego ogromną popularność,
także poza Wielką Brytanią i Irlandią. Jednocześnie ta popularność spowodowała rozpoczęcie
prac nad międzynarodową wersją certyfikatu - patrz poniżej.
Tematyka certyfikatu podstawowego:
Strona 15 z 49
16. TESTER.PL
Wprowadzenie (typy i cele certyfikatów, organizacja procesu certyfikacji, przebieg
i taktyka egzaminu, organizacja materiału szkoleniowego)
Podstawowe zasady testowania (terminologia, dlaczego testowanie jest konieczne,
podstawy procesu testowania, psychologia testowania, testowanie regresyjne, wyniki testów)
Testowanie w różnych fazach cyklu wytwarzania oprogramowania (modele procesu
wytwarzania oprogramowania, ekonomika testowania, planowanie testowania, testowanie
komponentów, testowanie integracyjne, testowanie systemu, testowanie właściwości,
testowanie akceptacyjne, testowanie pielęgnacyjne)
Dynamiczne techniki testowania (techniki "czarnej skrzynki", techniki "szklanej
skrzynki", zgadywanie błędów)
Testowanie statyczne (udział przeglądów w procesie testowania, rodzaje przeglądów
i inspekcji, analiza statyczna)
Podstawy zarządzania testowaniem (organizacja, zarządzanie
kontrolowanie testowania, śledzenie błędów, normy w dziedzinie testowania)
konfiguracją,
Narzędzia stosowane do testowania oprogramowania (podstawowe typy narzędzi,
elementy procesu wdrożenia automatycznego wykonywania testów).
Egzamin trwa 1 godzinę i składa się z 40-stu pytań testowych.
ISTQB: certyfikaty międzynarodowe
Popularność certyfikatu ISEB w wielu krajach spowodowała działania mające na celu
przekształcenie go w certyfikat międzynarodowy. Jesienią 2001 roku podczas konferencji
„EuroSTAR 2001”, odbywającej się wówczas w Sztokholmie, zebrała się grupa
przedstawicieli z 9 europejskich krajów i w ciągu kilku godzin wypracowano podstawy
działania ISTQB – International SW Testing Qualifications Board.
Począwszy od jesieni 2003 roku działania nabrały rozmachu – wcześniej przeszkodę
stanowił konflikt między ISEB a niemieckim stowarzyszeniem ASQF („Association for
Software Quality Frankonia”). Po zlikwidowaniu tego konfliktu sytuacja i cele ISTQB
wyglądają następująco:
W ramach ISTQB współpracują organizacje z USA, Austrii, Danii, Holandii,
Finlandii, Niemiec, Indii, Izraela, Norwegii, Polski, Portugalii, Szwecji, Szwajcarii i Wielkiej
Brytanii.
ISTQB stawia sobie za cel udoskonalenie treści dotychczasowego certyfikatu ISEB.
W przyszłości powstanie jeden, wspólny międzynarodowy certyfikat ISTQB. Jego
wersja podstawowa będzie w języku angielskim, zaś organizacje wszystkich krajów, które
sobie tego życzą, będą mogły przetłumaczyć materiały i pytania na język krajowy. W ten
sposób certyfikat ISTQB będzie pierwszym międzynarodowym certyfikatem w tej branży,
mającym wiele – merytorycznie w 100% równoważnych – wersji językowych.
Organizacje krajowe wezmą na siebie akredytację kandydatów na dostawców szkoleń
w swoich językach.
Przeprowadzanie egzaminów organizacje krajowe będą mogły albo organizować we
własnym zakresie (przestrzegając wymogów ISTQB w celu uniknięcia nadużyć) lub zlecić
organizację działającym obecnie instytucjom akredytacji i certyfikacji, tj. ISEB lub ASQF.
Strona 16 z 49
17. TESTER.PL
PSTB (Polish SW Testing Board) i jego rola w ISTQB
Latem 2003 roku zostało zarejestrowane pierwsze w Polsce zrzeszenie osób
zajmujących się zapewnianiem jakości oraz testowaniem: Stowarzyszenie Jakości Systemów
Informatycznych (SJSI). W ramach SJSI działa Polish SW Testing Board (PSTB), które
reprezentuje Polskę w ISTQB, a w przyszłości przekształci się w organizację odpowiedzialną
za akredytację podmiotów, które będą chciały prowadzić szkolenia zakończone egzaminem
ISTQB w języku polskim.
Dobiegają końca prace nad tłumaczeniem wspólnego słownika terminologii
z dziedziny testowania oprogramowania na język polski. Ten słownik będzie stanowił
podstawę zarówno do tłumaczenia na język polski pytań egzaminacyjnych, jak i do produkcji
materiałów szkoleniowych.
Dostępność certyfikatów w Polsce
W Polsce certyfikat SW Testing Foundation Certificate dostępny jest od lipca 2002
roku (szkolenie w języku polskim, materiały i ćwiczenia w języku angielskim, egzamin
w języku angielskim). Dotychczas w szkoleniach wzięło udział około 250 osób, z czego 180
przystąpiło do egzaminu na certyfikat, a około 75% zdało egzamin i uzyskało certyfikat.
Szkolenia otwarte prowadzone są regularnie co 2 miesiące w Warszawie przez
współpracujące firmy bbjTest i Software Konferencje. Możliwe jest także przeprowadzenie
szkoleń zamkniętych w firmach.
Certyfikat SW Testing Professional Certificate na razie nie jest w Polsce dostępny.
Możliwe jest zorganizowanie egzaminu eksternistycznego, jeśli znajdzie się co najmniej kilka
osób zainteresowanych.
Szkolenia na IEEE Certified Software Development Professional organizowane są
przez Software Konferencje.
Źródła
1. BCS, Information Systems Examination Board, SW Testing (tamże dostępne
szczegółowe dane nt. zakresu tematyki, egzaminów, akredytowanych dostawców szkoleń
itp.): www.bcs.org.uk/iseb/st
2. IEEE Computer Society, CSDP: www.computer.org/certification
3. Yahoo CSDP Study Group: groups.yahoo.com/group/ieee_csdp
4. IEEE: www.ieee.org
5. SWEBOK, IEEE SW Engineering Body of Knowledge: www.swebok.org
6. QAI, Certified SW Quality Analyst: www.softwarecertifications.com/qai_cqa.htm
7. QAI, Certified SW Tester: www.softwarecertifications.com/qai_cste.htm
8. Certyfikaty QAI: www.softwarecertifications.com/
9. QAI: www.qaiusa.com
10. ASQ, Certified Reliability Engineer: www.asq.org/cert/types/cre/
11. ASQ
Certified
Reliability
Engineer
Body
of
Knowledge:
www.asq.org/cert/types/cre/bok.html
12. ISTQB: www.istqb.org/vision.php
Strona 17 z 49
18. TESTER.PL
13. ASQF: www.asqf.de
14. Stowarzyszenie Jakości Systemów Informatycznych, Polish SW Testing Board:
www.sjsi.org/pstb
15. bbjTest (informacje na temat certyfikacji, realizacja szkoleń, w tym na SW Testing
Foundation Certificate): www.bbj.com.pl
16. Software Konferencje (realizacja szkoleń otwartych na SW Testing Foundation
Certificate oraz CSDP): www.software.com.pl/konferencje
17. International SW Quality Institute ISQI (ISTQB is part of it): www.isqi.org
Strona 18 z 49
19. TESTER.PL
CENTRA TESTOWANIA I OPTYMALIZACJI SYSTEMÓW IT
Rynek dostawców aplikacji do optymalizacji jakości stał się jednym
z najważniejszych i najbardziej strategicznych obszarów inwestycyjnych dla przemysłu
informatycznego. Firmy porzucają strategię testowania poszczególnych projektów
i przekształcają się w przedsiębiorstwa dostarczające aplikacje kompleksowo.
Od ponad 15 lat firma Mercury pomaga tysiącom klientów optymalizować jakość
i wydajność ich aplikacji. W swoim raporcie Gartner Magic Quadrant for Distributed Testing
firma Gartner ocenia firmę Mercury jako lidera rynku. Według instytutu IDC firma Mercury
jest najlepszym na świecie dostawcą aplikacji, posiadającym 55,6% udział w rynku
zautomatyzowanych produktów testowania jakości i wydajności oprogramowania (ASQ).
IDC z optymizmem wyraża się o perspektywie wzrostu rynku dostawców aplikacji
i przewiduje, że całościowy dochód rynku ASQ osiągnie 1,3 miliarda USD w 2008 r.
Wyniki najnowszych badań przeprowadzonych przez Economist Intelligence Unit
(EIU) i obejmujących ponad 750 dyrektorów z branży IT potwierdzają trzy największe
wyzwania stojące przez europejskimi firmami IT:
•
•
•
Poprawa jakości IT (69%)
Pomiar i wykazanie wartości IT dla biznesu (63%)
Obniżenie kosztów (56%)
Centra Optymalizacji Mercury – Każde z czterech centrów optymalizacji Mercury
oferuje zintegrowane oprogramowanie, usługi i najlepszą praktykę.
•
•
•
Centrum jakości i wydajności Mercury - dla działów testów pre-produkcyjnych
aplikacji
Centrum zarządzania IT - do zarządzania całym działem IT
Centrum dostępności biznesowej systemów IT - do zarządzania aplikacjami
Centrum jakości Mercury skupia główne zadania związane z dostarczaniem
aplikacji, m.in. zarządzanie testami, testy procesów biznesowych i testy funkcjonalne, co ma
na celu poprawę jakości oprogramowania strategicznego. Centrum jakości pozwala klientom
scentralizować funkcjonowanie ich firm, co zapewnia oszczędność czasu, obniżenie kosztów
i powoduje poprawę wydajności krytycznych zadań IT.
Zalety Centrum jakości Mercury:
•
•
Szybsza dostawa i poprawa jakości na poziomie produkcji
Konsekwentny, wielokrotny i sprawdzony proces testowania
Strona 19 z 49
20. TESTER.PL
•
•
•
•
•
•
Centralne raportowanie (przez przeglądarkę internetową, portale lub konsole
kierownicze) o statusie bieżących projektów, projektów nadchodzących i wynikach
poprzednich zadań
Technologia automatyzacji i testowania oraz wiedza specjalistyczna w zakresie
wykorzystania technologii
Skalowalność od poziomu departamentu do zastosowań globalnych dla aplikacji
rozproszonych
Konsola zarządzająca dla widoku w czasie rzeczywistym procesów testowania jakości
i wydajności
Zarządzanie centrum jakości (Usługi zarządzania Mercury) na żądanie
Centrum wydajności Mercury skupia główne zadania związane z dostarczaniem
aplikacji, m.in. testy obciążenia, diagnostyka aplikacji oraz planowanie wydajności
wszystkich strategicznych aplikacji biznesowych. Centrum wydajności umożliwia
poszczególnym zespołom IT wykonywanie zadań w sposób scentralizowany, co oszczędza
czas, ogranicza koszty i powoduje znaczny wzrost wydajności krytycznych zadań IT.
Zalety Centrum wydajności Mercury:
•
•
•
•
•
•
•
•
•
•
Szybsza dostawa i poprawa jakości na poziomie produkcji
Zoptymalizowana infrastruktura poprzez analizę, testy i lepszą wydajność
Centralny widok (przez przeglądarkę internetową, portale lub konsole kierownicze)
statusu bieżących projektów, projektów nadchodzących i wyników poprzednich zadań
Skalowalność od poziomu departamentu do zastosowań globalnych dla aplikacji
rozproszonych
Kompleksowy widok zapewniający optymalizację aplikacji lub procesu biznesowego
przed wprowadzeniem go na rynek i wymaganych dla niego zasobów
Odpowiednio wczesne wykrywanie „wąskich gardeł” pozwalające zwiększyć
wydajność aplikacji
Planowanie wydajności, m.in. symulacja hipotetycznych scenariuszy.
Skrócenie średniego czasu naprawy, dzięki zastosowaniu rozwiązań diagnostycznych
Konsola kierownicza dla widoku w czasie rzeczywistym przebiegu procesu jakości
i wydajności
Zarządzanie centrum wydajności (Usługi zarządzania Mercury) na żądanie
Strona 20 z 49
21. TESTER.PL
Wywiad z Jamesem Bachem
2
James Bach, współautor książki "Czego dowiedziałem się testując oprogramowanie"
(tytuł oryginału "Lessons Learned in Software Testing"), to osoba dosyć popularna w świecie
testów ze względu na swoje niekonwencjonalne idee. Jego strona internetowa jest dostępna
w sieci pod adresem www.satisfice.com.
Witryna WhatIsTesting przeprowadziła z nim wywiad. Mam nadzieję, że wywiad Was
zainteresuje i okaże się użyteczny.
James, proszę powiedz nam coś o sobie, o swoim wykształceniu i dotychczasowej pracy.
Co najbardziej interesuje Ciebie poza testowaniem i co porabiasz w wolnym czasie?
Urodziłem się w stanie Iowa w USA. Dziecięce lata spędziłem w cichej, wiejskiej
miejscowości Vermont.
W szkole nie było łatwo, szczególnie po piątej klasie. Przeczytałem w konstytucji
Stanów Zjednoczonych, że "Nie będzie w Stanach Zjednoczonych lub jakimkolwiek miejscu
podległym ich władzy ani niewolnictwa, ani przymusowych robót, chyba jako kara za
przestępstwo, którego sprawca został prawidłowo skazany". Na podstawie tego fragmentu
podjąłem postanowienie, że nie będę już odrabiał zadanych prac domowych. Odmowa ta
przekształciła się w generalne odrzucenie całej szkolnej biurokracji i niechęć do władzy
w ogóle. Dzisiaj wydaje się to absurdalne. Ale kiedy miałem 16 lat - w roku 1982 - mój ojciec
(który napisał książkę pod tytułem "Jonathan Livinston Seagull" mówiącą o dorastaniu
i kierowaniu swoim życiem) doradził mi, abym rzucił szkołę. Tak zrobiłem i kontynuowałem
naukę na swój sposób.
Dostałem pracę w sklepie komputerowym, gdzie przez sześć miesięcy nic nikomu nie
sprzedałem, ale wkrótce zostałem zatrudniony przez inna firmę, w której pisałem gry
komputerowe na Apple i Commodore 64. Po kilku latach pracy na stanowisko kierownika
testów zatrudniła mnie firma Apple Computer. Jestem przekonany, że byłem wtedy
najmłodszym kierownikiem w firmie. Nie miałem żadnego przygotowania z zakresu
zarządzania ani związanego z testowaniem, ale to nie stanowiło problemu. Niewiele osób
miało w ogóle pojęcie o testowaniu. Postanowiłem zostać ekspertem od spraw testowania,
dlatego spędzałem całe godziny w kafejce naprzeciwko mojej pracy czytając książkę za
książką i próbując odkryć tajemnice testowania.
2
Wywiad został zamieszczony dzieki Mariuszowi Janczewskiemu, który jest także tłumaczem tego wywiadu.
Mariusz Janczewski jest współpracownikiem Tester.PL, aktualnie pracuje w Gdansku, w firmie Atena, Usługi
informatyczne i finansowe, Sp. z.o.o. www.atena.pl
Strona 21 z 49
22. TESTER.PL
Ponieważ mam "antyestabliszmentowe" korzenie, nigdy nie czułem się zobligowany
do ograniczenia się do tylko jednej dziedziny. Miało to swoje wady, jak i zalety. Nigdy nie
byłem częścią systemu, który przekonywał ludzi, że pewien guru odnalazł prostą i skuteczną
metodę wytwarzania oprogramowania. Nie wierzę takim osobom. Nie ma prostych
przepisów, poza tą jedną, najbardziej prostą regułą wymagającą wielkiej umiejętności
skorzystania z własnego rozumu ("use your mind"!).
Mam szczególne uznanie dla dwóch rzeczy: metod naukowych oraz szczęścia
zwykłych ludzi. W innych sprawach jestem bardzo sceptyczny.
Twoja strona internetowa nosi nazwę "satisfice", jakie jest znaczenie tego słowa? Co
oznaczają słowa "epistemologia dla każdego", na które możemy trafić na Twojej
stronie?
"Satisfice" oznacza dążenie do rozwiązania wystarczająco dobrego. Zostało ono po raz
pierwszy użyte przez Herberta Simona, który otrzymał Nagrodę Nobla za swoje badania
dotyczące sposobu, w jaki organizacje podejmują decyzję. Skomplikowane decyzje, takie jak
odpowiedzi na pytania czy produkt jest gotowy do wypuszczenia na rynek, nie są
podejmowane wyłącznie na podstawie oczywistych racjonalnych przesłanek, ale w wyniku
procesu, który bywa czasem "mglisty". Proces ten Simon nazwał ograniczonym
racjonalizmem. To, czym się zajmuję, cała moja praca, polega na określeniu, w jaki sposób
mogę podejmować najlepsze decyzje w sytuacji, kiedy nie znam wszystkich faktów, kiedy
jestem przez to niedoskonały. To jest to, co tak bardzo interesuje mnie i moich Klientów.
Epistemologia jest dziedziną filozofii zajmującą się teorią poznania, określeniem
sposobu, w jaki poznajemy. Cała dziedzina nauki zajmuje się tym zjawiskiem.
"Epistemologia dla każdego" jest nawiązaniem do dawnego hasła firmy Apple Computer
"komputery dla każdego". Podobnie jak Apple, staram się przekazać coś ze świata
specjalistów do codziennego użycia. Taka jest moja filozofia testowania i wytwarzania
oprogramowania.
James, to może być krótkie pytanie i długa odpowiedź. Czy możesz opisać Twój związek
ze szkołą "context-driven testing"? W jaki sposób szkoła ta powstała? Jak dojrzewała?
Proszę opowiedz o historii i o tym jak widzisz przyszłość tej szkoły.
Termin "context-driven testing" powstał podczas wspólnej kolacji w dniu 21 listopada
1999. W spotkaniu braliśmy udział Cem Kaner, Brian Marick i ja. Było to w drodze na ósme
warsztaty z testowania oprogramowania w Los Altos. Dwa tygodnie później założyliśmy
grupę dyskusyjną na Yahoogroups poświęconą "context driven testing". W roku 2001 wraz
z Cem'em, Bret'em Pettichord sformułowaliśmy siedem zasad testowania "context-driven"
i opublikowaliśmy pierwszą książkę na ten temat pod tytułem "Lessons Learned in Software
Testing".
Chociaż termin nie był stosowany przed rokiem 1999, to grupa, którą nazwaliśmy
społecznością "context-driven" wyrosła na rozpoznawalne zjawisko jeszcze przed naszym
spotkaniem podczas wcześniejszego LAWST w roku 1997. Spotkanie to stanowiło przełom.
LAWST to skrót od "Los Altos Workshops on Software Testing". LAWST to nie komercyjne,
tygodniowe dyskusje, w których biorą udział małe grupy osób, żeby dzielić się swoim
doświadczeniem w dziedzinie testów. Pierwsze LAWST zostało zorganizowane przez Cem'a
Kaner'a i Brian'a Lawrence'a. Odbyło się już czterdzieści spotkań tych oraz innych
związanych z LAWST spotkań.
Strona 22 z 49
23. TESTER.PL
Podczas spotkań LAWST, żaden prelegent nie jest chroniony przed wnikliwymi
pytaniami i krytycyzmem. Podejście krytyczne wymaga od uczestników umiejętności
i wiedzy, w jaki sposób uzasadniać swoje racje i przedstawiać argumenty. Osoby trafiające na
LAWST w poszukiwaniu "najlepszych praktyk" są często rozczarowane, ponieważ znajdują
więcej pytań niż odpowiedzi i więcej kontrowersji niż zgody. Wiele osób uczestniczy w kilku
spotkaniach, a następnie rezygnuje z kolejnych, ale osoby, które uczestniczą we wszystkich
spotkaniach pozyskują cenne umiejętności w zakresie sztuki testowania. Dzięki temu LAWST
i inne bliźniacze konferencje są odpowiedzialne za wzrost nowej wrażliwości, która mówi, że
żadna praktyka może być dobrą praktyką i że żadna praktyka może być złą praktyką,
w zależności od kontekstu, a kontekst jest zawsze zależny od ludzi, którzy go tworzą.
Zatem „context-driven testing” nie jest techniką, jest raczej profesjonalnym sposobem
podejścia do technik. Aby prowadzić „context-driven testing” należy ustalić świadome, jasne,
samokrytyczne relacje pomiędzy procesem testowym i środowiskiem (czyli kontekstem),
w którym testy są prowadzone. Tester prowadzący testy zgodnie z „context-driven testing”
dąży do pełnej odpowiedzialności za swój własny proces testowania.
Metodę „context-driven testing” spostrzegam w przyszłości jako rozwijającą się
powoli w atmosferze spotkań zbierających się w małych grupach myślicieli, próbujących
pisać wnikliwe artykuły o testowaniu. Nie sądzę, że kiedykolwiek będzie ich więcej niż kilka
procent wśród całego środowiska testerów. Tak jak niewiele jest entuzjastów "ham radio"3
w porównaniu z liczbą użytkowników zwykłych telefonów komórkowych. Wierzę, że w nie
tak odległej przyszłość (za jakieś 30 lat) wartość "context-driven testing" zostanie doceniona
i będzie ono stanowiło wartościowe uzupełnienie innych metod testowania oraz będzie
rozpoznawane po prostu jako "wykwalifikowane testowanie". Etykieta "context-driven" nie
będzie już konieczna, ponieważ doświadczeni testerzy będą traktowali w oczywisty sposób,
że to kontekst dominuje praktykę.
Jest jeszcze jeden fragment historii, na który pragniemy rzucić nieco światła. Proszę
opowiedz nam o testowaniu eksploracyjnym i Twoim związku z nim. W jakim kierunku
będzie rozwijało się testowanie eksploracyjne? W jaki sposób szkoła "context-driven"
przyjmuje elementy testowana eksploracyjnego?
Testowanie eksploracyjne jest szczególną rodziną praktyk testowych zdefiniowanych
jako "równoczesna nauka, projektowanie testów i wykonywanie testów". Może ono być
traktowane jako mentalna sztuka walki. Sam termin został wymyślony (w każdym razie na
polu oprogramowania) przez Cema Kanera w późnych latach osiemdziesiątych, ale nie został
wówczas opublikowany i niewiele osób korzystało z niego. Podjąłem ten termin w roku 1994
po nieudanych próbach przekonania ludzi, że testowanie ad hoc jest umiejętnością, której
można uczyć, która stanowi wyrafinowaną formę testowania. Ad hoc nie oznacza "byle jaki",
ale wielu ludziom wydaje się, że taki właśnie jest, zatem uznałem, że na moje potrzeby termin
testowanie eksploracyjne będzie lepszy. Dzisiaj jest to relatywnie dobrze znany termin,
zarówno Cem jak i ja jesteśmy znani z działalności na tym polu.
3 ham - someone who receives and sends radio messages for fun rather than as their job
Strona 23 z 49
24. TESTER.PL
Także Elisabeth Hendrickson wykonała z nami znaczną pracę w tym zakresie,
podobnie jak James Whittaker. Niezbyt wiele osób w aktywny sposób pracowało nad
rozwojem i opisem tej praktyki, co przypomina sytuację związaną z pracami nad testowaniem
eksploracyjnym na innym polu.
Eksploracja jest z natury czynnością, którą trudno jest opisać za pomocą prostego,
konkretnego przepisu, tak wielu kierowników obawia się jej. Myślę, że testowanie
eksploracyjne stanowi podstawowe podejście do testowania. Innymi słowy, według mnie
tester staje się wykwalifikowany wtedy, kiedy dobrze przeprowadza testy eksploracyjne, jest
to pierwsza umiejętność, której uczę nowych testerów, którzy dla mnie pracują. Podstawowy
fenomen testowania eksploracyjnego można poznać studiując kontekst medyczny, inżynierię,
filozofię nauki, ekonomię, wodzenie teorii, teorię gier, kreatywne myślenie, sztukę,
nawigację, edukację, i sztuczną inteligencję. To wskazuje na listę książek, które musiałem
przeczytać.
Eksploracja jest rdzeniem lekkiego sposobu wytwarzania oprogramowania. Według
mnie nikt nie może uważać się za osobę wyedukowaną w zakresie testowania, utrzymując, że
eksploracja jest dodatkowym luksusem, który można przeprowadzać tylko wtedy, kiedy
wszystkie skrypty testowe zostaną wykonane. W tej sytuacji według mnie trudno jest
traktować poważnie autorów i konsultantów określających testowanie eksploracyjne jako
proces nieuporządkowany, którego nie można nauczać, którym nie można zarządzać. Mam
nadzieję, że spostrzegą oni to, że rok 1985 już minął i nasze rzemiosło nieco się rozwinęło.
Jakie jest miejsce testowania skryptowego w szkole kontekstowej? Jak spostrzegasz
zmiany zachodzące w testowaniu skryptowym w ostatnim czasie?
Szkoła testowania kontekstowego nie ma jakichkolwiek preferencji w zakresie
stosowanych praktyk, tak długo jak praktyki te nie są sprzeczne z jedną z siedmiu zasad
stojących u podstaw tej szkoły, podanych na stronie www.context-driven-testing.com.
Oznacza to, że testowanie skryptowe należy do szerokiej rodziny praktyk testowych: tester
kontekstowy zadaje sobie trud pojęcia dynamiki testowania skryptowego i poszukuje
sposobu, w jaki praktyka ta może pomóc mu w rozwiązania problemu, nad którym pracuje.
Tester kontekstowy stosuje te sposoby testowania, które najlepiej odpowiadają
bieżącym wyzwaniom. Na przykład jako tester kontekstowy, zwracam uwagę na dziewięć
powodów, dla których powinienem powtórzyć test i to wpływa na wybraną przeze mnie
formę dokumentowania przypadków testowych. Bez względu na kwestię powtarzalności
czynności testowych występują także inne ważne powody decydujące o przygotowywaniu
skryptów testowych. Mimo to nadal jestem zdania, że w przypadku bardziej
skomplikowanych projektów, jeśli Twoim głównym celem jest znalezienie ważnych błędów,
testowanie nie powinno być zbytnio oparte na przygotowanych skryptach. Zadaniem
testowania eksploracyjnego jest lokalizacja możliwie największej liczby błędów, w możliwie
krótkim czasie.
Testowanie skryptowe oznacza, że tworzysz test zanim go przeprowadzisz i nie
zmieniasz go podczas realizacji testu ani w jego wyniku. Ten sposób podejścia do testowania
stanowi oczywistą opozycję względem testowania eksploracyjnego, ale spostrzegam także, że
testowanie zwykle zawiera elementy obydwóch podejść - pewne elementy testowania
skryptowego oraz eksploracyjnego realizowane bywają równocześnie. Właśnie to, że
testowanie zawiera elementy obydwóch stylów, stanowi największą zmianę mojego sposobu
myślenia na temat testowania w ostatnich kilku latach.
Strona 24 z 49
25. TESTER.PL
Jaka jest Twoja rada dla firm, które utkwiły w "modelu testowania starego typu"?
Jakie kroki powinny one podjąć, aby otrzymać lepsze oprogramowanie?
Moja rada to bądźcie uważni. Uczcie się widzieć, co się naprawdę dzieje. Bądźcie
samokrytyczni.
Tak wiele firm kontynuuje swoje oparte o teorie produktywności i jakości podejście
do testowania, które rozpada się w pył, gdy okazuje się, że np. 85% błędów (to oszacowanie
oparte na moim doświadczeniu z klientami) jest lokalizowanych dzięki technikom
eksploracyjnym lub kiedy orientują się, że dokumentacja testowa przygotowana przez nich
już nie pomaga im w poprawie testów, a raczej stała się powodem utraty mnóstwa czasu
i energii. Wiele osób zakłada, że nowi testerzy zyskają dzięki zapoznaniu się ze starą
dokumentacją, ale wystarczy obserwować nowych testerów, aby zorientować się, że takie
założenie zwykle jest kompletnie błędne. Testerzy uczą się poprzez eksplorację oraz poprzez
udział w projektach z innymi ludźmi.
Warto czytać książki Gerald'a M. Weinberg'a. Szczególne jego serię o zarządzaniu
jakością oprogramowania.
W jaki sposób powstało: "Czego nauczyłem się testując oprogramowanie"?
Cem Kaner i ja braliśmy udział w konferencji poświęconej tworzeniu "wzorców"
testowych i zaczęliśmy frustrować się, kiedy zaczęto zadawać nam pytania dotyczące
"zakręconych" i mało użytecznych formatów. Wówczas to Cem wpadł na pomysł, aby spisać
zestaw prostych idei, każda z bardzo interesującym i wdzierającym się w pamięć tytułem.
Idee te stanowiły nasz zbiór wzorców. Przekazaliśmy szkic naszego opracowania Bretowi
Pettichord, który dołączył do projektu i ruszyliśmy do pracy.
Początkowo, podobnie jak we wszystkich projektach, w których brałem udział,
niewiele się działo. Ale wkrótce Cem zawarł umowę dotyczącą publikacji naszego
opracowania, co stanowiło znak, że należy szybko ruszyć do pracy. Zebraliśmy się razem
w moim laboratorium i w wyniku burzy mózgów zebraliśmy 522 idee dotyczące testowania,
którymi chcieliśmy podzielić się z innymi, kiedy zabieraliśmy się za to rzemiosło. Potem
podzieliśmy je na rozdziały i zabraliśmy się za nie.
Pisanie książki polegało na pisaniu mnóstwa email'i pomiędzy nami. Założeniem było
napisanie książki, która trafi do zapracowanego testera i z której będzie mógł korzystać bez
potrzeby czytania jej w określonym porządku.
Jaka jest według Ciebie najważniejsza lekcja, którą każdy tester powinien poznać czy to
na podstawie doświadczenia innych, czy też własnego?
Strona 25 z 49
26. TESTER.PL
Oto ona: Testowanie jest w Twojej głowie4. To znaczy, że najważniejsze w testowaniu
jest to jak myślisz, co myślisz, co widzisz i co zapamiętujesz. Czynnik ludzki w testowaniu
jest fundamentalny i nie może być zastąpiony przez automatyzację tego procesu.
Jestem przekonany, że większość książek o testowaniu została napisana przez ludzi,
którzy nie mają zbyt dużego pojęcia o tym temacie. Mają pewne doświadczenie i dlatego
myślą, że wiedzą o co chodzi. Ale testowanie jest zagadnieniem bardzo wymagającym.
Podobnie jak psychologia wymyka się prostym opisom i analizom. Stąd kolejna lekcja:
"Większość książek o testowaniu nie mówi prawdy o testach".
Należy zatem uczyć się następujących umiejętności:
•
•
•
•
•
w jaki sposób obserwować to co się dzieje,
jak stosować metody naukowe,
jak myśleć systematycznie,
jak współpracować z ludźmi,
jak stać się częścią społeczności samokrytycznej.
Czy pracujesz nad kolejną książką?
Co pewien czas przygotowuję materiał do kolejnego wydania książki Kaner'a "Testing
Computer Software" i stale pracuję nad książką o niekonwencjonalnym poznaniu.
Co miałeś na myśli określając indyjskich testerów swoim blogu mianem "Śpiącego
Giganta"? W jaki sposób mogą się oni "przebudzić"?
Nie widzę znaczących przeciwskazań stojących na drodze Indii ku staniu się
międzynarodowym centrum wykształconych testerów, jeśli oczywiście mieszkańcy Indii będą
chcieli zajmować się testami.
Zanim nie odwiedziłem Indii myślałem, że istnieją bariery edukacyjne i kulturowe.
Myliłem się. Proszę testerów z Indii o przyjęcie moich przeprosin.
Nie wiem, co powoduje ludźmi, że budzą się rano. Zastanawiam się jak to możliwe, że
budzę się każdego ranka. W jednym momencie śpię, a w następnym budzę się. To zaś, co
mogę stwierdzić, to fakt, że początkowo myślałem, że ludzie z którymi pracowałem i których
uczyłem w dwóch firmach w Bangalore nie interesują się testowaniem i mają ograniczone
pojęcie o nim. Ale grupa szybko robiła postępy i mogłem obserwować znaczącą poprawę
w ich zdolności do stawiania czoła zadaniom, które przed nimi stawiałem. W niektórych
grupach spostrzegłem też bardzo wiele chęci i entuzjazmu do nauki testowania. Sądzę, że
czynnikiem, który wpływa na pracowników indyjskiej społeczności technicznej, to dążenie do
uzyskania przewagi konkurencyjnej. Ci ludzie pragną stać się liderami światowego
społeczeństwa testerów, nie chcą być tymi słabszymi. Obecnie nie znam nikogo, kto
wypowiada się o Indiach jako kraju wiodącym prym w jakimkolwiek intelektualnym
4
Testing Is In Your Head
Strona 26 z 49
27. TESTER.PL
zagadnieniu dotyczącym testowania. Tak pozostanie tak długo aż niektórzy z nich nie pokażą
się "online" oraz w ramach różnych społeczności, i to nie jako nieśmiali "podsłuchiwacze",
czy osoby powtarzające historyczne idee z lat osiemdziesiątych (ciągle jest sporo takich
osób), ale jako praktycy wspierający rozwój najnowszych idei dotyczących testowania.
Te najnowsze idee, to według mnie lekkie wytwarzanie, usprawnianie procesu oparte
na umiejętnościach, testowanie heurestyczne oraz wyrafinowane psychologiczne teorie
związane z testowaniem.
Gdybyś przeprowadzał wywiad sam ze sobą, jakie pytania byś sobie zajął?
Oto one:
Co zajmuje Ci najwięcej czasu?
Przez większość czasu jestem w drodze, prowadzę kursy szybkiego testowania5
i testowania opartego na ryzyku6, biorę udział w konferencjach. Czasami pracuję jako ekspert
lub biegły w sprawach sądowych.
Co najbardziej lubisz robić?
Chciałbym więcej testować, jestem zmęczony ciągłym mówieniem o tym przez cały
czas. Projekt, który dał mi najwięcej radości, to testowanie Windows XP Embedded podczas
sprawy przeciwko firmie Microsoft w roku 2002. To wielki wstyd, że nie mogę napisać co
wówczas wykryłem podczas testowania, ani jakiej metody użyłem. Może kiedyś zostanę
zwolniony z umowy dotyczącej tajemnicy zawodowej.
5 rapid software testing
6 risk-based software testing
Strona 27 z 49
29. TESTER.PL
LReport – narzędzie do prezentacji i weryfikacji wyników zapytań
bazodanowych
Piotr Kałuski
CGI
Piotr Kałuski
Jest absolwentem Wydziału Elektroniki i Technik
Informacyjnych Politechniki Warszawskiej, kierunek informatyka.
Od 1995 uczestniczył w wielu projektach informatycznych jako
programista analityk, projektant i kierownik zespołu. Obecnie jest
pracownikiem firmy CGI i jako konsultant jest członkiem zespołu
System Test w firmie Polkomtel. Dziedzina jego zainteresowań to
sposoby usprawnienia procesu testowania i wykorzystanie narzędzi
Open Source w procesie wytwarzania i testowania
oprogramowania. Szczegóły można znaleźć pod adresem
www.piotrkaluski.com.
Strona 29 z 49
30. TESTER.PL
LReport – narzędzie do prezentacji i weryfikacji wyników zapytań
bazodanowych
Piotr Kałuski
CGI
Streszczenie
W artykule tym zaprezentuję narzędzie do czytelnej prezentacji wyników zapytań i
automatycznego porównywania tych wyników z oczekiwaniami. Spróbuję przekonać, że
czytelna dokumentacja wyników testów nie tylko cieszy oko, ale jest ważnym elementem
procesu wytwarzania i wdrażania oprogramowania wysokiej jakości. Będę też bronił tezy, że
w wielu sytuacjach skuteczna automatyzacja testów wcale nie musi obejmować automatyzacji
akcji na GUI. Podstawowe tezy przedstawione poniżej były prezentowane na I Konferencji
Stowarzyszenia Jakości Systemów Informatycznych.
Dokumentowanie testów – odwieczny problem testerów
Myślę, że większość testerów w swojej codziennej pracy, często staje przed
dylematem
– czy powinniśmy więcej czasu poświęcić na stworzenie rzetelnej, czytelnej
dokumentacji testów, które już wykonaliśmy
– czy też powinniśmy, kosztem jakości dokumentacji, postarać się wykonać jak
największą ilość scenariuszy.
W większości przypadków decydujemy się na drugie wyjście. Dokumentujemy gorzej
bądź wcale, aby móc przetestować jak najwięcej funkcjonalności. Bądź co bądź,
najważniejszym zadaniem testera jest jak najdokładniej przetestować powierzone mu
oprogramowanie.
Jednak posiadanie czytelnej dokumentacji testów ma pewne zalety, wobec których nie
powinniśmy przechodzić obojętnie. W procesie wytwarzania oprogramowania wysokiej
jakości, odgrywa ona dosyć ważną rolę w przepływie dokumentacji i wiedzy w firmie. Dobra
dokumentacja:
•
Pozwala szybko i sprawnie weryfikować wyniki testów
To oczywiste. Łatwiej jest wyłowić błędne dane, jeżeli są one podane w
sposób przejrzysty i czytelny.
•
Jest bazą wiedzy o testowanej funkcjonalności.
Ten drugi punkt chciałbym trochę rozwinąć. W firmach, w których proces
wytwarzania oprogramowania jest na wysokim poziomie, dla każdego modułu jest
tworzony zestaw dokumentacji – wymagania, specyfikacja funkcjonalna, architektura.
Jednak praktyka uczy, że te dokumenty, jakkolwiek niejednokrotnie kompletne i
rzetelne, nie są najlepszą lekturą dla osób, które chcą szybko zrozumieć szczegóły
działania systemu. Do wielu najlepiej przemawiają dobrze zilustrowane przykłady.
Stąd taka popularność tutoriali. Czytelny opis przebiegu testu jest właśnie takim
Strona 30 z 49
31. TESTER.PL
tutorialem. W związku z tym może być cennym źródłem wiedzy o tym jak działa
testowana aplikacja. Źródłem wiedzy zarówno dla osób doświadczonych, jak i dla
osób nowych, które dopiero system poznają.
Niestety, tworzenie czytelnej dokumentacji testów zajmuje czas. Różnica w czasie
potrzebnym do starannego i niedbałego opisu rezultatów jest znaczna. Dlatego decyzję o
przykładaniu dużej wagi do jakości dokumentacji trzeba dobrze przemyśleć, z pełną
świadomością jej kosztów. Lub też mieć pomysł jak te koszty zmniejszyć.
Niektórzy nie mają wyboru. Kontrakt wymusza na nich tworzenie kompletnej
dokumentacji wyników testów. Wtedy ich problemem nie jest czy tworzyć dokumentację
tylko raczej – jak to robić najbardziej efektywnie.
Niezależnie od tego czy jesteśmy do tego zobligowani kontraktem czy nie,
skorzystanie z narzędzia, które usprawni proces dokumentacji i weryfikacji rezultatów testów
może przynieść nam znaczne korzyści. LReport jest właśnie takim narzędziem.
LReport
LReport jest narzędziem do prezentacji wyników zapytań i ich weryfikacji.
Jakkolwiek nie wszystkie scenariusze testowe zawierają w sobie operacje na bazie danych, to
w większości aplikacji komercyjnych modyfikacje w bazie danych są jednym z głównym
efektów wykonania większości operacji. Jeżeli więc usprawnimy dokumentowanie tego
aspektu zachowania aplikacji, korzyści mogą być znaczne.
Co konkretnie LReport robi? Najłatwiej będzie mi to zilustrować przykładem.
Przykład
Wyobraźmy sobie, że testujemy aplikację dla firmy usługowej. Testujemy dodawanie
nowej usługi klientowi. Wiemy, że dodanie nowej usługi spowoduje modyfikację w 3
tabelach – CUSTOMERS, SERVICES, INVOICES. Scenariusz testu jest następujący – dodaj
nową usługę dla konta 12345. Rzetelne wykonanie tego testu wymaga abyśmy sprawdzili i
udokumentowali stan bazy danych przed wykonaniem testu, wykonali test i sprawdzili i
udokumentowali stan bazy danych po teście. W naszym przykładzie oznacza to umieszczenie
w dokumencie rezultatów następujących zapytań:
select * from CUSTOMERS where CUSTOMER_ID = 12345
select * from SERVICES where CUSTOMER_ID = 12345
select * from INVOICES where CUSTOMER_ID = 12345
Najszybszym sposobem udokumentowania zawartości bazy danych jest skorzystanie
z narzędzia typu RapidSQL, OraTool czy SQLPlus do wykonania zapytania i następnie
skopiowanie wyników zapytań do dokumentu. W naszym przypadku wyglądałoby to tak:
Select * from CUSTOMERS where CUSTOMER_ID = 12345
Strona 31 z 49
32. TESTER.PL
CUSTOMER_ID
LAST_NAME FIRST_NAME
FISCAL_NUMBER TAX
REGION
BANK_ACCOUNT
EMPLOYER LAST_KNOWN_SALARY
PHONE
ADDRESS
PREFFERED_TIME_TO_CONTACT
PROFESSION
CREDIT_CARD_NUMBER FATHERS_NAME
MOTHERS_NAME
MOTHERS_MAIDEN_NAME MAIDEN_NAME
DATE_OF_BIRTH CUSTOMER_SEGMENT
VIP BAD_DEBTS
IN_COLLECTION LAST_NOTE DATE_OF_CREATION
NUMBER_OF_SERVICES DISCOUNT_PLAN STATUS
EDUCATION
RESPONSIBLE_PERSON ELIGIBLE_FOR_PROMOTIONS
REASON_OF_DEACTIVATION
DEACTIVATION_DATE
COMMENTS
12345
Green
Marjorie 345-348-34-34 VAT22
Warsaw
12356232-238923-239238
Kaluski&Kaluski
10000
415 986-7020
309 63rd St. #411
Afternoon
Programmer
2562-2389-2376-2321 Jan Anna Kowalska
14-07-1984
INDIVIDUAL
N
N
N
01-032003 2
HJ-KDISC AC
MSC Jan Nowak Y
Moved to
our company from competitors
Select * from SERVICES where CUSTOMER_ID = 12345
CUSTOMER_ID
SERVICE_NUMBER SERVICE_TYPE
START_DATE
SERVICE_CHARGE STATUS
COMMENTS ADDRESS
DEACTIVATION_REASON DEACTIVATION_DATE
ON_HOLD
LAST_COMPLAINT LEVEL_OF_SATISFACTION
DISCOUNT
12345
1
SUPPORT
19-09-2004
24.5 AC
First
service activated for the customer.
309 63rd St. #411
N
31-09-2004
7
30
12345
2
QUICK_DELIVERY 29-09-2004
customer's request. 235 3rd St. #89
0
4.0
N
AC
On
10
Select * from INVOICES where CUSTOMER_ID = 12345
CUSTOMER_ID
INVOICE_ID
PAYMENT_TYPE
PAYED_ON_TIME
DISCOUNTS ALTERNATE_ADDRESS
TOTAL_NET ISSUED_BY IN_SAP
REJECTION_REASON
12345
1238.57
pkaluski
ISSUES_DATE
PAYMENT_DATE
AMOUNT
AMOUNT_NOT_PAID
PAYMENT_DELAY TOTAL_TAX
REVIEWED_BY
REVIEWED_ON
12345/1
01-09-2004
11-09-2004
CD
0.00 23.80
200.00
1038.57
N
lkowalski 02-09-2004
12345
12345/2
08-09-2004
18-09-2004
CD
57.45
3.00 0.00
7.45 50.00
pkaluski
lkowalski 09-09-2004
Strona 32 z 49
Y
N
N
33. TESTER.PL
12345
12345/3
15-09-2004
25-09-2004
500.00
300 5.00
200.00
300.00
Y
lkowalski 16-09-2004
12345
5000.00
pkaluski
CS
Y
pkaluski
12345/4
22-09-2004
01-10-2004
CD
0
250.14
2000.00
3000.00
N
zjankowsk 02-10-2004
Y
Jak widać, dane są kompletne, ale trudno je nazwać czytelnymi. Jeżeli ktoś ciągle
sądzi, że te dane są czytelne to mam dla niego prosty test. Proszę w ciągu 10 sekund określić,
jaka jest wartość pola LAST_NOTE w wierszu z tabeli CUSTOMERS.
Jakkolwiek można trochę nad tymi danymi popracować i ich prezencję upiększyć, to
wyraźnie widać pewną sprzeczność między czytelnością a kompletnością raportu. Im bardziej
kompletne dane zamieszczamy w raporcie (zapytania na wszystkich zmodyfikowanych
tabelach, wszystkie kolumny) tym raport staje się mniej czytelny ze względu na natłok
danych. Z drugiej strony, wybiórcze umieszczanie danych w raporcie ma 2 wady:
•
•
jest czasochłonne (zawsze jest łatwiej napisać “select *” niż select z nazwami
poszczególnych kolumn)
selekcjonując dane, możemy nie udokumentować wierszy, kolumn, których zawartość
na początku wydawała się nieważna a potem okazała się mieć duże znaczenie.
LReport radzi sobie z tą sprzecznością, co zademonstruję w tym przykładzie.
Oto jak wygląda raport, wygenerowany przez LReport dla stanu sprzed testu:
Rysunek 1 - Stan bazy danych przed wykonaniem testu
Strona 33 z 49
34. TESTER.PL
Jak widać nie wszystkie kolumny są uwzględnione w dokumencie. Co więcej, niektóre
są pokolorowane, dzięki czemu łatwiej jest zidentyfikować, do jakich kolumn należą dane
wartości. Powyższy raport jest utworzony w formacie RTF. Dzięki temu łatwo jest go
skopiować i wkleić do dokumentu w formacie Word. Poza tym, LReport tworzy we
wskazanym katalogu pliki tekstowe CSV, w których znajdują się pełne rezultaty wszystkich
interesujących nas zapytań. Dzięki temu, z jednej strony mamy czytelny raport a jednocześnie
mamy zapisany komplet danych, do którego możemy się odwołać w przypadku, gdy będzie
potrzebna dokładniejsza analiza.
Po wykonaniu scenariusza (w naszym przypadku – dodaniu usługi), LReport pomaga
nam sporządzić raport ze stanu po wykonaniu testu:
Rysunek 2 - Stan bazy danych po wykonaniu testu
LReport nie tylko zaprezentował wyniki zapytań po wykonaniu testu. Dodatkowo,
uwypuklił zmiany, jakie zaszły w bazie danych. W tabeli CUSTOMERS pole
NUMBER_OF_SERVICES jest wydrukowane kursywą, pogrubione i podkreślone. Oznacza
to, że wartość tego pola zmieniła się po wykonaniu testu. Rzeczywiście, przed wykonaniem
testu była to wartość 2, a po wykonaniu - 3.
W tabeli SERVICES, ostatni wiersz jest wydrukowany kursywą, pogrubiony
i podkreślony. W ten sposób oznaczony jest nowy wiersz, tzn. taki, którego przed
wykonaniem testu nie było w tabeli. Z tego samego powodu ostatni wiersz tabeli INVOICES
ma taki sam format.
Podsumujmy. LReport stworzył za nas czytelny, ładnie sformatowany raport
z wyników interesujących nas zapytań. Jednocześnie, zachował komplet danych w plikach
Strona 34 z 49
35. TESTER.PL
tekstowych, dzięki czemu łatwo będzie przeanalizować komplet danych w przyszłości, gdyby
okazało się, że w raporcie nie zawarliśmy ważnych kolumn.
Oczywiście, LReport nie jest tak mądry, aby samemu zdecydować o sposobie
formatowania wyników. Musimy go sami skonfigurować. Jak to robimy, pokażę później.
Teraz chciałbym powiedzieć o drugiej ważnej funkcjonalności LReport –
porównywaniu rezultatów zapytań z oczekiwaniami.
Automatyzacja testów
Śledząc różne opracowania na temat automatyzacji testów można by odnieść
wrażenie, że najważniejszą gałęzią tej dziedziny jest automatyzacja operacji na GUI.
Jakkolwiek są aplikacje i środowiska, w których część GUI-owa testów zajmuje dużo czasu,
to jest też wiele sytuacji, kiedy jest wręcz przeciwnie. Operacje GUI-owe zajmują
wprawnemu testerowi mało czasu w porównaniu w innymi czynnościami, które musi
wykonać, aby w pełni przeprowadzić testy. Do takich czynności należą:
•
Znajdowanie danych spełniających warunki początkowe scenariusza testowego.
Np. mamy reaktywować klienta, który był dezaktywowany 2 miesiące temu i
w momencie dezaktywacji miał określoną grupę przywilejów. Często okazuje się, że
znalezienie w bazie testowej takiego klienta zajmuje dużo więcej czasu niż
przeprowadzenie potem testu
•
Weryfikacja rezultatów
Jeżeli testujemy transakcję, która modyfikuje 5 tabel, to dokładna weryfikacja
rezultatów jest zadaniem żmudnym, czasochłonnym, przy którym łatwo popełnić
pomyłkę.
•
Dokumentacja rezultatów
Test automatyczny też jest testem. W związku z tym też musi być
udokumentowany, najlepiej automatycznie.
LReport nie pomoże nam przy wyszukiwaniu danych testowych. Ale może być bardzo
użyteczny przy automatycznej weryfikacji i dokumentowaniu rezultatów. Przejdźmy od razu
do przykładu.
Przykład – cd.
Wyobraźmy sobie, że testujemy funkcjonalność z poprzedniego przykładu. Tym
razem jednak w testowanej aplikacji jest błąd. Błąd polegający na tym, że po dodaniu jednej
nowej usługi:
•
•
•
Pole NUMBER_OF_SERVICES w tabeli CUSTOMERS ma złą wartość
W tablicy SERVICES zamiast jednego, dodawane są 2 wiersze
W tablicy INVOICES powinien być dodany jeden nowy wiersz. Tymczasem, zamiast
tego usunięty zostaje jeden z istniejących.
Oto jak LReport raportuje ten problem dla tablicy CUSTOMERS:
Strona 35 z 49
36. TESTER.PL
Rysunek 3 - Raportowanie błędu dla tablicy CUSTOMERS
LReport prezentuje wynik zapytania. Poniżej informuje, że pewne wartości w wierszu
różnią się od oczekiwanych. Informacja ta jest przekazana w postaci tabelki. Pierwsze
kolumny to klucz tabeli (w tym przypadku CUSTOMER_ID). Następnie pokazane są
wszystkie kolumny, dla których wartości są inne niż oczekiwane. Pierwszy wiersz zawiera
wartości oczekiwane, drugi – faktyczne. Jak widać, po dodaniu jednej usługi, w polu
NUMBER_OF_SERVICES pojawiła się wartość 7 zamiast oczekiwanej wartości 3.
Przejdźmy do tabeli SERVICES:
Rysunek 4 - Raportowanie błędu dla tablicy SERVICES
Zamiast jednego, pojawiają się dwa nowe wiersze. Czyli jeden wiersz pojawił się
nieoczekiwanie. Zostajemy o tym poinformowani przez LReport.
Tabela INVOICES:
Strona 36 z 49
37. TESTER.PL
Rysunek 5 - Raportowanie błędu dla tablicy INVOICES
Zamiast dodać jeden wiersz, program jeden wiersz usunął. Efekt jest taki, że brak
dwóch oczekiwanych wierszy. Tego, co istniał i został błędnie usunięty oraz tego, który
powinien być wstawiony. LReport informuje o tym w sekcji oczekiwanych, ale nie
znalezionych wierszy. Przy okazji, proszę zwrócić uwagę na prezentację wierszy, które
zostały usunięte - czyli poprzednio były, a teraz ich nie ma. Są one prezentowane z użyciem
czcionki przekreślonej.
Konfiguracja narzędzia.
LReport jest obiektowo zorientowaną biblioteką napisaną w Perlu. Pakiet instalacyjny
w formacie obsługiwanym przez program ppm, jest dostępny na stronie
http://lreport.sourceforge.net. Zainstalowanie go nie powinno być trudne.
Osobnym tematem jest definicja układów raportów i definicja oczekiwań dla
weryfikacji rezultatów. Oto przykład definicji układu raportu dla tablicy CUSTOMERS
i SERVICES:
Strona 37 z 49
38. TESTER.PL
Rysunek 6 - Definicja raportu dla tabel CUSTOMERS i SERVICES
Do definicji używamy pliku XML. Dla każdej tabeli (a tak naprawdę zapytania)
tworzymy tag SELECT. Zawiera on takie składowe jak STATEMENT, która określa jakie
zapytanie jest bazą danego raportu, KEY, określająca kolumny, które jednoznacznie
identyfikują wiersz. Kolumny, które się pokażą w raporcie i ich ewentualne kolory
definiujemy za pomocą tagów COLUMN. Tym samym fragment:
<COLUMN name=”NUMBER_OF_SERVICES”
color=”yellow” />
określa, że prezentacja wyników zapytania na tabeli CUSTOMERS będzie zawierać
kolumnę NUMBER_OF_SERVICES i wartości w tej kolumnie zostaną pokolorowane na
żółto.
Jest więcej szczegółów konfiguracyjnych. Nie będę ich tu teraz przedstawiał, bo nie
jest celem tego artykułu przedstawienie kompletnej instrukcji obsługi narzędzia LReport.
Chciałem raczej przedstawić jego możliwości. Dokumentację można znaleźć na stronie
http://lreport.sourceforge.net. Szczególnie polecam tutorial.
Strona 38 z 49
39. TESTER.PL
Zakres zastosowań
LReport jest narzędziem, które niewątpliwie może przynieść duże oszczędności czasu
potrzebnego na testowanie. Jednak definicja raportów a już tym bardziej specyfikacja
oczekiwań do weryfikacji rezultatów zajmują czas. Dlatego LReport powinien być używany
do pomocy w operacjach powtarzających się. Jeżeli testujemy daną funkcjonalność co
miesiąc to wtedy warto sięgnąć po LReport. Jeżeli przy testach różnych funkcjonalności
zawsze interesują nas zmiany w tych samych tabelach to wtedy warto sięgnąć po LReport.
Warto też sięgnąć po LReport przy automatyzacji testów i tworzeniu testów regresyjnych. We
wszystkich tych przypadkach, początkowa inwestycja szybko się zwróci.
Są jednak inne sytuacje. Czasami testujemy nową funkcjonalność, która często
gruntownie się zmienia, co powoduje, że w każdym teście wykonujemy inne zapytania i już
do nich nie wracamy. Czasami badamy aplikację, tworząc szereg jednorazowych zapytań.
Wtedy LReport nie jest najlepszym wyborem. Lepiej wtedy skorzystać z narzędzia typu
RapidSQL, OraTool czy SQLPlus. Doskonale nadają się one do tych celów i trudno mi sobie
wyobrazić coś lepszego.
Teraźniejszość i przyszłość LReport
LReport jest rozwijany jako projekt open source na stronie Source Forge
(www.sourceforge.net). Na razie narzędzie rozwijam sam. Jestem otwarty na wszelkie
sugestie, uwagi i pomoc. Pierwszą wersję narzędzia używam w codziennej pracy w zespole
System Test w Polkomtelu.
Strona 39 z 49
40. TESTER.PL
Badboy – nie taki zły jak nazwa wskazuje
Robert Rzeszotek
Robert Rzeszotek
Jest
absolwentem
Wydziału
Elektrycznego
Politechniki
Warszawskiej. Od ponad dwóch lat uczestniczy w projektach
informatycznych jako tester. Jest pracownikiem firmy IMPAQ. Dziedzina
jego zainteresowań to wykorzystanie narzędzi Open Source w procesie
testowania.
Strona 40 z 49
41. TESTER.PL
Badboy7 – nie taki zły jak nazwa wskazuje
Robert Rzeszotek
Kiedy testy regresyjne doprowadzają testera do szału wciąż powtarzającą się pracą,
zazwyczaj przychodzą myśli o automatyzacji, jako złotego środka na pozbycie się rutyny. Tu
pojawiają się problemy: jakie narzędzie wybrać, ile będzie to kosztować i ile czasu zajmie
nam przygotowanie scenariuszy testowych. W niniejszym artykule chciałbym zaprezentować
narzędzie do automatyzacji testów aplikacji okienkowych, narzędzie darmowe, które nie
wymaga poświęcania ogromnej ilości czasu na przygotowanie scenariuszy testowych.
Narzędziem tym jest Badboy. Badboy znacznie ułatwia testowanie poprzez nagrywanie
skryptów testowych i późniejsze ich odtwarzanie. Nie posiada żadnych skomplikowanych
funkcji, jest prostym intuicyjnym narzędziem do wykonywania testów jednostkowych.
Badboy działa monitorując aktywną przeglądarkę Internet Explorer, która jest
widoczna w jego oknie. Zapisuje interesujące nas wydarzenia, które można potem zobaczyć,
jeśli się zechce, oraz powtórzyć nagrany scenariusz. Narzędzie to pozwala na odtwarzanie
scenariuszy testowych tak, by użytkownik widział kroki, jakie wykonuje narzędzie, jeśli nie
interesuje nas obserwowanie kroków, scenariusz testowy możemy uruchomić w tle.
Badboy jest zbudowany z trzech głównych okien:
•
•
•
Okna przeglądarki, gdzie dokonuje się nagrywania jak również gdzie obserwuje się
działanie scenariusza testowego.
Okna scenariusza testowego, gdzie widzimy wszystkie przypadki testowe, kroki tych
przypadków, zmienne jakie należy zdefiniować, odpowiedzi i ich czas.
Okno narzędzi, gdzie widzimy:
o wyniki wykonywanych testów wraz ze średnim czasem, który był poświęcony
na odtworzenie scenariusza,
o wartości zmiennych jakie są używane w danym teście. Podczas wykonywania
testu są wyświetlane tylko te zmienne, które są używane akurat w tym
momencie.
o wykres czasów wykonywania poszczególnych scenariuszy w czasie,
o opcje dostępne przy tworzeniu scenariuszy testowych,
o listę dostępnych form w nagranym scenariuszu.
7
http://www.badboy.com.au/
Strona 41 z 49
42. TESTER.PL
Okno przeglądarki
Okno kroków
scenariusza
testowego
Okno narzędzi
Rys. 1 Interfejs narzędzia Badboy
Poniżej zostanie przedstawiony przykład scenariusza testowego, który umożliwi
zaprezentowanie niektórych funkcji tego narzędzia. Scenariusz testowy będzie testował
wysyłanie sms’a ze strony jednego z operatorów GSM. Dodatkowo zostanie zmodyfikowany
tak, by wysyłał na różne numery, które będzie pobierał z pliku.
Nagrywanie
Nagrywanie może być włączone bądź wyłączone. Jeśli Badboy jest w trybie
nagrywania, w nagłówku okna przeglądarki pojawia się komunikat.
Jeśli naciśniemy przycisk Play bądź Stop, nagrywanie zostanie zakończone. Jeśli
naciśniemy przycisk Play, automatycznie zostanie zatrzymane nagrywanie, a skrypt testowy
zostanie uruchomiony. Można ponownie zacząć nagrywanie poprzez naciśnięcie na czerwony
przycisk Nagrywania w pasku narzędzi.
Tak więc można zacząć nagrywać nasz scenariusz testowy znając podstawową funkcję
tego narzędzia. Naciskamy czerwony przycisk nagrywania wybierając go z paska narzędzi.
W polu Url: wpisujemy stronę http, którą chcemy przetestować i naciskamy przycisk Go.
Strona zostanie załadowana do okna BadBoy’a. Wykonujemy odpowiednie czynności na
stronie, które umożliwią nam wysłanie sms’a; czyli wpisanie numeru, na który zostanie
wysłany sms, oraz treści, jaka ma być wysłana. Wysyłamy przez naciśnięcie przycisku
Wyślij. Zatrzymujemy nagrywanie przez naciśnięcie przycisku Stop w pasku narzędzi.
Wykonane w oknie operacje zostały zapisane w formie kroków w oknie kroków scenariusza
Strona 42 z 49
43. TESTER.PL
testowego. Zostały również zapisane dane, które wprowadzaliśmy nagrywając ten scenariusz
testowy.
W ten nieskomplikowany sposób mamy już sporządzony prosty scenariusz testowy,
który możemy wykonać przez naciśnięcie przycisku Play. Wynik każdego z kroków zostanie
zapisany przy każdym kroku scenariusza testowego. Dodatkowo zostanie też zapisany czas
odpowiedzi każdego z kroków.
Mając nagrany scenariusz testowy możemy go przeanalizować. Postaram się opisać
ten scenariusz testowy.
Nagłówek testu
Krok testu
Zmienne
Odpowiedzi testu
Rys. 2. Okno dialogowe scenariusza testowego
Każdy scenariusz testowy posiada swój nagłówek, pod którym są umieszczone kroki
testowe jakie narzędzie wykonuje podczas odtwarzania scenariusza. W pierwszym kroku
zawsze znajduje się lokalizacja serwera, gdzie zainstalowana jest aplikacja. W zależności od
testowanej strony, w krokach pojawiają się zmienne i odpowiedzi. Zmienne pojawiają się
w tych krokach, w których jest zapis danych. Natomiast odpowiedzi pojawiają się w każdym
wykonanym kroku. W odpowiedziach podany jest dodatkowo czas odpowiedzi. Pojawienie
się odpowiedzi informuje o wykonaniu kroku. Jeśli test jest powtarzany, wiemy ile razy,
ponieważ liczba powtórzeń jest zliczana.
Strona 43 z 49
44. TESTER.PL
Zmienne jakie po nagraniu scenariusza znajdują się w krokach są to zmienne, które
wprowadziliśmy podczas nagrywania testu. Każda zmienna odpowiada jednemu polu
w aplikacji, do którego została wprowadzona dana. Możemy je modyfikować poprzez
dwukrotne kliknięcie zmiennej. Pojawi nam się okno gdzie możemy dokonać
zmiany wartości zmiennej, jak też
nazwy samej zmiennej (rys. 3).
Rys. 3 . Okno właściwości zmiennych
Mamy
główny
już
test,
wykonany
który
został
uruchomiony i działa. Teraz do tego
scenariusza dodamy sprawdzanie
różnych danych. Dane w Badboy
mogą być pobierane bezpośrednio
z bazy
danych,
kalkulacyjnego,
arkusza
Accessa,
bazy
FoxPro. W niniejszym przykładzie
dane będą wprowadzone w Excelu.
Rys. 4. Okno dialogowe dołączania źródła zmiennych
Po
zmiennej
zdefiniowaniu
naciskamy
przycisk
tablicy
Next.
Pojawia nam się okno: preferencje źródła
danych.
Mamy
w
jednym
okienku
zmienne, a w drugim wartości. Możemy
je
odpowiednio
sformatować
w zależności od typu danych. Jeśli to
mają być dane tekstowe, powinniśmy
odznaczyć pierwszą opcję w poniższych
polach. Jeśli danymi mają być liczby
całkowite, odhaczamy drugą opcję, a jeśli
Strona 44 z 49
45. TESTER.PL
Rys. 5 . Okno dialogowe preferencji źródła danych
dane mają być z miejscami po przecinku, wtedy należy wybrać opcję trzecią (rys 5).
Gdy mamy już zdefiniowane źródło danych, musimy dla każdej zmiennej w polu
wartości wpisać nazwę zmiennej, która będzie pobierana np. z excela. W naszym przypadku
nazwy zmiennych w arkuszu excela zostały tak samo nazwane, jak zmienne ze scenariusza
testowego. Aby zdefiniować zmienne tak, by były pobierane z arkusza excela, należy kliknąć
na zmienną prawym klawiszem myszy i wybrać opcję Add as variable. W polu wpisujemy
nazwę zmiennej, jaka jest zdefiniowana w arkuszu. Po modyfikacji zmiennych okno
scenariusza testowego wygląda jak pokazano na rysunku 6.
Dodatkowo w oknie zmiennych
pojawiły się zmienne, które zostały
dodane.
Jeśli
klikniemy
prawym
klawiszem myszy, będziemy mieli
kilka opcji, które można użyć, by
zmienne dostosować do scenariusza
testowego. Możemy dodać zmienną,
włączyć bądź wyłączyć automatyczny
przyrost zmiennych. Ustawimy dla
wybranych zmiennych automatyczny
przyrost na „yes”. Dzięki temu dla
każdego
wykonania
pobierana
inna
testu
będzie
ze
zbioru
dana
zmiennych.
Ustawienia
automatycznego dokonujemy klikając
na
zmienną
w
oknie
zmiennych,
prawym klawiszem otwieramy menu
i wybieramy opcję Auto increment on.
Rys. 6. Okno dialogowe scenariusza testowego o wprowadzeniu nazw zmiennych
Gdy już mamy ustawione zmienne musimy ustawić pętlę, która pomoże nam, by te
zmienne przyrastały. Dokonujemy tego w następujący sposób: klikamy prawym klawiszem na
krok testu, który odpowiada za wprowadzanie danych do aplikacji i wybieramy z menu
rozwijalnego Insert -> Increment. Otrzymujemy okno dialogowe właściwości przyrostu
zmiennych. Pierwsza opcja to przyrost wszystkich zmiennych, natomiast druga opcja to
przyrost specyficznej zmiennej, która może być wybrana z listy rozwijalnej.
Strona 45 z 49
46. TESTER.PL
Otrzymujemy
okno
dialogowe
właściwości przyrostu zmiennych. Pierwsza
opcja to przyrost wszystkich zmiennych,
natomiast
druga
opcja
to
przyrost
specyficznej zmiennej, która może być
wybrana z listy rozwijalnej.
Rys. 7. Okno właściwości przyrostu zmiennych
Teraz, aby scenariusz był wielokrotnie powtarzalny, należy ustawić mu ilość
powtórzeń. Dokonujemy tego w następujący sposób:
Klikamy prawym klawiszem myszy na nagłówek testu i wybieramy z menu
rozwijalnego Properties. Pojawia się nam okno dialogowe, w którym mamy możliwość
zdefiniowania nazwy scenariusza i liczby powtórzeń dla wszystkich zmiennych oraz dla
zmiennej, którą wybierzemy z rozwijalnej listy.
Zmienne,
które
chcemy by były zmieniane
podczas wykonywania testu,
zostały ustawione.
Rys. 8. Okno właściwości przypadku testowego
Aby scenariusz testowy był kompletny, należy dodatkowo ustawić warunek, który ma
być sprawdzany przez nasz scenariusz testowy. W naszym scenariuszu testowym będzie to
informacja o potwierdzeniu wysłania smsa. Ustawienia tego warunku dokonujemy przez
dodanie go do odpowiedniego kroku, wykorzystując funkcję Assertion. W oknie dialogowym
możemy dokładnie zdefiniować jak ma być wykonywane to sprawdzenie. Czy ma być
sprawdzany tekst, który ma istnieć na tej stronie czy nie; czy ma być sprawdzany we
wszystkich ramkach czy tylko na górze.
Strona 46 z 49
47. TESTER.PL
Możemy
w przypadku
ustawić
zrobić
zrzut
ekranu
niepoprawności,
poziom
możemy
zawiadomienia
nas
o wystąpieniu nieprawidłowości oraz dalsze
zachowanie
scenariusza
niepoprawności.
zostało
W
po
wykryciu
naszym
szukanie
ustawione
scenariuszu
wyrażenia
zawartego we wszystkich ramkach. Jeśli
zostanie wykryta jakaś nieprawidłowość,
zostanie
wysłane
a wykonywanie
zostanie
powiadomienie,
scenariusza
przerwane
w
testowego
miejscu,
gdzie
wystąpiła nieprawidłowość.
Rys. 9 Okno dialogowe do definiowania właściwości sprawdzania warunków
Tak zaprojektowany scenariusz
testowy
możemy
uruchomić
przyciskiem Run z paska narzędzi.
Wykona
on
10
takich
scenariuszy,
ale
dla
scenariuszy,
dla
każdej
samych
każdego
ze
zmiennej,
będzie pobierana inna wartość z pliku
zewnętrznego.
Rys. 10 Skonstruowany scenariusz testowy
Tak skonstruowany scenariusz testowy pojawi nam się w oknie scenariusza testowego
w formie jak na rysunku 10.
Gdy scenariusz testowy jest już gotowy możemy zacząć go używać.
Uruchomienie zostaje wywołane poprzez komendę Run. Test zostaje wykonany, a jego
wyniki pokazane w oknie wyników.
Strona 47 z 49
48. TESTER.PL
Prezentacja wyników jest dla każdego kroku, nie
dla całego scenariusza, co przy skomplikowanych
scenariuszach testowych może być kłopotliwe, jeśli
przyjdzie nam znaleźć krok, który nie przeszedł testu.
Rys. 11 Okno wyników
Przy dużej ilości scenariuszy testowych i dużej ilości powtórzeń można uruchomić
scenariusz testowy w tle. Można to zrobić w łatwy sposób uruchamiając Tools -> Run
Background Treads. Uruchamiając w ten sposób scenariusze nie mamy jednak wyników.
Jednak przy testach stabilności, bądź też przy testach wydajności, ta funkcja jest niezwykle
przydatna.
Możemy w tym oknie
ustawić ilość wątków, jakie
mają
być
wykonywane,
czyszczenie odpowiedzi, a także
opóźnienie z jakim ma być
wykonywane
kolejne
powtórzenie.
Uruchomienie
następuje poprzez naciśnięcie
przycisku Start.
Rys. 12 Okno dialogowe właściwości wykonywania testów w tle
Dodatkowo nie musimy uruchamiać scenariusza, przez otwieranie Badboya, lecz
używając do tego linii poleceń. Szczególnie jest to użyteczne kiedy nie zależy nam na
obserwacji czynności, które wykonuje narzędzie i chcemy np. uruchomić zestaw scenariuszy
testowych na całą noc.
To jedna z podstawowych funkcji tego narzędzia, umożliwiająca tworzenie
nieskomplikowanych automatycznych testów dla aplikacji okienkowych. Jak każde narzędzie,
i to ma swoje ograniczenia, ale posiada również swoje zalety.
Strona 48 z 49
49. TESTER.PL
Do zalet narzędzia należy zaliczyć prostotę w użyciu. Obsługa jest prawie intuicyjna,
więc aby wykorzystywać to narzędzie do pracy nie jest konieczne żadne szkolenie, wystarczy
trochę czasu by przeczytać może część instrukcji i „pobawić się” narzędziem, nagrywając
jakieś scenariusze testowe. Dodatkowym plusem jest to, że efekty tego co narzędzie robi,
pojawią się w jego oknie dialogowym.
Niewątpliwą wadą narzędzia jest ograniczona ilość powtórzeń danego scenariusza.
Maksymalnie można powtórzyć skrypt testowy 500 razy. Jeśli skrypt zostanie wykonany 500
razy, tester ponownie musi włączyć skrypt. Również blokujące są odpowiedzi, czyli wyniki
każdego z kroków. Przy dużych scenariuszach testowych będzie powstawało dużo tego typu
informacji, co będzie spowalniało narzędzie. Co jakiś czas należy wyczyścić odpowiedzi. Nie
ma tego problemu, jeśli testy będą wykonywane w tle. Wadą jest również niemożliwość
zapisania wyników w pliku, który po serii testów można by poddać analizie.
Narzędzie Badboy jest wciąż udoskonalane. Co jakiś czas pojawiają się nowe wersje
zawierające nowe funkcjonalności pozwalające na konstruowanie coraz bardziej
zaawansowanych scenariuszy. Może za jakiś czas to narzędzie będzie porównywalne do
komercyjnych narzędzi do automatyzacji testów.
Strona 49 z 49
