QA – Nearshore Software Development Company – IT Outsourcing Services

Zawód tester oprogramowania. Czy to praca dla każdego?

Przemysław Papis — Wed, 20 Sep 2023 03:09:00 +0000

Przejdź do:

1. Tester oprogramowania – praca dla każdego?
2. Praca jako tester oprogramowania – fakty i mity
3. Jaki zestaw umiejętności powinien posiadać dobry tester oprogramowania?
4. Jak zostać testerem oprogramowania?
5. Podsumowanie

W dynamicznie rozwijającym się świecie technologii, gdzie oprogramowanie jest integralną częścią naszego codziennego życia, istnieje grupa profesjonalistów, którzy pełnią kluczową rolę w zapewnianiu jakości i niezawodności każdej aplikacji, programu czy platformy – są to testerzy oprogramowania. Choć może się wydawać, że ich zadanie polega tylko na poszukiwaniu błędów, to w rzeczywistości jest to o wiele bardziej złożona i fascynująca dziedzina, która pozwala zapewnić bezpieczeństwo i doskonałą jakość cyfrowego świata, w którym żyjemy.

Tester oprogramowania – praca dla każdego?

Jako tester manualny pracuję od 2015 roku i od tego czasu zdążyłem zetknąć się z wieloma mitami dotyczącymi tej pracy, takimi jak:

Testowanie oprogramowania to zawód dla każdego, kto chce wejść do branży IT
Tester oprogramowania jest mniej ważny od programisty
Testowanie jest łatwe – polega tylko na klikaniu i szukaniu błędów
Testowanie można pominąć

Jeżeli chcesz spróbować swoich sił jako tester, z tego tekstu dowiesz się, jak jest naprawdę. Piszę o tym, czy naprawdę każdy może być testerem, jakie predyspozycje powinien mieć dobry tester i jaką rolę pełni on w cyklu rozwoju oprogramowania.

Czytaj także: Kim jest QA tester? Testowanie oprogramowania i zapewnianie jakości bez tajemnic!

Praca jako tester oprogramowania – fakty i mity

Mit 1: Każdy może pracować jako tester oprogramowania

Zacznijmy może od tego, skąd wzięło się przeświadczenie, że w obszarze testowania może pracować każdy. Sądzę, że jest kilka powodów tego stanu rzeczy, ale głównym jest sytuacja na rynku pracy jeszcze kilka-kilkanaście lat temu. Gdyby wówczas ktoś zadał mi pytanie, czy każdy może pracować jako tester, moja odpowiedź mogłaby być zgoła inna. Zarówno na staże czy stanowiska juniorskie w tamtych latach przyjmowano znacznie szerszą grupę osób, niż ma to miejsce obecnie. A ponieważ stanowisko testera ma faktycznie dość niski próg wejścia, wiele osób założyło, że jest to praca dla każdego, kto chce spróbować swoich sił w branży IT (która niezmiennie kusi zarobkami i stabilnością pracy).

Fakt: Tak jak w przypadku każdego stanowiska, tak i w testach potrzebny jest ciągły rozwój, a skończenie stażu czy wejście do branży IT jako junior to dopiero początek. Wiele osób, które spodziewają się szybkiej kariery jako testerzy oprogramowania, może być zaskoczonych tym, jak ważne w tym zawodzie są osobiste predyspozycje (o tym niżej), kompetencje miękkie, znajomość narzędzi, udział w szkoleniach, certyfikaty. Istotny jest też wybór swojej specjalizacji, odpowiedniej ścieżki rozwoju (testy manualne, testy automatyczne, ścieżka liderska lub test managerska). Podsumowując, w tej pracy trzeba mieć umiejętności techniczne, pomocne będą też na pewno zrozumienie podstaw programowania, znajomość narzędzi testowych (przynajmniej ze słyszenia), języki obce, znajomość systemów operacyjnych oraz umiejętność czytania dokumentacji technicznej.

Mit 2: Testowanie polega tylko na szukaniu błędów

Kolejnym powodem zainteresowania zawodem testera może być niezrozumienie tego, na czym polega testowanie oprogramowania i czym zajmuje się tester w procesie wytwarzania oprogramowania. Osoby spoza branży, które nie pracowały dotychczas z oprogramowaniem lub nie są zaznajomione ze złożonością kontroli jakości (Quality Control), mogą mieć mylny obraz obowiązków testera oprogramowania. “To łatwe. Wystarczy po prostu klikać i znajdować błędy” – to spore uproszczenie, które nie ma odzwierciedlenia w codziennych zadaniach. Oczywiście dla testera manualnego “przeklikiwanie” się przez scenariusze testowe, znajdowanie i zgłaszanie błędów stanowią znaczną część pracy. Jest to jednak wierzchołek góry lodowej.

Fakt: Tester oprogramowania (Quality Control) dostarcza informacji o jakości rozwijanego produktu. Nie tylko poszukuje defektów, wykonując testy, ale także pomaga zminimalizować ryzyko ich wystąpienia, przygotowuje raporty na temat stanu aplikacji oraz dostarcza ważnych informacji pomocnych w procesie zapewniania jakości (Quality Assurance). Dziś zwraca się uwagę, że działania testera (Quality Control) coraz bardziej zmierzają w stronę szeroko pojętego Quality Assurance.

Mit 3: Testowanie to mało ważny element wytwarzania oprogramowania

Niektórzy mogą też uważać, że testowanie jest mało znaczącym elementem wytwarzania oprogramowania. Często spotykam się z opinią, głównie wśród osób spoza branży, że “tester to taki gorszy programista” i w sumie to nie do końca wiadomo, czym się zajmuje.

Fakt: Testy oprogramowania są integralną, a nie opcjonalną częścią rozwoju oprogramowania. Testy nie są dodatkiem do pisania kodu, lecz istotnym elementem w procesie tworzenia wydajnych systemów zgodnych z wymaganiami funkcjonalnymi. W historii było mnóstwo sytuacji, w których niewykryty, z pozoru niewielki błąd generował milionowe koszty, udaremniał misję kosmiczną czy powodował koszmarne straty wizerunkowe. To obrazuje, jak istotne są testy i jak ważną rolę odgrywa tester oprogramowania.

Jaki zestaw umiejętności powinien posiadać dobry tester oprogramowania?

Rozpisałem się na temat mitów dotyczących zawodu testera (i pewnie nie wyczerpałem tematu), ale nie chciałbym jednak zniechęcać was do spróbowania swoich sił w testowaniu. Skupmy się więc na tym, dla kogo będzie to odpowiednia praca i jaki zestaw umiejętności powinien posiadać dobry tester, aby sprawdzać się w tej roli.

Dbałość o szczegóły – jedną z głównych cech testera kontroli jakości jest skrupulatność i dbałość o szczegóły. Specjaliści ds. kontroli jakości muszą przeczesywać złożone systemy, szukając nawet najmniejszych wad, które mogą negatywnie wpłynąć na działanie produktu. Podczas pracy z dokumentacją każde słowo ma znaczenie i niuans może zaważyć na tym, czy produkt będzie spełniał wymogi klienta.
Powtarzalność – zapewnianie jakości często obejmuje powtarzalne zadania, np. kilku- czy kilkudziesięciokrotne przechodzenie przez te same przypadki testowe w celu sprawdzenia zachowania oprogramowania w kolejnych iteracjach. Taki system pracy może być monotonny i nużący dla niektórych osób. Jednocześnie nie powinien sprawiać, że tester straci uwagę i stanie się mniej czujny (to prędko doprowadzi do obniżenia jakości).
Umiejętność rozwiązywania problemów – tak jak wspominałem wcześniej, testowanie to coś więcej niż tylko szukanie błędów. Dobry tester musi nie tylko znaleźć problem i go zgłosić, ale też mieć chęć zgłębienia go, by zapobiec podobnym przypadkom w przyszłości i pomóc w znalezieniu rozwiązania. Wbrew obiegowej opinii tester nie naprawia wszystkich znalezionych przez siebie defektów. Czasem źródło problemu leży zupełnie gdzieś indziej, niżby się wydawało (na ogół naprawą błędów zajmują się programiści czy DevOpsi; tester poprawia błędy, ale we własnym kodzie, w sytuacji, gdy pisze testy automatyczne)
Komunikacja i współpraca – skuteczna komunikacja ma kluczowe znaczenie w kontroli jakości. Testerzy muszą bardzo dokładnie zgłaszać defekty, jasno komunikować, gdzie leży problem, opisywać ścieżkę do odtworzenia problemu w taki sposób, aby jednoznacznie można było dany błąd odtworzyć i naprawić. Trzeba ściśle współpracować zarówno z programistami, jak i innymi interesariuszami. Specjaliści kontroli jakości często pełnią rolę mediatorów pomiędzy programistami a menedżerami produktu czy klientem, co wymaga doskonałych umiejętności interpersonalnych. Trzeba być empatycznym, uważać na słowa, pamiętać, że wszyscy dążą w tym samym kierunku, którym jest wydanie jak najlepiej działającego produktu.
Praca pod presją – testerzy często pracują pod dużą presją czasu, w napiętych terminach. Często czasu na testy jest zbyt mało, a oczekuje się od nich skutecznego dostarczania wyników. Harmonogramy projektów i cykle wydań mogą być stresujące, zwłaszcza gdy defekty pojawiają się tuż przed wprowadzeniem produktu na rynek. Specjaliści ds. kontroli jakości muszą zachować opanowanie i strategicznie ustalać priorytety, aby zapewnić wysoką jakość.
Ciągłe uczenie się i rozwijanie – sektor IT jest zapewne jednym z najprężniej rozwijających się pod względem technologicznym i wymaga ciągłego uczenia się. Tutaj boleśnie można odczuć prawdziwość stwierdzenia, że “Kto stoi w miejscu, ten się cofa”. Coraz to nowe technologie, narzędzia, metodologie – znajomość nowinek może znacząco poprawić nie tylko jakość, ale i efektywność testowania.
Empatia i abstrakcyjne myślenie – wspomniałem już o tym częściowo przy okazji komunikacji i współpracy, ale uznałem, że ten aspekt zasługuje na wyróżnienie w oddzielnym punkcie. Dobry tester musi umieć wczuć się w rolę użytkownika końcowego, spróbować przewidzieć jego zachowania. Musi chcieć „popsuć” oprogramowanie. Wymyślać jak najróżniejsze sposoby działania i sytuacje, na które może w przyszłości być narażony produkt, i zawczasu im zaradzić.

Jak zostać testerem oprogramowania?

Jest wiele możliwości, jedną z nich są programy stażowe. W Inetum prowadzimy nabór dla juniorów w ramach autorskich programów stażowych – znajdziecie je na stronie kariery. Mam nadzieję, że mój artykuł pomógł wam zrozumieć, jakie cechy powinien mieć dobry tester oprogramowania i jeśli uważacie, że spełniacie powyższe warunki, to moim zdaniem warto spróbować swoich sił.

Czytaj także: Co łączy testera z branżą filmową? Czyli scenariusze testowe bez tajemnic

Podsumowanie

Kontrola jakości jest bardzo ważnym aspektem całego procesu wytwarzania oprogramowania. Testerzy oprogramowania uczestniczą w procesie już od samego początku i są istotnym elementem na każdym etapie. Testerzy muszą posiadać unikalny zestaw umiejętności, znacznie wykraczający poza definicję typowych osób introwertycznych czy ekstrawertycznych. Tester oprogramowania blisko współpracuje z ludźmi, zarówno z programistami, jak i przedstawicielami biznesu, ale korzysta też z wachlarza narzędzi programistycznych, testerskich oraz biurowych. Czasem trzeba w ciszy i skupieniu powtarzać w nieskończoność te same testy, ale też rozmawiać z ludźmi, jasno i stanowczo prezentując swoje uwagi, popierając to konkretnymi danymi.

Kim jest QA tester? Testowanie oprogramowania i zapewnianie jakości bez tajemnic!

Zuzanna Slusarska — Fri, 28 Jul 2023 08:50:29 +0000

Przejdź do:

1. Kim jest tester?
2. Jaką rolę pełni w projekcie tester oraz z kim ściśle współpracuje specjalista QA?
3. Na jakich przedmiotach na studiach skupić się najbardziej, aby w przyszłości pracować jako tester oprogramowania?
4. Ścieżki rozwoju od stażysty do leadera
5. Plusy i minusy pracy na stanowisku Quality Assurance Specialist.
6. Podsumowanie

Data pierwszej publikacji: 04.04.2021
Ostatnia aktualizacja: 28.07.2023

Kim jest QA Tester? Czyli parę słów o zapewnianiu jakości

Zapewnianie jakości (Quality Assurance) to zadania, zachowania i działania, jakie wykonuje Tester/Test Manager, aby wdrażając program, aplikację, system lub stronę na produkcję, dbać o jakość wszystkich wytwarzanych produktów.

Wszyscy gramy w jakieś gry, więc wyobraźmy sobie grę. Ktoś ową grę musiał sobie wymarzyć – to będzie nasz klient. Ktoś musiał spisać obszerną dokumentację, jak ta gra ma wyglądać i jakie ma mieć zasady – to analityk/architekt/Product Owner. Ktoś musiał tę grę zaimplementować – pojawia się developer. Później ktoś musiał w nią grać każdego dnia, przechodząc level pierwszy tysiąc razy w poszukiwaniu błędów. Następnego dnia tylko level drugi, również szukając błędów. A później znów level pierwszy, gdyż developer poprawił znalezione przez testera błędy i trzeba sprawdzić, czy zrobił to skutecznie – tym zajmuje się Tester (Quality Control).

Finalnie dochodzimy do QA (Quality Assurance) – to osoba, która oprócz wykonywania testów planuje testy, ocenia ryzyko oraz opracowuje procesy, aby osiągnąć najwyższą możliwą jakość całej gry, a nie tylko jednego poziomu. To ktoś, kto myśli o tej grze jako całości o określonym efekcie końcowym. Rekomenduje środowiska, w jakich powinny być wykonywane testy, oraz określa, jakie typy i rodzaje testów powinny być wykonywane.

Przeczytaj także: Quality Assurance (QA) – zapewnij jakość w twoich projektach IT

Jaką rolę pełni w projekcie tester oraz z kim ściśle współpracuje specjalista QA?

QA pełni rolę strażnika jakości. Sprawdza, czy oprogramowanie będące przedmiotem testów jest gotowe do wdrożenia. Optymalizuje procesy testowe.

Z kim współpracuje QA?

Z Analitykiem/Product Ownerem (Scrum) – QA przede wszystkim od niego czerpie wiedzę, jak powinna działać aplikacja, którą testuje.
Z Test Managerem/Test Leadem – z nim QA ustala, jakie testy wykonać, w jakim czasie, gdzie raportować.
Z developerem – weryfikacja tego, co zaimplementował developer, jest podstawowym zajęciem QA, dlatego ścisła relacja z developerem jest bardzo ważna
Z innym QA w zespole – QA wymieniają miedzy sobą wiedzę na temat przedmiotu testów, sposobu testowania, wymieniają doświadczenia, weryfikują wzajemnie swoją pracę.

Na jakich przedmiotach na studiach skupić się najbardziej, aby w przyszłości pracować jako tester oprogramowania?

Na każdym! Wszechstronna wiedza jest potrzebna, by móc pracować w różnych sektorach. Aplikacje tworzone są dla sektora ubezpieczeniowego, lotniczego, motoryzacyjnego, rolniczego, wojskowego, publicznego. Wszędzie wykorzystywane są aplikacje i my, QA, testujemy je przed uruchomieniem produkcyjnym. Takie podejście owocuje większym zakresem wśród ofert pracy.

Przeczytaj także: Piramida testów – czyli co, kiedy i jak testować, żeby testy przyniosły zysk?

Tester manualny vs QA test engineer – czyli ścieżki rozwoju od stażysty do leadera

W sektorze QA tych ścieżek jest wiele. Kilka przykładów poniżej.

Tester manualny (stażysta, junior, mid, senior) -> Leader Testów (mid, senior) -> Test Manager (Senior)
Tester manualny -> tester automatyzujący -> Leader Testów -> Test Manager
Tester manualny -> tester automatyzujący -> programista
Tester automatyzujący -> tester manualny -> Leader Testów -> Test Manager
Tester automatyzujący -> leader testów -> Test Manager
Tester automatyzujący -> programista

Plusy i minusy pracy na stanowisku Quality Assurance Specialist – moje największe wyzwania

Praca przy rozwoju oprogramowania jest pełna niespodzianek. W branży IT każdy dzień to wyzwanie, a więc każdy dzień to nowe zadania.

Plusy:

Udział w projektach mających znaczenie – wiele aplikacji działa, chroniąc ludzkie życie bądź je ułatwiając. To, by brać udział w takich projektach, ma dla mnie znaczenie.
Poznawanie różnych sektorów – przykładowo, praca urzędnika jest jednosektorowa. My jako QA dziś jesteśmy w projekcie bankowym, a jutro w lotnictwie, a pojutrze w ubezpieczeniach.
Poznawanie ludzi – praca zespołowa jest tym, w czym się spełniam, a na to pozwala mi bycie QA!

Minusy:

Presja czasu – często QA to ostatnie ogniwo wytwarzania oprogramowania, a jeśli gdzieś po drodze będą opóźnienia, to dla nas zostaje najmniej czasu.
Wytykanie błędów innym – to rodzi konflikty, czyli musimy posiadać komunikacyjne kompetencje miękkie na wysokim poziomie, aby nie zaogniać sytuacji, tylko ją rozwiązać.

Gdybym mogła cofnąć czas, czy dalej zostałabym QA?

Zaczynałam od programowania w PL/SQL-u, następnie zaczęłam testować. Gdzieś po drodze sprawdziłam, jak to jest być analitykiem. Prawda jest taka, że QA to trochę developer, trochę analityk, a przede wszystkim tester. Pracując w tej branży od ponad 15 lat, miałam czas, by zmienić role, a nawet pracę, ale po co? To, co robię, daje mi mnóstwo satysfakcji. Zaczynając od tego, że do dziś produkcyjnie działają aplikacje z różnych sektorów, które testowałam i wdrażałam wiele lat temu.

Dziś jestem Test Managerem. Uczę innych testowania, tworzę procesy testowe, robię audyty procesów testowych w projektach, w których nie biorę udziału na co dzień, oraz nadal czasem testuję – bo to uwielbiam. Podsumowując: cofanie czasu nie ma sensu, bo robiłabym dokładnie to samo.

Testy automatyczne: Selenium + Python vs Selenium + Java

Jacek Laska — Wed, 12 Jul 2023 05:33:00 +0000

Jako (przyszły) inżynier automatyzacji testów celujący w pracę z Selenium w pewnym momencie dotrzesz do punktu, w którym trzeba będzie podjąć decyzję, w którą stronę iść oraz czego używać do testowania. Świat IT i QA szybko się zmienia, a niektóre z narzędzi i języków, które były kiedyś popularne, dziś już takie nie są. Jak w każdym przypadku, istnieje wiele czynników, które mogą odegrać rolę w podjęciu decyzji. W tym artykule postaram się ułatwić ci to zadanie, przedstawiając zalety i wady łączenia Selenium z dwoma obecnie najpopularniejszymi językami programowania: Javą i Pythonem.

Przejdź do:

1. Automatyzacja testów: jakie mamy opcje? Java i Python
2. Język programowania czy język skryptowy?
3. Czego łatwiej się nauczyć: Javy czy Pythona?
4. Automatyzacja testów – jakie są opcje?
5. Czym jest Selenium WebDriver?
6. Selenium i Python
7. Selenium i Java
8. Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?
9. Jak wykonać skrypt Selenium w Pythonie?
10. Jak zainstalować Selenium z PIP?
11. Automatyzacja testów – podsumowanie
12. FAQ

Automatyzacja testów: jakie mamy opcje? Java i Python

Każdy z tych języków ma ugruntowaną pozycję, jest niezależny od platformy, zorientowany obiektowo i posiada dużą, wspierającą społeczność użytkowników. Jeśli chodzi o wybór powiązań (ang. bindings) języka Selenium dla Javy i Pythona, powinieneś najpierw zrozumieć kilka kluczowych różnic pomiędzy nimi.

Selenium obsługuje szeroką gamę języków programowania do automatyzacji testów. W tym kontekście Java i Python są najlepszymi kandydatami (i konkurentami) do połączenia z Selenium.

Język programowania czy język skryptowy?

Jednym z głównych pytań, które mogą przyjść ci do głowy, porównując Javę i Pythona, może być: „Czy Python i Java to języki programowania, czy języki skryptowe?”.

Zasadniczo wszystkie języki skryptowe są uważane za języki programowania. Główną różnicą między nimi jest to, że języki programowania są kompilowane, podczas gdy języki skryptowe są interpretowane. Języki skryptowe są wolniejsze niż języki programowania i pozostają zazwyczaj za nimi w tyle.

Szybkie porównanie znajdziesz tutaj: Interpreter vs compiler

Python

Python można nazwać zarówno językiem skryptowym, jak i językiem programowania, ponieważ działa zarówno jako kompilator, jak i interpreter. Standardowy Python może skompilować kod Pythona do kodów bajtowych, a następnie zinterpretować go tak jak Java i C.

„Jednak biorąc pod uwagę historyczny związek między językiem programowania ogólnego przeznaczenia a językiem skryptowym, bardziej właściwe byłoby stwierdzenie, że Python jest językiem programowania, który dobrze działa również jako język skryptowy”.

Interpreter to warstwa oprogramowania, która działa jako pomost między programem a sprzętem systemowym, aby utrzymać działanie kodu. Interpreter Pythona to aplikacja odpowiedzialna za uruchamianie skryptów Pythona.

Java

Java jest na ogół szybsza i bardziej wydajna niż Python, ponieważ jest językiem skompilowanym. Jako język interpretowany, Python z kolei ma prostszą, bardziej zwięzłą składnię. Może pełnić tę samą funkcję co Java, przy użyciu mniejszej liczby linijek kodu. W Javie typy danych zmiennych powinny być zadeklarowane przed ich użyciem, w przeciwieństwie do Pythona. Zdecyduj, co bardziej ci odpowiada.

Czego łatwiej się nauczyć: Javy czy Pythona?

Kolejne pytanie, które może się zrodzić (zwłaszcza gdy dopiero zaczynasz przygodę z programowaniem) brzmi: jak szybko mogę nauczyć się Javy vs. Pythona?

Tu nie ma wątpliwości: Python jest zwycięzcą. Jak wspomniałem, jego składnia jest krótsza i prostsza. Prototypowanie w Javie jest bardziej złożone – przykładowo, obciąża kod dodatkowymi deklaracjami i ograniczeniami. Wybierz Pythona, jeśli nie masz wiele czasu na naukę.

Oto lista kluczowych czynników, które trzeba wziąć pod uwagę przed podjęciem decyzji:

Oferty pracy: wciąż więcej ofert pracy jest w Javie

Zmiana pracy / migracja: dzięki skryptowaniu, łatwiej jest w przypadku Pythona, jeśli np. myślisz o kulturze DevOps
Programowanie zorientowane obiektowo: zarówno Python, jak i Java polegają na programowaniu obiektowym, więc znajomość jednego z tych języków stanowi dobry punkt wyjścia do nauki drugiego
Niezależne od platformy: zarówno binaria Pythona, jak i Javy (kody bajtowe) po wygenerowaniu mogą być wykonywane na dowolnych obsługiwanych platformach dzięki własnym maszynom wirtualnym (odpowiednio PVM i JVM)
Prostota: Python jest łatwiejszy w użyciu dzięki prostszej składni
Wykonanie: jako reprezentacja języka skryptowego Python ma możliwość bezpośredniego uruchamiania kodu skryptu za pomocą interpretera zamiast bezpośredniego uruchamiania kompilatora (np. Javac dla Java)
Wydajność / szybkość wykonania: Java ma tu przewagę, ponieważ jest szybsza (można skompilować ją JIT, aby była bardziej wydajna)
Popularność / wsparcie: Java wygrywa w tym zestawieniu jako popularne rozwiązanie, które ma bardzo dużą i wspierającą społeczność programistów
Python jest językiem statycznie typowanym (sprawdza typ w czasie wykonywania, co oznacza, że twój kod może w ostatniej chwili zawieść)
Java jest językiem dynamicznie typowanym (sprawdza typ w czasie kompilacji, co oznacza, że wychwytujesz problemy w swoim kodzie wcześniej w procesie tworzenia oprogramowania)
Rozszerzalność: ponieważ Java jest bardziej popularna, na rynku jest dostępne więcej wtyczek, interfejsów API, frameworków i bibliotek niż w przypadku Pythona

Automatyzacja testów – jakie są opcje?

Selenium zaspokaja określoną potrzebę w świecie automatyzacji testów. Jest tylko dla przeglądarek. Jeśli chcesz szybko rozpocząć automatyzację swoich przypadków testowych, zaprzyjaźnij się z Selenium IDE. Pozwala ono szybko i łatwo rozpocząć automatyzację testów dzięki opcji nagrywania.

Kroki testowe wykonywane w przeglądarce są bezpośrednio przekształcane w zestaw poleceń dzięki Selenese (to wbudowany język Selenium IDE). To bardzo ułatwia zadanie. Ponadto, po zapisaniu testów w zestawie poleceń Selenese, można je agregować w pakiety testowe i ostatecznie eksportować do preferowanych powiązań Selenium (np.: Java, Python itp.).

Selenese i Selenium IDE to dobry początek, ale im bardziej będziesz się zagłębiać w temat automatyzacji aplikacji internetowych, tym wyraźniej dostrzeżesz ich ograniczenia.

Aby solidnie przetestować nowoczesną aplikację internetową z jej dynamicznie zmieniającą się treścią (np. przy użyciu technologii AJAX czy JS), zaczniesz szukać bardziej zaawansowanych opcji. Tutaj z pomocą przychodzi Selenium WebDriver wraz z powiązaniami językowymi Selenium. Selenium WebDriver jest często używany jako baza do testowania aplikacji internetowych.

Zgodnie z sylabusem A4Q Selenium 4 Tester:

„Selenium, gdy jest używane do testowania aplikacji internetowych, potrzebuje pewnych frameworków testowych. Silnik Selenium, jako samodzielne narzędzie, wystawia TAE tylko swoje natywne API jako metody lub funkcje. Inżynier automatyzacji testów musi następnie zaprogramować środowisko testowe, aby użyć tych interfejsów API do przeprowadzenia wymaganych testów. Framework testowy można opracować od podstaw lub wykorzystać już istniejące. Selenium obsługuje wiele frameworków testowych w różnych językach, np.:

dla Javy: Selenide
dla Pythona: Selene

Niezależnie od tego, czy korzystasz z własnych frameworków, czy nie, musisz w jakiś sposób sterować wykonywaniem testów. Wielu inżynierów korzysta z bibliotek testów jednostkowych do prowadzenia swoich testów (test runnerów).

Niektóre z nich, takie jak TestNG lub Pytest, oprócz podstawowego zastosowania w testach jednostkowych pozwalają tworzyć testy funkcjonalne wyższego poziomu (funkcjonalne, komponentowe, integracyjne, end-to-end itp.).

Dla Pythona

Najprostszym przypadkiem jest użycie standardowej biblioteki testów jednostkowych Pythona. Alternatywnie możesz użyć bardzo popularnego Pytest.

Dla Javy

Możesz użyć bibliotek xUnit (np. JUnit 4/5) lub TestNG.

Po zaznajomieniu się z uruchamianiem testów lokalnie za pomocą wybranej przeglądarki możesz zrobić krok naprzód i skonfigurować siatkę przeglądarek do zdalnego uruchamiania testów.

W ten sposób testy można uruchamiać na różnych przeglądarkach i kilku systemach operacyjnych na wielu komputerach w trybie równoległym. Jeśli masz sporą konfigurację, możesz przeprowadzić testy regresji w krótkim czasie (w porównaniu z czasem bez Selenium Grid).

Następnie możesz iść o jeszcze jeden krok dalej i zintegrować swoje testy z CI/CD pipeline (np.: uruchomić Selenium Tests w GitLab CI/CD lub Jenkins).

Pamiętaj, że masz możliwość skorzystania z dobrodziejstw konteneryzacji, np. Dockera, aby utworzyć różne obrazy do automatycznych testów interfejsu użytkownika.

W ten sposób możesz przygotować oddzielną maszynę wirtualną dla dowolnej kombinacji środowiska systemu operacyjnego / przeglądarki dla SUT (System Under Test) / AUT (Application Under Test).

CI/CD odgrywa kluczową rolę w tworzeniu cykli życia oprogramowania, w których nowe funkcje są ciągle aktualizowane maksymalnie szybko i wydajnie. Dzięki temu użytkownicy końcowi mają dostęp do nowych funkcji bez konieczności pobierania aktualizacji oprogramowania, co zapewnia im bezproblemową obsługę.

Biorąc pod uwagę krótki czas trwania cyklu wydawania oprogramowania, testy muszą być skalowane, aby dostarczane oprogramowanie było wolne od błędów we wspomnianym przedziale czasowym. W tym miejscu Selenium odgrywa kluczową rolę, umożliwiając automatyzację testów w CI/CD pipeline.

Dzięki automatyzacji z Selenium można wykonywać testy równoległe w wymaganej skali, a Dockerem, z pomocą kontenerów, pomaga to utrzymać środowisko testowe w dobrym stanie.

Przeczytaj także: Testy akceptacyjne użytkownika (UAT) – dlaczego są ważne?

Czym jest Selenium WebDriver?

Najbardziej wyczerpującym źródłem wiedzy w tym temacie jest strona Selenium WebDriver:

„Selenium WebDriver odnosi się zarówno do powiązań językowych, jak i implementacji kodu sterującego danej przeglądarki. Powszechnie używa się po prostu określenia WebDriver”.

lub cytując sylabus A4Q:

„Selenium WebDriver, jak sama nazwa wskazuje, współdziała z przeglądarką w taki sam sposób, jak zrobiłby to prawdziwy użytkownik. WebDriver to kompleksowe narzędzie do kompilacji testów dla aplikacji internetowych, które jest również często określane jako Selenium WebDriver”.

Z architektonicznego punktu widzenia Selenium wszystkie komponenty są odpowiednio zwizualizowane na oficjalnej stronie dokumentacji.

Można powiedzieć, że WebDriver pomaga nam naśladować interakcje użytkownika / przeglądarki i dlatego jest tak pomocne w automatyzacji testów. WebDriver kontroluje przeglądarkę za pomocą właściwych dla niej sterowników, które są zwykle tworzone przez dostawców przeglądarek (np. Google dla Chrome lub Mozilla dla Firefox).

Cała komunikacja jest dwukierunkowa i zgodna z następującymi protokołami:

dla Selenium 3: JSON Wire Protocol prez HTTP (komunikacja tłumaczona)
dla Selenium 4: W3C WebDriver Protocol (komunikacja natywna). Zobacz więcej na stronie W3C

Dzięki protokołowi W3C wprowadzonemu w Selenium 4 mamy bezpośredni transfer informacji między klientem a serwerem. Tak więc, jeśli nadal używasz Selenium 3 (WebDriver) i wahasz się, czy zacząć korzystać z wyższej wersji, koniecznie sprawdź informacje na stronie: Upgrade to Selenium 4.

Minimalne wymagane wersje to Java w wersji 8 i Python w wersji 3.7

Selenium i Python

Jeśli wybrałeś tę drogę i jesteś początkujący, wypróbuj Selenium IDE i wygeneruj swój kod Pythona za pomocą funkcji eksportu.

Gdy będziesz już bardziej obeznany z Selenium IDE, przygotuj pełne środowisko programistyczne do automatyzacji testów Selenium / Python.

Przygotuj:

IDE (PyCharm, Visual Studio Code lub Aqua)
Python
PIP (Package Installer for Python)
Narzędzie do budowania Pipenv ( PIP + Venv/Virtualenv, Poetry lub Bazel)
Powiązania Selenium z Pythonem
Sterowniki przeglądarek dla Selenium (Chrome, Firefox, Safari, Opera, Edge or webdriver-manager/SeleniumManager*)
Test Runner (Unittest lub Pytest)

*Selenium Manager jest dostępny od wersji 4.6 (Beta)

Przeczytaj artykuł: NumPy – wstęp do biblioteki w języku Python

Selenium i Java

Jeśli wybrałeś tę opcję i jesteś początkujący, wypróbuj wtyczkę Selenium IDE dla Chrome lub Firefox i wygeneruj kod Java za pomocą funkcji eksportu:

Gdy już nabędziesz doświadczenia, przygotuj pełne środowisko programistyczne do automatyzacji testów Selenium / Java.

Przygotuj:

IDE (IDEA, Visual Studio Code lub Aqua)
Java (JDK)
Narzędzie do budowania (Maven lub Gradle)
Powiązania z Selenium w Javie
Sterowniki przeglądarek dla Selenium (Chrome, Firefox, Safari, Opera, Edge or WebDriverManager/SeleniumManager*)
Test Runner (JUNIT4 / JUNIT5 lub TestNG)

*Selenium Manager jest dostępny od wersji 4.6 (Beta)

Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?

Jeśli jesteś całkowicie „zielony” i chcesz sprawdzić możliwości programowania czy automatyzacji za pomocą Selenium z Javą lub Pythonem, proponuję, abyś zaczął od skorzystania z Selenium IDE.

Selenium IDE jest dostarczany w formie dodatku do Chrome, Firefox i Edge (wersja 3.x). Umożliwia wygenerowanie kodu Javy / Pythona za pomocą funkcji eksportu. To bardzo proste – zwyczajnie rejestrujesz swoje działania w przeglądarce. Kod jest następnie generowany za pomocą funkcji eksportu do ulubionego języka. W momencie pisania tego artykułu (czerwiec 2023) możliwe było nawet pobranie samodzielnej wersji (4 alpha) Selenium IDE na kilka platform (np.: Windows, MacOS).

Dowiedz się więcej o najnowszych wersjach Selenium.

Z punktu widzenia automatyzacji, a zwłaszcza integracji CI/CD, wygląda na to, że lepiej sprawdzi się tu duet Selenium i Java. Dobrze wpisuje się w powyższy proces – zazwyczaj natywnie i łatwo dzięki bardzo dobrej integracji z narzędziami takimi jak Jenkins / Maven / Gradle.

Nie oznacza to jednak, że nie można tego osiągnąć za pomocą Pythona. Będzie to co prawda bardziej męczące i wymaga użycia niektórych wtyczek. Ale przypomnijmy: Python oznacza łatwe programowanie i większą czytelność. Jeśli więc nie masz żadnego zaplecza programistycznego w obszarze Javy i Pythona, może kusić cię wykorzystanie drugiego z tych języków.

Jednym z ważnych punktów w procesie rozwoju automatyzacji testów w Selenium jest debugowanie testów. Wiele przeglądarek udostępnia „DevTools” – zestaw narzędzi zintegrowanych z przeglądarką, których programiści mogą używać do debugowania aplikacji internetowych i sprawdzania wydajności swoich stron.

Pierwszym narzędziem tego typu, które przychodzi mi do głowy, jest Chrome DevTools oparty na protokole Chrome DevTools Protocol (CDP):

Jest on prawdopodobnie najczęściej używany i zintegrowany z samym Selenium 4. Pomaga sprawdzać, testować i weryfikować selektory. Ponieważ selektory są ogólne i niezależne od języka, mają uniwersalne zastosowanie. Przydatne w debugowaniu kodu testowego Selenium będą również punkty przerwania (breakpoints) w twoim ulubionym IDE. Ustaw je w dowolnym miejscu, które wydaje ci się problematyczne, a test w przeglądarce zatrzyma się w wybranym momencie. Teraz możesz kontynuować debugowanie za pomocą DevTools przeglądarki, takich jak Chrome DevTools.

Działa to zarówno dla Javy (np.: IDEA), jak i Pythona (np.: PyCharm). Ale jeśli chodzi o Pythona, jest jedna kwestia interesująca również w kontekście debugowania. Mam na myśli PDB (The Python Debugger), jedną z najlepszych technik debugowania dla Selenium.

Ten moduł Pythona zapewnia interaktywną opcję debugowania kodu źródłowego. Aby samemu przekonać się o tym, jak bardzo może być przydatna, spójrz na poniższy przykład:

C:\Users\user> py 

Python 3.11.4 (tagi/v3.11.4:d2340ef, 7 czerwca 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)] na win32 

Wpisz „pomoc”, „prawa autorskie”, „kredyty” lub „licencja”, aby uzyskać więcej informacji. 

>>> from selenium import webdriver 

>>> from selenium.webdriver.common.by import By 

>>> import pdb 

>>> if __name__ == '__main__': 

...     print('Hello World!') 

...     browser = webdriver.Chrome() 

...     browser.  Get('http://selenium.dev/') 

...     web_driver_selector = "div.selenium-button-container a.selenium-webdriver" 

...     web_Driver_link = browser.find_element(By.CSS_SELECTOR, web_Driver_Selector) 

...     pdb.set_trace  () 

...     browser.  Quit() 

... 

Hello World!

a teraz, gdy twoja przeglądarka zostanie zatrzymana w wybranym punkcie ustawionym na stronie, możesz sprawdzić web_driver_link:

(Pdb) dir 

 

(Pdb) dir(web_driver_link) 

['__abstractmethods__', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', '_abc_impl', '_execute', '_id', '_parent', '_upload', 'accessible_name', 'aria_role', 'clear', 'click', 'find_element', 'find_elements', 'get_attribute', 'get_dom_attribute', 'get_property', 'id', 'is_displayed', 'is_enabled', 'is_selected', 'location', 'location_once_scrolled_into_view', 'parent', 'rect', 'screenshot', 'screenshot_as_base64', 'screenshot_as_png', 'send_keys', 'shadow_root', 'size', 'submit', 'tag_name', 'text', 'value_of_css_property']

Jak widać, PDB daje możliwość sprawdzenia obiektu i tego, co można z nim zrobić, za pomocą polecenia dir, na przykład:

(Pdb) web_driver_link.is_displayed() 

True 

(Pdb) web_driver_link.is_enabled() 

True 

(Pdb) web_driver_link.is_selected() 

False 

(Pdb) web_driver_link.text 

'READ MORE' 

(Pdb) web_driver_link.get_property('href') 

„https://www.selenium.dev/documentation/webdriver/” 

(Pdb) web_driver_link.get_dom_attribute('class') 

'selenium-button selenium-webdriver text-uppercase font-weight-bold' 

(Pdb) web_driver_link.get_attribute('class') 

'selenium-button selenium-webdriver text-uppercase font-weight-bold' 

(Pdb) web_driver_link.get_dom_attribute('class') 

> 

(Pdb) web_driver_link.id 

'E97FE72B561D59DFF64B6C8846C4CC17_element_31' 

(Pdb) web_driver_link.__class__ 

 

(Pdb) web_driver_link.value_of_css_property 

> 

(Pdb) web_driver_link.value_of_css_property('color') 

'rgba(200, 16, 46, 1)' 

(Pdb)

Może to być również jeden z argumentów przemawiających na korzyść Pythona. Możesz go rozszerzyć nawet za pomocą dodatku ipdb, który poprawia obsługę debuggera pdb.

Tryb debugowania ipdb dodaje kolorowe podświetlanie składni, uzupełnianie tabulatorów i rozszerzony widok kodu z numerami wierszy. Przed użyciem PDB musi być zainstalowany niezależnie od Pytest:

pip install ipdb

Do czego służy Selenium z Pythonem?

Wspomniany duet technologiczny służy do testowania frontu aplikacji webowych. Pomaga wspierać żmudne i powtarzalne działania lub testy GUI, zastępując je automatycznymi skryptami. W ten sposób można je zintegrować z narzędziami CI/CD i wykorzystać na przykład do testów regresji przeprowadzanych w nocy. Gdybym miał odpowiedzieć na powyżej zadane pytanie jednym zdaniem, powiedziałbym:

„Selenium + Python służy zasadniczo do automatyzacji testów aplikacji internetowych”.

Selenium (WebDriver) odpowiada za dwukierunkową komunikację klient – serwer między tobą a przeglądarką. Python i jego powiązania z Selenium „opakowują” to wszystko w wykonywalny kod, dostarczany przez niektóre frameworki testowe, takie jak xUnit / TestNG.

Czy Selenium z Pythonem to dobry wybór?

Odpowiedź na to pytanie zależy od wielu czynników. Każdy z nas jest inny, różnią nas doświadczenie, kompetencje i umiejętność uczenia się. Ostateczna odpowiedź na to pytanie będzie więc miała dla ciebie wymiar indywidualny. Celem tego artykułu jest to, aby pomóc ci ją odnaleźć. Przeczytaj go, przeanalizuj, biorąc pod uwagę własne cele zawodowe, doświadczenie, aktualne projekty i swoje plany, tak by dokonać możliwie jak najlepszego wyboru.

Jak wykonać skrypt Selenium w Pythonie?

W Pythonie możemy wyróżnić 2 główne typy plików:

Pliki .py to pliki tekstowe możliwe do odczytania przez człowieka, zawierające wewnątrz kod Pythona, zwane skryptami Pythona (w systemach Windows rozszerzeniem może być również .pyw)
Pliki .pyc to skompilowane pliki kodu bajtowego, które są generowane przez interpreter języka Python podczas importowania lub wykonywania skryptu Pythona.

Pliki Pythona są zapisywane na komputerze użytkownika z rozszerzeniem .py, podobnie jak pliki Java są zapisywane z rozszerzeniami .java. Kody Pythona, po ich zinterpretowaniu, są następnie konwertowane na kody bajtowe. Te kody bajtowe są zapisywane w pliku z rozszerzeniem .pyc.

Katalog „__pycache__” to folder utworzony w celu przechowywania plików .pyc.

Pomyśl o pliku .pyc jako skompilowanym kodzie bajtowym podobnym do pliku .class w świecie Javy.

Gdy tylko go wygenerujesz, może być bezpośrednio wykonany przez interpreter bez rekompilacji pliku skryptu .py za każdym razem, gdy go używasz – zatem przyspieszasz wykonanie.

To ważne, gdy masz spore skrypty i/lub moduły Pythona.

Podsumowując:

Pliki .pyc są generowane automatycznie przez interpreter języka Python podczas importowania lub wykonywania skryptu Python
Pliki .pyc są przechowywane w tym samym katalogu co odpowiadające im pliki .py i mają taką samą nazwę jak pliki .py, z wyjątkiem rozszerzenia .pyc zamiast .py
Pliki .pyc są właściwe dla danej wersji Pythona, użytej do ich wygenerowania. Jeśli spróbujesz uruchomić plik .pyc z inną wersją języka Python, możesz napotkać błędy lub może się pojawić nieoczekiwane zachowanie

eśli chcesz uruchomić skrypt Pythona, masz 2 opcje:

uruchamianie Python Scriptu przez Interpretera Pythona w trybie interaktywnym (w postaci fragmentu kodu napisanego w sesji interaktywnej – przydatnego do debugowania)

python

e.g.:

wpisywanie kodu linijka po linijce

C:\Users\user> py 

Python 3.11.4 (tagi/v3.11.4:d2340ef, 7 czerwca 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)] na win32 

Wpisz „pomoc”, „prawa autorskie”, „kredyty” lub „licencja”, aby uzyskać więcej informacji. 

>>> from selenium import webdriver 

>>> if __name__ == '__main__': 

...     print('Hello World!') 

...     browser = webdriver.Chrome() 

...     browser.get('http://selenium.dev/') 

...     browser.quit() 

... 

Hello World! 

  

DevTools listening on ws://127.0.0.1:56302/devtools/browser/fdca3cc9-4266-49af-a146-41d60ed464eb 

>>> exit() 

  

C:\Users\user>

lub za pomocą exec() , który zapewnia alternatywny sposób uruchamiania skryptów:

C:\Users\user> py 

Python 3.11.4 (tagi/v3.11.4:d2340ef, 7 czerwca 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)] na win32 

Wpisz „pomoc”, „prawa autorskie”, „kredyty” lub „licencja”, aby uzyskać więcej informacji. 

>>> exec(open('your_script.py').read()) 

Hello World! 

>>> 

>>> quit() 

  

C:\Users\user>

Interaktywna sesja Pythona pozwala napisać wiele linijek kodu, jednak po jej zamknięciu tracisz wszystko, co napisałeś.

Dlatego często do pisania programów w Pythonie używa się zwykłych plików tekstowych. Plik z kodem Pythona musi znajdować się w bieżącym katalogu roboczym. Plik musi znajdować się w ścieżce wyszukiwania modułów Pythona (PMSP), w której Python wyszukuje importowane moduły i pakiety.

2) uruchom Python Script za pomocą Command-Line (w formie skryptu lub modułu – przydatne do automatyzacji)

python your_script.py

C:\Users\user> py your_script.py 

Hello World!

lub jeszcze łatwiej: używając skojarzeń plików systemu Windows i podając tylko nazwę skryptu:

C:\Users\user> your_script.py 

Hello World!

w systemach GNU/Linux możesz osiągnąć coś podobnego, dodając tak zwany hashbang lub shebang do swojego skryptu. Jest on kombinacją znaków #! po którym następuje ścieżka interpretera.

Istnieją dwa sposoby określenia ścieżki do interpretera:

#!/usr/bin/python: pisząc ścieżkę absolutną

#!/usr/bin/env python: za pomocą polecenia systemu operacyjnego env, które lokalizuje i wykonuje kod Pythona, przeszukując zmienną środowiskową PATH

Ponieważ nie wszystkie systemy uniksopodobne lokalizują interpreter Pythona w tym samym miejscu, drugi charakter ścieżki podany powyżej wygląda bardziej uniwersalnie.

musisz również dodać uprawnienia do wykonywania:

#assign the execution permissions 

chmod +x your_script.py 

#run script using its filename 

./your_script.py 

Hello World!

możesz uruchomić wygenerowany bezpośrednio kod bajtowy skryptu:

C:\Users\user> dir your_script.py 

Volume in drive C is Windows 

Volume Serial Number is 94D2-9546 

  

Directory of C:\Users\user 

  

15-Jun-23  14:02               544 your_script.py 

               1 File(s)            544 bytes 

               0 Dir(s)  194,664,701,952 bytes free 

  

C:\Users\user> cd __pycache__ 

  

C:\Users\user\__pycache__> dir your_script.cpython-311.pyc 

Volume in drive C is Windows 

Volume Serial Number is 94D2-9546 

  

Directory of C:\Users\user\__pycache__ 

  

15-Jun-23  14:06               401 your_script.cpython-311.pyc 

               1 File(s)            401 bytes 

               0 Dir(s)  194,664,546,304 bytes free 

  

C:\Users\user\__pycache__> your_script.cpython-311.pyc 

Hello World! 

  

C:\Users\user\__pycache__>

Jak zainstalować Selenium z PIP?

zainstaluj Pythona (ręcznie lub za pomocą IDE)

Wejdź na Python.org i pobierz odpowiednią wersję.

py –version

Python 3.N.N

e.g. for WIN (CMD):

 

C:\Users\user> py --version 

Python 3.11.4 

  

C:\Users\user>

install or upgrade PIP (manually or using IDE)

Czym jest PIP?

PIP jest instalatorem pakietów dla Pythona. Możesz go użyć do zainstalowania pakietów z indeksu pakietów Pythona i innych. Najpopularniejsze narzędzie do instalowania pakietów Pythona dołączone do najnowszych wersji tego języka. Dostarcza podstawowych funkcji wyszukiwania, pobierania i instalowania pakietów z innych indeksów pakietów Pythona i może być włączony do szerokiego zakresu przepływów pracy programistycznej (workflow) za pośrednictwem interfejsu wiersza poleceń (CLI).

py -m pip –version

pip X.Y.Z from … (python 3.N.N)

e.g., for WIN (CMD):

 

C:\Users\user> py -m pip --version 

pip 23.1.2 from C:\Program Files\Python311\Lib\site-packages\pip (python 3.11) 

  

C:\Users\user> 

  

e.g., for WIN (IDE): 

  

  

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip list 

 

 

setuptools 65.5.1 

wheel      0.38.4 

  

[notice] A new release of pip available: 22.3.1 -> 23.1.2 

[notice] To update, run: python.exe -m pip install --upgrade pip 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip --version 

pip 22.3.1 from C:\Users\user\PycharmProjects\pythonSelenium\venv\Lib\site-packages\pip (python 3.11) 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> python.exe -m pip install --upgrade pip 

Requirement already satisfied: pip in c:\users\user\pycharmprojects\pythonselenium\venv\lib\site-packages (22.3.1) 

Collecting pip 

  Downloading pip-23.1.2-py3-none-any.whl (2.1 MB) 

     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1/2.1 MB 2.7 MB/s eta 0:00:00 

Installing collected packages: pip 

  Attempting uninstall: pip 

    Found existing installation: pip 22.3.1 

    Uninstalling pip-22.3.1: 

      Successfully uninstalled pip-22.3.1 

Successfully installed pip-23.1.2 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium>  

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip --version 

pip 23.1.2 from C:\Users\user\PycharmProjects\pythonSelenium\venv\Lib\site-packages\pip (python 3.11) 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium>  

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip list 

Package    Version 

---------- ------- 

pip        23.1.2 

setuptools 65.5.1 

wheel      0.38.4 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium>

Jeśli to zadziałało, gratulacje! Masz w swoim środowisku działający PIP.

instalacja powiązań Selenium Python

Zweryfikuj obsługiwaną wersję Pythona (dla wersji Selenium 4.10.0):

  Python 3.7+ 
  

Instalacja

Jeśli masz PIP w swoim systemie, możesz po prostu zainstalować lub zaktualizować powiązania Pythona:

pip install selenium 

pip install -U selenium

Jeśli potrzebujesz określonej wersji powiązań Selenium z Pythonem:

pip install selenium==

Alternatywnie możesz pobrać dystrybucję źródłową z PyPI (np. selen-4.10.0.tar.gz), odarchiwizować ją i uruchomić:

py setup.py install

e.g. for WIN (CMD):

  

C:\Users\user> py -m pip list 

Package    Version 

---------- ------- 

pip        23.1.2 

setuptools 65.5.0 

  

C:\Users\user> 

C:\Users\user> py -m pip install selenium 

Defaulting to user installation because normal site-packages is not writeable 

Collecting selenium 

  Downloading selenium-4.10.0-py3-none-any.whl (6.7 MB) 

     ---------------------------------------- 6.7/6.7 MB 23.7 MB/s eta 0:00:00 

Collecting urllib3[socks]<3,>=1.26 (from selenium) 

  Downloading urllib3-2.0.3-py3-none-any.whl (123 kB) 

     ---------------------------------------- 123.6/123.6 kB ? eta 0:00:00 

Collecting trio~=0.17 (from selenium) 

  Downloading trio-0.22.0-py3-none-any.whl (384 kB) 

     ---------------------------------------- 384.9/384.9 kB 25.0 MB/s eta 0:00:00 

Collecting trio-websocket~=0.9 (from selenium) 

  Downloading trio_websocket-0.10.3-py3-none-any.whl (17 kB) 

Collecting certifi>=2021.10.8 (from selenium) 

  Downloading certifi-2023.5.7-py3-none-any.whl (156 kB) 

     ---------------------------------------- 157.0/157.0 kB 9.2 MB/s eta 0:00:00 

Collecting attrs>=19.2.0 (from trio~=0.17->selenium) 

  Downloading attrs-23.1.0-py3-none-any.whl (61 kB) 

     ---------------------------------------- 61.2/61.2 kB 3.2 MB/s eta 0:00:00 

Collecting sortedcontainers (from trio~=0.17->selenium) 

  Downloading sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB) 

Collecting async-generator>=1.9 (from trio~=0.17->selenium) 

  Downloading async_generator-1.10-py3-none-any.whl (18 kB) 

Collecting idna (from trio~=0.17->selenium) 

  Downloading idna-3.4-py3-none-any.whl (61 kB) 

     ---------------------------------------- 61.5/61.5 kB 3.2 MB/s eta 0:00:00 

Collecting outcome (from trio~=0.17->selenium) 

  Downloading outcome-1.2.0-py2.py3-none-any.whl (9.7 kB) 

Collecting sniffio (from trio~=0.17->selenium) 

  Downloading sniffio-1.3.0-py3-none-any.whl (10 kB) 

Collecting cffi>=1.14 (from trio~=0.17->selenium) 

  Downloading cffi-1.15.1-cp311-cp311-win_amd64.whl (179 kB) 

     ---------------------------------------- 179.0/179.0 kB ? eta 0:00:00 

Collecting exceptiongroup (from trio-websocket~=0.9->selenium) 

  Downloading exceptiongroup-1.1.1-py3-none-any.whl (14 kB) 

Collecting wsproto>=0.14 (from trio-websocket~=0.9->selenium) 

  Downloading wsproto-1.2.0-py3-none-any.whl (24 kB) 

Collecting pysocks!=1.5.7,<2.0,>=1.5.6 (from urllib3[socks]<3,>=1.26->selenium) 

  Downloading PySocks-1.7.1-py3-none-any.whl (16 kB) 

Collecting pycparser (from cffi>=1.14->trio~=0.17->selenium) 

  Downloading pycparser-2.21-py2.py3-none-any.whl (118 kB) 

     ---------------------------------------- 118.7/118.7 kB ? eta 0:00:00 

Collecting h11<1,>=0.9.0 (from wsproto>=0.14->trio-websocket~=0.9->selenium) 

  Downloading h11-0.14.0-py3-none-any.whl (58 kB) 

     ---------------------------------------- 58.3/58.3 kB ? eta 0:00:00 

Installing collected packages: sortedcontainers, urllib3, sniffio, pysocks, pycparser, idna, h11, exceptiongroup, certifi, attrs, async-generator, wsproto, outcome, cffi, trio, trio-websocket, selenium 

Successfully installed async-generator-1.10 attrs-23.1.0 certifi-2023.5.7 cffi-1.15.1 exceptiongroup-1.1.1 h11-0.14.0 idna-3.4 outcome-1.2.0 pycparser-2.21 pysocks-1.7.1 selenium-4.10.0 sniffio-1.3.0 sortedcontainers-2.4.0 trio-0.22.0 trio-websocket-0.10.3 urllib3-2.0.3 wsproto-1.2.0 

  

C:\Users\user> 

C:\Users\user> py -m pip freeze 

async-generator==1.10 

attrs==23.1.0 

certifi==2023.5.7 

cffi==1.15.1 

exceptiongroup==1.1.1 

h11==0.14.0 

idna==3.4 

outcome==1.2.0 

pycparser==2.21 

PySocks==1.7.1 

selenium==4.10.0 

sniffio==1.3.0 

sortedcontainers==2.4.0 

trio==0.22.0 

trio-websocket==0.10.3 

urllib3==2.0.3 

wsproto==1.2.0 

  

C:\Users\user> 

C:\Users\user> py -m pip show selenium 

Name: selenium 

Version: 4.10.0 

Podsumowanie: 

Home-page: https://www.selenium.dev 

Author: 

Author-email: 

License: Apache 2.0 

Location: C:\Users\user\AppData\Roaming\Python\Python311\site-packages 

Requires: certifi, trio, trio-websocket, urllib3 

Required-by: 

  

C:\Users\user> 

  

  

or for WIN (IDE): 

  

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip install selenium 

Collecting selenium 

  Using cached selenium-4.10.0-py3-none-any.whl (6.7 MB) 

Collecting urllib3[socks]<3,>=1.26 (from selenium) 

  Using cached urllib3-2.0.3-py3-none-any.whl (123 kB) 

Collecting trio~=0.17 (from selenium) 

  Using cached trio-0.22.0-py3-none-any.whl (384 kB) 

Collecting trio-websocket~=0.9 (from selenium) 

  Using cached trio_websocket-0.10.3-py3-none-any.whl (17 kB) 

Collecting certifi>=2021.10.8 (from selenium) 

  Using cached certifi-2023.5.7-py3-none-any.whl (156 kB) 

Collecting attrs>=19.2.0 (from trio~=0.17->selenium) 

  Using cached attrs-23.1.0-py3-none-any.whl (61 kB) 

Collecting sortedcontainers (from trio~=0.17->selenium) 

  Using cached sortedcontainers-2.4.0-py2.py3-none-any.whl (29 kB) 

Collecting async-generator>=1.9 (from trio~=0.17->selenium) 

  Using cached async_generator-1.10-py3-none-any.whl (18 kB) 

Collecting idna (from trio~=0.17->selenium) 

  Using cached idna-3.4-py3-none-any.whl (61 kB) 

Collecting outcome (from trio~=0.17->selenium) 

  Using cached outcome-1.2.0-py2.py3-none-any.whl (9.7 kB) 

Collecting sniffio (from trio~=0.17->selenium) 

  Using cached sniffio-1.3.0-py3-none-any.whl (10 kB) 

Collecting cffi>=1.14 (from trio~=0.17->selenium) 

  Using cached cffi-1.15.1-cp311-cp311-win_amd64.whl (179 kB) 

Collecting exceptiongroup (from trio-websocket~=0.9->selenium) 

  Using cached exceptiongroup-1.1.1-py3-none-any.whl (14 kB) 

Collecting wsproto>=0.14 (from trio-websocket~=0.9->selenium) 

  Using cached wsproto-1.2.0-py3-none-any.whl (24 kB) 

Collecting pysocks!=1.5.7,<2.0,>=1.5.6 (from urllib3[socks]<3,>=1.26->selenium) 

  Using cached PySocks-1.7.1-py3-none-any.whl (16 kB) 

Collecting pycparser (from cffi>=1.14->trio~=0.17->selenium) 

  Using cached pycparser-2.21-py2.py3-none-any.whl (118 kB) 

Collecting h11<1,>=0.9.0 (from wsproto>=0.14->trio-websocket~=0.9->selenium) 

  Using cached h11-0.14.0-py3-none-any.whl (58 kB) 

Installing collected packages: sortedcontainers, urllib3, sniffio, pysocks, pycparser, idna, h11, exceptiongroup, certifi, attrs, async-generator, wsproto, outco 

me, cffi, trio, trio-websocket, selenium 

Successfully installed async-generator-1.10 attrs-23.1.0 certifi-2023.5.7 cffi-1.15.1 exceptiongroup-1.1.1 h11-0.14.0 idna-3.4 outcome-1.2.0 pycparser-2.21 pysoc 

ks-1.7.1 selenium-4.10.0 sniffio-1.3.0 sortedcontainers-2.4.0 trio-0.22.0 trio-websocket-0.10.3 urllib3-2.0.3 wsproto-1.2.0 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium>  

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip list             

Package          Version 

---------------- -------- 

async-generator  1.10 

attrs            23.1.0 

certifi          2023.5.7 

cffi             1.15.1 

exceptiongroup   1.1.1 

h11              0.14.0 

idna             3.4 

outcome          1.2.0 

pip              23.1.2 

pycparser        2.21 

PySocks          1.7.1 

selenium         4.10.0 

sniffio          1.3.0 

sortedcontainers 2.4.0 

trio             0.22.0 

trio-websocket   0.10.3 

urllib3          2.0.3 

wheel            0.38.4 

wsproto          1.2.0 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium> py -m pip show selenium 

Name: selenium 

Version: 4.10.0 

Podsumowanie: 

Home-page: https://www.selenium.dev 

Author: 

Author-email: 

License: Apache 2.0 

Location: C:\Users\user\PycharmProjects\pythonSelenium\venv\Lib\site-packages 

Requires: certifi, trio, trio-websocket, urllib3 

Required-by: 

(venv) PS C:\Users\user\PycharmProjects\pythonSelenium>

Automatyzacja testów – podsumowanie

Selenium obsługuje wiele języków programowania do automatyzacji testów. Wśród programistów zarówno Java, jak i Python zyskały rekordową popularność. Pythona łatwo się nauczyć, jego składnia jest czytelna, więc jeśli dopiero zaczynasz programować, użycie Selenium z Pythonem może być interesujące pod względem automatyzacji. Natomiast Java i Selenium, szczególnie w kontekście integracji CI/CD, dzięki zastosowaniu odpowiednich narzędzi do budowania, doskonale wpisują się w cały proces wytwarzania oprogramowania. Odpowiedź na pytanie, czy wybrać Javę czy Pythona, należy do ciebie i będzie zależeć od twojego doświadczenia zawodowego i celów, jakie sobie stawiasz.

FAQ Pakiet startowy Selenium + Java lub Python

Oto twój pakiet startowy do automatyzacji testów z Selenium + Java lub Selenium + Python, bez względu na to, którego z nich zdecydujesz się użyć.

Testy akceptacyjne użytkownika (UAT) – dlaczego są ważne?

Paweł Jaroszek — Thu, 15 Jun 2023 08:48:44 +0000

Przejdź do:

1. Automatyzacja testów: jakie mamy opcje? Java i Python
2. Język programowania czy język skryptowy?
3. Czego łatwiej się nauczyć: Javy czy Pythona?
4. Automatyzacja testów – jakie są opcje?
5. Czym jest Selenium WebDriver?
6. Selenium i Python
7. Selenium i Java
8. Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?
9. Jak wykonać skrypt Selenium w Pythonie?
10. Jak zainstalować Selenium z PIP?
11. Automatyzacja testów – podsumowanie
12. FAQ

Automatyzacja testów: jakie mamy opcje? Java i Python

Selenium obsługuje szeroką gamę języków programowania do automatyzacji testów. W tym kontekście Java i Python są najlepszymi kandydatami (i konkurentami) do połączenia z Selenium.

Język programowania czy język skryptowy?

Jednym z głównych pytań, które mogą przyjść ci do głowy, porównując Javę i Pythona, może być: „Czy Python i Java to języki programowania, czy języki skryptowe?”.

Szybkie porównanie znajdziesz tutaj: Interpreter vs compiler

Python

Java

Czego łatwiej się nauczyć: Javy czy Pythona?

Kolejne pytanie, które może się zrodzić (zwłaszcza gdy dopiero zaczynasz przygodę z programowaniem) brzmi: jak szybko mogę nauczyć się Javy vs. Pythona?

Oto lista kluczowych czynników, które trzeba wziąć pod uwagę przed podjęciem decyzji:

Oferty pracy: wciąż więcej ofert pracy jest w Javie

Zmiana pracy / migracja: dzięki skryptowaniu, łatwiej jest w przypadku Pythona, jeśli np. myślisz o kulturze DevOps
Programowanie zorientowane obiektowo: zarówno Python, jak i Java polegają na programowaniu obiektowym, więc znajomość jednego z tych języków stanowi dobry punkt wyjścia do nauki drugiego
Niezależne od platformy: zarówno binaria Pythona, jak i Javy (kody bajtowe) po wygenerowaniu mogą być wykonywane na dowolnych obsługiwanych platformach dzięki własnym maszynom wirtualnym (odpowiednio PVM i JVM)
Prostota: Python jest łatwiejszy w użyciu dzięki prostszej składni
Wykonanie: jako reprezentacja języka skryptowego Python ma możliwość bezpośredniego uruchamiania kodu skryptu za pomocą interpretera zamiast bezpośredniego uruchamiania kompilatora (np. Javac dla Java)
Wydajność / szybkość wykonania: Java ma tu przewagę, ponieważ jest szybsza (można skompilować ją JIT, aby była bardziej wydajna)
Popularność / wsparcie: Java wygrywa w tym zestawieniu jako popularne rozwiązanie, które ma bardzo dużą i wspierającą społeczność programistów
Python jest językiem statycznie typowanym (sprawdza typ w czasie wykonywania, co oznacza, że twój kod może w ostatniej chwili zawieść)
Java jest językiem dynamicznie typowanym (sprawdza typ w czasie kompilacji, co oznacza, że wychwytujesz problemy w swoim kodzie wcześniej w procesie tworzenia oprogramowania)
Rozszerzalność: ponieważ Java jest bardziej popularna, na rynku jest dostępne więcej wtyczek, interfejsów API, frameworków i bibliotek niż w przypadku Pythona

Automatyzacja testów – jakie są opcje?

Selenese i Selenium IDE to dobry początek, ale im bardziej będziesz się zagłębiać w temat automatyzacji aplikacji internetowych, tym wyraźniej dostrzeżesz ich ograniczenia.

Zgodnie z sylabusem A4Q Selenium 4 Tester:

dla Javy: Selenide
dla Pythona: Selene

Dla Pythona

Najprostszym przypadkiem jest użycie standardowej biblioteki testów jednostkowych Pythona. Alternatywnie możesz użyć bardzo popularnego Pytest.

Dla Javy

Możesz użyć bibliotek xUnit (np. JUnit 4/5) lub TestNG.

Po zaznajomieniu się z uruchamianiem testów lokalnie za pomocą wybranej przeglądarki możesz zrobić krok naprzód i skonfigurować siatkę przeglądarek do zdalnego uruchamiania testów.

Następnie możesz iść o jeszcze jeden krok dalej i zintegrować swoje testy z CI/CD pipeline (np.: uruchomić Selenium Tests w GitLab CI/CD lub Jenkins).

Pamiętaj, że masz możliwość skorzystania z dobrodziejstw konteneryzacji, np. Dockera, aby utworzyć różne obrazy do automatycznych testów interfejsu użytkownika.

W ten sposób możesz przygotować oddzielną maszynę wirtualną dla dowolnej kombinacji środowiska systemu operacyjnego / przeglądarki dla SUT (System Under Test) / AUT (Application Under Test).

Dzięki automatyzacji z Selenium można wykonywać testy równoległe w wymaganej skali, a Dockerem, z pomocą kontenerów, pomaga to utrzymać środowisko testowe w dobrym stanie.

Przeczytaj także: Testy akceptacyjne użytkownika (UAT) – dlaczego są ważne?

Czym jest Selenium WebDriver?

Najbardziej wyczerpującym źródłem wiedzy w tym temacie jest strona Selenium WebDriver:

„Selenium WebDriver odnosi się zarówno do powiązań językowych, jak i implementacji kodu sterującego danej przeglądarki. Powszechnie używa się po prostu określenia WebDriver”.

lub cytując sylabus A4Q:

Z architektonicznego punktu widzenia Selenium wszystkie komponenty są odpowiednio zwizualizowane na oficjalnej stronie dokumentacji.

Cała komunikacja jest dwukierunkowa i zgodna z następującymi protokołami:

dla Selenium 3: JSON Wire Protocol prez HTTP (komunikacja tłumaczona)
dla Selenium 4: W3C WebDriver Protocol (komunikacja natywna). Zobacz więcej na stronie W3C

Minimalne wymagane wersje to Java w wersji 8 i Python w wersji 3.7

Selenium i Python

Jeśli wybrałeś tę drogę i jesteś początkujący, wypróbuj Selenium IDE i wygeneruj swój kod Pythona za pomocą funkcji eksportu.

Gdy będziesz już bardziej obeznany z Selenium IDE, przygotuj pełne środowisko programistyczne do automatyzacji testów Selenium / Python.

Przygotuj:

IDE (PyCharm, Visual Studio Code lub Aqua)

Python
PIP (Package Installer for Python)
Narzędzie do budowania Pipenv ( PIP + Venv/Virtualenv, Poetry lub Bazel)
Powiązania Selenium z Pythonem
Sterowniki przeglądarek dla Selenium (Chrome, Firefox, Safari, Opera, Edge or webdriver-manager/SeleniumManager*)
Test Runner (Unittest lub Pytest)

*Selenium Manager jest dostępny od wersji 4.6 (Beta)

Selenium i Java

Jeśli wybrałeś tę opcję i jesteś początkujący, wypróbuj wtyczkę Selenium IDE dla Chrome lub Firefox i wygeneruj kod Java za pomocą funkcji eksportu:

Gdy już nabędziesz doświadczenia, przygotuj pełne środowisko programistyczne do automatyzacji testów Selenium / Java.

Przygotuj:

IDE (IDEA, Visual Studio Code lub Aqua)
Java (JDK)
Narzędzie do budowania (Maven lub Gradle)
Powiązania z Selenium w Javie
Sterowniki przeglądarek dla Selenium (Chrome, Firefox, Safari, Opera, Edge or WebDriverManager/SeleniumManager*)

Test Runner (JUNIT4 / JUNIT5 lub TestNG)

*Selenium Manager jest dostępny od wersji 4.6 (Beta)

Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?

Dowiedz się więcej o najnowszych wersjach Selenium.

Frameworki do automatyzacji testów. Wprowadzenie do Atata

Łucja Nowińska — Fri, 12 May 2023 05:17:00 +0000

Spis treści:

1. Kiedy i dlaczego automatyzować testy oprogramowania?
2. Atata automation framework
3. Atata vs Selenium
4. Który framework do automatyzacji testów będzie najlepszy dla mojego projektu?
5. Podsumowanie

Kiedy i dlaczego automatyzować testy oprogramowania?

Czym jest automatyzacja?

Zanim skupimy się na temacie frameworka, jakim jest Atata, chciałabym słowem wstępu przypomnieć, czym w ogóle jest automatyzacja testów oprogramowania i dlaczego warto się nią zainteresować. Wokół tego tematu narosło bowiem wiele mitów.

Testowanie to bardzo istotny element procesu wytwarzania oprogramowania. Jednym z podejść do tego zagadnienia jest automatyzacja, czyli wykorzystanie specjalnych narzędzi i frameworków, które umożliwiają programowanie testów i ich automatyczne wykonanie bez dalszej ingerencji człowieka.

Korzyści automatyzacji

Automatyzacja tych procesów może przynieść niezliczone korzyści, w tym jedną z najważniejszych – oszczędność czasu i kosztów. Ponadto testy automatyczne są bardziej powtarzalne i dokładniejsze niż testy przeprowadzane ręcznie, co przekłada się na ich niezawodność i skuteczność.

Scenariusze i przypadki testowe a automatyzacja

Warto rozważyć opcję automatyzacji testów w naszym projekcie również z powodu możliwości przeprowadzania testów o skomplikowanych scenariuszach i w wielu środowiskach jednocześnie, co mogłoby stanowić wyzwanie podczas ręcznego realizowania scenariusza testowego na co dzień. Możliwe jest przeprowadzanie testów na różnych platformach, w różnych konfiguracjach sprzętowych i sieciowych, co byłoby trudne lub wręcz niemożliwe do osiągnięcia w przypadku testów manualnych.

Tworzenie przypadków testowych w zautomatyzowanej formie zapewnia ich powtarzalność, a co za tym idzie, podnosi ich skuteczność w wykrywaniu defektów. Właśnie dlatego automatyzacja jest szczególnie użyteczna w testowaniu funkcjonalności krytycznych dla aplikacji. Warto jednak pamiętać, że rzeczywistość testowa nie jest zero-jedynkowa i jak wszystko ma swoje plusy i minusy. Jakie są zatem ciemne strony automatyzacji?

Przeczytaj także: Jak pisać scenariusze testowe? Jak scenariusz testowy pomaga na późniejszych etapach pracy rozwoju oprogramowania? Czym różnią się scenariusze testowe i przypadki testowe?

Ciemne strony automatyzacji

Automatyzacja testów może być fantastycznym rozwiązaniem w wielu projektach, lecz nie jest uniwersalnym rozwiązaniem. W niektórych przypadkach testy manualne mogą być dużo lepszą, bardziej efektywną lub nawet jedyną dostępną opcją. Dlatego przed podjęciem decyzji o automatyzacji testów warto dokładnie przeanalizować specyfikę projektu, potrzeby, które się z nim wiążą, oraz wszelkie dostępne narzędzia i frameworki.

Nie można też zapominać o czasie, który należy zainwestować w stworzenie zautomatyzowanych przypadków testowych. Wymaga to wielu godzin pracy, tworzenia konfiguracji oraz rozwiązywania problemów, które nie występują podczas ręcznego testowania oprogramowania. Jest to proces, który z początku może rozwijać się bardzo powoli, a miarodajne wyniki nieraz są widoczne dopiero po włożeniu w projekt ogromu pracy. Nie do pominięcia jest również potrzeba zatrudnienia testera automatyzującego, który będzie zdolny do zaprojektowania całego systemu tak, aby testy były stabilne i zgodne z dobrymi praktykami programowania.

Typy frameworków do automatyzacji testów

Frameworki do automatyzacji to narzędzia, które ułatwiają to zadanie, dostarczając rozwiązań dla wielu powszechnych problemów. W zależności od potrzeb i specyfiki projektu możemy wybierać spośród różnych typów frameworków. Poniżej krótki opis wybranych z nich.

Library Architecture Framework

Library Architecture Framework (LAF) to jedna z popularnych technik automatyzacji testów oprogramowania. W ramach tej metodyki wykorzystywane są biblioteki z gotowymi funkcjami testowymi, które mogą być wywoływane w kodzie testu. LAF jest często stosowany w przypadkach, gdy testy są skomplikowane i wymagają wielu etapów, a także w sytuacjach, gdy testy muszą działać na różnych systemach operacyjnych i przeglądarkach internetowych.

Ten typ frameworka sprawdza się zwłaszcza w przypadku testów niskiego poziomu, takich jak testy jednostkowe.

Module Based Testing Framework (MBTF)

To rodzaj frameworka do automatyzacji testów oprogramowania, który opiera się na modularnym podejściu do projektowania testów. W tym modelu testy są projektowane w sposób modułowy, a każdy moduł obejmuje jedną funkcjonalność lub przypadki testowe związane z jednym modułem aplikacji. W MBTF moduły testowe są projektowane w taki sposób, by były uniwersalne, mogły być wykorzystywane wielokrotnie dla różnych aplikacji i systemów. Po stworzeniu zestawu modułów można ich użyć w różnych projektach bez potrzeby ponownego pisania kodu.

Linear Automation Framework

Linear Automation Framework to rodzaj frameworka do automatyzacji testów, który opiera się na liniowym podejściu. W LAF testy są projektowane w taki sposób, aby odzwierciedlały procesy biznesowe lub scenariusze użytkowania aplikacji. Oznacza to, że są one wykonywane w sposób sekwencyjny. W tym modelu testy są projektowane jako zestawy kroków, a każdy krok testu jest związany z akcją użytkownika lub wynikiem, który jest oczekiwany w aplikacji. Zaletą Linear Automation Framework jest to, że testy są bardziej zbliżone do rzeczywistych przypadków użycia, co może przyczynić się do znalezienia bardziej życiowych defektów w aplikacji, takich, na które trafiłby użytkownik.

Hybrid Test Automation Framework

To rodzaj frameworka, który łączy w sobie cechy wszystkich wymienionych powyżej podejść. Ten typ umożliwia projektowanie i wykonanie testów w sposób elastyczny i dopasowany do potrzeb projektu. W HTAF testy są tworzone w sposób modularny, podobnie jak w Module Based Testing Framework, ale z większą elastycznością i dostępem do szerokiej gamy narzędzi testowych. Framework ten pozwala na integrację różnych narzędzi i technologii, takich jak Selenium WebDriver, TestNG, Appium, JMeter itp., co pozwala na automatyzację testów w różnych środowiskach, takich jak aplikacje webowe, mobilne, desktopowe i wiele innych.

Atata automation framework

Atata to pełnowartościowy framework do automatyzacji testów, który jest oparty na Selenium WebDriver i zaprojektowany z myślą o aplikacjach internetowych. Został napisany w języku C# i oferuje szeroki zakres funkcjonalności, które ułatwiają automatyzację testów aplikacji internetowych.

Atata – zalety

Dostępność – framework Atata jest w pełni open source’owy i dostępny na platformie GitHub na licencji Apache License 2.0.
Przejrzystość i łatwość użytkowania – jednym z kluczowych elementów Atata Framework jest użycie modelu Fluent Page Object Pattern. Ten wzorzec pozwala na pisanie kodu, który jest łatwy do czytania i zrozumienia. Wbudowany system logowania ułatwia śledzenie i rozwiązywanie problemów podczas testowania.
Triggery – dodatkowo, framework ma unikalną funkcjonalność triggerów, która pozwala na uruchamianie niestandardowego kodu w momencie wystąpienia określonych zdarzeń.
Niski próg wejścia – Atata została zaprojektowana w taki sposób, aby była łatwa w użyciu i utrzymaniu. Framework dostarcza prostą i intuicyjną składnię do definiowania i używania obiektów występujących na stronie. Wymaga to minimalnej ilości kodu, co pozytywnie wpływa na czytelność oraz ułatwia wprowadzenie kolejnych testerów do projektu.
Gotowe komponenty – framework dostarcza również zestaw gotowych do użycia komponentów, które mają ułatwiać pracę. Komponenty te to np. kontrolki, strony i układy. Atata dostarcza szeroki zakres wbudowanych kontrolek, które można wykorzystywać do interakcji z elementami internetowymi na stronie. Kontrolki to np. przyciski, pola tekstowe, pola wyboru, przyciski opcji i wiele, wiele innych.
Data-driven testing – Atata obsługuje również testowanie oparte na danych. Umożliwia testerom tworzenie testów, korzystając z funkcji Data-Driven Testing. Dzięki tej funkcji developerzy mogą uruchamiać ten sam scenariusz testowy z różnymi zestawami danych.
Testowanie równoległe – framework obsługuje również testowanie równoległe. Dzięki funkcji Parallel Testing testerzy mogą uruchamiać wiele testów jednocześnie, co może znacznie zmniejszyć czas potrzebny do przetestowania. Jest to szczególnie przydatne w przypadku dużych aplikacji internetowych, które wymagają rozbudowanej kontroli jakości.

Atata – wady

Mimo swoich wielu zalet Atata Framework ma także pewne wady.

Ograniczone zastosowanie – jedną z głównych wad jest to, że framework jest ograniczony tylko do obsługi stron internetowych. Jest to istotne ograniczenie np. dla firm rozwijających oprogramowanie, które oprócz stron webowych projektują również inne rodzaje aplikacji. W takim przypadku konieczne może być użycie innego narzędzia do automatyzacji testów.
Dostępny wyłącznie z C# – framework ten jest też stworzony tylko dla języka C#, co uniemożliwia wykorzystanie go przez wielu programistów specjalizujących się w innych popularnych językach programowania.
Mała społeczność – kolejną wadą w porównaniu do innych narzędzi służących do automatyzacji testów może być mniejsza społeczność. Framework ten jest stosunkowo nowy, w porównaniu do innych narzędzi, które istnieją na rynku od wielu lat. Musimy się liczyć z mniejszą ilością zasobów i dokumentacji online, a także materiałów pomocy dostępnych dla użytkowników. Na szczęście społeczność użytkowników jest bardzo zaangażowana i gotowa do pomocy. Warto też zaznaczyć, że kontakt z twórcami frameworka jest niezwykle prosty, a komunikacja bardzo sprawna (odpowiedź na większość problemów można uzyskać od samych twórców nawet w 20 minut).

Jednak pomimo tych wad Atata Framework jest nadal jednym z najlepszych narzędzi do automatyzacji testów internetowych w języku C#. Jego liczne zalety sprawiają, że jest on popularny wśród testerów, którzy szukają prostego i intuicyjnego sposobu na automatyzację.

Atata vs Selenium

Na wstępie warto zaznaczyć, że pytanie nie jest do końca adekwatne w kontekście omawianego zagadnienia. Powiem więcej, porównywanie Selenium, do nakładki, jaką stanowi Atata, może się wydawać bezzasadne. Jest to przecież nic innego jak framework przykrywający swoimi funkcjonalnościami bazę, która dostarcza nam niezbędnych, podstawowych narzędzi. Dzięki takiemu zabiegowi dostajemy „ładniejszą” wersję Selenium, przyjemniejszą w użytku i szybszą w implementacji.

Przeczytaj także: Testy E2E – Cypress vs Selenium

Mimo to postanowiłam zebrać istotne różnice w formie tabeli poniżej. Warto być świadomym, jakie korzyści może przynieść zastosowanie takiej nakładki dla całego projektu. Koniec końców przy planowaniu prac projektowych wybór nie jest prosty i im więcej możliwości, tym trudniej podjąć decyzję nawet w obrębie frameworków opierają się na innych, dostępnych już narzędziach.

Atata

Jedną z największych zalet frameworka Atata jest jego użyteczny system logowania, który umożliwia śledzenie i diagnozowanie problemów w trakcie testowania. Atata oferuje także unikalne funkcje, takie jak mechanizm triggerów, który umożliwia wykonywanie niestandardowego kodu w odpowiedzi na określone zdarzenia podczas testowania.

Atata oferuje również intuicyjną składnię do definiowania i używania obiektów strony, co ułatwia programowanie i utrzymanie testów. Wspiera zastosowanie modelu Page Object Pattern, co dla zwolenników tego wzorca jest ogromną zaletą. Struktura jest dzięki temu przejrzysta i łatwiejsza w zrozumieniu.

Framework posiada wbudowany zestaw gotowych komponentów, takich jak kontrolki, strony i układy, co przyspiesza proces automatyzacji testów. Poniżej zamieściłam przykład możliwości, jakie oferuje nam Atata – zawiera nie tylko podstawowe elementy stron jak pola tekstowe, ale rozróżnia też pola przeznaczone dla adresów e-mail, haseł, numerów czy plików. Poza tym, obsługuje listy wyborów, elementy klikalne i wiele, wiele innych. Pełną specyfikację i możliwości można zawsze odnaleźć w bardzo czytelnie napisanej dokumentacji https://atata.io/components/.

using _ = TextBoxPage; //alias for better readability 
    [Url(TextBoxUrl)]      //Url extension to base url placed in SpecFlowHooks.cs 
    [VerifyTitle("ToolsQA")] 
    public class TextBoxPage : BasePage<_>  
    { 
        private const string TextBoxUrl = "/text-box"; 
 
 
        [FindById("userName")] //Selector to find element 
        public TextInput<_> UserNameTextBoxInput { get; set; } //An element with its type and name 
 
 
        [FindById("userEmail")] 
        public EmailInput<_> UserEmailTextBoxInput { get; set; } 
 
 
        [FindById("currentAddress")] 
        public TextArea<_> CurrentAddressTextBoxTextArea { get; set; } 
 
 
        [FindById("permanentAddress")] 
        public TextArea<_> PermanentAddressTextBoxTextArea { get; set; } 
 
 
        [FindById("submit")] 
        public Button<_> SubmitTextBoxButton { get; set; } 
        
        [FindById("output")] 
        public Text<_> TextBoxOutputBox { get; set; } 
 
 
        [FindById("name")] 
        public Text<_> TextBoxOutputName { get; set; } 
 
 
        [FindById("email")] 
        public Text<_> TextBoxOutputEmail { get; set; } 
 
 
        [FindById("currentAddress")] 
        public Text<_> TextBoxOutputCurrentAddress { get; set; } 
 
 
        [FindByXPath("output")] 
        public Text<_> OutputBox { get; set; } 
 
 
        [FindById("permanentAddress")] 
        public Text<_> TextBoxOutputPermanentAddress { get; set; } 
    }

Zastosowanie gotowych komponentów

Mimo ogromu możliwości zdarza się jednak, że brakuje nam komponentu lub niemożliwe jest zastosowanie gotowego rozwiązania, które oferuje Atata. Na szczęście twórcy nie odebrali nam możliwości sensownego dostępu do czystej wersji Selenium i bez przeszkód możemy wyszukiwać nasze elementy lub stosować określone akcje wobec nich. Poniżej przykład wywołania WebDrivera.

  public class ProjectDetailsPage : BasePage 
    { 
        public int findGarageParkingPlaces() 
        { 
            var element = AtataContext.Current.Driver.FindElement(By.XPath("//div[contains(text(),'Garage Parking Places')]")); 
            return int.Parse(element.FindElement(By.ClassName("value")).Text); 
        } 
    }

Wywołanie AtataContext.Current.Driver

Dla fanów raportów i tabelek również znajdzie się tu przydatna funkcja. Atata oferuje wbudowane narzędzie do wykonywania zrzutów ekranu według wybranego wzoru np. po wykonaniu każdego kroku. Jeżeli połączymy t funkcję z biblioteką do tworzenia raportów np. ExtendedReports otrzymujemy bardzo przyjemne środowisko do generowania raportów w formie pliku .html.

Po uruchomieniu testów mamy natychmiastowy wgląd w wyniki wraz ze statystykami, zaznaczonymi błędami, tagami i wykresami. Na pierwszy rzut oka można powiedzieć, że takie dane oferuje nam również samo IDE, jednak forma zestawienia ich przez tą bibliotekę jest dużo czytelniejsza i przyjemniejsza dla oka. Po drobnych zmianach w celu dostosowania się do potrzeb projektu dostajemy raport, który możemy przedstawić podczas spotkań biznesowych bez dużego nakładu pracy.

Przykład raportu

  [Screenshot(AfterAnyAction)] 
    public abstract class BasePage : Page 
        where TOwner : BasePage 
    { 
        //Some general helping methods that can be used in all pages 
        public int[] GetElementSize(Text element) 
        { 
            return new int[2] { element.ComponentSize.Width.Value, element.ComponentSize.Height.Value }; 
        } 
         
        public void AcceptAlert() 
        { 
            AtataContext.Current.Driver.SwitchTo().Alert().Accept(); 
        } 
 
 
        public string GetAlertMessage() 
        { 
            return AtataContext.Current.Driver.SwitchTo().Alert().Text; 
        } 
    }

Przykład dodawania zrzutów ekranu do raportu

Intuicyjnie zostało rozwiązane też zagadnienie dotyczące nawigowania między stronami aplikacji w trakcie jednej sesji. W załączonym niżej przykładzie można zauważyć, że wystarczy zastosować funkcję Go.To (idź do) lub On (pozostań na stronie). Wystarczy przesłać odpowiedni adres strony do metody – nie ma konieczności otwierania i zamykania sesji w odpowiedni sposób tak, jak ma to miejsce przy użyciu Selenium bez nakładki. Przyczynia się to do znacznych oszczędności czasu przy konfiguracji środowiska.

 [Binding] 
    public sealed class TextBoxSteps : BaseSteps 
    { 
        private readonly ScenarioContext _scenarioContext; 
 
 
        [Obsolete("Visual Studio IntelliSense Work Around", true)] 
        public TextBoxSteps(ScenarioContext scenarioContext) 
        { 
           _scenarioContext = scenarioContext;   //Initializing scenario context, you can save test session data in it 
           SetRandomUser(_scenarioContext);      //Creating new fake user data and saving it in context so it can be used in multiple tests without generating new set  
        } 
 
 
        [When(@"User input all personal data on address form page")] //SpecFlow binding to feature files, methods are named the same as scenario steps  
        public void WhenUserInputAllPersonalDataOnAddressFormPage() 
        { 
            Go.To()                 //Open page    
                .UserNameTextBoxInput.Set(User.FirstName + " " + User.LastName) //Make actions on web elements from page you just opened eg. set -> input text  
                .UserEmailTextBoxInput.Set(User.Email) //User.Email is a reference to our generated fake data 
                .CurrentAddressTextBoxTextArea.Click() 
                .CurrentAddressTextBoxTextArea.Set(User.Country) 
                .PermanentAddressTextBoxTextArea.Set(User.Country); 
        } 
 
 
        [When(@"confirm the data by clicking button")] 
        public void WhenConfirmTheDataByClickingButton() 
        { 
            On()                     //On already opened page 
                .SubmitTextBoxButton.Click(); 
        } 
 
 
        [Then(@"user should see provided data below")] 
        public void ThenUserShouldSeeProvidedDataBelow() 
        { 
            On() 
                .TextBoxOutputBox.Should.BeVisible()  //Should is assertion verification if something is as you wanted 
                .TextBoxOutputName.Content.Should.Contain($"Name:{User.FirstName} {User.LastName}") 
                .TextBoxOutputEmail.Content.Should.Contain($"Email:{User.Email}") 
                .TextBoxOutputCurrentAddress.IsVisible.Should.BeTrue() 
                .TextBoxOutputCurrentAddress.GetContent(ContentSource.Value).Should.Contain(User.Country) 
                .TextBoxOutputPermanentAddress.GetContent(ContentSource.Value).Should.Contain(User.Country); 
        } 
    }

Przykład nawigowania po stronach (Go.To oraz On), ponownie wklejam pełny kontekst klasy

Niestety, framework ten powstał tylko dla języka programowania C#, co jest poważnym ograniczeniem względem Selenium, które działa również z Javą czy Pythonem.

Który framework do automatyzacji testów będzie najlepszy dla mojego projektu?

Wybór frameworka do automatyzacji testów zależy od wielu czynników, takich jak rodzaj projektu, wymagania biznesowe, preferencje programistów i dostępne zasoby. Oto kilka kroków, które mogą pomóc w wyborze najlepszego frameworka dla twojego projektu:

Określ swoje wymagania

Przed podjęciem decyzji o wykorzystaniu danego frameworka do automatyzacji testów musisz wiedzieć, jakie są twoje wymagania. Na przykład, jeśli twój projekt zakłada rozwój aplikacji webowej, to framework, który wspiera testowanie interfejsów użytkownika, może być najlepszym wyborem. Nie ma sensu też wybierać technologii, która wspiera dodatkowo inne rodzaje aplikacji kosztem tego, który nas interesuje.

Znajdź odpowiednie narzędzia

Skonsultuj się z programistami i testerami, którzy mają doświadczenie w automatyzacji testów, i poproś ich o zalecenia co do narzędzi. Zbierz informacje o różnych frameworkach, ich funkcjonalnościach, ograniczeniach i zasobach społecznościowych.

Przetestuj frameworki

Przetestuj wybrane frameworki w praktyce. Przygotuj zestaw testów, które są reprezentatywne dla twojego projektu, i zaimplementuj je w każdym z frameworków. Analizuj, jakie frameworki są najbardziej intuicyjne i proste w użyciu.

Sprawdź integrację

Jeśli rozwijana aplikacja używa zewnętrznych narzędzi, upewnij się, że framework, który wybierzesz, integruje się z nimi. Na przykład, jeśli korzystasz z platformy Continuous Integration, upewnij się, że framework, który wybierzesz, posiada dla niej plugin.

Zwróć uwagę na dostępność dokumentacji i wsparcia społeczności

Wybierz framework, który ma dobrą dokumentację i szeroką społeczność użytkowników. To pomoże w rozwiązywaniu problemów technicznych, jakie możesz napotkać podczas pracy z frameworkiem.

Podsumowanie

Podsumowując, wybór frameworka do automatyzacji testów zależy od wielu czynników i nie ma jednoznacznej odpowiedzi na pytanie, który z nich sprawdzi się w twoim projekcie. Obecnie na rynku jest dostępnych wiele typów frameworków, musisz więc zbadać różne opcje i wybrać ten, który najlepiej odpowiada twoim wymaganiom i specyfice projektu.

Mam nadzieję, że tym artykułem udało mi się też przybliżyć możliwości stosunkowo nowego narzędzia, jakim jest Atata. Choć Selenium jest jednym z bardziej popularnych i cenionych narzędzi, warto poznawać inne opcje. Atata jest ciągle rozwijana przez społeczność programistów, co oznacza, że każdy może przyczynić się do usprawnień, zgłaszając błędy, wprowadzając ulepszenia lub pisząc dokumentację. W ten sposób Atata staje się coraz lepszym narzędziem.

Testuj przed wszystkimi, czyli shift-left testing w praktyce

Mariusz Skomra — Mon, 12 Dec 2022 06:09:00 +0000

Spis treści:

1. Scrum czy Scrumfall?
2. Shift-left – co to takiego?
3. Środowisko produkcyjne
4. Środowisko testowe
5. Środowisko developerskie
6. Analiza biznesowa i ustalanie wymagań
7. Czy można testować jeszcze wcześniej?
8. Shift-left testing – co nam to daje?
9. Shift-left – dlaczego u nas działa?

Scrum czy Scrumfall?

W klasycznych metodykach wytwarzania oprogramowania, takich jak Waterfall, proces testowania oprogramowania następuje po fazie jego zaprojektowania i wytworzenia. Tym samym obiektem poddawanym testowaniu jest gotowy, ostateczny produkt. Głównymi problemami, jakie to rodzi, są długi czas naprawy błędów, ich wysoki koszt, a także ryzyko, iż wprowadzone zmiany wpłyną na inne funkcjonalności (co z kolei niesie za sobą konieczność ponownego wykonania wszystkich testów, a tym samym wydłużeniu ulega cały proces).

W ostatnich latach state-of-the-art w wytwarzaniu oprogramowania są tzw. metodyki zwinne (Scrum, Kanban itp.). Dzięki iteracyjnemu podejściu procesowi testowania nie jest poddawany cały, gotowy produkt, lecz jego fragmenty będące rozwinięciem poprzedniej wersji, niebędące jednak jego ostateczną wersją.

Niestety, niepoprawne wdrożenie metodyk zwinnych również niesie ryzyko powtórzenia powyżej opisanych błędów. Przykładem niech będzie jeden z moich wcześniejszych projektów, gdzie w czasie trwania Sprintu był wyraźny podział na fazę omawiania zadań, development, a następnie testowanie. Czym się kończył taki Scrumfall pod koniec Sprintu?

Testerzy mieli mało czasu na wykonanie testów (bo development zadania się przedłużył),
Developerzy mieli mało czasu na wykonanie ewentualnych poprawek (bo testerzy potrzebowali czasu na testy),
Product Owner sugerował, aby niekiedy przymknąć oko na testy (bo trzeba oddać, a przetestować można później),
Klient zastanawiał się, czy testerzy są potrzebni na cały etat (bo przecież w pierwszym tygodniu Sprintu nic nie robią).

Dodatkowo dochodziło do sytuacji, gdzie na etapie testowania okazywało się, że developer zrozumiał zadanie w jeden sposób, tester w drugi, a klientowi chodziło o coś zupełnie innego. Tym samym zadanie, które było uznawane za „prawie skończone” stawało się zadaniem „do omówienia” (co wydłużało proces jego dostarczenia).

Shift-left – co to takiego?

Nie tylko błędne zrozumienie Agile w organizacji może zwiększać ryzyko niepowodzenia w projekcie. Problem planowania czasu na testy oprogramowania pojawia się w wielu projektach bez względu na stosowaną metodykę. Okazuje się jednak, że istnieje podejście, które może być jeśli nie „lekiem na całe zło”, to na pewno środkiem łagodzącym objawy nieumiejętnego rozplanowania prac w projekcie. Mowa tu o shift-left testing. To podejście mówiące o tym, żeby proces testowania zaczynać na jak najwcześniejszym etapie wytwarzania oprogramowania.

Przejdźmy teraz przez wszystkie etapy wytwarzania oprogramowania i odpowiedzmy sobie na pytania:

„Czy to jest wystarczająco wcześnie na testy? A jeżeli nie, to dlaczego?”.

Środowisko produkcyjne

Pytanie o testy na produkcji zawsze jest dyskusyjne i niejednokrotnie prowadzi do odpowiedzi: „To zależy”. Czy warto testować na tym etapie? Moim zdaniem tak. Jednakże mówimy tu wówczas o tzw. smoke testach. Za ich pomocą sprawdzamy jedynie, czy kluczowe ścieżki działają. Szczegółowe testy powinny zostać wykonane na wcześniejszych etapach – o ile jest to możliwe. Kiedy nie jest? Przykładowo: serwis należy do zewnętrznego dostawcy i na niższych środowiskach jest on mockowany. Kolejny przykład: wysyłamy zapytanie do innego serwisu, którego baza produkcyjna jest 1000-krotnie większa niż na środowisku testowym (kilkanaście milionów obiektów vs kilkanaście tysięcy), co znacząco wpływa na rozmiar otrzymywanych danych i ich liczbę. Jeszcze innym przykładem testów na produkcji mogą być np. testy konfiguracji. W jednym z projektów dostaliśmy zadanie, aby zmienić sposób budowania aplikacji. Z poziomu użytkownika nic się nie zmieniło. Dla zespołu developerskiego zmieniło się wszystko, gdyż wdrożone zostało nowe narzędzie wraz z nową konfiguracją. Dodatkowo okazało się, że jego konfiguracje nieco różniły się na każdym ze środowisk.

Środowisko testowe

Środowisko testowe to środowisko starające się odzwierciedlić w jak największym stopniu środowisko produkcyjne. Wykonujemy na nim testy regresji (w postaci testów automatycznych uruchamianych co noc), które mają nie tylko sprawdzić jak najszerszy zakres funkcjonalności naszej usługi, ale też jej integrację z innymi serwisami. Takie podejście pozwala nam upewnić się, że najnowsza wersja aplikacji może być wydana na produkcję. Jednakże ten etap procesu wytwarzania również nie jest najwcześniejszym, na jakim wykonujemy testy. Traktujemy go bardziej jako element pewnego rodzaju „double check”, dodatkowego sprawdzenia zmiany. Takie podejście wynika z faktu, iż proces naprawy błędu zajmuje sporo czasu ze względu na konieczność stworzenia nowej wersji kodu z poprawką, poddania jej procesowi code review, scalenia oraz wydania nowej wersji aplikacji.

Środowisko developerskie

To środowisko wykorzystywane jest przez developerów podczas codziennego wytwarzania oprogramowania. Charakteryzuje się tym, iż wdrożona na nim wersja aplikacji może zmieniać się bardzo często (nawet kilkukrotnie w ciągu dnia) oraz tym, iż nie musi ona działać poprawnie (stabilnie). Jednakże właśnie ze względu na bardzo krótki czas wdrażania zmian jest to również wyśmienite miejsce do przeprowadzania testów funkcjonalnych (zarówno wstępnych, jak i całościowych) oraz zgrubnych testów regresji. Dzięki testom na tym środowisku, jako tester, w bardzo krótkim czasie jestem w stanie powiedzieć, czy dana wersja może wejść na środowisko testowe, czy jednak wymaga zmian. Niekiedy zmiany te wprowadzane są niemalże w czasie rzeczywistym – developer obserwuje zachowanie aplikacji podczas testów, analizuje przyczynę problemu, wprowadza poprawkę, a następnie wykonywany jest retest, który sprawdza, czy wszystko działa. Takie podejście zdecydowanie skraca czas otrzymania informacji zwrotnej od testera. Skraca również proces code review, ponieważ oddawany kod działa tak, jak powinien, i nie trzeba go modyfikować celem poprawy błędów (co tylko wydłużyłoby jego przegląd).

Analiza biznesowa i ustalanie wymagań

Czy można testować dokumentację bądź wymagania biznesowe? Oczywiście! Bardzo często spotykam się z sytuacją, kiedy ustalane są cele zadań i ich zakres, wszyscy mówią, że rozumieją i wiedzą, co ma być zrobione, po czym padają pytania: „A czy to nie wpływa na inny obszar aplikacji?”, „A czy ta logika na pewno jest zgodna z wymaganiami innych serwisów?”, „A czy wiemy, skąd te dane mamy pobrać?”, „A czy mamy makiety i tłumaczenia tekstów?”. I nagle okazuje się, że zadanie, które już zostałoby wzięte w zakres Sprintu – jest z niego usuwane lub zostaje zablokowane celem dalszych wyjaśnień. Gdyby nie to, to bardzo prawdopodobna byłaby sytuacja, w której te pytania zostałyby zadane już w trakcie developmentu. A to skutkowałoby przedłużonym czasem rozwoju oprogramowania lub nawet niedostarczeniem funkcjonalności.

Czy można testować jeszcze wcześniej?

Wydawać by się mogło, że określanie wymagań biznesowych to najwcześniejszy etap procesu wytwarzania oprogramowania, w którym możliwe są testy oprogramowania. A co za tym idzie – nie da się przesunąć testowania bardziej w lewo. Otóż… nie jest to do końca prawda. Na konferencji TestWarez 2019 Marcus Merrell w swoim wystąpieniu „Shift Left, Shift Right – Why These Buzzwords Matter” powiedział, że kolejnym przesunięciem testowania na wcześniejszy etap jest… środowisko produkcyjne. Ale jak to? Testowanie na produkcji? Otóż nie testowanie, a monitorowanie. A następnie wyciąganie wniosków i tworzenie na ich podstawie nowych zadań mogących usprawnić działanie systemu.

Przykładowo: w naszym projekcie jedną z metryk, jakie zbieramy i analizujemy, jest rodzaj błędów biznesowych występujących w aplikacji. Gdy któryś błąd zaczyna się pojawiać dużo częściej, badamy, co jest jego przyczyną, i zastanawiamy się, co możemy zrobić, aby zredukować jego występowanie.

Shift-left testing – co nam to daje?

Najbardziej oczywistą i podkreślaną przez wszystkich zaletą podejścia shift-left testing jest wykrycie błędów na wczesnym etapie developmentu. Niemniej podejście to, w projekcie, jaki realizujemy w Inetum dla klienta z obszaru e-commerce, przynosi też inne zalety. Oto one:

Wczesna automatyzacja

W dyskusjach o automatyzacji testów bardzo często pojawia się pytanie: „Kiedy zacząć automatyzować?”. Moja odpowiedź zawsze brzmi: „Jak najwcześniej”. Przykładowo – zadanie polega na wprowadzeniu nowego pola do formularza oraz dodaniu nowych walidacji. Czy muszę czekać, aż developerzy przygotują backend i frontend, abym mógł zacząć testować manualnie, a następnie stworzyć testy automatyczne? Nie. Na podstawie opisu zadania tworzę przypadki testowe , jakie będą wykonane, wybieram te, które zostaną zautomatyzowane, a następnie przygotowuję kod testów. W efekcie, kiedy developer oddaje mi zadanie do testów, bardzo często wystarczy, że uruchomię taki kod i w bardzo krótkim czasie dostanę informację, czy funkcjonalność działa zgodnie z założeniami, czy nie (niekiedy wręcz nie muszę wykonywać testów manualnych, ponieważ automatyczne pokryją wszystkie przypadki, a na dodatek będą szybsze i dokładniejsze).

Podwójne sprawdzenie

Automatyzacja na wczesnym etapie niesie ze sobą dodatkową zaletę, jaką jest podwójne sprawdzenie funkcjonalności. Tzn. zmiana testowana jest na środowisku developerskim, kod jest scalany, nowa wersja aplikacji jest wydawana i wgrywana na środowisko testowe. Przygotowane testy automatyczne mają dać takie same wyniki na obu środowiskach. Czy tak się dzieje? Zazwyczaj tak. Niestety, w projektach zdarzały się sytuacje, kiedy jednego dnia scalonych zostało kilka różnych zmian, co w efekcie spowodowało niepoprawne działanie już przetestowanych funkcjonalności. Na szczęście codzienne uruchamianie testów pozwoliło nam na szybkie wykrycie tego problemu i jego poprawę.

Większa świadomość znaczenia testów

W dzisiejszym świecie bardzo często podkreśla się znaczenie testów w procesie wytwarzania oprogramowania. A jak jest naprawdę? Różnie. Pokuszę się o stwierdzenie, że co zespół, to inne podejście. W moim obecnym projekcie początkowo tryb pracy był… typowy tzn. developer zaczynał pracę nad zadaniem, przygotowywał zmianę, kod przechodził proces code review, wydawana była nowa wersja aplikacji i zadanie przechodziło w etap testów. Po kilku miesiącach pracy ten proces się znacząco zmienił. Wypracowaliśmy podejście, w którym przed przesunięciem zadania do code review kod jest sprawdzany przez QA.

Shift-left – dlaczego u nas działa?

Czy podejście shift-left zadziała zawsze i w każdym zespole?

Moim zdaniem nie. Dlaczego u nas się sprawdza? Jest kilka powodów:

Wszystkie osoby tworzą zespół developerski. Nie mamy sytuacji, w których np. zespół dostaje zadania do wykonania bez wcześniejszych konsultacji czy testerzy i developerzy tworzą osobne zespoły bez bieżącego kontaktu ze sobą. Każdy ma wygląd w zadania i może zgłosić swoje uwagi na każdym etapie pracy.
Odpowiednia infrastruktura. Jako zespół developerski nie musimy angażować swojego czasu w tworzenie infrastruktury, środowisk itp. Wszystko to przygotowywane jest przez osobny, dedykowany do tego zespół. My zgłaszamy zapotrzebowanie na zasoby, a następnie dostajemy działające rozwiązania.
Dojrzałość zespołu. Zespół tworzony jest przez osoby, które mają doświadczenie w pracy zarówno w dobrze zorganizowanych projektach, jak i takich, które nie mogą zostać określone tym mianem. Tym samym wszelkie nasze doświadczenia („Wtedy robiliśmy tak i tak, i to powodowało, że mieliśmy problemy z tym i tamtym”) pozwalają nam teraz ustalić dużo lepszy proces developmentu i testowania. Dodatkowo wiemy, że swoboda naszego działania jest akceptowana, póki dostarczamy produkt wysokiej jakości. Dlatego też wszystkim zależy, aby błędy wykrywane były jak najszybciej.

Testy E2E – wprowadzenie do Cypress

Sebastian Szemer — Wed, 09 Nov 2022 12:35:25 +0000

Przejdź do:

1. Czym jest Cypress?
2. Wykorzystanie dodatkowych bibliotek
3. Cypress vs Selenium
4. Nasz pierwszy test w Cypress
5. Zalety Cypressa
6. Wady Cypressa
7. Podsumowanie: czy Cypress jest frameworkiem dla każdego?

Czym jest Cypress?

Cypress to framework open source do tworzenia testów end-to-end i testów komponentów aplikacji webowych. Stworzony przez frontend developerów dla frontend developerów, dzięki swojej prostocie i przyjaznemu debuggerowi stał się popularny także w świecie testerskim.

Jego główne zalety to czytelna składnia oraz łatwa instalacja, po której od razu możemy pisać pierwsze testy i tym samym łatwo zweryfikować działanie aplikacji. Cypress cechuje się szybkością pisania i wykonywania testów, zapewniając przy tym ich niezawodność dzięki automatycznemu czekaniu na elementy na stronie.

Wykorzystanie dodatkowych bibliotek

Stos Cypressa korzysta z kilku dość popularnych bibliotek testowych do asercji czy generowania raportów. Są to:

Mocha – pozwala zbudować raport JUnit lub TeamCity. Istnieje mnóstwo pluginów do biblioteki Mocha, dzięki czemu z pewnością wygenerujemy raport w formacie, jakiego potrzebujemy.
Chai – wbudowana biblioteka do asercji.
Sinon – framework, którego metody Cypress wykorzystuje w cy.spy, cy.stub, czyli w monitorowaniu wywołań funkcji.

Jest kilka pluginów, które nie są wbudowane, ale uważam, że warto je zainstalować. Mam na myśli m.in.:

Cypress-recurse – plugin ułatwiający pisanie funkcji rekurencyjnych.
Cypress-tab – plugin dodający możliwość wysyłania klawisza ‘TAB’ do przeglądarki.
Cypress-xpath – w Cypress szukamy elementów za pomocą selektorów CSS, ten plugin pozwoli korzystać z xpath.

Cypress vs Selenium

To nie jest tak, że jakieś rozwiązania są lepsze lub gorsze, ale wszyscy wiemy, że Selenium jest po prostu przestarzałe i nie radzi sobie najlepiej w przypadku witryn internetowych z nowoczesnym frontem, gdzie elementy w DOM są dynamicznie podmieniane zamiast ładowania całego DOM od nowa.

To największa wada Selenium i głównie w kontrze do niej powstał Cypress, stawiając na stabilność testów nowoczesnych aplikacji frontendowych. Początkowo miał być wsparciem dla frontend developerów piszących testy integracyjne, dziś skupia się na testach end-to-end i testach komponentów. Dzięki przejrzystej składni narzędzie szybko zdobyło zaufanie wielu testerów.

Przeczytaj również: Piramida testów: dowiedz się, jak testować, żeby testy przynosiły zysk.

Selenium ma sporą przewagę, jeśli chodzi o obsługiwane języki programowania. Jest ono dostępne dla Javy, Pythona, C#, JavaScript i Ruby. Cypress z założenia obsługuje tylko JavaScript (po konfiguracji także TypeScript), co może być problemem, gdy w zespole bądź firmie brakuje odpowiednich kompetencji.

Selenium jest na rynku od lat i choć ma wiele wad, to są one dobrze znane, a internet jest pełen poradników, jak sobie z nimi radzić. Selenium wyznaczyło pewien standard i przez lata wiodło prym w automatyzacji testów aplikacji przeglądarkowych, ale nowe czasy wymagają nowych rozwiązań, a Cypress z pewnością jest godny uwagi.

Testy w Cypress są wykonywane szybko i stabilnie, a ich pisanie to, moim zdaniem, wręcz przyjemność (w przeciwieństwie do Selenium, wystarczy stworzyć lokator i można na obiekcie wykonywać akcje – w Selenium trzeba mieć lokator i Factory, żeby to działało).

Obsługuje on wszystkie najważniejsze przeglądarki, takie jak Chrome, Edge, Firefox czy nawet Webkit. Co ciekawe, do wyboru mamy też Brave, a domyślną przeglądarką jest Electron. Przeglądarki te są zawarte w pakiecie, więc nie trzeba o nie dbać, jak w przypadku Selenium. Należy jednak pamiętać o aktualizacji Cypressa, jeśli chcemy mieć ich najnowsze wersje.

Nasz pierwszy test w Cypress

Aby zacząć pisać test w Cypress, możemy użyć aplikacji standalone (do pobrania na oficjalnej stronie Cypress.io) lub stworzyć projekt poprzez komendę npm (po uprzedniej instalacji):

mkdir cypress 
cd cypress 
npm init 
npm install cypress --save-dev

Po pierwszym uruchomieniu utworzony zostaje folder /cypress – a w nim kolejne:

do przechowywania testów e2e,
fixtures dla wszelkich testaliów,
downloads, screenshots,
oraz support dla różnych helperów.

Otwieramy więc Test Runner, wybieramy typ testów e2e i wybieramy domyślną przeglądarkę.

npx cypress open

Następnie stworzymy nowy plik firstSpec.cy.js w folderze e2e, a w jego treści umieszczamy poniższy kod, który otwiera stronę, wprowadza nazwę użytkownika i hasło, loguje do aplikacji, a następnie weryfikuje skuteczność zalogowania poprzez sprawdzenie widoczności elementu.

describe('My First Test', () => { 

  it('Does not do much!', () => { 

    cy.visit('http://zero.webappsecurity.com/login.html');  
    cy.get('#user_login').type('username');  
    cy.get('#user_password').type('password'); 
    cy.get('[name="submit"]').click(); //klikamy submit 
    cy.get('#account_summary_tab').should('be.visible'); 

  }) 

});

Test możemy uruchomić w konsoli przy pomocy komendy:

npx cypress run

lub w debuggerze:

npx cypress open

Zalety Cypressa

Prosta instalacja

Jeśli kiedykolwiek konfigurowaliście JBehave, to z pewnością docenicie prostotę instalacji Cypressa i to, jak szybko można po niej zacząć pisać wartościowe testy. Nie oferuje tego żaden inny, nawet najbardziej nowoczesny, framework do testów e2e w przeglądarce.

Niski próg wejścia

Mimo że Cypress działa tylko w połączeniu z JavaScript, wcale nie jest to dużą przeszkodą dla chcących z niego korzystać. Sam nie miałem z JavaScript wiele wspólnego, poznając Cypress. Jednak aby zacząć pisać testy, wystarczy poznać podstawowe komendy, których składnia jest bardzo prosta i naturalna. Możliwość łączenia komend pozwala na synchroniczne ich wykonanie, co sprawia, że testy są nadzwyczaj stabilne (dla przykładu, klikamy w dany input, czyścimy jego zawartość, wpisujemy text, po czym klikamy button i weryfikujemy, czy owy button zmienił swój text).

Sprawdzanie stanu elementów

Cypress domyślnie sprawdza, czy szukany element znajduje się w DOM, czy jest widoczny, zakończył animacje. Pozwala to usunąć z testu zbędny kod związany z czekaniem, a jeśli jakiś element ładuje się dłużej, to po prostu zwiększamy danej komendzie timeout. Dzięki temu testy są jednocześnie czytelne i stabilne.

Narzędzia

Jedną z moich ulubionych cech Cypressa jest to, że dostarcza sporo narzędzi przydatnych w testach, jak cy.fixture czy cy.intercept. Pierwsze pozwala na zarządzanie danymi testowymi czy to PDF, który chcemy wgrać do aplikacji, czy to plik JSON z payloadem do API bądź danymi testowymi w podejściu DDD. Drugie zaś pozwala na przechwytywanie ruchu sieciowego, a nawet mockowanie odpowiedzi z backendu. Jest to wielce przydatne, gdy czekamy na odpowiedź z API, która ma zasilić danymi front, lub gdy dostawca zewnętrzny nie odpowiada i chcemy jego odpowiedzi zmockować.

Debugger GUI

Po tym narzędziu widać, że Cypress został napisany przez frontend developerów. Ma świetny interfejs użytkownika (UI) łączący ze sobą możliwość uruchamiania i debugowania testów. Tworzenie snapshotów stanu aplikacji po każdej akcji daje nam możliwość odbycia „podróży w czasie” po różnych etapach trwania naszego testu. Dostęp do narzędzi developerskich pozwala podejrzeć np. ruch sieciowy. Wszystko to daje nam komplet narzędzi niezbędnych do szukania błędów.

Wady Cypressa

Mimo wielu plusów Cypress ma też swoje wady i nie można obok nich przejść obojętnie, jeśli jesteśmy na etapie wybierania najlepszego rozwiązania dla projektu.

Testowe post mortem

Chyba każdy doświadczył tego, jak uciążliwe może być debugowanie testu nieprzechodzącego w środowisku CI/CD. Pod tym względem Cypress oferuje nam nagranie video, zrzut ekranu, a w logach – error message. O ile w wielu przypadkach okazuje się to wystarczające, to bywa uciążliwe, kiedy chcemy prześledzić chociażby ruch sieciowy. W Selenium wcale nie było pod tym względem lepiej – moim osobistym faworytem jest Playwright ze swoimi trace’ami. Cypress to domyślnie narzędzie z GUI i to na nim najłatwiej debugować testy.

Wielowątkowość

Cypress chwali się wsparciem dla równoległego wykonywania testów. Nie jest ono jednak włączone domyślnie i wymaga nieprostej konfiguracji w CI/CD. W ten sposób możemy tworzyć wiele kontenerów, z których każdy wykona jeden wątek testów (podobnie do Selenium Grid). W porównaniu z Playwright, gdzie testy domyślnie uruchamiają się w wielu wątkach, albo nUnit, gdzie taka konfiguracja to jedna linijka kodu, to dość rażące niedociągnięcie.

Wątpliwe wsparcie dla BDD

Sam w sobie Cypress nie wspiera BDD, za to polega na zewnętrznych pluginach bazujących na cucumber-js. Oficjalnie wspierany cypress-cucumber-preprocessor przestał być rozwijany i musimy się posilać różnymi klonami precyzyjnie wybranymi dla naszej konkretnej wersji Cypressa.

Podsumowanie: czy Cypress jest frameworkiem dla każdego?

Cypress skraca czas pisania testów e2e dzięki swojej składni i narzędziom, jakie oferuje. Pisanie testów w Cypress to sama przyjemność i nie powinno sprawić problemów nawet początkującym użytkownikom. Debugowanie błędów lub bardziej zawiłe konfiguracje mogą się jednak okazać trudniejsze, niżbyśmy chcieli.

Jeśli potrzebujemy więc w krótkim czasie napisać testy na potrzeby danego projektu i nie jest ich dużo, to śmiało możemy użyć Cypressa. Jego bezproblemowa konfiguracja i prosta składnia wybaczą niedobory wiedzy o JavaSripcie. Proste rzeczy w Cypressie są… naprawdę proste. Jeśli jednak projekt jest bardziej wymagający, to i bardziej wymagająca będzie konfiguracja Cypressa, środowiska uruchomieniowego czy licznych pluginów, niekoniecznie zgodnych z najnowszymi wydaniami Cypressa. Jeśli JavaScript nie jest wam jednak obcy, to Cypress może się okazać nowym rozwiązaniem dla waszego projektu.

Przykładowy kod możecie znaleźć na moim Githubie:
https://github.com/sszemer/cypress.io

Co łączy testera z branżą filmową? Czyli scenariusze testowe bez tajemnic

Paweł Chojnacki — Wed, 28 Sep 2022 05:54:39 +0000

Jak scenariusz testowy pomaga na późniejszych etapach pracy rozwoju oprogramowania? Jak pisać scenariusze testowe? Czym różnią się scenariusze testowe i przypadki testowe? Sprawdźmy!

1. Inny rodzaj scenariusza, czyli kilka słów o scenariuszach testowych
2. Czym jest scenariusz testowy?
3. Kilka słów o przypadkach testowych
4. Przepis na przypadek testowy
5. Przykład scenariusza testowego
6. Podsumowanie

Inny rodzaj scenariusza, czyli kilka słów o scenariuszach testowych

Czy są jakieś podobieństwa między scenariuszem filmowym a scenariuszem testowym? Owszem, można pewne zauważyć. Scenariusz filmowy opisuje zwykle pewną fabułę, historię – scenariusz testowy również, ale bardziej w aspekcie technicznym. Przedstawia on zazwyczaj listę wykonywanych akcji w danym oprogramowaniu – historię użytkownika, który porusza się np. po aplikacji webowej, mobilnej lub desktopowej. Jest to bardzo ważny rodzaj dokumentacji, dzięki której testerzy oprogramowania mogą zweryfikować, czy dane oprogramowanie działa poprawnie, sprawdzić działanie dostępnych funkcji i upewnić się, czy system spełnia wymogi stawiane przez klientów.

Przeczytaj także: Testowanie oprogramowania: co warto wiedzieć?

Czym jest scenariusz testowy?

Zacznijmy od definicji scenariusza testowego ISTQB. Według niej jest to:

„Dokument zawierający sekwencję działań wymaganych do wykonania testu. Znany również jako skrypt testowy lub manualny skrypt testowy”.

Tworzenie scenariusza testowego polega na:

Identyfikacji scenariusza testowego
Stworzeniu wykazu czynności przygotowawczych scenariusza testowego
Stworzeniu wykazu przypadków testowych
Stworzeniu wykazu czynności końcowych

Ale po co pisać scenariusz testowy? Przecież logowanie do aplikacji jest proste…

Często można się spotkać z opiniami osób, które twierdzą, że tworzenie tego typu dokumentacji, jaką jest scenariusz testowy, jest bezużyteczne. Argumenty? „Logowanie jest przecież dziecinnie proste, to jest rzecz oczywista, a rozpisywanie tego wszystkiego to strata czasu…”. Ja sam, pracując w branży testerskiej w różnych projektach, spotkałem się z tego typu tokiem myślenia.

Zalety posiadania scenariuszy testowych

Tworzenie dokładnych, przemyślanych, dobrze zaprojekowanych scenariuszy testowych jest jak najbardziej potrzebne i przynosi wiele korzyści. Najważniejsze z nich:

przejrzyste scenariusze testowe są doskonałą pomocą dla nowo zatrudnionych w firmie testerów. Dzięki nim proces zapoznania się z daną aplikacją oraz wdrożenia do projektu jest o wiele szybszy,
dobrze przygotowany scenariusz jest świetną podstawą do manualnych testów regresji (jeśli scenariusz nie jest zautomatyzowany). Trzymając się danego scenariusza, tester wykonuje zawsze te same kroki, co pozwala zachować powtarzalność testów. Bez scenariusza testowego byłoby trudno zapamiętać całą historię użytkownika i testowanie oprogramowania stałoby się chaotyczne,
scenariusze testowe są często bazą do późniejszej automatyzacji danej historyjki użytkownika. W oparciu o taką dokumentację znacznie łatwiej jest implementować testy automatyczne z gwarancją, że nie pominie się ważnych części systemu.

Miniscenariusz testowy, czyli kilka słów o przypadkach testowych

W praktyce najczęściej spotykam się z sytuacją, że dana aplikacja jest na początkowym etapie rozwoju i dany scenariusz testowy opisuje np. tylko akcje logowania do systemu. Gdy taki scenariusz jest jeszcze na etapie, na którym są rozpisane tylko akcje logowania, to wówczas mamy do czynienia z przypadkiem testowym. Tym samym odpowiadam na częste pytanie początkujących testerów: „Co odróżnia przypadek testowy od scenariusza testowego?”.

Na kolejnych etapach projektu powstają coraz to nowsze historyjki użytkownika, więc istnieje potrzeba tworzenia kolejnych przypadków testowych. Przykładowa sytuacja: programiści dodali opcję zmiany hasła po zalogowaniu – powstaje kolejny przypadek testowy.

Wraz z rozwojem aplikacji powstaje coraz to więcej przypadków testowych, które po zebraniu tworzą dany scenariusz testowy – historyjkę użytkownika. Zbiór przypadków testowych będzie zatem niezbędny do realizacji danego scenariusza testowego celem sprawdzenia poprawności działania systemu w jakimś zakresie.

Przepis na przypadek testowy

Jeśli chodzi o formę przypadków testowych, często jest ona elastyczna, w zależności od danego projektu i klienta. Jednak przyjęło się, że przypadek testowy powinien zawierać następujące elementy:

Tytuł, ID oraz informacje o testerze, który tworzy dany przypadek
Krótki opis, wymagania biznesowe, do których się odnosi
Warunki wstępne
Kroki testowe
Oczekiwany rezultat

Przykład scenariusza testowego

Scenariusze testowe mają elastyczne formy. Jedne są mniej rozbudowane, inne bardziej, na przykład zawierają dane testowe, informacje o środowisku testowym, statusy, etykiety itp.

Scenariusze testów: podsumowanie

Scenariusze testów są pomocne nie tylko w branży filmowej. Scenariusz testowy jest ważnym elementem codziennej pracy w wielu firmach dostarczających oprogramowanie na całym świecie. Dzięki nim testowanie aplikacji dla różnych platform jest wykonywane skutecznie, a ryzyko pojawienia się błędów w oprogramowaniu na etapie produktu końcowego znacząco maleje.

Złote zasady wytwarzania oprogramowania w przemyśle kosmicznym

Monika Wojciechowska — Tue, 16 Aug 2022 08:57:00 +0000

1. Test what you fly and fly what you test
2. Testuj, żeby ujawniać błędy, a nie dowodzić ich braku
3. Testuj najwcześniej, jak tylko się da
4. Testuj na czas
5. SpaceX – jak oni testują?

Test what you fly and fly what you test

Generalna zasada w przemyśle kosmicznym brzmi: „Test what you fly and fly what you test” i oznacza, że należy sprawdzać te komponenty misji, które mają być używane, oraz wykorzystywać te, które zostały przetestowane. Brzmi banalnie, lecz to właśnie ścisłe trzymanie się tej zasady mogłoby pomóc w wielu projektach. Testowanie w przypadku misji kosmicznych jest o tyle trudne, że nie zawsze możliwe jest wierne odtworzenie warunków środowiskowych lotu lub takich, jakie panują na innej planecie. Tworzy się w tym celu specjalne laboratoria bądź symulacje komputerowe, lecz nawet wtedy stanowi to duże wyzwanie. ISTQB mówi wprost – testowanie gruntowne jest niemożliwe. Tylko w najprostszych przypadkach da się sprawdzić wszystkie kombinacje danych i warunków, a złożone systemy wykorzystywane w misjach kosmicznych zdecydowanie nie należą do prostych. Ponadto testowanie jest zależne od kontekstu. Tak specyficzne systemy wymagają również dostosowanych testów.

Testuj, żeby ujawniać błędy, a nie dowodzić ich braku

Kolejną zasadą, która odgrywa ogromną rolę w testowaniu oprogramowania misji kosmicznych, jest testowanie jako proces ujawniający istnienie błędów, a nie dowodzący ich braku. Jest to pesymistyczne, ale nader realistyczne podejście, o którym zapomniano choćby w przypadku katastrofy Ariane 5 z satelitami Cluster. Wspomina o tym nawet oficjalny raport, w którym stwierdzono, że oprogramowanie zostało uznane za poprawne, dopóki nie okazało się, że jest wadliwe.

Testuj najwcześniej, jak tylko się da

Równie istotna jest wspomniana już wcześniej zasada związana z testowaniem tzw. shift-left. Wykrycie błędów na wczesnym etapie projektu pozwala zaoszczędzić czas i pieniądze. W wielu misjach błędy pojawiły się już na etapie projektowania i nie zostały wykryte z powodu niedostatecznie rzetelnych procesów weryfikacji.

Jeśli chodzi o stosowane w NASA praktyki, to wiadomo, że organizacja kładzie duży nacisk na testowanie w cyklu tworzenia oprogramowania. Szacuje się, że około 40% budżetu projektu jest poświęcone właśnie na testy. Aktywności związane z zapewnianiem jakości rozpoczynane są zwykle na etapie analizy wymagań, które muszą być zrozumiałe, szczegółowe, realistyczne i adekwatne do możliwości, a także testowalne. Celem dobrze zaprojektowanej specyfikacji oprogramowania jest to, aby inżynier sprzętu rozumiał, jak oprogramowanie kieruje systemem. We wczesnych stadiach testowania oprogramowania NASA używa często symulacji danych wejściowych. W późniejszych fazach testowanie obejmuje również sprzęt do testowania operacji i interfejsów, poleceń naziemnych i końcowej fazy. Dużą wagę przykłada się wtedy nawet do takich szczegółów jak odpowiednia długość kabli. Ponadto większość sprzętu NASA nie może być naprawiana w trakcie eksploatacji, co nadaje jeszcze większą wagę zapewnianiu jakości już na etapie jego tworzenia.

Quality Assurance

Zapewnianie jakości w projektach IT. Sprawdź jakie trendy ukształtują rynek, na którym będzie wysokie zapotrzebowanie na testerów oprogramowania i zespoły zarządzania jakością.

Przeczytaj artykuł: Quality Assurance (QA) – zapewnij jakość w Twoich projektach IT

Testuj na czas

Innym istotnym dla testowania w misjach kosmicznych czynnikiem jest czas. Chodzi nie tylko o okna pogodowe umożliwiające start i synchronizację działań w czasie, ale także logistykę na etapie wytwarzania produktu (np. przygotowanie komponentu lub systemu w odpowiednim terminie, aby można było go przetestować w komorze próżniowej). Nawet tego typu testy zazwyczaj nie są jednak w stanie zagwarantować identycznych warunków jak te, które panują w kosmosie.

Proces testowania w NASA obejmuje także najnowsze i najbardziej zaawansowane technologie, które pozwalają też na oszczędności. Jedną z nich jest technologia Digital Twin, polegająca na tworzeniu dokładnych i szczegółowych cyfrowych replik produktów, procesów i systemów.

SpaceX – jak oni testują?

Również w SpaceX powszechną praktyką jest testowanie połączeń różnych systemów i symulacja warunków ich działania. Do testów oprogramowania wykorzystuje się m.in. tzw. table rocket. Polega to na ułożeniu wszystkich komputerów i kontrolerów lotu na stole i połączeniu ich tak, jakby były w prawdziwej rakiecie. W celu wykonania testów integracyjnych przeprowadza się na komponentach pełną symulację lotu, monitorując wydajność i wychwytując potencjalne awarie. W przypadku testów obciążeniowych inżynierowie robią to, co nazywają „przecinaniem sznurków” – losowo wyłączają komputer pokładowy w trakcie symulacji, aby zobaczyć, jak zareaguje. Ten poziom symulacji, połączony ze znacznym udziałem automatyzacji, pozwala osiągać świetne wyniki.

SpaceX jest w stanie bez obaw wprowadzać zmiany w oprogramowaniu produktu nawet 17 000 razy dziennie! Z tego, jak SpaceX tworzy oprogramowanie, możemy wywnioskować, że ponowne wykorzystywanie kodu, kultura DevOps i ciągły przepływ testowania są dla nich kluczem do sukcesu.

Podsumowanie

Powyższe obserwacje, chociaż kontekst może wydawać się odległy o lata świetlne, są całkiem bliskie projektowej codzienności każdego z nas.

Wiele z opisanych w artykule przypadków dostarcza uniwersalnych wniosków, które mogą znaleźć zastosowanie w projektach z innych branż, nie tylko kosmicznej. Mowa tu, chociażby o takich obszarach jak:

analiza ryzyka,
cykl życia oprogramowania (shift-left i włączenie procesu testowania do wczesnych faz powstawania software’u),
testowanie produktu w środowiskach o różnych konfiguracjach i zasobach (dev, stage, preprod),
automatyzacja procesu wytwarzania i integracji oprogramowania (CI/CD),
pokrywanie funkcjonalności różnymi przypadkami testowymi.

Test regresji – strata czasu czy must have w projekcie?

Natalia Klockiewicz — Wed, 03 Aug 2022 11:41:35 +0000

1. Rozwój oprogramowania a testowanie regresyjne
2. Co to są testy regresji?
3. Jak często przeprowadzać testy regresji?
4. Na jakim poziomie przeprowadza się testy regresji?
5. Tworzenie przypadków testowych
6. Wybór przypadków testowych w regresji
7. Co robimy podczas sprawdzania regresji?
8. Regresja a retesty – jaka jest różnica?
9. W jaki sposób wykonujemy testy? Czyli automatyzacja w regresji
10. Testowanie regresji – korzyści
11. Podsumowanie

Rozwój oprogramowania a testowanie regresyjne

Wyobraźmy sobie, że mamy już działającą w środowisku produkcyjnym aplikację. Klient jest bardzo zadowolony, ponieważ cieszy się ona popularnością wśród użytkowników, i chce dodać nową funkcjonalność, która ma zwiększyć ich zadowolenie oraz spowodować napływ nowych. Zespół projektowy już pali się do pracy: nowa funkcjonalność, nowe zadanie, nowe wyzwanie! Po ustaleniu szczegółów developerzy ochoczo zabrali się do pracy. Następnie testerzy sprawdzili nową funkcjonalność. Po drobnych poprawkach wszystko działa. Czas wrzucić nową funkcjonalność na produkcję. Gdy nadszedł dzień wypuszczenia nowej wersji aplikacji, wszyscy byli szczęśliwi, że projekt udało się zrealizować w terminie i zgodnie z wymaganiami.

Niestety, szczęście nie trwało długo… Już dzień później serwis został zasypany zgłoszeniami, że nie wszystkie dotychczasowe funkcje aplikacji działają prawidłowo. W zespole zdziwienie: przecież nawet nie ruszaliśmy tych funkcjonalności, a nowo dodana działa w prawidłowy sposób. Co poszło nie tak?

Smutne skutki braku testów regresji…

Otóż zabrakło jednego, ale jakże istotnego elementu w procesie testowania. Nie sprawdzono, czy nowo dodana funkcjonalność nie wpłynęła na te, które już w aplikacji istniały. Innymi słowy, nie przeprowadzono testów regresji.

Brak testów regresji spowodował, że aplikacja nie tylko nie zyskała nowych użytkowników, ale straciła też znaczną część dotychczasowych. Utraciła swoją wysoką pozycję w rankingach, spadły zyski, co spowodowało spore niezadowolenie klienta.

Co to są testy regresji?

Definicja według słownika ISTQB mówi, że testowanie regresji to: „Rodzaj testowania związanego ze zmianami mający na celu wykrycie, czy defekty zostały wprowadzone lub odkryte w niezmienionych obszarach oprogramowania”.

Przedstawiając to w bardziej obrazowy sposób: w trakcie testów sprawdzamy, czy „podczas kładzenia tapety w jednym pokoju nie odpadł nam tynk ze ściany w drugim pokoju”. Wszelkie zmiany w kodzie w jednym miejscu mogą spowodować zepsucie funkcji w innym, choć na pierwszy rzut oka wydaje się, że nie są one ze sobą powiązane. Dlatego tak ważne jest ponowne przetestowanie oprogramowania po wprowadzonych zmianach.

Przeczytaj artykuł: Testowanie oprogramowania – poznaj świat testów

Jak często przeprowadzać testy regresji?

Widzimy już, jak istotne jest, żeby upewnić się, czy zmiany nie wpłynęły negatywnie na dotychczasowe funkcje, i znaleźć błędy odpowiednio wcześnie. Wprowadzane zmiany mogą wynikać z modyfikacji wymagań i kodu oprogramowania, dodania nowych funkcjonalności czy naprawy usterki, dlatego ważne jest, aby testy regresji były przeprowadzane tak często, jak wydawana jest nowa wersja oprogramowania.

Na jakim poziomie przeprowadza się testy regresji?

Testy regresji są niezależne od poziomu testów oraz ich rodzajów. Można je przeprowadzać na poziomie testów modułowych, integracyjnych, systemowych czy też akceptacyjnych i niezależnie od tego, czy mamy do czynienia z testami funkcjonalnymi, czy niefunkcjonalnymi.

Tworzenie przypadków testowych

Podczas sprawdzania oprogramowania tester tworzy przypadki testowe. Nie wszystkie jednak wejdą do puli przypadków wykonywanych podczas regresji. Od czego to zależy?

Przede wszystkim od ich ilości i czasu, jaki trzeba poświęcić, aby je wykonać. Jeżeli mamy do czynienia z nierozbudowanym systemem i wykonanie wszystkich przypadków testowych podczas przeprowadzania testów regresji nie zajmie zbyt wiele czasu – to jak najbardziej można je wykonać.

Najczęściej jednak systemy czy aplikacje są mocno rozbudowane i zależne od innych systemów. Nie jesteśmy wtedy w stanie użyć wszystkich utworzonych przypadków testowych. Czym w takim razie się kierować podczas wyboru przypadków, które powinny się znaleźć na liście podczas wykonywania testów regresji?

Wybór przypadków testowych w regresji

Jeżeli musimy się ograniczyć, warto odpowiednio dobrać zestaw przypadków testowych. Ujmijmy koniecznie te przypadki, które:

Sprawdzają najbardziej krytyczne funkcje – przede wszystkim należy uwzględnić przypadki testowe, które weryfikują działanie głównych funkcji aplikacji albo sprawdzają często używane funkcjonalności.
Powstały na bazie defektów – przypadki testowe, które powstały na bazie zgłoszonych defektów, są ważne.
Weryfikują podatność na błędy – warto się zastanowić, który obszar aplikacji jest najbardziej narażony na błędy po wprowadzonej zmianie, i podczas testów regresji wykonać także przypadki testowe z danego obszaru.
Sprawdzają nową funkcjonalność – nie możemy również zapomnieć o przypadkach testowych, które sprawdzają nowo dodaną funkcjonalność.
Wymagają wielu kroków – pamiętajmy też o złożonych przypadkach testowych wymagających wykonania dłuższej sekwencji czynności.

Odpowiedni priorytet

Ważne jest również odpowiednie nadanie priorytetu przypadkom testowym. Pomaga to w ich doborze, szczególnie wtedy, kiedy zakres obszaru testów jest duży, a czasu na ich wykonanie – mało.

W takiej sytuacji tester, uwzględniając czas, jaki ma na wykonanie testów, wybiera przypadki testowe o najwyższym priorytecie. Daje nam to pewność, że sprawdzone będą najbardziej krytyczne obszary aplikacji. Pozostałe przypadki z niższym priorytetem, które nie były wykonane w czasie regresji, należy umieścić w raporcie końcowym, odpowiednio je oznaczając jako niewykonane.

Jak nadawać priorytety przypadkom testowym?

Podczas nadawania priorytetów przypadkom testowym należy wziąć pod uwagę kilka czynników:

Ważność danej funkcjonalności z punktu widzenia biznesowego
Jej dostępność / widoczność dla użytkownika końcowego
Złożoność danej funkcjonalności
Jej wpływ na szeroko pojęte finanse
Czy była tworzona pod presją czasu
Czy w podobnych funkcjonalnościach występowały problemy

Uwzględniając powyższe aspekty i odpowiadając sobie na zadane pytania, przypisanie priorytetu przypadkom nie powinno stwarzać większego problemu. A praca włożona w ten proces zaowocuje w sytuacji, gdy czas na testy będzie mocno ograniczony.

Przypadki testowe wielokrotnego użytku w regresji

Listę przypadków testowych wytypowanych do testów regresji należy weryfikować cyklicznie. Część z nich będzie można wykorzystać w kolejnych testach regresji, są to tzw. przypadki wielokrotnego użytku. Inne zaś mogą okazać się już nieaktualne, a co za tym idzie – nieprzydatne w następnych cyklach regresji i taki „przestarzały przypadek” należy usunąć z listy testów regresji.

Weryfikacja przydatności polega głównie na próbie wykonania danego przypadku testowego. Jeżeli nie da się odtworzyć opisanych kroków lub dana funkcjonalność już nie istnieje, to taki przypadek testowy należy usunąć. Często zdarza się, że ścieżka wykonania lub oczekiwany rezultat uległy niewielkiej modyfikacji i wystarczy tylko zaktualizować dany przypadek testowy. Weryfikacja zbioru przypadków testowych wytypowanych do testów regresji jest konieczna, gdyż pozostawienie nieaktualnych przypadków testowych daje nam w raportach końcowych zafałszowany obraz stanu aplikacji, a cały proces regresji nie przynosi żadnej wartości.

Co robimy podczas sprawdzania regresji?

Sprawdzamy oczekiwany rezultat

Podczas przeprowadzania testów regresji sprawdzamy, czy system zachowuje się w oczekiwany sposób. Jeżeli testy regresji są przygotowane w formie przypadków testowych, to po wykonaniu opisanych w przypadku kroków sprawdzamy, czy otrzymujemy to, co jest przedstawione jako oczekiwany rezultat.

Weryfikujemy z checklistą

Innym sposobem na testowanie regresji jest przygotowanie listy kontrolnej, czyli tzw. checklisty. Lista kontrolna to zbiór operacji w aplikacji, które będą testowane, zapisany w formie krótkich haseł. Checklista jest stosunkowo łatwa w przygotowaniu i utrzymaniu i idealnie sprawdza się, kiedy osoby testujące bardzo dobrze znają aplikację i nie potrzebują szczegółowo rozpisanych kroków. Osoby te wiedzą, jakie operacje należy sprawdzić w danym obszarze i jaki jest oczekiwany rezultat.

Niestety, w przypadku checklisty istnieje ryzyko, że nie wszystkie operacje, które powinny zostać sprawdzone, będą przetestowane. W celu uniknięcia takiej sytuacji dobrze jest aktualizować checklistę w czasie omawiania przez zespół zmian, jakie mają zostać wprowadzone. Również podczas procesu testowania danej funkcjonalności należy na bieżąco uzupełniać brakujące elementy, tak by podczas regresji lista była kompletna.

Idealna checklista, czyli jaka?

Dobrze przygotowana checklista powinna być zwięzła, ale jednocześnie powinna obejmować wszystkie istotne funkcjonalności. Jeżeli system jest obszerny i checklista jest długa, to powinna być ona podzielona na odpowiednie kategorie, które jasno definiują obszar podlegający testowaniu. Warto też zadbać, by testowane operacje były ustawione w odpowiedniej kolejności, co przyspieszy testy i nie będzie trzeba wracać do już sprawdzonych rzeczy. Nie można zapomnieć, że każda checklista musi być rozbudowywana wraz z rozwojem oprogramowania.

Regresja a retesty – jaka jest różnica?

Wiele osób, zwłaszcza stawiających pierwsze kroki w IT, zastanawia się, czy retesty i testy regresji to to samo.

Retest to pojedynczy test, który sprawdza, czy defekt został usunięty. To ponowne testowanie przypadku, którego rezultat końcowy był inny od oczekiwanego i zostało to zgłoszone jako błąd oraz naprawione przez programistę. Jeżeli po wprowadzonej poprawce system działa tak, jak tego oczekiwano, możemy zamknąć zgłoszenie. Natomiast jeżeli nadal nie otrzymujemy oczekiwanych rezultatów, zgłoszenie powinno pozostać nadal otwarte, gdyż wymaga dalszej analizy i naprawy.
Regresja to zbiór testów, których wykonanie daje nam odpowiedź, czy cały moduł lub system nie zawiera błędów po wprowadzeniu zmian do kodu oprogramowania. Testy regresji są znacznie bardziej czasochłonne od retestów, ale pamiętajmy też, że są przeprowadzane w innym celu.

W jaki sposób wykonujemy testy? Czyli automatyzacja w regresji

To, w jaki sposób zostaną przeprowadzone testy regresyjne, zależy głównie od tego, z jak dużym systemem mamy do czynienia oraz często od dostępnego budżetu.

W małych projektach, gdy testy regresyjne nie zawierają dużej liczby przypadków testowych, często wystarczy wykonać test manualnie. Co jednak, jeśli do wykonania mamy ich tysiące i ręczne wykonywanie trwałoby miesiącami? Albo podczas wykonywania regresji wystąpiłby błąd blokujący dalszą pracę i po jego usunięciu trzeba by sprawdzić wszystko od nowa? Wtedy najlepszym rozwiązaniem jest zastosowanie testów automatycznych. Testy regresji są idealnym kandydatem do tego, by je zautomatyzować. Głównie dlatego, że wykonujemy je cyklicznie oraz dlatego, że testy automatyczne zdecydowanie skracają czas wykonania przypadków testowych. Jeśli jest ich kilka tysięcy, automatyzacja pozwala na sporą oszczędność czasu i nakładu pracy.

Oczywiście wprowadzenie testów automatycznych niesie za sobą koszty związane np. z zakupem licencji dla narzędzi oraz zatrudnienia osoby z odpowiednimi kompetencjami. Nadal jednak koszty te w przypadku dużych projektów są znacznie niższe niż te ponoszone za każdym razem przy przeprowadzaniu regresji w sposób manualny.

A jeśli nie możemy skorzystać z automatyzacji testów?

Bardzo często w projektach stosuje się podejście mieszane, gdyż nie każdy przypadek testowy pozwala na automatyzację. Często problemem są złożone przypadki testowe, które trudno zautomatyzować, dlatego najczęściej wykonuje się je manualnie. Oczywiście najlepiej, jeśli przypadków do wykonania manualnego jest najmniej, a pozostałe są zautomatyzowane – wtedy proces regresji przebiega sprawnie i nie zajmuje tak dużo czasu.

Testowanie regresji – korzyści

Proces testowania regresji wymaga pracy i odpowiedniego przygotowania. Niewątpliwie pociąga za sobą też koszty związane z czasem, nakładem pracy czy narzędziami. Jednak mądrze zaplanowany i odpowiednio przeprowadzony, przynosi korzyści znacznie przewyższające poczynioną inwestycję. Testowanie regresji zapobiega wprowadzeniu na produkcję defektów, przez które klient może ponieść wielotysięczne straty. Jeśli dojdzie do takiej sytuacji, to zespół musi zająć się naprawianiem defektów, przez co dalszy rozwój oprogramowania schodzi na dalszy plan i najczęściej jest odłożony w czasie.

Raport z testów regresji daje nam odpowiedź, czy dane oprogramowanie posiada oczekiwaną jakość i czy może zostać wdrożone w środowisku produkcyjnym. Często też wskazuje moduły czy obszary oprogramowania szczególnie podatne na defekty, co daje zespołowi możliwość zbadania problemu i objęcia tego obszaru szczególną uwagą.

Podsumowanie

Testy regresji są bardzo ważnym etapem w procesie wytwarzania oprogramowania niezależnie od tego, w jakiej metodologii jest prowadzony projekt: czy w podejściu kaskadowym, czy zwinnym. Odpowiadają one na pytanie, w jakiej kondycji jest nasza aplikacja po wprowadzeniu zmian, oraz pozwalają na uniknięcie kosztów naprawy defektów, które mogłyby wydostać się na produkcję. A jak już wiadomo, koszty poniesione podczas naprawy takich błędów znacznie przewyższają te poniesione podczas procesu testowania regresji.

QA – Nearshore Software Development Company – IT Outsourcing Services

Zawód tester oprogramowania. Czy to praca dla każdego?

Tester oprogramowania – praca dla każdego?

Praca jako tester oprogramowania – fakty i mity

Mit 1: Każdy może pracować jako tester oprogramowania

Mit 2: Testowanie polega tylko na szukaniu błędów

Mit 3: Testowanie to mało ważny element wytwarzania oprogramowania

Jaki zestaw umiejętności powinien posiadać dobry tester oprogramowania?

Jak zostać testerem oprogramowania?

Podsumowanie

Kim jest QA tester? Testowanie oprogramowania i zapewnianie jakości bez tajemnic!

Kim jest QA Tester? Czyli parę słów o zapewnianiu jakości

Jaką rolę pełni w projekcie tester oraz z kim ściśle współpracuje specjalista QA?

Z kim współpracuje QA?

Na jakich przedmiotach na studiach skupić się najbardziej, aby w przyszłości pracować jako tester oprogramowania?

Tester manualny vs QA test engineer – czyli ścieżki rozwoju od stażysty do leadera

Plusy i minusy pracy na stanowisku Quality Assurance Specialist – moje największe wyzwania

Plusy:

Minusy:

Gdybym mogła cofnąć czas, czy dalej zostałabym QA?

Testy automatyczne: Selenium + Python vs Selenium + Java

Automatyzacja testów: jakie mamy opcje? Java i Python

Język programowania czy język skryptowy?

Python

Java

Czego łatwiej się nauczyć: Javy czy Pythona?

Automatyzacja testów – jakie są opcje?

Dla Pythona

Dla Javy

Czym jest Selenium WebDriver?

Selenium i Python

Selenium i Java

Przygotuj:

Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?

Do czego służy Selenium z Pythonem?

Czy Selenium z Pythonem to dobry wybór?

Jak wykonać skrypt Selenium w Pythonie?

Jak zainstalować Selenium z PIP?

Czym jest PIP?

Automatyzacja testów – podsumowanie

FAQ Pakiet startowy Selenium + Java lub Python

Selenium / WebDriver z powiązaniami językowymi

Selenium i Python

Selenium i Java

Selenium Grid i kontenery Docker

Testy akceptacyjne użytkownika (UAT) – dlaczego są ważne?

Automatyzacja testów: jakie mamy opcje? Java i Python

Język programowania czy język skryptowy?

Python

Java

Czego łatwiej się nauczyć: Javy czy Pythona?

Automatyzacja testów – jakie są opcje?

Dla Pythona

Dla Javy

Czym jest Selenium WebDriver?

Selenium i Python

Selenium i Java

Przygotuj:

Która opcja jest lepsza dla testów automatycznych (Selenium z Pythonem czy Selenium z Javą)?

Frameworki do automatyzacji testów. Wprowadzenie do Atata

Kiedy i dlaczego automatyzować testy oprogramowania?

Czym jest automatyzacja?

Korzyści automatyzacji

Scenariusze i przypadki testowe a automatyzacja

Ciemne strony automatyzacji

Typy frameworków do automatyzacji testów

Library Architecture Framework

Module Based Testing Framework (MBTF)

Linear Automation Framework

Hybrid Test Automation Framework

Atata automation framework

Atata – zalety

Atata – wady

Atata vs Selenium

Atata

Który framework do automatyzacji testów będzie najlepszy dla mojego projektu?

Podsumowanie

Testuj przed wszystkimi, czyli shift-left testing w praktyce

Scrum czy Scrumfall?

Shift-left – co to takiego?