Prelekcje

Jak od zera uruchomic testy w organizacji?

Prezentacja: Testy od zera w organizacji

link do prezentacji, w której jest pokazane, że najlepsze zespoły Scrumowe nie posiadające testerów dorównują jakością produktów zespołom z testerami: The Impact of Agile Quantified (slajd 38)

 

Automation Through the Back Door

Prezentacja: SerettaGamba_Automation through the back door_Testwarez2014

When working on test automation it can happen that even though you have done everything right, good architecture, efficient framework and good tools you still don’t get anywhere. For Seretta Gamba the problem was that the product her team had to automate had turned so successful that anyone with just some domain knowledge was sent to the field and those left on the automation team didn’t really know the extended application. In a typical Catch 22 situation the work load in regression test prevented testers from supporting the automation team that therefore could not automate what would have effectively reduced the regression test load. Seretta reasoned that since testers used exactly the needed information to execute manual tests, the most efficient way to “harvest” it, would be to extend the test automation framework to support also manual testing. Learn how we succeeded in giving better support to manual testing while at the same time collecting the data needed to finally move on with test automation.

 

Test Automation Patterns

Half-day tutorial by Seretta Gamba and Dorothy Graham

Prezentacja: SerettaGamba_Patterns in Test Automation_excercise_tutorial_Testwarez2014

SerettaGamba_Patterns in Test Automation_tutorial_Testwarez2014

LAPTOPS REQUIRED

There are many problems in automating system level test execution. The surprising thing is that many people encounter the same problems, yet they are not aware of common solutions that have worked well for others – these are “patterns”. Seretta Gamba recognized the commonality of these test automation issues and their solutions and, together with Dorothy Graham, has organized them into Test Automation Patterns. Although unit test patterns are known elsewhere, our patterns address more general issues. Dot and Seretta cover management, process, design and execution patterns to help you recognize common test automation issues and show you how to identify appropriate patterns to solve the problems. Issues such as NO PREVIOUS AUTOMATION, HIGH ROI EXPECTATIONS, or HIGH TEST MAINTENANCE COST are addressed by patterns such as MAINTAINABLE TESTWARE, TOOL INDEPENDENCE and MANAGEMENT SUPPORT. Laptops are needed to gain access to the wiki (or an offline version if internet access is not available) during the tutorial.

 

 

 The Future of Testing

Prezentacja: testwarez_Future_of_Testing_Handout

The Future of Testing is clearly driven by upcoming, emerging information technologies. So the talk first will have a look on new technologies and IT trends. In the light of these trends I will discuss where we currently are in testing and what new testing methods and testing tools perhaps can be expected in 2050 or (more realistic) in 2020.

 

Testing in Agile/Scrum

Prezentacja: testwarez_Workshop – Agile Testing

 

Jak czytać rezultaty testów wydajnościowych

Prezentacja: Piotr_Pawluk_Reading Performance results_Testwarez2014

W czasie szkoleń o testach wydajnościowych skupiamy się głównie na tworzeniu skryptów w konkretnym narzędziu. W drugiej kolejności omawiamy jak sobie te testy organizować. Analiza wyników zwykle jest w ostatnim dniu szkolenia, Kiedy wszyscy są już zmęczeni i uciekają do domu.
Dlatego swoja prezentacje chciałbym poświecić jedynie analizie wyników. Bazuje tu na przykładach z projektów w których sam prowadziłem testy wydajnościowe:
W pierwszej kolejności patrze na ilość transakcji na sekundę – z tego mogę wnioskować jaka jest pojemność systemu, przy jakim obciążeniu zaczyna niedomagać, co się dzieje, gdy obciażenie spada.
Następnie patrze na czasy odpowiedzi – które transakcje trwają najdłużej,  Jak odpowiadają różne warstwy aplikacji, jak aplikacja odpowiada z różnych lokalizacji.
Jeśli dostępne są dane z monitoringu systemów – można z nich też dużo wyczytać:
Wnioskuje, który parametr wskazuje na wąskie gardło.
Sprawdzam czy jakiś zasób, np. pamięć nam nie wycieka.
Na koniec analizy sporządzam raport dla „interesariuszy” projektu
– dla programistów/architektów – żeby wiedzieli gdzie poprawiać aplikacje.
– dla decydentów – żeby wiedzieli czy system jest gotowy do wdrożenia.

 

Słowa kluczowe jak góry lodowe czyli rzecz o bibliotekach testowych

Prezentacja: MarcinKowalczyk_ SlowaKluczoweJakGoryLodowe_Testwarez2014

Testowanie w oparciu o słowa kluczowe jest bardzo rozpowszechnionym sposobem weryfikacji oprogramowania. Celem prezentacji jest przedstawienie zalet tworzenia własnych „keyword’ów”. Skojarzenie z górami lodowymi wynika z tego że są one zanurzone w większości w wodzie natomiast widoczny z lądu jest tylko ich wierzchołek. Analogicznie słowa kluczowe posiadają wierzchołek w postaci wywołania w platformie testowej natomiast funkcjonalność jest niewidoczna. Rzecz w tym, że w bardzo prosty sposób możemy stworzyć własnego „keyworda” i samemu zdecydować gdzie jest granica między wywołaniem a funkcjonalnością. Innymi słowy, możemy przenieść kroki testowe do biblioteki i ukryć je za wywołaniem dzięki czemu składnia samego przypadku testowego jest bardziej przejrzysta a funkcjonalność testowa gotowa do wykorzystania w innym teście. Poza optymalizacją automatycznych testów istnieją również bardziej oczywiste powody dla których moglibyśmy chcieć napisać własne biblioteki testowe. Po pierwsze potrzebna nam funkcjonalność testowa nie została jeszcze przez nikogo napisana więc musimy stworzyć ją samemu. Po drugie, potrzebna nam funkcjonalność może być specyficzna dla naszego środowiska w związku z czym trudno oczekiwać że jest ogólnodostępna. W czasie prelekcji, zostaną zaprezentowane przykłady oparte na powszechnie znanej platformie testowej Robot Framework. Zademonstrowane zostaną zalety wynikające z pisania własnych słów kluczowych oraz przykład tworzenia własnej biblioteki w języku Python i dokumentowania jej.

 

 

Pokaz możliwości narzędzia Microsoft Test Manager

Prezentacja: MartaFirlej_ MicrosoftTestManager_Testwarez2014

Celem prezentacji jest przedstawienie możliwości narzędzia Microsoft Test Manager ze wskazaniem jego silnych i słabych stron. Uczestnicy dowiedzą się od czego zacząć, jak skonfigurować pierwszy test plan, jak dodać, zarządzać i wykonywać testy, jak dodawać i zarządzać defektami oraz konfiguracją. Zaprezentowane zostaną także dodatkowe funkcje takie jak wspieranie wykonywania, nagrywania i odtwarzania testów oraz zbierania ich wyników.

Narzędzie jakim jest Microsoft Test Manager to samodzielna aplikacja, która nie jest częścią Visual Studio jednak wymaga połączenia z Team Foundation Server, który jest dla niego bazą danych. Przed rozpoczęciem pracy należy stworzyć oraz skonfigurować test plan. Następnie można skorzystać z jednej z dwóch części Testing Center lub Lab Center.

Testing Center zostal zaprojektowany, żeby wspierać główne obszary i aktywnosci takie jak: Plan, Test, Track oraz Organize.

Testing Center jest używane do:

• tworzenia i zarządzania planami testów(Test Plan),

• tworzenia i zarządzania zestawami testowymi (Test Suites),

• tworzenia, zarządzania i przypisywania współdzielonych kroków testowych (Shared steps) do przypadków testowych,

• tworzenia i zarządzania przypadkami testowymi dla danego test planu,

• tworzenia, zarządzania i przypisywania konfiguracji testowych do danego przypadku testowego, takich jak system operacyjny, przeglądarka,

• przypisywania testerów do poszczególnych przypadków testowych,

• przyporządkowywania każdego elementu test planu do wymagań z Team Foundation Server,

• przypisywanie używanej wersji oprogramowania (Bulid) do wykonywanych przypadków testowych,

• wykonywania testów manualnych,

• wykonywania testów eksploracyjnych,

• tworzenia i zarządzania defektami,

• analizy wpływu wykonanych testów i wyłonienia rekomendowanych testów regresji,

• nagrywania i odtwarzania testów (Fast-forward),

• puszczania testów automatycznych przypisanych do danego przypadku testowego.

Najwiekszym wyzwaniem podczas wykonywania testów jest zbieranie danych diagnostycznych potrzebnych do identyfikacji problemów. Opisywane narzędzie umożliwia zbieranie wielu danych diagnostycznych takich jak:

• zrzuty ekranu (screen shots),

• nagrania wideo (video recordings),

• informacje systemowe (system information),

• wpływ testu (test impact),

• dziennik akcji (action log),

• dziennik zdarzeń (event log),

• pokrycie kodu (code coverage),

• ASP.NET profiler,

• IntelliTrace,

• network emulation.

Druga część Microsoft Test Manager, Lab Center, jest używany do tworzenia oraz ustawiania środowisk potrzebnych do wykonywania testów.    Microsoft Test Manager to narzędzie stworzone specjalnie dla testerów w celu ułatwienia i zwiekszenia transparentności ich codziennej pracy. Uczestnik prezentacji zdobędzie wiedzę na temat możliwosci narzędzia, a także sposobu w jaki rozpocząć i kontynuować z nim pracę.

 

Testing mobile WWW – tools & best practices

Prezentacja: TomaszBrowarski_Testing mobile WWW_Testwarez2014

Wraz z nieustannie rosnącym wskaźnikiem sprzedaży smartphonów, a także umacnianiem się rynku tabletów, połączonym z dostępem do większej ilości sieci komórkowych, internet stał się dostępny dla użytkowników poprzez wiele nowych kanałów.

Rewolucja w telefonii komórkowej zainspirowała właścicieli stron internetowych, od portali społecznościowych, poprzez duże sklepy internetowe, do witryn niszowych, do utworzenia mobilnych wersji swoich serwisów.

 

Obecnie ponad 1,2 mld ludzi używa aplikacji mobilnych. Rosnący zakres dostępnych smartphonów i tabletów używanych do przeglądania internetu stawia właścicieli serwisów webowych przed wyzwaniem dostosowania ich do przeglądarek mobilnych.

 

Testowanie mobilnej strony internetowej manualnie byłoby zadaniem wręcz niewykonalnym ze względu na ilość smartphonów potrzebnych do testów, czas na wykonanie testów, a także koszty.

Jak więc przetestować mobilny serwis WWW? Jak zagwarantować działanie strony na wszystkich urządzeniach lub przeglądarkach? Jak uzyskać pewność prawidłowego działania strony bez względu na położenie geograficzne?

Z pomocą przychodzą narzędzia do automatyzacji i walidacji mobilnych witryn internetowych. Prelekcja „Testing mobile WWW” ma na celu zapoznanie słuchaczy z narzędziami do testowania stron WWW, wykorzystujących:

– testowanie w czasie rzeczywistych stron na wielu urządzeniach jednocześnie,

– symulatory smartphonów,

– walidację stron z wykorzystaniem najlepszych praktyk budowania serwisów WWW,

– testy wydajnościowe dla różnych parametrów sieci,

– testy automatyczne na wielu urządzeniach mobilnych.

W rzeczywistości przetestowanie serwisu na wszystkich dostępnych urządzeniach jest niemożliwe, jednak istnieją sposoby na zredukowanie ilości testów przy jednoczesnym zachowaniu wysokiego poziomu pewności co do jakości testowanej witryny internetowej. Tematyka najlepszych praktyk zostanie również przybliżona podczas prelekcji.

 

Źródła dumy zawodowej testera oprogramowania

Prezentacja: TomaszOsojca_zrodla dumy zawodowej testera oprogramowania_Testwarez2014

Autor, w ramach swojej praktyki zawodowej, bardzo często spotyka się z negatywnymi skutkami utożsamiania Testowania z Zapewnieniem Jakości. Traktowanie tych pojęć zamiennie prowadzi do ślepej uliczki, w której od testerów wymaga się realizacji zadań jednocześnie nie dając im wystarczających uprawnień do ich realizacji. Na testerów spycha się całą odpowiedzialność za jakość produktu i obarcza nadmiernymi zadaniami (np. to testerzy mają pilnować programistów aby naprawili defekty). Takie umiejscowienie testera w procesie produkcji oprogramowania bardzo często jest nieuświadomionym efektem prób podniesienia pozycji zawodowej podejmowanych przez samych testerów. Autor wielokrotnie spotyka się z wypowiedziami typu: “Ja nie jestem zwykłym testerem, ja jestem QA”. Znamienne są również określenia nazw stanowisk: “Analityk ds. jakości”, “Starszy specjalista zapewnienia jakości systemów” itp., w sytuacji gdy osoba zatrudniona na tym stanowisku jest “tylko” (w opinii autora “aż”)  testerem oprogramowania…

 

W ramach prezentacji autor przedstawi różnicę pomiędzy Quality Assurance a Testowaniem. Autor podejmie próbę przekonania słuchaczy, że nawet potoczne, określanie testera mianem QA jest błędne merytorycznie i prowadzi do nieefektywnego wykorzystania specyficznych i nierzadko unikatowych umiejętności testerów w projektach informatycznych. Uwaga słuchaczy zostanie zwrócona na takie, z pozoru błahe, pomyłki jak oczekiwanie od testerów rekomendacji, mylenie kryteriów oceny systemu z kryteriami zakończenia testów.

Autor przedstawi dwie możliwe pozycje testera w zespole:

• “zbawcy świata, samotnego rycerza walczącego o jakość” prowadzącą do nieporozumień, frustracji, obniżania rangi zawodu i marnowania wysiłków testerów,
• “profesjonalnego testera” skupionego na jak najlepszym wykonaniu inżynierskiej pracy jaką jest testowanie oraz na dostarczeniu miarodajnej i wiarygodnej informacji o jakości stanowiącej podstawę do podejmowania decyzji w projekcie.

Na zakończenie zostaną przedstawione cechy i umiejętności “profesjonalnego testera”, które jak wynika z obserwacji autora, są często niedoceniane, również przez samych testerów. To prowadzi do pomijania bardzo ważnych aspektów testowania (np. analiza i projektowanie testów) na rzecz pogoni za większą “ważnością” w procesie w postaci wchodzenia w buty Quality Assurance.

Podsumowaniem całości wystąpienia jest stwierdzenie, iż profesjonalne testowanie jest tak wymagającym zajęciem iż “zwykli” testerzy powinni być dumni z tego, że są testerami a nie szukać podbudowania zawodowego w błędnym nazywaniu siebie QA.

 

Automaty do zadań specjalnych

 Prezentacja: OlgaMaciaszek_ArtutKotow_automaty do zadań specjalnych_Testwarez2014

1. Temat i cel prezentacji

Nawiązując do tematyki konferencji Testwarez 2014, chcielibyśmy zaprezentować wystąpienie, które będzie przedstawiało „customowe” podejście do automatyzacji testów. Nasza prezentacja skupiać się będzie na pokazaniu powodów, dla których warto czasami zwrócić się ku własnym rozwiązaniom zamiast używać rozwiązań „z pudełka”. Prezentacja jest skierowana głównie do ludzi aktywnie zajmując się tematyką automatyzacji, a szczególnie takich, którzy nie boją się zagłębiać w meandra kodu. Również osoby nieco mniej techniczne będą mogły zaczerpnąć wiedzy kiedy warto zainwestować w rozwiązania z pogranicza testowania i programowania. Stawiamy na praktykę dlatego nasza prezentacja będzie zawierała wiele przykładów okraszonych odrobiną teorii.

 2. Plan wykładu

1. Wstęp

2. Case study 1

3. Case study 2

4. Podsumowanie

5. Pytania

 

3 Wstęp

Kiedy myślimy o automatyzacji testów, jednym z pierwszych dylematów jest dobór narzędzia. W pierwszej kolejności zapytamy jak uczestnicy prezentacji wybierają rozwiązania. Czym się kierują oraz czy budowali automaty z poziomu kodu. Następnie opowiemy dlaczego zaczęliśmy rozpatrywać budowanie własnych narzędzi. Jak nasze rozwiązania wspierają podstawowe cele automatyzacji testów. Wstęp będzie dość krótki bo najciekawsza część prezentacji to oczywiście przykłady z projektów wzięte.

 

3.1 Case Study 1 – semi-customowe podejście do testów automatycznych GUI z wykorzystaniem frameworku Selenium WebDriver

W tej części prezentacji skoncentrujemy się na kwestiach związanych z testami automatycznymi bazujących na graficznym interfejsie użytkownika. Często do automatyzacji testów funkcjonalnych stosowane są gotowe narzędzia pozwalające na nagrywanie kroków realizowanych przez testera i określanie elementów i wartości, które powinny podlegać weryfikacji w ramach danego scenariusza. Na tej podstawie narzędzia generują kod w popularnych językach skryptowych bądź obiektowych, takich jak VBScript, JavaScript czy Java. Ma to z swoje zalety, wśród których jednymi z najistotniejszych są z pewnością: szybkość przygotowania skryptów testowych, możliwość powierzenia zadań związanych z automatyzacją zespołowi z jedynie niewielkimi kompetencjami programistycznymi oraz generowanie przez narzędzia graficznych i tabelarycznych raportów bez konieczności włożenia dodatkowej pracy w ich opracowanie. Takie podejście ma też jednak bardzo istotną wadę: w rezultacie otrzymujemy kod, który jest znacznie mniej czytelny i trudniejszy do utrzymania i ponownego użycia. Jest to szczególnie problematyczne w momencie gdy potrzebujemy automatów do regresji w ramach prac nad dynamicznie zmieniającym się systemem z częstymi wdrożeniami nowych funkcjonalności. Zdarza się też, że klient zamawia skrypty automatyczne jako oddzielny produkt – jak miało to miejsce w projekcie, o którym będziemy chcieli opowiedzieć bardziej szczegółowo w ramach naszej prezentacji – z naszego punktu widzenia ważne jest wtedy żeby kod automatów był tworzony z taką samą dbałością o jakość jak kod jakiejkolwiek innej aplikacji, którą dostarczamy naszym klientom. Trudno by nam było osiągnąć taki efekt korzystając z popularnych narzędzi do nagrywania skryptów. Udało nam się jednak zbudować modułowe, proste w rozwoju i utrzymaniu rozwiązanie poprzez samodzielne oprogramowanie testów w Javie z wykorzystaniem biblioteki Selenium WebDriver.

W trakcie prezentacji opowiemy szczegółowo o konstrukcji tego rozwiązania, wyzwaniach przed jakimi stanęliśmy budując je, i o tym, jak udało nam się je rozwiązać. Zademonstrujemy jak działa, pokażemy fragmenty kodu i zestawimy je z kodem, który otrzymalibyśmy gdybyśmy zamiast samodzielnej implementacji zdecydowali się na wykorzystanie gotowego narzędzia.

3.2 Case Study 2 – Automaty do zadań specjalnych

Innym projektem związanym z opracowaniem customowego rozwiązania do automatyzacji testów, o którym chcielibyśmy opowiedzieć jest projekt, w ramach którego chcieliśmy początkowo opracować skrypty do testów bazujące na graficznym interfejsie użytkownika, ale po wykonaniu prototypowych skryptów i bliższym poznaniu specyfiki systemu klienta oraz dostępnych środowisk testowychm zdecydowaliśmy się ostatecznie na zastosowanie całkowicie odmiennego podejścia, które pozwoliło nam opracowywać i wykonywać efektywne testy automatyczne znacznie szybciej i mniejszym nakładem pracy niż miałoby to miejsce gdybyśmy pozostali przy pierwotnych założeniach.

Nasz klient pracował z wykorzystaniem systemu PeopleSoft z dużym wachlarzem dostępnych usług i konfiguracji i jednocześnie był nam w stanie udostępnić tylko mało wydajne środowisko testowe. Jednocześnie, klient używał też własnego rozwiązania do zasilania bazy systemu CRM danymi przesyłanymi od jego bezpośrednich klientów w formie plików xml. Okazało się też, że w środowisku produkcyjnym tylko ok. 20% transakcji realizowanych jest poprzez GUI PeopleSofta, a ok. 80% z pomocą wspomnianego rozwiązania. W celu stworzenia automatów, które działałyby szybko nawet w mało wydajnym środowisku testowym jakie mieliśmy do dyspozycji, a jednocześnie takich, które bardziej odpowiadałyby specyficznemu wykorzystaniu systemu przez naszego klienta, opracowaliśmy własne rozwiązanie pozwalające na generowanie plików xml zgodnych wg. konkretnych formatów wykorzystywanych w procesie klienta, zasilanych danymi z testowej bazy PeopleSoft oraz danymi generowanymi automatycznie, przesyłanie ich do systemu za pośrednictwem protokołu FTP oraz analizowanie odpowiedzi. Aplikacja została napisana w Javie, z wykorzystaniem frameworków SimpleFramework (do generowania plików xml) i Apache Commons (do komunikacji po protokole FTP).

Tak samo jak w przypadku rozwiązania omawianego wcześniej będziemy chcieli zaprezentować fragmenty kodu i przybliżyć słuchaczom techniczną konstrukcję rozwiązania oraz omówić zalety i wady takiego podejścia.

4. Podsumowanie

W podsumowaniu zbierzemy najważniejsze wnioski z obu case study, wady i zalety poszczególnych rozwiązań oraz kluczowe doświadczenia, które pomogą uczestnikom na własną ocenę przydatności tego typu skryptów w ich projektach. Będzie to również czas na odpowiedź na wszystkie pytania które pojawią się w trakcie prezentacji. Wierzymy, że naszą prezentacją będziemy mogli zainspirować wiele osób do realizacji własnych narzędzi testowych.

 

Testowanie Mutacyjne

Prezentacja: MichalChudy_Mutation Testing_Testwarez2014

Czym jest testowanie mutacyjne? Na czym polega ta idea? W jaki sposób wpływa na zwiększenie jakości oprogramowania? Czemu testowanie mutacyjne jest tak mało znane, skoro wymyślono je już w 1971 roku? Jak łatwo wdrożyć u siebie testy mutacyjne? Na te pytania odpowiemy sobie podczas prezentacji.

Porozmawiamy też o metrykach, które pozwalają nam śledzić jakość oprogramowania. Czy wszystkie są dobre? Weźmiemy po lupę metrykę pokrycia kodu testami. Przekonamy się, jak słabą, a następnie jak bardzo słabą metryką jest Code Coverage. Co się stanie, jeśli postawimy sobie taki super cel – zbliżyć się do stuprocentowego pokrycia kodu? Z doświadczenia wiadomo, że bardzo wiele może pójść nie tak. Szczególnie wtedy, kiedy programiści są nagradzani za utrzymywanie metryki na wysokim poziomie.

Prezentacja będzie przeplatana przykładami z życia. Przejdziemy przez narzędzia służące do testów mutacyjnych i obejrzymy ciekawe wyniki ich odpalenia. Na warsztat zostaną wzięte projekty open source dobrze znane i na co dzień używane w testerskim światku. Powiemy sobie, jak wprowadzić testy mutacyjne w naszych firmach z perspektywy zarówno testera, jak i developera. Jak przekonać menadżera, że to dobry pomysł, aby zacząć testowanie mutacyjne? I czy zabijanie mutantów jest… dobre?

a wpływ przeglądu kodu na jego jakość.

 

Testowanie aplikacji mobilnych z ukierunkowaniem na system Android

Prezentacja: LukaszZlocki_Testowanie aplikacji mobilnych_Testwarez2014

Instrukcja: Srodowisko Android

Demo1

Warsztat przedstawia kilka popularnych i ogólnodostępnych narzędzi wykorzystywanych podczas automatyzacji testowania aplikacji na urządzeniach mobilnych, za pomocą których można tworzyć wydajne i efektywne testy funkcjonalne. Omówione zostanie środowisko Android wraz z emulatorami, Robotium Recorder wraz z frameworkiem Robotium, TestDroid Recorder, MonkeyTalk oraz Appium. Automatyzacją w tych narzędziach jest głównie tworzenie samego skryptu testowego oraz jego wykonywanie na wybranych urządzeniach. Każde omawiane narzędzie będzie pokrótce przedstawione i po zapoznaniu się z jego funkcjami uczestnicy odbędą ćwiczenia praktyczne utrwalające ich doświadczenie z pracy z nim.

 

Zautomatyzuj swoje testy automatyczne Selenium

Prezentacja: MichalSierzputowski_zautomatyzuj testy automatyczne_Testwarez2014

Testy automatyczne przytaczane są jako remedium na długi i kosztowny proces testowy. Jednak nieumiejętne podejście do tego tematu może spowodować to, że staną się one jednym z większych problemów w projekcie. Żeby zaoszczędzić sobie tej kosztownej lekcji należy wdrażać odpowiednie praktyki, które często są też wykonywane w ramach rozwoju „właściwej” aplikacji.

W prezentacji autor postara podzielić się swoim doświadczeniami z automatyzacji testów z kilku projektów aplikacji webowych, w których miał okazję pracować. Przykłady będą oparte o narzędzie Selenium. Przede wszystkim jednak będą one przedstawiać dobre praktyki, uniwersalne dla testów automatycznych.

Większość z nich będzie koncentrowała się wokół odpowiedniego budowania frameworka testowego, organizacji testów jak również zwiększenia jakości samego kodu testowego.

 

 

Explore the Unknown

Prezentacja: RemigiuszDudek_ExploratoryTests_Testwarez2014

We’ve got used to thinking about Agile testing as mainly automated testing. This aspect is really important as it enables a short feedback loop and through this feedback loop it enables safe refactoring which is one of the core aspects of Agile development. Nevertheless we tend to forget about manual testing at all. This presentation will cover one of the pillars of Agile testing that is not possible to automate. I’d like to talk about exploratory tests. I will show how we can use exploratory tests to test non-functional areas of our product – like design or domain model.
Exploratory testing is difficult. It requires a great deal of knowledge and what is even more difficult a great deal of a gut feeling that develops in the guts of an experienced tester. During my talk I will present techniques that can be used to make exploratory testing efficient and not get lost in the meanders of the product. I will show concrete heuristics that can be used to find so called hidden variables that are crucial to identify in order to go beyond the obvious. I will tell how to recognize so called trusted zones of the software and how we can leverage the area outside of a trusted zone to put a pressure on the software we’re testing.
Furthermore I will explain how exploratory testing can be used to enhance the design of the software, how we as testers can play a crucial role in defining a business domain model that is used in our software, what we need to pay attention to in order not to loose these aspects out of sight.
I will also cover an aspect of a Confirmation bias – a psychological phenomenon that used to be our best adviser in the stone-age times but right now prevents us from being a good exploratory tester or even a good tester at all. In order to fight with it we need to recognized its existence.
Finally I will give few hints on how to organize the testing process in the Agile environment as a whole, so we actually have time to explore, so we do not waste the time on finding the obvious.

 

Optymalizacja Automatycznych Testów Regresywnych w Organizacji Transformującej do Agile

Prezentacja: AdamMarciszewski_Optymalizaca Testow Regresywnych_Testwarez2014

Z pewnością każdy z nas wykonując swoją pracę, zetknął się z problemem nadmiernie rozrastających się testów regresywnych. Początkowo zgrabny zestaw testów regresywnych, w miarę rozwoju testowanego systemu, zaczyna niepokojąco przybierać na wadze. W pewnym momencie nasze testy, jeszcze nie tak dawno skuteczne i efektywne, stają się uciążliwym balastem, który skutecznie spowalnia projekt. W takiej sytuacji z pomocą przychodzą różne metody testowania i optymalizacji testów. Często pojawia się pokusa by odchudzić zestaw testów regresywnych, pozbywając się niektórych przypadków testowych. Kolejnym wyjściem może być wydłużenie czasu pomiędzy kolejnymi cyklami testów regresywnych. Ale jak sobie poradzić, kiedy nie znamy wymagań, nie znamy stopnia pokrycia systemu testami oraz skuteczności testów? Dodatkowo, pikanterii całej sytuacji dodaje fakt, że klient właśnie podjął decyzję by przejść do metodyk zwinnych.
Na przykładzie projektu realizowanego na rzecz dużej międzynarodowej organizacji transformującej do Scrum, chciałbym przedstawić metodę optymalizacji testów regresywnych, która pozwoliła wyjść obronną ręką z tej, wydawałoby się, beznadziejnej sytuacji. Dla zaostrzenia apetytu warto zaznaczyć, iż zastosowana metoda optymalizacji powstała na podstawie konsultacji i publikacji takich znakomitości jak: Tom Gilb, Lee Copeland oraz Julie Gardiner.

Warunki początkowe, w jakich przyszło rozpocząć pracę:
• Projekt przejęty od innego wykonawcy.
• Zleceniodawca transformujący do Scrum.
• Brak zdefiniowanych wymagań.
• Brak wiedzy na temat stopnia pokrycia systemu testami.
• Czas wykonania automatycznej regresji przekraczał 30 godzin. Co za tym idzie, brak możliwości wykonania codziennej regresji.
• Duża ilość przypadków testowych (ponad 1000).
• Duże ryzyko przedostania się usterek do środowiska klienta.
• Brak wiedzy na temat efektywności i skuteczności obecnych testów regresywnych.
Przystępując do pracy przyjęto założenia:
• Czas wykonania regresji musi zostać skrócony do maksimum 12 godzin. Tylko wówczas wykonanie codziennej regresji będzie możliwe.
• Skrócenie czasu regresji nie może obniżyć skuteczności wykrywania błędów.
• Skrócenie czasu regresji nie może zredukować pokrycia systemu testami.
• Obszary obarczone większym ryzykiem będą testowane intensywniej.
• Obszary kluczowe dla klienta będą testowane intensywniej.
• Zmienna granulacja przypadków testowych, zależna od stopnia ryzyka.

Metoda optymalizacji:
Opisywana metoda optymalizacji, została podzielona na dwie fazy.
W fazie pierwszej zajęto się optymalizacją procesu testowego poprzez identyfikację wymagań, ocenę pokrycia funkcjonalności testami, ocenę skuteczności testów, identyfikację obszarów obarczonych najwyższym ryzykiem, identyfikację obszarów kluczowych dla klienta oraz zmienną granulację przypadków testowych.
W fazie drugiej, optymalizacja była kontynuowana od strony technicznej. Przeprowadzono między innymi optymalizację skryptów oraz narzędzi testowych.

Po wielu miesiącach pracy, efekt końcowy był zaskakujący! Szczegóły będziecie mogli Państwo poznać w trakcie konferencji.

Behaviour Driven Development is not about tools is about communication

Prezentacja: BartSzulc_BDD_Testwarez2014

What BDD is really all about? Is it about new tools, frameworks, enforced acceptance scenario pattern? I don’t think so. It’s all about interaction and the flow of your development in agile environment. Tools help, but without proper coaching of the development team and business team BDD will be yet another xDD that failed in organization.
While adopting BDD you need to recognize and focus on the most important aspects, than move gradually down, to the frameworks, tools, best practices and processes that you can adopt to ease development and business team.
I will try to share with my vision of adopting BDD in teams new to the idea. What should you start from? What should you avoid? How to move down the stream? What tools to use and wo should use them? What are the benefits of implementing BDD for development, testing, and business? These will be the answers I will try to answer.

 

Automatyzacja testów aplikacji okienkowych z użyciem UIAutomation

Prezentacja: MilenaSobolewska_PawelMaciejewski_Automatyzacja testów aplikacji okienkowych z użyciem UIAutomation_Testwarez2014

Celem prezentacji jest przybliżenie biblioteki programistycznej UIAutomation, służącej m.in. do automatyzacji testów interfejsów aplikacji okienkowych wykorzystujących WPF oraz omówienie rozwiązań niezbędnych do zdalnego uruchamiania testów.
UIAutomation to standardowa biblioteka .NET Framework, dostępna od wersji 3.0, która ze względu na specyficzne przeznaczenie, jest mało znana.
UIAutomation nie jest narzędziem nagrywającym testy, a biblioteką umożliwiającą interakcje z aplikacjami okienkowymi. Projekt oparty o UIAutomation zbliżony jest strukturą do projektu opartego o Selenium WebDriver: NUnit oraz referencja UIAutomation.
UIAutomation jest proste w opanowaniu, jednocześnie, dzięki dużej elastyczności łączenia parametrów, umożliwia szerokie zastosowanie.
WPF oraz UIAutomation opiera się o strukturę drzewa rodzic – dziecko. Znalezienie dowolnego elementu polega na wyszukaniu elementu o wskazanych właściwościach w drzewie dzieci innego elementu. Nadrzędnym rodzicem dla każdej aplikacji graficznej w Windows jest pulpit identyfikowany w UIAutomation poprzez RootElement.
Poznanie właściwości identyfikujących, takich jak AutomationId czy Name, umożliwia niewielkie, darmowe dla komercyjnego użycia, narzędzia o nazwie UIVerify. UIVerify umożliwia poznanie także tzw. wzorców, które informują jakie akcje, np. kliknięcie, dla danego elementu są dostępne.
Liczba obsługiwanych przez UIAutomation właściwości oraz wzorców umożliwia dużą elastyczność w interakcji z aplikacjami. Możliwe są skomplikowane identyfikacje używające wielu właściwości i warunków. Wiele płatnych narzędzi charakteryzuje się ograniczeniami w zakresie obsługiwanych właściwości i wzorców, natomiast UIAutomation obsługuje wszystkie te właściwości i wzorce, które programista może dodać.
W przeciwieństwie do aplikacji internetowych, gdzie testy automatyczne wykorzystują te same struktury na których operują programiści, aplikacje okienkowe posiadają odrębne właściwości umożliwiające automatyzację testów interfejsów. Wśród programistów wiedza na ten temat jest mała i na testerach często spoczywa odpowiedzialność przedstawienia potrzebnych rozwiązań. Oprócz dodania wzorców i właściwości konieczna jest również implementacja struktury AutomationProvidera, odpowiadającego za widoczność niestandardowych kontrolek w drzewie aplikacji. W przypadku braku wyróżnialnych właściwości identyfikacyjnych, istnieje możliwość bezpośredniego poruszania się po drzewie za pomocą klasy TreeWalker. Poprzez programistyczne poruszanie kursorem i kliknięcia możliwe są interakcje z elementami bez zaimplementowanych wzorców. Są to jednak rozwiązanie, które powinny być stosowane jedynie w ostateczności, gdyż testy pisane w taki sposób trudno utrzymać i dostosowywać do zmian w aplikacji.
Dodatkowym wyzwaniem jest zdalne wykonywanie testów, ponieważ dla aplikacji okienkowych nie ma możliwości pozbycia się sesji graficznej i symulowania działania pulpitu. Sesja musi być więc dostępna przez cały czas wykonywania testów. Można to wymusić nawiązaniem połączenia RDC do maszyny testowej. Jednak w wielu przypadkach, np. z powodu polityk bezpieczeństwa w organizacji, utrzymanie tego połączenia przez cały czas trwania testów może być niemożliwe. Rozwiązaniem wymagającym więcej pracy jest uruchamianie testów poprzez serwis systemowy. Uzyskuje się dostęp do tzw. sesji zerowej, nawet w przypadku, gdy do maszyny nie jest zalogowany użytkownik. Jest to więc rozwiązanie możliwe do zastosowania bezpośrednio na serwerze budującym aplikację testowaną. Z tym podejściem wiążą się jednak dwa poważne utrudnienia. Nie jest możliwe włączenie lokalnego użytkownika systemowego w domenę – jeżeli więc w aplikacji testowej system autoryzacji korzysta w jakiś sposób z ustawień domenowych nie jest możliwe skorzystanie z tego rozwiązania. Dodatkowo, w niektórych wersjach WIndows sesja zero ma wyłączoną obsługę kursora, więc testy muszą wykorzystywać wyłącznie wzorce. Jedną z możliwości obejścia wspomnianych ograniczeń jest uruchamianie połączenia RDC poprzez serwis systemowy i uruchamianie testów na podłączonej zdalnie maszynie, na której aktywność sesji podtrzymywana jest poprzez programistyczne poruszanie kursorem.
Podsumowując, przedstawiona biblioteka jest doskonałym narzędziem do przygotowywania testów automatycznych aplikacji dla systemu Windows i z powodzeniem może konkurować ze znanymi w testerskim świecie programami takimi jak Test Complete czy QTP.

 

Testy akceptacyjne w administracji publicznej – pro publico bono?

Prezentacja: MichalKruszewski_Testy akceptacyjne w administracji publicznej – pro publico bono_Testwarez2014

Dlaczego testy akceptacyjne „wystawiane są na zewnątrz”? Jakie są największe wyzwania podczas ich realizacji? Czy wynika to ze świadomych braków kompetencji zamawiającego, który oczekuje pomocy? Czy może jest to potrzeba przeniesienia odpowiedzialności na podmiot zewnętrzny (wykonawcę testów), za jakość systemu?

W ciągu ostatniego 1,5 roku znacząco wzrosło zainteresowanie podmiotów publicznych wsparciem podczas realizacji testów oprogramowania, w szczególności testów akceptacyjnych. Przyczyn tego zjawiska jest kilka, jedną z głównych jest zakończenie ostatniego okresu programowania 2007 – 2013 i konieczność zagwarantowania, odpowiednio wysokiej, jakości oprogramowania przy odbiorze szerokiej gamy systemów ITC, o wartości od kilkuset tysięcy do kilkudziesięciu milionów złotych.

Jednym z największych problemów, z jakim zderzamy się podczas testów akceptacyjnych w instytucjach publicznych są kryteria odbioru systemu. Oczywiste stwierdzenie, że nie możemy mówić o całkowitym braku błędów (defektów), staje często w sprzeczności z zapisami SIWZ, w której jednym ze stosowanych standardów jest zapis „odbiór systemu bez zastrzeżeń”. Jak więc będąc między młotem a kowadłem, zamawiającym a wykonawcą, doprowadzić do szczęśliwego końca? Jak wybrnąć ze słowno-znaczeniowych pułapek prawnych? Doświadczenie pokazuje, że można.

Drugą największą bolączką testowanych systemów są z reguły wymagania niefunkcjonalne. Należałoby raczej mówić właściwie o ich braku lub całkowitej nietestowalności. Od zapisów mówiących o zgodności systemu z prawem, polegających na wylistowaniu kilkudziesięciu aktów prawnych, do wymagań wydajnościowych typu „system umożliwi wprowadzenie 1000 dokumentów rocznie”.

„Nawet ludzie, którzy się nie lubią, pomagają sobie w kłopotach, gdy płyną na tej samej łodzi”

Nie można prowadzić projektów (nie tylko testowych) w administracji publicznej bez zrozumienia kluczowych aktów prawnych. Bez ich znajomości skazujemy się na wirtualne ściany, których nie rozumiemy i nie potrafimy przejść, dlaczego?

Dyscyplina finansów publicznych nakłada odpowiedzialność na urzędników za ich działania. W naszym przypadku, odpowiedzialność ta związana jest z odbiorem systemu. Fakt odbioru systemu jest potwierdzeniem, że finanse publiczne zostały spożytkowane prawidłowo, że nie ma zastrzeżeń. I tu pojawia się nasza rola – i jest to jeden z kluczowych elementów. Jesteśmy ekspertami, profesjonalistami, którzy majestatem wiedzy i doświadczenia pozwolą na spokojny sen zamawiającego.

“You must unlearn, what you have learned”

Każdy SIWZ posiada własną klasyfikację błędów, są one różne od zero-jedynkowych do, dwu do pięciostopniowych. Praktyka wymusza na nas zbudowanie ich nowych definicji, które będą zgodne z wymogami formalnymi podpisanych umów, pozwolą na sprawną naprawę defektów i doprowadzą do ostatecznego odbioru systemu. Jak do tego dojść? Musimy wziąć pod uwagę:

• Wymogi formalne umowy,
• Faktyczne kryteria odbioru systemu,
• Definicję „zmiany” w SIWZ,
• Zakres wsparcia świadczonego przez Wykonawcę na etapie eksploatacji systemu.

Nie można przetestować tego, czego nie ma, trudno też testować nietestowalne. Droga do celu jest „prosta”, należy na nowo zdefiniować wymagania. Trudność polega na wzięciu pod uwagę uwarunkowań prawnych realizowanego projektu i kryteriów z SIWZ. Sukces przedefiniowania wymagań związany jest z:

• Ukierunkowaniem wymagań w kierunku odbioru systemu,
• Uwzględnieniem formalnych zapisów umowy,
• Nieznacznymi zmianami w zakresie sposobu realizacji testów.

ATF – Nietypowe podejście do automatyzacji w systemie rozproszonym

Prezentacja: DanielDec_ATF_Testwarez2014

Celem wystąpienia jest przedstawienie rozwiązania narzędzia do testów w rzeczywistym systemie o architekturze zbliżonej do koncepcji microservices.

Narzędzi do testowania jest wiele. W przypadku dużego systemu ciężko tak naprawdę wybrać jedno idealne. Warto spróbować napisać swoje. Nasz zespół musiał się zmierzyć z wymaganiami klienta co do założeń narzędzia. Standardowym podejściem w automatyzacji jest wykonywanie testów funkcjonalnych opartych o zasadę porównania aktualnego wyniku z oczekiwanym. Zazwyczaj porównanie to dotyczy wykonania konkretnej metody lub logiki biznesowej. W takim podejściu każdy test jest skupiony na konkretny cel. Przykładowo testując funkcjonalność dodawania kalkulatora interesuje mnie tylko wynik dodawania. Gdybym chciał sprawdzić czy ta operacja poprawnie zapisała się do logu, to byłby to już nowy test. Szczególnie zasada pojedynczej asercji dotyczy testów jednostkowych. W podejściu testów e2e przechodzimy przez wiele warstw, więc można powiedzieć, że testujemy “więcej” niż jedną rzecz na raz. Jednak z piramidy testów automatycznych testów e2e powinno być jak najmniej, ponieważ są trudno utrzymywalne i w przypadku błędu identyfikacja może być problematyczna, ponieważ asercja dotyczy końcowej warstwy.
Koncepcja omawianego narzędzia opiera się na porównywaniu danych referencyjnych z oczekiwanym stanem systemu. Stan systemu uwzględnia:

• zmiany w bazie we wszystkich modułach
• zmiany na operowanym modelu danych
• zmiany w logach systemu (alarmy, notyfikacje)

W procesie dany stan systemu musi być raz ręcznie zaakceptowany przez testera, co jednocześnie awansuje go na referencyjny stan danych. Podczas wykonywania testów następuje porównanie, w wyniku którego dostajemy faktyczne zmiany w systemie od ostatniej wersji. Jeżeli zmiany te skorelowane są z faktycznymi zmianami w oprogramowaniu, wtedy mogą być zaakceptowane – następuje aktualizacja danych referencyjnych. Innymi słowy to zespół testujący decyduje czy zmiana jest wynikiem błędnego działania czy zamierzoną zmianą wymagań (związana z rozwijaniem systemu).W praktyce takie podejście ma swoje plusy i minusy. Dużym plusem jest przeźroczystość systemu, dokładnie wiemy, co się zmienia podczas danego scenariusza. Możemy zobaczyć zmianę stanu lub typ wykonanej operacji (np. sekwencje operacji CRUD). Minusem jest prędkość wykonywania testów, ponieważ wymagają one uruchamiania synchronicznego, aby zapewnić izolację od czynników zewnętrznych. Sporym wyzwaniem jest też utrzymanie danych referencyjnych w często zmieniającym się systemie. Taki problem można rozwiązać narzędziem, które będzie odpowiednio automatycznie aktualizować zadane zmiany.
Innym omawianym aspektem będzie architektura narzędzia do testów, która zostanie zestawiona z architekturą testowanego systemu.
Zostanie też przedstawiony proces tworzenia testów:

• zasada biznesowa
• współpraca z Product Ownerem
• definicja scenariuszy w Gherkinie
• implementacja kroków
• reużywalność kroków

W procesie tworzenia test casów wykorzystywany jest Sublime z pluginem do podpowiadania kroków, kolorowaniem składni Gherkina oraz plugin exportujący scenariusz do TestLinka.

Istotne kroki testu:

• generowanie transakcji na podstawie szablonu
• walidacja transakcji zgodności ze specyfikacją
• uruchomienie nasłuchiwania zmian
• wykonanie kroków testu
• zbieranie wyników
• generowanie raportu

W procesie wspomnę też o automatycznym provisoiningu środowiska testowego i użytych narzędziach.

Na koniec opowiem jak narzędzie zaczęło być używane przez programistów do testów modułowych, a kolejno zostało rozszerzone o testy z poziomu interfejsu użytkownika. Zwrócę też uwagę na wpływ przeglądu kodu na jego jakość. Architektura tego narzędzia moim zdaniem mogłaby by być wdrożona w wielu projektach. Dałoby się być może wydzielić niektóre komponenty narzędzia do celów publicznych.
Jeżeli starczy czasu to przeprowadzę demo na żywo, pokazując jak działa narzędzie.

 

Testy penetracyjne webaplikacji — co i czym sprawdzać?

Prezentacja: PiotrKonieczny_testy penetracyjne webaplikacji_Testwarez2014

Celem prelekcji jest zobrazowanie jak należy testować aplikacje webowe (ale także mobilne) pod kątem bezpieczeństwa. Prelekcja ma charakter praktyczny — zademonstrowane zostaną wybrane podatności (tzw. dziury) oraz wykorzystujące je ataki, jak i przede wszystkim sposoby wykrywania nieprawidłowości w aplikacjach, zarówno przy użyciu testów dynamicznych i statycznych przeprowadzanych ręcznie przez testera, jak i testów automatycznych (z wykorzystaniem odpowiednich skanerów i innych pomocnych narzędzi).

Prelegent będzie starał się pokazać (przede wszystkim testerom funkcjonalnym) jak łatwo mogą poszerzyć swoje kompetencje i przy stosunkowo niskim nakładzie dodatkowej pracy będą mogli testować również pewne aspekty bezpieczeństwa aplikacji webowych i mobilnych.

 

Testowanie systemów wbudowanych i krytycznych dla bezpieczeństwa

Prezentacja: BogdanBereza_Testowanie systemów wbudowanych_Testwarez2014

Testerzy oprogramowania ogólnego: aplikacji mobilnych, internetowych, ERP i CRM, zwykle niewiele wiedzą o testowaniu aplikacji i systemów wbudowanych, a szkoda, bo mogliby się stamtąd wiele nauczyć. Ponieważ świat wbudowany / bezpieczny rzadko pojawia się na ogólnych konferencjach testerskich, a testerzy ze świata ogólnego nie jeżdżą raczej na konferencje wbudowane, chcę uczestnikom Testwarez opowiedzieć, czego od wbudowanych mogą się nauczyć. Mając na to 40 minut, zasygnalizuję tylko najważniejsze obszary, do każdego podając jeden, konkretny przykład (dla różnych rodzajów systemów wbudowanych). Liczby przy punktach, to numery slajdów prezentacji.

1. Czym różni się testowanie systemów wbudowanych od testowania aplikacji nie-wbudowanych, i co warto naśladować?

• 2. Testowanie na wielu platformach symulowanych
• 3. Projektowania wbudowanej aplikacji także pod kątem możliwości testowania, również na środowisku docelowym
• 4. Równoległe, nie sekwencyjne, projektowanie, tworzenie i testowanie środowiska sprzętowego, i aplikacji
• 5. Stosowanie języków niskopoziomowych, które wymagają od programistów dużej staranności i unikania błędów
• 6. Ze względu na ograniczoną dostępność testów w środowisku docelowym:

o   7. Staranie, by jak najwięcej przetestować w środowiskach symulowanych

o   8. Pełny nadzór, co jest testowane, w jakim środowisku

o   9. Bardzo dokładne planowanie testów w środowisku docelowym

• 10. Używanie narzędzi, programistycznych i sprzętowych, umożliwiających bardzo dokładny oraz niskopoziomowy nadzór nad przebiegiem testów, ich wynikami
• 11. Bliskie związki testowania z debugowaniem, na dobre (współpraca) i złe (możliwa rywalizacja o dostęp do środowiska)
• 12. Nowość – testowanie zdalne przez zaślepki internetowe.

13. Jakie specjalne testy stosuje się wobec (wbudowanych) systemów czasu rzeczywistego?

• 14. Testy szybkości oraz czasowej przewidywalności nie tylko aplikacji, lecz również platformy sprzętowej i systemu operacyjnego
• 15. Długotrwałe testy stabilności
• 16. Testowanie poprawności implementacji wymagań czasowych
• 17. Testowanie niezawodności (MTBF)
• 18. Projektowanie testów na podstawie specjalnych modeli działania czasu rzeczywistego

19. Jak się robi testowanie systemów krytycznych dla bezpieczeństwa?

• 20. Istnienie norm – przykłady. Korzyści z norm
• 21. Nacisk norm na zapobieganie, nie tylko na testowanie
• 22. Sposoby oceny krytyczności komponentów (SIL) i wynikające z nich wymogi wobec testów
• 23. Całościowa analiza bezpieczeństwa – nie tylko miary niezawodności komponentów IT
• 24. Wymogi testów statycznych
• 25. Wymogi miar pokrycia testowego
• 26. Inne wymogi wobec testowania
• 27. Wymogi wobec narzędzi stosowanych do testowania

 

Wirtualizacja serwisów na przykładzie HP Service Virtualization

Instrukcja: Instalacja HP Service Virtualization 3.6

Opis warsztatu

W inżynierii oprogramowania, wirtualizacja serwisów jest metodą emulacji poszczególnych komponentów budowanego systemu. Wirtualizacja serwisów dostarcza zespołom deweloperów oraz testerów dostęp do potrzebnych komponentów, które z jakiegoś powodu w danym momencie są niedostępne. HP Service Virtualization jest kompleksowym rozwiązaniem umożliwiającym wirtualizację serwisów opartych o różne protokoły i technologie. W ramach warsztatu uczestnicy dowiedzą się istotnych informacji z obszaru wirtualizacji serwisów oraz wykonają szereg ćwiczeń pozwalających zapoznać się możliwościami tego narzędzia.

Agenda

• Ogólne informacje na temat wirtualizacji serwisów
• Najpopularniejsze narzędzia do wirtualizacji serwisów
• Różnice pomiędzy wirtualnym serwisem a zaślepką
• Wprowadzenie do narzędzia HP Service Virtualization
• Omówienie przykładowej aplikacji
• Ćwiczenia

Wymagania

Własny komputer z zainstalowanym narzędziem HP Service Virtualization. Do pobrania ze strony http://www8.hp.com/pl/pl/software-solutions/service-virtualization/ po wcześniejszej rejestracji.

 

Testowanie wymagań

Prezentacja: KarolinaZmitrowicz_RadekSmilgin_Testowanie wymagań_Testwarez2014

Warsztaty mają na celu omówienie podstawowych aspektów jakości wymagań na oprogramowanie i ich powiązań z procesem testowania. Uczestnicy poznają w praktyce problemy związane z tworzeniem i interpretacją wymagań, poznają konsekwencje złej jakości wymagań na efektywność procesu testowania oraz nauczą się weryfikować wymagania pod kątem ich jakości, w szczególności testowalności. Warsztaty prowadzone są przez doświadczonych ekspertów reprezentujących dwa różne punkty widzenia na tematykę – analityka oraz testera, co pozwoli uczestnikom przeanalizować problem z różnych perspektyw.