Wielu testerów i nie tylko testerów zna narzędzia do automatyzacji testów, takie jak Selenium. Wielu potrafi w tych narzędziach skutecznie zaimplementować skrypty testowe. Testowanie to jednak nie tylko implementacja i wykonanie testów. Żeby automatyzacja przyniosła maksymalne korzyści trzeba ją zaplanować, a nade wszystko umieścić w odpowiednim miejscu organizacji i procesu testowania.
W swojej prezentacji omawiam cele automatyzacji testów, jej sens, potencjalne zyski i zagrożenia. Pokazuję podstawowe zasady dobrze wykonywanej automatyzacji.
W swojej prezentacji skupiam się na następujących zagadnieniach
• po co automatyzować
• co automatyzować
• problemy automatyzacji
• techniki automatyzacji
• automatyzacji a proces testowania (kiedy automatyzować)
• utrzymanie testów automatycznych
Prezentacja nie jest przywiązana do Selenium, czy innego konkretnego narzędzia testowego.
Prelekcja zainspirowana znaną książką psychologiczną Erica Berne „W co grają ludzie”. Na gruncie analizy transakcyjnej postaram się przedstawić typowe sytuacje i „gry” między testerami a pozostałymi członkami zespołów projektowych. Zrozumienie sytuacji „społecznych” zachodzących w zespole pozwala na ulepszenie kontaktów i podniesienie produktywności zespołu.
I would like to give some thoughts about what it means to be better tester. Who can and should be a better tester? Why someone may want to be still better in his/her job. I will concentrate on personal development as opposed to training courses. There are some traits a tester should posses and they cannot be taught on courses. How to acquire and develop those traits?
Companies always need better people, especially now in the days of staggering economy. Is it possible to motivate people for personal growth? And if it is how to do that? I would like to show the way organizations can enable and facilitate personal growth of testers to the mutual benefit of employers and employees.
Jak zbudować framework do automatyzacji testówJan Sabak
W prezentacji pokazuję (za) proste podejście do automatyzacji testów. Pokazuję też architekturę frameworku do automatyzacji testów funkcjonalnych, taką która umożliwia budowanie zestawu testów, który jest utrzymywalny. Utrzymywalny, to znaczy, że pozwala na minimalizację pracochłonności zmian automatów testowych przy zmianach testowanej aplikacji. Zaprezentuję również proces powstawania takich testów oraz przykładowe narzędzia i techniki stosowane w tym procesie.
Wielu testerów i nie tylko testerów zna narzędzia do automatyzacji testów, takie jak Selenium. Wielu potrafi w tych narzędziach skutecznie zaimplementować skrypty testowe. Testowanie to jednak nie tylko implementacja i wykonanie testów. Żeby automatyzacja przyniosła maksymalne korzyści trzeba ją zaplanować, a nade wszystko umieścić w odpowiednim miejscu organizacji i procesu testowania.
W swojej prezentacji omawiam cele automatyzacji testów, jej sens, potencjalne zyski i zagrożenia. Pokazuję podstawowe zasady dobrze wykonywanej automatyzacji.
W swojej prezentacji skupiam się na następujących zagadnieniach
• po co automatyzować
• co automatyzować
• problemy automatyzacji
• techniki automatyzacji
• automatyzacji a proces testowania (kiedy automatyzować)
• utrzymanie testów automatycznych
Prezentacja nie jest przywiązana do Selenium, czy innego konkretnego narzędzia testowego.
Prelekcja zainspirowana znaną książką psychologiczną Erica Berne „W co grają ludzie”. Na gruncie analizy transakcyjnej postaram się przedstawić typowe sytuacje i „gry” między testerami a pozostałymi członkami zespołów projektowych. Zrozumienie sytuacji „społecznych” zachodzących w zespole pozwala na ulepszenie kontaktów i podniesienie produktywności zespołu.
I would like to give some thoughts about what it means to be better tester. Who can and should be a better tester? Why someone may want to be still better in his/her job. I will concentrate on personal development as opposed to training courses. There are some traits a tester should posses and they cannot be taught on courses. How to acquire and develop those traits?
Companies always need better people, especially now in the days of staggering economy. Is it possible to motivate people for personal growth? And if it is how to do that? I would like to show the way organizations can enable and facilitate personal growth of testers to the mutual benefit of employers and employees.
Jak zbudować framework do automatyzacji testówJan Sabak
W prezentacji pokazuję (za) proste podejście do automatyzacji testów. Pokazuję też architekturę frameworku do automatyzacji testów funkcjonalnych, taką która umożliwia budowanie zestawu testów, który jest utrzymywalny. Utrzymywalny, to znaczy, że pozwala na minimalizację pracochłonności zmian automatów testowych przy zmianach testowanej aplikacji. Zaprezentuję również proces powstawania takich testów oraz przykładowe narzędzia i techniki stosowane w tym procesie.
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...Radoslaw Smilgin
Prezentacja opisuje w jaki sposób zorganizować 60 minut testowania tak by osiągnąć maksymalny efekt. Wszystko przy użyciu strategi testowania eksploracyjnego i testowania sterowanego kontekstem.
Prezentacja była pokazana podczas WarszawQA 2016
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Automatyzacja w praktyce. Praktyka automatyzacjiRadoslaw Smilgin
Automatyczna kontrola jakości oprogramowania jest obecnie w topie pożądanych działań projektowych. Można uznać, że w większości to właśnie zespoły testerskie są odpowiedzialne za dobór właściwego narzędzia, wdrożenie i utrzymanie automatyzacji w organizacji. Podczas prezentacji skupię się na analizie obecnej sytuacji projektów automatyzacji i roli testerów w tym procesie. Bazuję na dostępnych źródłach, własnych obserwacjach, rozmowach z ekspertami oraz na wynikach ankiety przeprowadzonej na testerzy.pl
Najważniejsze tematy:
– proces i projekt automatyzacji jest skrajnie trudny (analizując failure rate)
– czynności w automatyzacji nie są tak trudna jak się większości wydaje
– automatyzacja może być tańsza
– automatyzacja może dostarczać jeszcze większą wartość.
Web Content Accessibility Guideline is not only for web. It works also for desktop and mobile apps, wearables and many others. But still it is only how to make software usable for people with disabilities. There are many trends to change the concept and think how to design better software for all which actually make software even more user friendly.
The presentation is devoted to show how build accessible any kind of software that every user can benefit from.
Eksploracja w kulturze Agile i DevOps czyli o zwinnym testowaniu eksploracyjnymRadoslaw Smilgin
Wystąpienie z Agile & Automation Days 2017 opowiadające o nowej roli testera w projektach zwinnych i w kulturze DevOps. Przyszłością testowania są testerzy techniczni.
Context Driven School of testing w prostych przykładachRadoslaw Smilgin
Szkoła testowanie sterowanego kontekstem to jedno z najważniejszych metod testowania promująca testerów myślących i krytycznych względem produktu.
Slajdy z darmowego webinarium.
Wielu ekspertów mówi, że automatyzacja testów bez kodowania nie jest możliwa. Dla nas „niemożliwe” jest najlepszą motywacją do tego by spróbować.
Wyobraź sobie narzędzie skuteczniejsze od automatu testowego i wydajniejsze od testera manualnego. Wyobraź sobie narzędzie, który uruchomi automatyczną weryfikację po naciśnięciu pojedynczego przycisku. Wyobraź sobie przyszłość, gdzie każdy tester manualny może automatyzować efektywniej niż najbardziej efektywny programista. Musisz sobie to wszystko wyobrażać… bo takie narzędzie nie istnieje. Nie ma jeszcze skuteczności opisywanej powyżej, ale stoi za nim bardzo dobrze przemyślana koncepcja.
Dlaczego chcemy zrealizować ten projekt? Na rynku występuje deficyt automatyków testów oraz testerów manualnych. Pracujący w organizacjach testerzy są przeciążani, albo brak osób do testowania przekłada się na niższą jakość produktów dostarczanych na rynek. Jeśli uda nam się zbudować narzędzie, będziemy mogli odciążyć testerów i pomóc weryfikować (przynajmniej część) rzeczy automatycznie.
W pseudoautomatyzacji w oparciu o narzędzia nagrywająco-odtwarzające użytkownik rejestruje swoje działania w aplikacji. Poprawność generowania kodu sprawdza się po zakończeniu nagrywania skryptu.
W klasycznej automatyzacji pisanej „z palca” skrypty próbkują aplikację próbując przechodzić przez jej wybrane punkty aż do miejsca weryfikacji. W AutoMagicTest implementowana koncepcja ma prezentować się następująco:
• narzędzie dokonuje możliwie najpełniejszej analizy struktury oprogramowania i generuje jego „model”
• w ramach modelu możemy ujawnić pierwsze problemy automatycznie, a defekty ujawnione manualnie można oznaczyć i zaraportować
• scenariusze automatyczne buduje się poprzez wskazanie rozpoznanych automatycznie elementów aplikacji, a na końcu definiuje się weryfikator osiągnięcia lub też braku osiągnięcia celu.
Dzięki temu analizujemy znacznie więcej niż w klasycznej automatyzacji i robimy to bez znaczącego zaangażowania testera. Ta część analizy jest jedynie weryfikacją struktury więc z perspektywy biznesowej ma ograniczone znaczenie. Ma jednak dużą wartość dla testera, który może np. zweryfikować podatność aplikacji na automatyzację. Z drugiej strony osiągamy znacznie więcej niż w przypadku narzędzi nagrywająco – odtwarzających ponieważ podatność elementów aplikacji na automatyzację jest badana przed samym definiowaniem scenariuszy.
Dlaczego warto regularnie dbać o wydajność aplikacji od samego początku jej tworzenia. Jak można wykorzystać do tego narzędzie Gatling i jakie daje możliwości?
Apache JMeter™ to otwarte oprogramowanie, napisane w Javie i dedykowane do wykonywania testów obciążeniowych, wydajnościowych oraz funkcjonalnych. Oryginalnie było projektowane i rozwijane przez Stefano Mazzocchi z Apache Software Foundation, który napisał go do testowania wydajności Apache JServ (projektu, który został zastąpiony przez Apache Tomcat). Następnie JMeter został przeprojektowany i wyposażony w GUI celem rozszerzenia jego zastosowań do testów funkcjonalnych. W listopadzie 2011 roku JMeter stał się projektem Apache najwyższego poziomu (ang. top level), co oznacza, że zyskał społeczność odpowiedzialną za jego rozwój (ang. Project Management Commitee) oraz dedykowany serwis.
Apache JMeter jest używany do testowania wydajności statycznych oraz dynamicznych zasobów takich jak pliki, dynamiczne języki programowania serwisów internetowych, np. PHP, Java, ASP.NET, itp., obiekty Java, bazy danych i kwerendy, serwery FTP, itp. Z powodzeniem jest wykorzystywany do symulowania wzmożonego ruchu na serwerze, grupie serwerów, w sieci lub na „hartowanym” obiekcie. Służy również do analizowania całkowitej wydajności pod obciążeniem różnego typu, np. do graficznej analizy całkowitej wydajności lub do testowania zachowania się serwera / skryptu / obiektu przy wzmożonym i zrównoleglonym obciążeniu.
60 minut testowania - czyli co tester może osiągnąć w jedną godzinę przy pomo...Radoslaw Smilgin
Prezentacja opisuje w jaki sposób zorganizować 60 minut testowania tak by osiągnąć maksymalny efekt. Wszystko przy użyciu strategi testowania eksploracyjnego i testowania sterowanego kontekstem.
Prezentacja była pokazana podczas WarszawQA 2016
Ponad 80% organizacji twierdzi, że korzysta z metod Agile, a 80% z nich ma Scrum. Pomimo 21 lat od powstania Scrum i 15 lat od spisania Agile Manifesto nadal pojawiają się nieprawdziwe opinie, a nawet powstają całe metody rozwiązujące nieistniejące problemy. Im wyżej w strukturze organizacji tym gorzej z wiedzą i tym więcej nieprawdziwych założeń. Od czasu do czasu nadal usłyszymy, że nie ma architektury, że Scrum nadaje się tylko do małych projektów, że Scrum to metoda zarządzania projektami, że nie trzeba pisać dokumentacji, testerów nie ma, bo nie ma takiej roli, a Sprint to taki mały waterfall i tym podobne głupoty. Skąd to się bierze? Najczęściej z braku zrozumienia podstaw lub ze słabej jakości źródeł pozyskanej wiedzy. W praktyce jeśli nie wie się co jest prawdą, a co jest zmyślone bardzo trudno zrozumieć co się na prawdę dzieje i jak powinny wyglądać procesy wytwórcze.
Można dać komuś rybę, ale dużo lepiej jest dać wędkę i nauczyć łowić ryby. Dlatego podczas mojego wystąpienia omówię podstawy zagadnień i zbuduję solidne fundamenty do podejmowania decyzji na co dzień.
Automatyzacja w praktyce. Praktyka automatyzacjiRadoslaw Smilgin
Automatyczna kontrola jakości oprogramowania jest obecnie w topie pożądanych działań projektowych. Można uznać, że w większości to właśnie zespoły testerskie są odpowiedzialne za dobór właściwego narzędzia, wdrożenie i utrzymanie automatyzacji w organizacji. Podczas prezentacji skupię się na analizie obecnej sytuacji projektów automatyzacji i roli testerów w tym procesie. Bazuję na dostępnych źródłach, własnych obserwacjach, rozmowach z ekspertami oraz na wynikach ankiety przeprowadzonej na testerzy.pl
Najważniejsze tematy:
– proces i projekt automatyzacji jest skrajnie trudny (analizując failure rate)
– czynności w automatyzacji nie są tak trudna jak się większości wydaje
– automatyzacja może być tańsza
– automatyzacja może dostarczać jeszcze większą wartość.
Web Content Accessibility Guideline is not only for web. It works also for desktop and mobile apps, wearables and many others. But still it is only how to make software usable for people with disabilities. There are many trends to change the concept and think how to design better software for all which actually make software even more user friendly.
The presentation is devoted to show how build accessible any kind of software that every user can benefit from.
Eksploracja w kulturze Agile i DevOps czyli o zwinnym testowaniu eksploracyjnymRadoslaw Smilgin
Wystąpienie z Agile & Automation Days 2017 opowiadające o nowej roli testera w projektach zwinnych i w kulturze DevOps. Przyszłością testowania są testerzy techniczni.
Context Driven School of testing w prostych przykładachRadoslaw Smilgin
Szkoła testowanie sterowanego kontekstem to jedno z najważniejszych metod testowania promująca testerów myślących i krytycznych względem produktu.
Slajdy z darmowego webinarium.
Wielu ekspertów mówi, że automatyzacja testów bez kodowania nie jest możliwa. Dla nas „niemożliwe” jest najlepszą motywacją do tego by spróbować.
Wyobraź sobie narzędzie skuteczniejsze od automatu testowego i wydajniejsze od testera manualnego. Wyobraź sobie narzędzie, który uruchomi automatyczną weryfikację po naciśnięciu pojedynczego przycisku. Wyobraź sobie przyszłość, gdzie każdy tester manualny może automatyzować efektywniej niż najbardziej efektywny programista. Musisz sobie to wszystko wyobrażać… bo takie narzędzie nie istnieje. Nie ma jeszcze skuteczności opisywanej powyżej, ale stoi za nim bardzo dobrze przemyślana koncepcja.
Dlaczego chcemy zrealizować ten projekt? Na rynku występuje deficyt automatyków testów oraz testerów manualnych. Pracujący w organizacjach testerzy są przeciążani, albo brak osób do testowania przekłada się na niższą jakość produktów dostarczanych na rynek. Jeśli uda nam się zbudować narzędzie, będziemy mogli odciążyć testerów i pomóc weryfikować (przynajmniej część) rzeczy automatycznie.
W pseudoautomatyzacji w oparciu o narzędzia nagrywająco-odtwarzające użytkownik rejestruje swoje działania w aplikacji. Poprawność generowania kodu sprawdza się po zakończeniu nagrywania skryptu.
W klasycznej automatyzacji pisanej „z palca” skrypty próbkują aplikację próbując przechodzić przez jej wybrane punkty aż do miejsca weryfikacji. W AutoMagicTest implementowana koncepcja ma prezentować się następująco:
• narzędzie dokonuje możliwie najpełniejszej analizy struktury oprogramowania i generuje jego „model”
• w ramach modelu możemy ujawnić pierwsze problemy automatycznie, a defekty ujawnione manualnie można oznaczyć i zaraportować
• scenariusze automatyczne buduje się poprzez wskazanie rozpoznanych automatycznie elementów aplikacji, a na końcu definiuje się weryfikator osiągnięcia lub też braku osiągnięcia celu.
Dzięki temu analizujemy znacznie więcej niż w klasycznej automatyzacji i robimy to bez znaczącego zaangażowania testera. Ta część analizy jest jedynie weryfikacją struktury więc z perspektywy biznesowej ma ograniczone znaczenie. Ma jednak dużą wartość dla testera, który może np. zweryfikować podatność aplikacji na automatyzację. Z drugiej strony osiągamy znacznie więcej niż w przypadku narzędzi nagrywająco – odtwarzających ponieważ podatność elementów aplikacji na automatyzację jest badana przed samym definiowaniem scenariuszy.
Dlaczego warto regularnie dbać o wydajność aplikacji od samego początku jej tworzenia. Jak można wykorzystać do tego narzędzie Gatling i jakie daje możliwości?