QualityLabs

AI przyspieszyła rozwój oprogramowania.
Testy nie nadążyły.

Pomagamy Waszym testom nadążyć: automatyzacja, testy obciążeniowe i wydajnościowe oraz zespół przygotowany, by samodzielnie o nie dbać.

Zacznijcie od bezpłatnego audytu albo napiszcie na hello@qualitylabs.eu

Z czym się do nas zwracają

Pięć problemów, które rzadko przychodzą pojedynczo.

  • Testy napisała AI i żaden z nich nie potrafi zawieść.

    Poproście AI o przetestowanie procesu zakupowego, a dostaniecie testy, które przechodzą za pierwszym razem i za każdym kolejnym. Klikają przycisk tylko wtedy, gdy akurat jest na miejscu, czekają sztywno trzy sekundy i nie sprawdzają niczego, co ma znaczenie. Wskaźnik pokrycia rośnie. Ryzyko nie maleje.

    Czytamy to, co wygenerowano, zostawiamy testy, które wychwyciłyby problem wart obudzenia kogoś w nocy, poprawiamy te, którym niewiele brakuje, a resztę usuwamy. Potem ustalamy standard przeglądu, żeby kolejny tysiąc testów nie trafił do projektu w ten sam sposób.

    Wygenerowane, bez przeglądu typowe 
    test('checkout works', async ({ page }) => {
  await page.goto('/checkout');
  await page.waitForTimeout(3000);

  const btn = page.locator('.btn-primary').first();
  if (await btn.isVisible()) await btn.click();

  expect(true).toBeTruthy(); // zawsze zielony
});
    Co przetrwało przegląd zostaje 
    test('charged exactly once', async ({ page }) => {
  const cart = await seedCart({ sku: 'SKU-118' });

  await page
    .getByRole('button', { name: 'Place order' })
    .click();

  await expect(page).toHaveURL(/\/confirmation\//);
  expect(await chargesFor(cart)).toHaveLength(1);
});

  • AI zwielokrotniła liczbę zmian. Czas na ich sprawdzenie został ten sam.

    Kiedy zespół zaczyna pisać kod z AI, liczba zmian czekających na sprawdzenie rośnie na długo przedtem, zanim ktokolwiek pomyśli o zmianie sposobu sprawdzania. Dwie czy trzy osoby, które rok temu mogły przejrzeć każdą zmianę, dziś już nie mogą, więc sprawdzanie zamienia się w wyrywkowe kontrole, choć nikt tego nie postanowił.

    Takiej luki nie zamkną ani nowe zatrudnienia, ani prośby, żeby ludzie pracowali szybciej. Zamyka ją decyzja, co naprawdę wymaga testowania, sprawienie, by reszta działała szybko i automatycznie, i danie osobom sprawdzającym pracę tych samych narzędzi AI, które programiści już mają.

    Napływ zmian a możliwości ich przeglądu Kształt luki. To nie jest pomiar Waszego zespołu. Zmiany wprowadzane w tygodniu Możliwości przeglądu i testowania wtedy teraz

  • Na testach działa, w najgorętszy dzień się sypie.

    Duży ruch odsłania problemy, do których zwykłe testy nigdy nie docierają: bazę danych zwymiarowaną na zeszły rok, stronę, która działała szybko przy tysiącu klientów, a przy pięćdziesięciu tysiącach ledwo się ładuje, dostawcę, który odcina Was w środku kampanii.

    Symulujemy ruch, którego faktycznie się spodziewacie, na środowisku na tyle zbliżonym do prawdziwego, żeby wynik coś znaczył, i znajdujemy pierwszy element, który puszcza. Dostajecie punkt, w którym system się psuje, z konkretną liczbą, i element, który za to odpowiada, a nie wykres, z którym nic nie da się zrobić.

    Co uruchamiamy
    Zwykły dzień, Waszą najbardziej obciążoną godzinę i test na tyle długi, żeby powolne wycieki dały o sobie znać.
    Czego szukamy
    Pierwszej części systemu, która dochodzi do granic możliwości, a potem tej, która stoi za nią i przez cały czas była prawdziwym ograniczeniem.
    Co zostaje u Was
    Punkt krytyczny, jego przyczyna i zmiana, którą wprowadzilibyśmy, żeby go podnieść.

  • Stare testy, których nikt nie chce ruszać.

    Sześć lat testów w starszym narzędziu, takim jak Selenium, serwery, które ktoś musi utrzymywać przy życiu, żeby je uruchamiać, i wyniki, które ludzie nauczyli się podważać zamiast im ufać. Te testy wciąż zawierają prawdziwą wiedzę o produkcie i dlatego usunięcie ich wszystkich jest równie błędne jak przepisanie ich wszystkich.

    Jeśli zestaw warto zostawić w obecnej technologii, utrzymujemy go w niej. Dotyczy to również Cypress, Selenium i WebdriverIO.

    Krok pierwszy
    Inwentaryzacja. Sporej części starych testów w ogóle nie warto przenosić, a my wskazujemy, która część jest wartościowa.
    Krok drugi
    Pilotaż na około 10–15% testów, działający naprawdę, żeby koszt reszty był znany, a nie zgadywany.
    Krok trzeci
    Reszta prac, z konkretną osobą po Waszej stronie zaangażowaną od pierwszego dnia, a nie dopiero przy przekazaniu.

  • Wszystkie testy przechodzą. Aplikacja wciąż działa wolno.

    Wszystkie testy mogą przechodzić, a produkt i tak może sprawiać złe wrażenie. Dotknięcia, na które ekran reaguje z opóźnieniem, strona, która skacze w trakcie ładowania, pierwszy ekran, który pojawia się w kawałkach. Nic z tego nie widać w wynikach testów, a wszystko widać w tym, jak zachowują się Wasi klienci.

    Mierzymy to na urządzeniach Waszych prawdziwych użytkowników, a nie w laboratorium, śledzimy każdy problem aż do jego przyczyny i proponujemy zmianę, która go naprawia, a nie panel, który go raportuje.

    LCP
    Ile trwa, zanim na ekranie pojawi się to, dla czego strona w ogóle istnieje.
    INP
    Ile czasu interfejs potrzebuje, żeby odpowiedzieć na dotknięcie. Ten, na który większość zespołów nigdy nie patrzyła, i ten, który użytkownicy opisują jako ociężałość strony.
    CLS
    Jak bardzo strona się przesuwa, kiedy ktoś już zaczął ją czytać.

Nasz zespół budował i dostarczał jakość w takich firmach jak

Rynki regulowane i nieregulowane: usługi finansowe i handel wysokiej częstotliwości, kryptowaluty i aktywa cyfrowe, portale nieruchomości, przeglądarki w skali konsumenckiej i sporo nisz pomiędzy nimi.

Nasza teza

Brakującym elementem nigdy nie było narzędzie.

Większość zespołów, z którymi rozmawiamy, próbowała już narzędzia, które miało to rozwiązać, często niejednego. Narzędzia robią to, co obiecują. Żadne z nich nie powie Wam, na których dwunastu z Waszych czterystu zachowań opiera się biznes, a rozstrzygnięcie tego to większość pracy. Cztery generacje narzędzi sprzedawano jako zastępstwo dla osoby, która podejmuje tę decyzję. Takiego zastępstwa nie ma.

To nie jest argument przeciwko AI. Duża część naszej własnej pracy na niej działa. Najlepszy niezależny pomiar oszacował oszczędność przy tej pracy na 24,9%, podczas gdy cała kategoria reklamuje minuty. Odzyskana jedna czwarta wysiłku to realny zysk. Ale to wciąż nie jest ta praca.

Platforma
Była właścicielem Waszych testów. Poprawienie jednego oznaczało zgłoszenie do supportu.
Samonaprawiający się test
Tak samo naprawia przesunięty przycisk i zmienioną regułę biznesową. Tylko jedno z nich powinno przejść.
Testy napisane przez AI
Zasięg bez priorytetów, podczas gdy ryzyko rozkłada się wszystko, tylko nie równomiernie.
Recenzent AI
Widzi zmianę w kodzie, a nie dawny incydent, który tłumaczy, dlaczego ten kod się tam znalazł.

Dłuższa wersja, generacja po generacji (po angielsku)

Co robimy

Testowanie to nie cała jakość.

Od pierwszego testu po obciążenie, które kładzie system, i zespół, który potem o to dba.

Wasza strona, testowana automatycznie

Automatyczne testy ścieżek, na których opiera się Wasz biznes, takich jak rejestracja czy zakup, sprawdzające to, co ważne, i uruchamiane przy każdej zmianie. Zbudowane w Playwright.

Systemy za Waszą aplikacją

Testy usług i danych, od których zależy Wasza aplikacja, łącznie z tym, co się dzieje, gdy coś pójdzie nie tak. Szybkie, bo nie biorą w nich udziału żadne ekrany.

Wasze aplikacje na iOS i Androida

Automatyczne testy aplikacji mobilnych w Appium albo we własnych narzędziach Apple i Google, tam gdzie lepiej pasują.

Przeniesienie lub utrzymanie starych testów

Testy w starszych narzędziach, takich jak Selenium czy Cypress, przeniesione do Playwright: inwentaryzacja, pilotaż, a potem reszta. Albo zostawiamy je tam, gdzie są, i o nie dbamy.

Przegląd testów generowanych przez AI

Zostawiamy testy, które sprawdzają coś realnego, poprawiamy te, którym niewiele brakuje, i ustalamy standard przeglądu dla kolejnej partii.

Testy obciążeniowe

Jaki ruch wytrzyma Wasz system, zanim się posypie, i która część posypie się pierwsza. Zbudowane w k6 i dołączone do migracji.

Wydajność i doświadczenie użytkownika

Jak szybko Wasz produkt działa w odczuciu prawdziwych użytkowników, mierzone na ich urządzeniach i prześledzone do przyczyny, z propozycją poprawki zamiast panelu.

Testy przy każdej zmianie

Wasze testy uruchamiane automatycznie przy każdej zmianie w kodzie, w narzędziach, których już używacie, i na tyle szybkie, że nikt ich nie pomija.

Szkolenia

Playwright, zautomatyzowane procesy i korzystanie z AI w pracy nad jakością bez ślepego zaufania. Praca ramię w ramię w trakcie projektu, warsztaty przy przekazaniu.

Narzędzia, w których pracujemy

  • Playwright
  • TypeScript
  • Python
  • k6
  • Lighthouse
  • Web Vitals
  • Selenium
  • Cypress
  • WebdriverIO
  • Appium
  • XCUITest
  • Espresso
  • GitHub Actions
  • GitLab CI
  • Azure DevOps
  • Jenkins

Jak to działa

Cztery kroki, a przerwać można po każdym z nich.

  1. Audyt

    Około tygodnia, bezpłatnie. Dostajecie pisemną inwentaryzację Waszych testów, plan, co z nimi zrobić, i ocenę bez owijania w bawełnę, co warto zachować. Zostaje u Was niezależnie od tego, czy nas zatrudnicie.

  2. Pilotaż

    Prawdziwy fragment Waszych testów, a nie demo, przeniesiony i przechodzący przy każdej zmianie, którą wprowadza Wasz zespół. Tu okazuje się, czy szacunek się broni, póki zmiana kursu jest jeszcze tania.

  3. Migracja i szkolenia

    Główna część pracy, etapami, z Waszymi inżynierami pracującymi razem z nami. Szkolenie to nie tylko warsztat na koniec. To sposób, w jaki wykonujemy pracę.

  4. Przekazanie

    Dokumentacja projektu, warsztaty z transferu wiedzy i zespół, który potrafi samodzielnie rozwijać zestaw testów. Potem wsparcie, jeśli go chcecie.

Notatki

Co myślimy, razem z tokiem rozumowania.

Na tej stronie nie ma logotypów klientów udających rekomendacje. Przeczytajcie argumenty i sami oceńcie, czy wiemy, co robimy. Notatki są po angielsku.

Zacznijcie tutaj

Cztery generacje samonaprawiających się testów i wciąż ta sama brakująca osoba

Platforma, która była właścicielem Waszych testów, potem testy, które same się naprawiały, potem AI, która pisze testy, a teraz AI, która przegląda każdą zmianę. Każde z nich to lepsza inżynieria niż poprzednie i każde sprzedawano jako sposób, by obyć się bez osoby, która rozumie produkt. Ta osoba była jedynym elementem nośnym.

Czytaj notatkę

Czego się nie podejmujemy

Migracje, których odmawiamy, i zestawy, w których usunięcie testów jest lepsze niż ich przenoszenie.

Czytaj notatkę

Gdzie AI naprawdę zawodzi przy migracji testów

Jedno kontrolowane badanie oszacowało oszczędność na 24,9%, a nie na „minuty”. Oto sześć miejsc, w których regularnie się sypie, i dlaczego.

Czytaj notatkę

Niestabilne testy występują w skupiskach

Trzy czwarte niestabilnych testów ma wspólną przyczynę z mniej więcej tuzinem innych. Naprawianie ich pojedynczo to powód, dla którego kolejka nigdy się nie kończy.

Czytaj notatkę

Wasz zestaw testów nie jest wolny. On Was okłamuje.

Czas wykonania to łatwa metryka. Zaufanie to ta, która decyduje, czy w ogóle warto uruchamiać zestaw. Oto cztery sposoby, by je zmierzyć.

Czytaj notatkę

Analizy

Cudze migracje, przeczytane uważnie.

Nie mamy studiów przypadków klientów, które moglibyśmy pokazać, więc żadnych nie wymyślamy. Zamiast tego bierzemy najlepiej udokumentowane publiczne relacje z tej dziedziny i czytamy je dokładnie, łącznie z fragmentami, które przemawiają przeciwko zatrudnianiu kogokolwiek. Każda liczba poniżej prowadzi do opublikowanego źródła, które możecie sprawdzić. Analizy są po angielsku.

Jak wygląda prawdziwy harmonogram migracji z Selenium

Sto testów, osiem miesięcy, dwa zestawy działające równolegle. Liczba, od której dostawcy nigdy nie zaczynają.

Czytaj analizę

Dwa tygodnie, 200 testów i część, którą wszyscy pomijają

Dwa tygodnie na 200 testów, GPT-4 wymyślający nieistniejące sprawdzenia i wyjaśnienie, dlaczego 71% udanych testów na laptopie zamieniło się w 44% na serwerze budującym.

Czytaj analizę

Projekt automatyzacji, który w trzy lata znalazł osiem błędów

Dyrektorka ds. jakości opisała publicznie własną trzyletnią porażkę. Powrót do testów manualnych mógł być słuszną decyzją.

Czytaj analizę

Zalando robi testy obciążeniowe na produkcji. Oto dlaczego.

Przy 7200 zamówieniach na minutę testowa kopia serwisu przestaje mówić cokolwiek, co warto wiedzieć.

Czytaj analizę

Nikt nie przyjdzie tego za Was przetestować

Amazon przeszedł od dziesięciu inżynierów na jednego testera do stu. Praca testerska nigdzie nie zniknęła.

Czytaj analizę

Zacznijcie od audytu.

Napiszcie, na czym działa Wasz produkt i jak go dziś testujecie. Wrócimy z tym, co Wasze testy naprawdę sprawdzają, z ryzykiem, którego nic nie pokrywa, i ze wskazaniem, gdzie brakuje osądu, a nie narzędzi. Czasem okazuje się, że potrzeba mniej, niż myślicie. Dokument zostaje u Was w każdym przypadku.

Poproście o audyt albo napiszcie na hello@qualitylabs.eu

Kim jesteśmy

Mały zespół z ponad 30 latami doświadczenia w tej pracy.

Jesteśmy butikiem, nie agencją. Osoby, które ustalają zakres pracy, to te same osoby, które ją wykonują, i prowadzimy niewiele projektów naraz, bo tylko tak da się je zrobić porządnie.

Działamy w UE i pracujemy w strefach czasowych Europy i USA. W naszej pracy intensywnie korzystamy z AI i mówimy wprost, gdzie pomaga, a gdzie nie. Tego samego osądu uczymy Wasz zespół.

Pytania

O co pytają nas przed audytem.

Jeśli czegoś tu brakuje, zapytajcie w mailu. Odpowiedź też nic nie kosztuje.

Co dokładnie dostajemy w ramach bezpłatnego audytu?

Pisemną inwentaryzację zestawu testów, ocenę tego, co każda jego część naprawdę sprawdza, obszary produktu z ryzykiem, którego nic nie pokrywa, oraz plan przeniesienia testów, jeśli ma to sens. Zajmuje to około tygodnia naszego czasu i bardzo niewiele Waszego.

Dokument jest Wasz niezależnie od tego, czy nas zatrudnicie. Czasem okazuje się, że potrzebujecie mniej, niż myślicie, i wtedy to powiemy.

Jak przebiega współpraca?

W czterech krokach: audyt, pilotaż przechodzący przy każdej zmianie, główna część pracy z Waszymi inżynierami u naszego boku i przekazanie. Każdy kończy się czymś, z czego można korzystać samodzielnie, więc możecie przerwać po każdym z nich.

Pilotaż istnieje po to, żeby szacunek dla reszty był zmierzony na Waszym kodzie, a nie zgadywany na podstawie naszego. Kroki szczegółowo.

Czy to Wy wykonujecie pracę, czy nasz zespół?

Jedni i drudzy, od pierwszego dnia. My bierzemy na siebie najcięższą część, a imiennie wskazany właściciel po Waszej stronie pracuje razem z nami, zamiast poznawać zestaw testów dopiero na końcu. Podział pracy ustalamy na początku i może się zmieniać, w miarę jak Wasz zespół nabiera pewności.

Osoby, które ustalają zakres pracy, to te same osoby, które ją wykonują. Nie ma przekazania do zespołu realizacyjnego, którego nie znacie.

Mamy dziś bardzo mało automatyzacji. Czy to za wcześnie, żeby się do Was zgłosić?

To dobry moment. Start od niewielkiej bazy oznacza, że nie ma czego odkręcać. Budujemy pokrycie tam, gdzie go nie ma, dzielimy ręczne sprawdzenia na to, co warto automatyzować, i to, czego nie warto, i uruchamiamy wszystko w narzędziach, z których już korzystacie. Wasz zespół uczy się nawyków, póki zestaw jest mały, czyli wtedy, gdy nauka kosztuje najmniej.

Nasze testy używają starszego narzędzia, takiego jak Selenium albo Cypress. Czy musimy je zmienić?

Nie. Tam, gdzie zestaw warto zostawić takim, jaki jest, utrzymujemy go i ulepszamy na miejscu: także w Cypress, Selenium i WebdriverIO. Tam, gdzie przeniesienie się opłaca, migrujemy etapami, bez przełączania wszystkiego naraz, a niektóre testy lepiej usunąć, niż przenosić. Audyt pokazuje, co jest czym, test po teście.

Czy są prace, których się nie podejmujecie?

Tak. Migracji, po której nikt po Waszej stronie nie przejmie zestawu. Zlecenia przeniesienia całego zestawu w określonym terminie bez wcześniejszego pilotażu. I automatyzowania pracy, która wymaga ludzkiego osądu, jak testy eksploracyjne czy przeglądy dostępności. Jeśli testy są niestabilne, bo aplikacji nie da się przywrócić do tego samego punktu wyjścia przed każdym z nich, mówimy o tym przed migracją czegokolwiek, bo przeniesienie testów przeniosłoby tylko problem. Pełna lista z uzasadnieniem (po angielsku).

Ile to trwa?

Audyt trwa około tygodnia. Wszystko, co potem, zależy od wielkości i stanu zestawu testów, i właśnie dlatego następny jest pilotaż: zamienia szacunek dla głównej części w liczbę zmierzoną na Waszym kodzie. Uważajcie na każdego, kto wycenia pełną migrację, zanim zobaczy działający fragment. Jak wygląda prawdziwy harmonogram (po angielsku).

Co się dzieje, kiedy odchodzicie?

Wasz zespół jest gotowy, by działać dalej bez nas. Przekazanie to dokumentacja projektu i warsztaty z transferu wiedzy.

Po zakończeniu projektu nadal oferujemy wsparcie. Ma różne poziomy, w zależności od tego, jak blisko chcecie nas mieć, i można je przedłużyć na warunkach, które uzgodnimy.