Odc. 2: Mocne i słabe strony automatyzacji testów low-code | #TestArchitectsTalk

A narzędzia low-code to będą te narzędzia o dużo prostszym interfejsie, oparte bardziej o rozwiązania typu drag and drop, czyli tak naprawdę budowanie aplikacji, nawet złożonych, z prostych klocków. Możemy to przyrównać trochę do budowania z klocków LEGO. Okej, no to w sumie, tak co pierwszym przychodzi do głowy, no to w sumie Postman, no nie? To jest chyba takie, można powiedzieć, najprostsze, najprostszy taki low-code chyba, którego gdzieś tam pewnie każdy dotknął, czy to w automatyzacji testów, czy nawet jako tester manualny, czy nawet to Selenium IDE, gdzie sobie mogliby gdzieś te lata temu ponagrywać te nasze testy, kiedy za bardzo nie potrafiliśmy jeszcze programować, ale to tylko w tym się zamykają low-cody, czy to możemy coś wskazać jeszcze trochę bardziej zaawansowanego? Te rozwiązania są dużo bardziej Dzięki temu te rozwiązania mają budżetowanie, które pozwala im się rozwijać, dodawać nowe technologie takie jak AI.

I tu jak powiedziałeś o Postmanie, tak? Postman też jakby przeniósł się do chmury, stał się bardziej płatnym narzędziem. I nawiązując właśnie do Postmana i dlaczego możemy uwagać za narzędzia low-code'owe, ja bym stwierdził, że to są narzędzia, w których często musimy się najpierw nauczyć wizualnej warstwy ich, a dopiero później możemy w nich napisać testy. Nie zawsze za takie narzędzia uważałem np. JMeter'a, I tutaj myślę, że Artur mógłby się ze mną zgodzić lub nie zgodzić, ponieważ jest naszym osobą, która specjalizuje w testach performance'u. I Arturze, co o tym myślisz? Wiesz co, Wojtek, to jest bardzo dobry temat. Jeżeli chodzi o JMeter'a, ja bardzo długo w ogóle nie rozważałem tego narzędzia jako narzędzia low-code'owe. Dopiero tak naprawdę, kiedy zastanowimy się nad definicją, którą przed chwilą podała nam Daria, Faktycznie dochodzimy do tego, że jest to narzędzie, do którego możemy tak trochę klockami dokładać sobie kolejne requesty, kolejne zapytania, które wysyłamy.