#15 Meetup ŁuczniczQA - Jak nie utonąć w morzu automatyzacji?

#AGENDA SPOTKANIA:

1. Tomek Konieczny - "Serverless - Automated Tests of web apps in Cloud world"

Manual execution of E2E tests, especially regression ones, can take a really long time and it can also be a very repetitive task. These are the reasons why regression tests are often automated.

Automated tests can provide results faster than manual ones and it's possible to execute them more frequently. That allows to test earlier in the development process, decrease overall time needed for tests and what is probably the most important it's possible to release faster and more frequently.

But what if we have more and more tests and even automated execution of them takes too much time - 10 minutes... 30 minutes... maybe even hours? Should we consider the ability to execute full tests set just a few times a day as something normal? Is adding more compute resources the only option to reduce the execution time? Or maybe there are too many high-level tests and some of them should be replaced by low-level ones according to tests pyramid? Is the tests pyramid still valid in the cloud world?

During the presentation you will see how the cloud services like AWS Lambda may be used to run tests in the highly parallelized environment that can reduce execution time even hundreds of times.

2. Maciej Wyrodek - "Test Automation Health CheckList - Panel Dyskusyjny"

Pisanie Automatyzacji testów to naprawdę ogromny temat, setki podejść, tysiące narzędzi… Przez co żadne dwa projekty nie są tak samo zautomatyzowane. Ale jeśli wyjdziemy z okopów codziennego pisania i spojrzymy na temat z dalej perspektywy to jest wiele rzeczy wspólnych. Każda udana automatyzacja ma pewne wspólne cechy.

Fajnie by mieć jakiś guide line lub checklistę która pomogłaby nam określić jak zdrowa jest nasza Automatyzacja.

Dlatego w ramach tego spotkania zrobimy burzę myśli i spróbujemy stworzyć taką checklistę!

3. Michał Krzyżanowski - "Bobcat - historia prawdziwa"

Bobcat - historia prawdziwa: od pójścia live jako projekt open-source, do dzisiaj

Posiadanie własnego frameworku testowego wydaje się być czymś naturalnym dla poważnej, szanującej się firmy. Dodatkowe punkty łapiemy, kiedy owe narzędzie udostępnimy publicznie jako open-source. Często jednak nie zwracamy uwagi na konsekwencje takiej inwestycji, a w danej chwili nie mamy wizji kilkuletniej roadmapy naszego nowego produktu. Chcę opowiedzieć Wam, czego dowiedziałem się na temat projektowania API służącego szerszemu gronu, wspierania community, zarządzania dokumentacją, konsekwencji decyzji, które w trakcie podejmowania wydawały się najlepszym pomysłem na jaki wpadliśmy i innych ciekawostek, na jakie natknąłem się opiekując się naszym firmowym open-source'owym frameworkiem, Bobcatem.