Przegląd wymagań
Czytamy historyjki użytkownika i specyfikację, zanim powstanie kod. Sprzeczność typu „rabat liczony od brutto” w jednym miejscu i „od netto” w drugim wyłapana na tym etapie kosztuje jedną rozmowę.
Pojedyncze błędy to połowa wartości. Druga połowa to rosnący zestaw scenariuszy, który przy kolejnych wersjach przechodzi się znacznie szybciej niż za pierwszym razem.
Czytamy historyjki użytkownika i specyfikację, zanim powstanie kod. Sprzeczność typu „rabat liczony od brutto” w jednym miejscu i „od netto” w drugim wyłapana na tym etapie kosztuje jedną rozmowę.
Opisane kroki z oczekiwanym wynikiem w TestRail, Xray albo zwykłym arkuszu. Mogą z nich korzystać nasi testerzy, Twój zespół, a później skrypty automatyczne.
NIP z dziewięcioma cyframi, kod pocztowy bez myślnika, nazwisko z „ł” i „ż”, ilość 0 i 9999 w koszyku, data 29 lutego. Właśnie na takich danych formularze najczęściej się sypią.
Sprawdzamy, czy zamówienie trafia do Comarch ERP Optima albo Subiekta, czy faktura ma poprawną stawkę VAT i czy status przesyłki z InPost wraca do panelu klienta.
Nowa funkcja nie może psuć starych. Po każdej zmianie przechodzimy scenariusze z obszarów, których dotknął programista, i te, które psuły się w przeszłości.
Kroki, środowisko, przeglądarka, dane testowe i oczekiwane zachowanie, wpisane wprost do Jiry, GitLaba lub Azure DevOps. Programista nie musi dopytywać.
Co sprawdziliśmy, czego nie, jakie błędy zostały otwarte i jakie ryzyko bierzesz, wypuszczając wersję teraz.
Pierwsza runda trwa dłużej, bo scenariusze powstają od zera. Każda kolejna idzie wyraźnie szybciej. Pracujemy zdalnie na Twoim środowisku testowym lub stagingu.
Uczymy się produktu i ustalamy z Tobą, które funkcje przynoszą pieniądze, a które mogą chwilę poczekać.
Zakres, przeglądarki, urządzenia i to, co świadomie pomijamy. Wszystkiego przetestować się nie da, więc priorytety wynikają z ryzyka.
Przechodzimy scenariusze, zgłaszamy błędy i sprawdzamy poprawki, gdy tylko programiści je oddadzą.
Rekomendacja „wypuszczamy” lub „wstrzymujemy” z listą otwartych błędów i obszarów bez pokrycia.
Zgłoszenie „nie działa koszyk” to nie jest zgłoszenie błędu. Takie wiadomości krążą między ludźmi tygodniami i kończą się statusem „nie da się odtworzyć”. Każdy błąd opisujemy tak, żeby programista odtworzył go za pierwszym podejściem: kroki, konto testowe, dane, przeglądarka, zrzut ekranu lub nagranie.
To zależy od złożoności funkcji i pokrycia, jakiego oczekujesz, a liczbę godzin widzisz w planie testów przed startem. Mniej też się da, ale wtedy sprawdzamy tylko główne ścieżki i część błędów trafi do użytkowników. Czasem to rozsądny wybór, byle podjęty świadomie.
Nie. Zaczynamy od testów eksploracyjnych: poznajemy system tak, jak robiłby to nowy użytkownik, i na tej podstawie spisujemy, jak aplikacja zachowuje się dziś. Przy okazji powstaje pierwsza sensowna dokumentacja funkcjonalna.
Tak, na fizycznych telefonach z Androidem i iOS w chmurze urządzeń oraz na emulatorach. Listę modeli ustalamy według Twoich statystyk, bo aplikacja dla firmy transportowej i sklep z modą mają zupełnie innych użytkowników.
Pojedyncze rundy po 190 zł netto za godzinę, z limitem godzin zapisanym w planie testów. Stałe testy przed każdym wydaniem wyceniamy ryczałtowo na miesiąc, żeby koszt był przewidywalny.
Opisz system i to, co Cię niepokoi. Przygotujemy plan testów i oszacujemy liczbę godzin.
Zapytanie dotarło do nas
Odpowiedź dostaniesz w ciągu dnia roboczego, a jeśli zgłaszasz awarię, która zatrzymuje pracę, zajmiemy się nią w pierwszej kolejności.
Nie mamy tego miasta na liście. Sprawdź pisownię albo wybierz najbliższe duże miasto - pracujemy zdalnie, więc nie wpływa to na zakres obsługi.