Relacja z Testwarez 2018


Trendy, nieszablonowe rozwiązania i prelegenci, którzy porywają tłumy. Oto, czego oczekiwałem, uczestnicząc już po raz czwarty w konferencji Testwarez. Tematy podstawowe celowo pomijałem. Wydarzenie tym razem odbyło się pod hasłem „Rising the bar”, choć ktoś zażartował, że zamiast „bar” powinno być „pub”. 🙂 Ja opowiem Wam, czy merytorycznie udało się podnieść poprzeczkę na tyle wysoko, żeby mnie zszokować.

Agendę wydarzenia można podejrzeć na https://www.testwarez.pl/pl/testwarez-2018-pl/. Organizatorzy nagrywali każdą prelekcję i obiecali, że to, co najciekawsze, umieszczą na swoim kanale na YouTube. 

Cała konferencja odbyła się w Zakopanem. Część uczestników narzekała więc na dojazd cieszącą się złą sławą wśród kierowców Zakopianką, drogą w wiecznej przebudowie. Jednak samo miejsce spotkania rekompensowało wszystkie niedogodności: gościliśmy w Nosalowym Dworze. Hotel, a właściwie centrum konferencyjne, był w całości do dyspozycji uczestników konferencji, zapewniając bardzo wysoki poziom techniczny i organizacyjny. 

Dzień „zero” rozpoczynaliśmy warsztatami w małych 10-20 osobowych grupach. Ja wybrałem całodzienny warsztat „Selenium od POP do BDD”, prowadzony przez Patrycję i Jakuba. Czego się dowiedziałem? No właśnie – niewiele… Po opisie spodziewałem się bardziej zaawansowanych zajęć.

Problemem okazał się brak przygotowania uczestników do zajęć (niezainstalowane środowiska, kłopoty z dependency), co zabierało niezbędny czas prowadzącym. Mimo wszystko warsztat i tak pokazywał podstawowe podejście do BDD, słowa klucze, logikę oraz zastosowanie. 

Wartością dodaną były: 

  • namiary na materiały o wyciąganiu lokatorów z css (Kuba jest ich fanem, w przeciwieństwie do mnie jestem z drużyny xPath)
  • #languages – można pisać w kilkudziesięciu językach, w tym w polskim 🙂 
  • dodatkowo upewniłem się, że w naszych projektach wszystko jest „zgodne ze sztuką” 🙂 

Najgorsze jednak było na koniec. W finale zajęć padło stwierdzenie, że tak naprawdę… BDD jest bez sensu. Jak może się czuć osoba, która po ośmiu godzinach warsztatu dostaje takie info, a zapłaciła za udział niemało? Sami sobie odpowiedzcie. 


Dzień pierwszy otworzyły krótkie informacje organizacyjne, spośród których przytoczę dwie.  

  • Używanie #slacka do komunikacji – bardzo przyjemna aplikacja, jednak chyba nie zdobyła aż takiego zainteresowania w trakcie konferencji, z wyjątkiem wątków warsztatowych. 
  • Używanie sli.do do zadawania pytań do prelegentów w czasie wystąpień – tu najgorzej, ponieważ najpopularniejszym pytaniem dnia pierwszego było: „Ktoś chętny jutro na 6:30 na Nosal?”.  🙂  

Pierwsza prelekcja dla wszystkich zatytułowana „Super QA of the future” rozpoczęła merytoryczną część Testwareza. Tomek Kubikowski snuł plany dotyczące przyszłości testowania – w perspektywie najbliższych 5/10/20 lat. Motywem przewodnim był film „Powrót do przyszłości”. Nie mamy się czym martwić, bo prawdopodobieństwo automatyzacji naszej pracy wynosi 4 procent. 🙂 Konkluzja była taka, że wszystkie technologie, którymi się dziś ekscytujemy – takie jak AI, blockchain czy IoT – spowszednieją tak jak wcześniej „big data”, „grid computing” czy nawet chmura.

Tomek dopatruje się natomiast problemu w coraz to różniejszych danych testowych i wyjściach z logiki aplikacji. Przygotowanie ich będzie prawdziwym wyzwaniem w zależności od kontekstu. Supertester będzie wyluzowanym gościem pracującym zdalnie z kanapy we własnym salonie. Będzie mieć wąską specjalizację, uzupełniając się z pozostałymi członkami zespołu.

Na podstawie tego wystąpienia można sformułować kilka praktycznych zaleceń: 

  • Bądź kreatorem swojej kariery. 
  • Nie dopuszczaj do tego, by tłumić w sobie własne pomysły. Realizuj je, nawet jeśli oznacza to zmianę pracodawcy.
  • Nie licz, że po dwutygodniowym kursie staniesz się testerem, który zarabia „kupę forsy”. 
  • Odpowiedz sobie na pytanie, czy testowanie to praca czy to twoja pasja. Właśnie pasjonatów nam potrzeba!  
  • Bądź dumny z roli QA – nie jest to takie proste, jak w przypadku deweloperów.  
  • Nie słuchaj rekruterów. Oni mogą chcieć wcisnąć Tobie wszystko. 🙂 

Następnie szybko przeszedłem na prezentację Mieke Gevers, czyli pierwszej z zagranicznych postaci tej edycji Testwarez. Opowiadała o projekcie, w którym miała zrealizować audyt wydajnościowy.  

Oto problemy, jakie dostrzegła w trakcie audytu: 

  • Biznes i IT  
    • udziałowcem był dyrektor biura 
    • aż cztery departamenty IT, w tym jeden w innym kraju 
    • brak kontaktu z klientem 
    • projekt nie przebiegał zgodnie z harmonogramem 
  • Ludzie 
    • brak profitów i nagród 
    • brak rozwoju  
    • odmienne kultury 
    • brak szkoleń i poprawy umiejętności 
  • Technologia 
    • próbowano nadążyć nad trendami 
    • istniało wiele warstw kolejnych aplikacji 
  • Testowanie  
    • brak test planu, szacowania ryzyka, dokumentacji 
    • testy automatyczne, o których mało kto wiedział 
    • brak testów wydajnościowych 
  • Organizacja 
    • uzyskanie każdej dodatkowej rzeczy od Relase Managera trwało wieczność, przez co osoba z zewnątrz musiała marnować mnóstwo czasu

Po wstępnych konsultacjach i napisaniu raportu na dzień przed jego wysłaniem okazało się, że wszystkie wyniki pracy oraz konto Mieke Gevers zostały skasowane z powodu… No właśnie, z jakiego powodu? Może otworzyła przysłowiową „puszkę Pandory”? 

Co z tego wynika? Oto pięć słabych punktów. Błędy popełnione w związku z każdym z nich potrafią się zemścić: 

  • Polityka – czy realizacja planu nie jest związana jakimiś pozabiznesowymi relacjami w organizacji?
  • Szczegóły – czy nie zatracamy się w nich?
  • Nagrody – czy jeśli coś zrobisz, zostaniesz nagrodzony? 
  • Dzielenie się – potrafimy to robić czy raczej trzymamy wiedzę tylko dla siebie? 
  • Czas – jak go wykorzystujemy? jesteśmy na końcu czy na początku projektu?

Są na szczęście narzędzia, dzięki którym jesteśmy w stanie poprawić słabe punkty. Podaję je hasłowo: 

  • MBTI – test Myers-Briggs, osobowości 
  • Circle of influence 
  • Six thinking hats – różne perspektywy myślenia  
  • Fishbone diagrams – rozwiązanie problemu 
  • Soft system methodology 
  • Analiza danych 

Prelegentka pokazała również „Satir Model”, który obrazuje, że po każdej porażce następuje nowe status quo, w lepszej kondycji niż poprzednie. A zatem warto z projektami wpadać w tarapaty, bo jest od czego się odbić i osiągnąć jeszcze większy sukces. 😊


W dalszej części dnia przełączyłem się na ścieżkę mobilną, na której Wojciech Lizakowski z Allegro opowiadał, jak skutecznie testować aplikacje mobilne. Należy po prostu korzystać ze smartfona, ale pamiętając o własnych przyzwyczajeniach, ponieważ użytkownicy mogą ich używać w inny sposób.  

Aplikacje można podzielić z grubsza na cztery grupy: 

  • Aplikacje natywne 
  • Strony internetowe na mobilnych przeglądarkach 
  • Aplikacje hybrydowe – Angular  
  • Aplikacje w przeglądarce w zamkniętym środowisku przeglądarki 

Dodatkowo trzeba zadać sobie pytania:

  • Jak dobierać urządzenia przy rosnącej fragmentacji? 
  • Jakich użytkowników można się spodziewać, jeśli chodzi o ich preferencje co do wersji oprogramowania ?

Co do fragmentacji hardware i software:

  • Zwróć uwagę na wszystko w hardware: procesor, grafikę, RAM, moduły zewnętrzne, czujniki.
  • Wymogi prawne modyfikacje operatora, producenta.
  • Systemy operacyjne 
    • IOS bardzo szybko się aktualizuje, Android się trochę wlecze. 
  • Fragmentacja dla Androida jest ciężka, jeżeli chodzi o hardware oraz software.

Na co zwrócić jeszcze uwagę? 

  • Sieć – szukanie sieci, zmieniają się połączenia (zrywanie połączeń) – urządzenia symulujące sieci (Android Studio, Charles Server Proxy) 
  • Pakiety danych 
  • Wyposażenie smartfona 
  • Bateria 
  • Aktualizacja i wsparcie dla wersji 
    • Czy zachowane są konteksty użytkownika 
    • Nie kasujemy danych i historii 
    • Nie widać zmian w postaci zakłóceń pracy 
    • Brak miejsca na urządzeniu 
  • Użyteczność – human interfaces guidlenes/material design – tam można znaleźć przykłady 
    • Czytelność 
    • Płynność 
    • Nieprzysłonięte elementy 
    • Alerty o błędach
    • Reakcje na dotyk 
    • Brakujące dane – zlepki 
    • Notyfikacje wibracje 
  • Społeczność w testach kanałów dystrybucji i praca z własnymi użytkownikami 

Pozostałem w ścieżce mobilnej, gdzie Adam Stasiak opowiedział o tym, jak testować automatycznie UI w React Native Apps. Prezentacja prowadzona w formule livecoding naprawdę robiła wrażenie. Generalnie chodziło o odpalanie i widoczność tej samej aplikacji na różnych urządzeniach mobilnych. 

Technologia JavaScript code -> React Nativ – > JavaScipt code przekazany do natywnych wykonań. 

 Zaprzęgnięto Detox automation Guide, który:

  • Posiada konfiguracje wszystkich urządzeń w pliku json – aplikacja natywna (gradlew/xcodebuild) 
  • jest kompatybilny z IOT 
  • używamy pagobject + specflow i testujemy 
  • umożliwia manipulacje, np.: lokalizacjami, orientacjami i innymi 
  • umożliwia mock-owanie  np.: Bluetooth
  • zapewnia raporty – mocha – mochawesome 
  • umożliwia zapis screenshotów i video 
  • blink-diff porównanie screenshotów 
  • wspiera CI/CD 

Minusy: 

  • nie wspiera farmy urządzeń, tylko symuluje 
  • problemy między wersjami iOS oraz Android 
  • nowa inicjatywa, nowy projekt – na razie jest na początku drogi 

Kolejno poszedłem posłuchać Dawida Bałuta, który swoje doświadczenie zdobywał między innymi w Dolinie Krzemowej. Mówił o swojej ścieżce kariery i przekazywał praktyczne wskazówki. A zatem czego nie robić w życiu testera? 

  • Nie trać czasu na prace w „złych firmach”, bo marnujesz swoje życie.
  • Jeżeli jesteś zmęczony pracą, zadaj sobie pytanie, czy ta praca jest najlepszym miejscem dla Ciebie? 
  • Pracując tylko dla pieniędzy, nie zajmujemy się tym co jest ważne: ludźmi, rodziną, zdrowiem. Jakie są priorytety w Twoim życiu? 
  • Zarabiaj tyle, na ile się wyceniasz – znaczy z głową.
  • Pomyśl, czy nie za dużo czasu zajmuje ci zastanawianie się versus działanie.
  • Nie patrz na to, jak zachowują się ludzie, którzy są na topie. Wstawianie o trzeciej rano nie zrobi z ciebie CEO. Tamci ludzie mają inne priorytety i na pewno nie należy do nich wstawianie w środku nocy (chodziło tu o historie managerów z korporacji z sukcesami, którzy swoje historie wrzucają na blogi i Istagrama).
  • Nie zasiedź się w jednym miejscu. Stagnacja w pracy powoduje stres, brak balansu między życiem i pracą. Ludzie nie robią tego, co chcą i nie mają nadziei na zmianę, tkwiąc cały czas w jednym miejscu.
  • Z drugiej strony nie uciekaj zbyt szybko  do nowej firmy. Weź pracę zdalną, jeśli nie możesz dogadać się z kimś z biura, zamiast uciekać.
  • Nie bój się zmian. 
  • Praca zdalna powinna być dla wszystkich, ale nie wszystkim musi ona pasować. 
  • Focus on matters – skoncentruj się na rzeczach istotnych[
  • Chaos -> Waste of time -> stress -> anxiety 

 Zwiększ produktywność

  • Głęboka praca (deep) – nie rozpraszaj się.
  • Licz godziny.
  • Zapisz listę zadań.
  • Odpisywanie na maile nie działa dobrze. Raczej rozmawiaj/dzwoń.
  • Nie sprawdzaj Facebooka co pięć minut. 
  • Zrób wszystko, żeby kończyć zadania. 
  • Nie rób wielu rzeczy na raz, ale tylko kilka, lecz dobrze. 
  • Nie działaj efektownie, tylko efektywnie.  
  • Zobacz, co jest dla ciebie ważne i dla twojej organizacji i właśnie to zrób w mniejszej skali. Zrób to dobrze: optymalizuj, twórz rozwiązania (często ludzie robią rzeczy, ale nie do końca dobrze.
  • Przeorganizuj listę pilnych rzeczy.
  • Przestań winić innych – jeżeli inni zarabiają więcej, robią to, co chcą. A jeśli jest ci dobrze i lubisz to, co robisz, a dostajesz mało, zastanów się, co dla ciebie jest ważniejsze i przestań narzekać.

 Dodatkowo: 

  • Zainwestuj w komunikację, naucz się rozmawiać – więcej zyskasz. 
  • Wyjdź ze strefy komfortu – lepsze jest dla Ciebie siedzenie poza nią i walka.
  • Na koniec dnia uświadom sobie, czy możesz zrobić coś lepiej – nie patrz na innych ludzi, bo oni nie dają tobie szczęścia, tylko twoje działania.
  • Myśl przed działaniem. 
  • Pamiętaj, że twoje zadowolenie jest na pierwszym miejscu.
  • Bądź zadowolony z tego, co robisz.

Następnie wybrałem dzienne audyty bezpieczeństwa kodu, czyli prezentację Michała Kowalskiego z SII. Często nie mamy świadomości, że ktoś może nas zhakować.  Czy jest się czym przejmować? Nie musimy brać specjalnej firmy, audyt jesteśmy w stanie wykonać sami na własnym kodzie.

Prowadzący przedstawił, jak sprawdzać anatomię audytu w kolejnych krokach:  

  • zweryfikować wersję dependency (java dependencied scan) 
  • sprawdzić ważność licencji 
  • przeprowadzić analizę statyczną kodu (sonarqube) 
  • wykonać audyt infrastruktury
  • spróbować shakować poprzez App pentesting 
  • to samo wykonać dla procesów biznesowych 
  • podążać za dobrymi praktykami 
    • korzystać np. z NVD CVE database 

 A oto problemy, jakie stwarza audyt: 

  • Stan bezpieczeństwa daje punkt w czasie.
  • Nie może być dowodem stanu bezbronności (vulenrability-free state). 
  • Konsumuje czas i tym samym pieniądze. 
  • Jest uciążliwy, bo ludzie z zewnątrz mają dostęp i muszą mieć wsparcie ludzi z organizacji – wymaga czasu i zaangażowania [
  • Ciężko go zautomatyzować. 

Podczas prezentacji padło świetne zdanie: „jeżeli zamawiasz audyt bezpieczeństwa, to nie naprawiaj wszystkiego przed audytem, a jeżeli wiesz, co jest nie tak, to lepiej zrób to od razu, po co ci audyt?” 


Następną prelekcją było wystąpienie Adama Romana, jednego z naszych EuroStarowych polskich sław (Eurostar największa konferencja testerska w Europie). Poruszył on temat bardzo filozoficzny: skąd wzięły się schematy metodyki i pozostałe działania w testach. 

Odniósł się do manifestu ze strony programing motherfucker, o wyłącznym kodowaniu i nieprzejmowaniu się niczym. Ludzie nie potrafią myśleć systemowo: rozszerzyć trzeba kontekst i patrzeć z lotu ptaka. Rzeczy wynikające z modelu rozwiązania przychodzą łatwiej

Dzięki temu naturalnie zadajemy pytanie, ile mamy czasu na realizację projektu lub czy z klientem mamy ustalać wymagania. 

Kolejno zastanawialiśmy się czy programowanie w parach działa, generalnie tak ponieważ jest sporo prac naukowych mówiących o tym, ale takie podejście sporo kosztuje. Dodatkowo wszystko zależy od kombinacji cech deweloperów zadań i miar jakości – organizacja musi być dojrzała.

Prelegent przytoczył również kilka mitów związanych z testowaniem.

TDD to strata czasu, bo: 

  • programuje na ślepo,
  • wymaga debugowania,
  • utrzymanie go jest strasznie, 
  • testy się dezaktualizują. 

Bez TDD testuje się swoje własne założenia, najpierw piszemy kod i tworzymy pod niego testy. Deweloper tym bardziej będzie pewny, że napisał superkod. 😊 

Testowanie eksploracyjne wystarczy.

Prowadzący przytoczył tu odwieczny konflikt Testy Exploracyjne vs skrypty testowe, który jest bez sensu, ponieważ one się niejako przeplatają: 

  • testy dynamiczne są tak naprawdę eksploracyjne 
  • testy statyczne są nie doceniane 
  • testy eksploracyjne powinny być planowane, powinniśmy pisać skrypty  
  • skrypty powinny mieć wkład z zapoznania się z aplikacją + doświadczeniem, piszemy skrypty ale z wiedza o eksplorowanym obszarze 

Testów eksploracyjnych i skryptów testowych nie da się tego rozdzielić.

Autor przytoczył również przykład testowania opartego na modelu, który wykazuje błędy już na etapie modelu przed jakąkolwiek linią kodu. Dodatkowo zadawać więc trzeba pytania, myśleć abstrakcyjnie i myśleć logicznie (na marginesie: Sokrates został skazany na śmierć, bo zadawał zbyt wiele pytań).

Na początku za pomocą metody „5 why’s”, czyli dochodzenia do przyczyny źródłowej problemów, wskazał przyczynę wystąpienia awarii: nieumiejętne rekrutowanie przez HR. 😊 

Wielkim „zwycięzcą” był jeden z głównych organizatorów imprezy, który co chwilę przerywał, dorzucał komentarze. Nie było go bardzo słychać, bo robił to bez mikrofonu w środku prezentacji, ale jedna dodatkowo wytrącał z równowagi prowadzącego. Naprawdę tak trudno jest poczekać do końca pytaniami? Tym bardziej, że sami organizatorzy wskazali aplikację do zadawania pytań…


Kolejnym gościem z zagranicy była Greta Ruskiene. Mówiła nam o UX, który cały czas w wielu organizacjach jest niedoceniany. Ona sama przebyła długą drogę do ugruntowania pewnej pozycji dla tej gałęzi we własnej organizacji. 

 Jak zweryfikować, czy twój UX jest ok? 

  • sprawdź opinie oraz ranking na sklepach (app store, play store),
  • śledź liczbę użytkowników – czy przypadkiem nie odpływają.

 Jak UX wpływa na biznes?

  • Mniej ludzi wchodzi na stronę z kilkoma poziomami – nie mają czasu na to, jest to zbyt wyczerpujące kolejne kliknięcie. 😊 
  • Więcej czasu zużywasz, żeby nauczyć ludzi z niego korzystać – gdyby aplikacja była intuicyjna, nie trzeba by było dodatkowych godzin na szkolenia. 
  • Ludzie nie potrzebują „kombajnów” z dużą ilością funkcji, wystarczą im te podstawowe.

 A jeśli nie ma w organizacji specjalisty od UX? Sprawdzaj!

  • Google technology guidlines 
  • Microsoft design principles page 
  • Android decelopes guildlines 
  • Human interface guidlines 

 Jak zacząć z UX? 

  • Dodaj go do CR-ów.
  • Zacznij od marginesów, rozmiaru tekstów.
  • Użyteczność produktu – komunikaty błędów, reakcje na niespodziewane akcje. 
  • Analizuj dane użytkowników oraz ich feedback. 
  •  Narzędzia podstawowe to paint i wykonywanie zrzutów ekranu.[
  • Śledź zachowania użytkowników.
  • Sprawdź, jak nowy feature wpływa na stare. 

Rób laboratoria z własnym zespołem przy rozwiązywaniu problemu z UX. 

Dodatkowe działania: 

  • Stwórz hall of shame/fame. 
  • Pokaz złe praktyki innych firm.
  • Zbierz te rozwiązania UX z których jesteś dumny i powiedz o nich zespołowi.
  • Skończ na tym, aby wszystkie UX przykłady poprawiły wasze produkty.
  • Podążaj za trendami.
  • Dobrze się baw.  
  • Przekonaj się, że UX daje zysk we wszystkich produktach i zespole.  

Kolejna prelegentka z zagranicy tym razem z Danii. Mette Bruhn Pedersen mówiła o SAFe, czyli Agile dla dużych organizacji. Jest to metoda najbardziej skalowalna i poprawna dla tego typu organizacji. Bardzo fajna była interakcja podczas wystąpienia, ponieważ głosowaliśmy on-line, jakie u nas w firmie mamy podejście, a na prezentacji pojawiał się wykres z rozkładem preferencji. 

Zmieniła się skala dostarczania produktu, która pozwala bardzo szybko trafić do milionów ludzi. Całe podejście jest wielką maszyną, która wydłuża poszczególne składowe, np. scrum-owego podejścia.

  • zespoły Agile 50-125 osób 
  • plan iteracji 8-12 tygodni 
  • stand-up raz na tydzień 

Na koniec próbowaliśmy odnaleźć się w tej hierarchii SAFe i okazuje się, że możemy być „prawie” wszędzie. 


Dalej udałem się do Jarosława Hryszko, który opowiadał o narzędziu do wykrywania błędów przez AI. Mowa o KNIME & DePress. Najpierw AI uczy się twojego kodu, a następnie przy pisaniu kolejnych linii wskazuje Tobie zagrożenia. AI predict defects jest różnicą między błędem w aplikacji a wymaganiami. Następnie prowadzący przedstawiał, jak niewielki jest koszt wdrożenia tego rozwiązania oraz ile daje zysku. 


Końcówka dnia to już techniczne wystąpienie Macieja Laskowskiego o wydajności. Na wstępie powiedział o tym, jak bardzo testy wydajnościowe oraz monitoring są ważne w aplikacjach. 

Sugerowane wartości: 

  • Liczba żądań, jaka jest w stanie obsłużyć nasza aplikacja   > 300RPS 
  • Czas odpowiedzi < 3sek 
  • Reakcja na skok odwiedzin – stabilny przed i po, dostępny w trakcie; może być wolniej, ale stabilnie 

Co badać pod względem wydajności: 

  • Monitoring 
  • Procesor – zużycie procesowa (utylizacja) i obciążanie (LOAD) 
  • Pamięć 
  • Aktywność GC 
  • Zużycie sieci 
  • Zużycie I/O (wejścia / wyjścia) dysk 
  • Liczba wątków 
  • Czasy odpowiedzi (odchylenie standardowe, im większe, tym bardziej niestabilna aplikacja optymalnie <15% średniej) 

W tym calu pokazał na analizie dwóch aplikacji, które robią dokładnie to samo na tym samym środowisku. Różnicą było zarządzanie wątkami: jedna aplikacja przełączała się pomiędzy czasami bezczynności i obsługiwała kolejne,  a druga czekała na zakończenie wykonywania zadania. 

Prowadzący skupił się na procesorze i wątkach. Aplikacja numer dwa nie odpowiadała w odpowiednim czasie i nie radziła sobie przy skokach użytkowników na nią wchodzących, a procesor wyraźnie się nudził. 

Aplikacja numer jeden zachowywała się dużo lepiej, mimo dużej zajętości procesora. Widać, że radzi sobie z obsługa zadań i nie wynika to z przeciążenia, tylko optymalnej zajętości. 

Narzędzia użyte to Jmeter + influxdb + ultimate thread group + grafana oraz zabbix do monitoringu Oceniając tę prezentację, trzeba docenić bardzo dobrze przygotowany materiał i analizę.  


Na sam koniec został Jędrzej Osiński, który podjął temat zmiany swojego myślenia i podniesienia umiejętności jako QA poprzez zaawansowaną matematykę. Była więc logika, matematyka i wiele innych.

Niezwykle ciekawie wypadła próba udowadniania tez z zakresu testowania poprzez matematykę.  

Direct proof (axioms I= Thesis) oraz przez zaprzeczenia – dowód przez sprzeczność

Wymaganie funkcjonalność działa tak jak oczekiwano -> Dowód  

I pytanie: jakim jesteś testerem? Działasz poprzez wykonanie wszystkich możliwych testów i potwierdzenie, że to działa, czy wykonujesz możliwie wiele testów, aby wynaleźć jakieś niespójności i błędy? 

Ale nie każda teoria jest możliwa do udowodnienia wprost. 

  • Nie wszystko jest testowalne.
  • Wyczerpujące testowanie nie jest możliwe.
  • System samodzielnie nie może być użyty do przetestowania samego siebie – potrzeba do tego narzędzi.
  • Kod testowanej aplikacji nie może by testowany Oracle. Potrzeba niezależnego źródła wiedzy. 

Testowanie możliwe jest możliwe bez aplikacji: 

  • Wystarczy dokumentacja 
  • Testy UX 
  • Shift left 

Poprzez logikę możemy uznać, że jeśli każde wymaganie jest logicznym zdaniem, możemy założyć, iś jest prawdziwe lub fałszywe. 

Co za tym idzie:  

  • Wymagania, które nie są logicznymi zdaniami, są nietestowalne.
  • W tej grupie zawierają się takie, które mają frazy jak np. dobrze, w większości, szybko.

Zidentyfikuj wymagania logicznie niepoprawne np.:  

  • Zawsze prawda i wymaganie jest zbędne – system powinien dać 0 lub więcej rezultatów.
  • Zawsze prawda i wymaganie jest niepoprawne – jeżeli wartość jest równa 5, ikona zmienia się na czerwony lub inny kolor.
  • Zawsze fałsz i wymaganie jest sprzeczne – service on line powinien używać bezpiecznego połączenia i tylko protokołu http.

Pamiętaj, że klasy równoważności to nie tylko liczby (jak zawsze ISTQB daje przykład), ale także konfiguracje, ficzery, użytkownicy i wiele innych. 

Dodatkowo: 

  • Nie bój się zmieniać myślenia i procesów.
  • Zweryfikuj ryzyka.
  • Pamiętaj, że wiele dzieje się na zewnątrz i może mieć to wpływ na twój projekt.
  •  Efekt motyla – mała zmiana w jednym miejscu może spowodować duże zmiany/wpływ w innym
  • Im więcej wiesz, tym większa jest szansa na sukces.

Teoria Goodstaina – kropla drąży skałę.

  • Lepiej robić małe zadania. 
  • Pamiętaj o jakości (briefly but often).
  • Jeżeli coś ma zająć dwie minuty, zrób to od razu (two minute rule). 
  • Rób sesje eksploracyjne.
  • Stosuj Scrum.

Bardzo ciekawy wykład! Szkoda, że został na koniec, kiedy już uczestnikom nie starczało sił, by wchłonąć wszystkie wartościowe informacje. Testwarez to trzy intensywne dni. Dużo ścieżek tematycznych, miejsce, gdzie można oderwać się od codzienności pracy i skupić się na tematach, które po powrocie do biura pomogą poprawić naszą pracę. 


Najważniejszymi wątkami były: bezpieczeństwo, wydajność oraz nasza kariera testerska. Żadnej z prelekcji nie mogę określić jaki „mind-blowing”, udało się jednak podchwycić kilka ciekawych informacji i spróbować pójść ścieżką trendów. Nie będzie więc rewolucji, a raczej ewolucja. 🙂 

Polecam Testwarez i za rok również chciałbym tam być. 



O Michał Czyżykowski

Testowałem manualnie, automatycznie i wydajnościowo w ciągu mojej kariery w SII dla Ateny oraz w Atenie. Miałem jeszcze mały epizod pracy jako deweloper zaraz po studiach, ale testowanie bardziej przypadło mi do gustu :). W tej chwili jest testerem wiodącym w Atenie i zajmuje się pisaniem i utrzymaniem testów usług REST/SOAP. Piszę również automaty GUI w Selenium Web Driver. Prowadzę również szkolenia z narzędzia Soap UI NG wewnętrznie w firmie dla naszego oraz innych biur Ateny. Lubię i gram w planszówki i siatkówkę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *