Archiwum kategorii: Testowanie

SkładQA 2017 – jak było?

Jakiś czas temu, bo 20 marca 2017, udało mi się zajrzeć na tegoroczną edycję testerskiej konferencji SkładQA. O samej SkładQA pisałam przy okazji omawiania wiosennych wydarzeń w IT.

Zespół KraQA nie zawiódł i tym razem. Profesjonalne prowadzenie konferencji, świetnie wybrana lokalizacja (obszerna hala Starej Zajezdni, która pomieści naprawdę sporo osób), dobre zaplecze techniczne (nagłośnienie itd.), ciekawi prelegenci i przekrój  różnorodnych tematów. Organizatorzy to profesjonaliści i to widać.

Merytorycznie mogę odnieść się jedynie do trzech ostatnich prezentacji:

  • Marcin Żołna & Karol Pękała – How to become a cybersecurity hero. Z początku myślałam, że ta prezentacja skierowana jest raczej do początkujących. Ale na szczęście nie tylko. Wyniosłam z niej coś dla siebie – wymienione zostało narzędzie OWASP, któremu z pewnością przyjrzę się bliżej.
  • Wiktor Żołnowski – Pragmatyczny QA. Na którejś edycji Quality Excites miałam możliwość wysłuchania prelekcji Wiktora, kiedy jeszcze zajmował się wdrożeniami Agile. Tym razem zaprezentował model CYNEFIN. Nawet nie wiedziałam, że tak nazywa się ten diagram (o którym pisałam zresztą we wpisie Dla kogo Scrum?, lecz w formie dużo bardziej uproszczonej). Warto zatem chodzić na konferencje, zawsze można się czegoś ciekawego dowiedzieć:)
  • Michał Sajdak – Hackowanie aplikacji webowych na żywo – wybrane przypadki. Ta prezentacja totalnie mnie zachwyciła. Prawdziwy show. Niektóre „sztuczki” pobieżnie znałam z artykułów na Sekuraku czy Niebezpieczniku, ale zobaczenie jak to wygląda na żywo – naprawdę robi wrażenie.

Podsumowując, było to naprawdę dobrze spędzone, INSPIRUJĄCE popołudnie. Chcę więcej i polecam wszystkim:)

Kiedy skończyć testowanie

Testowanie oprogramowania to proces teoretycznie nieskończony. Zawsze można znaleźć warunki lub ścieżki, które nie zostały jeszcze sprawdzone. W warunkach biznesowych proces testowania jest jednak ograniczony (czasem, budżetem, możliwościami). Często pojawia się pytanie: kiedy można zakończyć testowanie, uznając że produkt jest dostatecznie dobrze sprawdzony?

Odpowiedź nie jest jednoznaczna – zakończenie testów jest umowne i zależy od spełnienia jakiegoś warunku:

  • Budżet – kwestia dość prosta.
  • Czas – może produkt „pudełkowy” ze sztywną datą wydania, może wytwarzany w modelu kaskadowym (a może w Scrumie), może trzeba gonić konkurencję, a może po prostu osoba decyzyjna stwierdza, że czas na testy ubiegł – kończymy.
  • Metryki. Tu zaczyna się robić ciekawie, o czym w dalszej części wpisu.

Ciekawy materiał na ten temat od IBM:
[ftp://public.dhe.ibm.com] – kopia [IBM_Kiedy_mozna_zakonczyc_testowanie].

Metryki są pewnym założeniem i są to wartości dość względne. Mogą zostać ustalone na początku testowania. Niektóre z nich to np.:

  • Wykonanie założonego procentu przypadków testowych zakończyło się sukcesem (nie zostały wykryte błędy).
  • Ilość wykrytych błędów (lub krzywa wykrywanych błędów) spadła poniżej założonego progu.
  • Pokrycie funkcjonalności testami (manualnymi, automatycznymi) osiągnęło założony zakres, np.:
    • przetestowano ręcznie najważniejszą ścieżkę,
    • pokrycie testami jednostkowymi na poziomie 90%.

Narzędzia do automatyzacji aplikacji desktopowych Windows Forms

Jakich narzędzi można użyć do automatyzacji testów aplikacji desktopowych, działających w systemie Windows (Windows Forms, WPF)?

Na szczęście istnieje wiele rozwiązań. Poniżej kilka propozycji. Większość z nich jest darmowa – poza licencją na Visual Studio (w przypadku pierwszej grupy, opartej o .NET Framework lub rozwiązań Microsoftu).

Inspect.exe

Narzędzie Inspect.exe

Zapraszam do lektury:

Czytaj dalej

How to run tests in Visual Studio?

How to run tests (unit tests, Selenium or any other in Microsoft Visual Studio? This is quite simple.

My instruction is for Visual Studio Professional 2015.

  1. First – choose test runner (nUnit, MSTest, xUnit or other). I choosed nUnit, because of its popularity.
  2. Install a test runner. I use NuGet to manage dependencies in my projects. To install nUnit, click (right) on project and click „Manage NuGet Packages”, search „nUnit” and install it. A current version number is 3.4.1.
  3. Prepare a simple test. Remember about:
    • making class containing tests public (public class TestClass{})
    • making test methods public (public void TestMethod(){})
    • marking test methodss with [Test] attribute.
  4. Prepared test should be visible in Test Explorer (open this window from menu: Test -> Windows -> Test Explorer). If Test Explorer window is empty and after building project Visual Studio doesn’t display any tests, you need to install nUnit Test Adapter (version 3.x is compatible with nUnit 3.x). To install nUnit Test Adapter, choose „Extensions and Updates” from „Tools” menu, search for „nUnit Test Adapter” and install it. After rebooting Visual Studio and rebuilding project, tests should be displayed in Test Explorer Window.

Różne linki o testowaniu (i nie tylko;))

  1. Forum Forum Stowarzyszenia Jakości Systemów Informatycznych, gdzie poruszane są różne tematy o jakości oprogramowania i testowaniu: http://sjsi.org/forum/index.php
  2. Blog o testowaniu: http://www.testingminded.com/
  3. WebInject, jedno z darmowych narzędzi do automatycznego testowania, podobne nieco do JMetera. Jeśli dobrze pamiętam, próbowałam się nim bawić, ale „chemii między nami nie było”, zwłaszcza że nie chciało współpracować z proxy;) http://www.webinject.org/ . Ale to było dawno (2014) i nieprawda. Może już zostało naprawione 🙂
  4. Ciekawy artykuł „Signs that you’re a bad programmer”https://sites.google.com/site/yacoset/Home/signs-that-you-re-a-bad-programmer .
  5. Przykład tzw. Yoda condition:
    !"".equals(id)
    co stanowi krótszą formę od:
    !(id == null || id.equals(""))
  6. Artykuł o equals w Java: http://www.jakubiak.eu/2007/06/prawdy-o-equals.html.
  7. Zbiór linków o wzorcach projektowania stron, w kontekście usabilityhttp://www.webusability.pl/2008/05/13/design-patterns-czyli-wzorce-projektowe/.
  8. I na deser – fajne przykłady animowanych wykresów stworzonych w TeX: http://tex.stackexchange.com/questions/158668/nice-scientific-pictures-show-off.

Page Object Pattern + Fluent Interface

Page Object Pattern jest jednym z częściej używanych wzorców w testach interfejsowych. Nie bez powodu – pozwala świetnie odzwierciedlić architekturę aplikacji w testach, zapobiega także niepotrzebnemu powtarzaniu kodu, jeżeli pewne struktury powtarzają się w wielu miejscach aplikacji (na przykład wspólne dla każdej podstrony menu).

Jeden Page Object powinien odwzorowywać jeden logiczny fragment aplikacji. Posługując się przytoczonym wyżej przykładem menu, klasa „Menu” będzie zawierać wszystkie pozycje w menu (a jeśli ma ono strukturę hierarchiczną, także i zagnieżdżone, kolejne Page Objecty).

Każda metoda w klasie udostępnia oferowane przez obiekt usługi (np. rozwinięcie i zwinięcie podmenu, wybór pozycji itd.).

W tym wzorcu metoda zawsze zwraca Page Object (z czego korzysta kolejny wzorzec: Fluent Interface). Dzięki temu w testach można stworzyć bardzo elegancko wyglądającą ścieżkę wędrówki pomiędzy podstronami.

Z pozoru te same akcje mogą zwracać różne wyniki, np. dwie metody:


public AdminPage LoginWithCorrectCredentials(string userName, string password);

public ErrorPage LoginWithIncorrectCredentials(string userName, string password);

Asercje wykonywane są w testach, nie w klasach Page Objectowych.

Sterownik (WebDriver) może być przekazywany w konstruktorze Page Object.

Dobre praktyki w testach Selenium

kawa_selenium

Dobre praktyki w automatycznych testach w Selenium:

  • Podstawowa zasada – używanie aktywnego czekania (WebDriverWait, wait.Until, ImplicitlyWait itd.) zamiast Thread.Sleep, który spowalnia testy, nie dając jednocześnie gwarancji, że zastosowana przerwa jest odpowiednio długa (jest wiele artykułów na ten temat w sieci).
  • Wyszukiwanie elementów na stronie za pomocą selektorów CSS (By.CssSelector) lub identyfikatorów ID lub name (By.Id, By.Name) – taka metoda jest o niebo szybsza niż wyszukiwanie przez XPATH.
  • Używanie wzorca Page Object.

Oraz kilka dobrych praktyk, które mogą być stosowane ogólnie w testach, nie tylko Selenium:

  • DRY – Don’t Repeat Yourself – niepowielanie tego samego kodu poprzez tworzenie np. zestawów funkcji bibliotecznych, dobre rozplanowanie architektury testów, korzystanie z dostarczanych przez framework metod jak Test Setup, Teardown (np. ustawienie przeglądarki przed testami, zamknięcie przeglądarki po testach).
  • Behaviour Driven Testing – testy będą „bliżej autentycznego użytkownika”.
  • Logowanie błędów! Bardzo przydatne w przypadku testów uruchamianych na środowiskach Continuous Integration, gdzie jeśli testy nie mają logów, jedyną informacją, jaką dostarczą będzie „test nie przeszedł, coś nie działa”. Warto logować ścieżkę wykonanych akcji wraz z parametrami metod oraz informacje o środowisku na którym uruchomiono testy: system, przeglądarka, baza danych itd., godzina – a nuż błąd pojawia się na przykład pomiędzy 23 a 1 dnia następnego?, itd.
  • Screenshoty – jeżeli jest taka możliwość (a w Selenium jest) – stanowią wspaniałe źródło informacji o błędach. Nie wszystko da się wyczytać z logu – informacja typu „nie da się kliknąć kontrolki x” niewiele mówi – tymczasem „obraz wyraża więcej niż tysiąc słów”, a na screenie dokładnie widać, co się wydarzyło.

Może się wydawać (nadal!), że testy są niepotrzebne, są stratą czasu. Tymczasem są one w stanie wykryć defekty już na bardzo niskim poziomie (testy jednostkowe). Jeżeli aplikacja boryka się z problemami dużego długu technicznego, złej architektury a klasy cechują się wysokim sprzężeniem, próby modyfikacji aplikacji „na siłę”, byle tylko pokryć ją testami mogą niestety narobić więcej szkody, niż pożytku. W takim przypadku lepiej sprawdzi się metoda małych kroków. Implementując nowe funkcjonalności w aplikacji warto rozważyć piszanie testów jednostkowych tylko do nowych partii aplikacji (TDD). Przymierzając się natomiast do dużych zmian w całej aplikacji warto przygotować jak najwięcej wysokopoziomowych testów czarnoskrzynkowych (funkcjonalnych, integracyjnych). Nawet jeśli ich implementacja byłaby kosztowna w sensie czasowym lub finansowym, warto to zrobić. Optymalnym rozwiązaniem jest zautomatyzowanie owych testów. Minimalnym – spisanie wszystkich wymagań stawianych aplikacji (np. w formie proponowanej przez BDD).

Inspirację do tworzenia nowych przypadków testowych można czerpać również z błędów zgłaszanych przez użytkowników. To bardzo dobre źródło informacji o tym, w jaki sposób użytkownicy naprawdę używają aplikacji. Dobrze zgłoszony błąd zawiera pełną ścieżkę czynności potrzebnych do zreprodukowania błędu. Po jego naprawieniu, warto ją zautomatyzować.

Pobieranie UDID podłączonego iPhone

Jednym z wymaganych ustawień Appium jest UDID – Unique Device Identifier.

Pobieranie numeru UDID podłączonego urządzenia z systemem iOS (iPhone/iPad…) jest możliwe za pomocą komendy:

udid=$(system_profiler SPUSBDataType | grep "Serial Number: " | tail -c 41)

Oczywiście może różnić się w zależności od systemu. Testowana była na OS X 10.10.

Tak pobraną wartość można przekazać do skryptu uruchamiającego serwer Appium.

How to check if element is invisible in Ruby Selenium client

How to check if element is invisible in Ruby Selenium client? In Java or C# answer is easy. There is a mechanism called ExpectedCondition, which has got ready for use method: ExpectedConditions.invisibilityOfElementLocated. Example:

driverWait.until(ExpectedConditions.invisibilityOfElementLocated(element));

Unfortunatelly, Ruby client hasn’t got anything like this. Quick workaround – try to find element. When element is not displayed, catch exception and return false:

def check_if_not_exist(locator)
  begin
    wait = Selenium::WebDriver::Wait.new :timeout => 10
    wait.until { @driver.find_element(:name, 'elementName').displayed? }
  rescue
    false
  end
end

Not very elegant and quick, but works.