Od początku. (wiedza praktyczna)

          Zaczynając od samego początku, myślałam, żeby napisać długi wpis o tym, czym jest testowanie oprogramowania, jednak zdałam sobie sprawę, że nie jest to konieczne, ze względu na fakt, iż ludzie zainteresowani tematem testowania zdają sobie sprawę co to jest.
          Blog będę się starała prowadzić systematycznie, dodając notki z zaznaczeniem w temacie czy jest to wiedza praktyczna czy teoretyczna.

          Zacznę od tego, od czego ja sama zaczęłam przygodę z nauką testowania, czyli od błędów.
Aby móc zacząć testować, trzeba rozróżnić i rozumieć nieco więcej niż samo określenie bug (ang. błąd). Rodzajów jest dużo, ale ja spotkałam się praktycznie w pracy z:

GUI- graphical user interface- są to błędy graficzne, wynikające z niepoprawnie działającego layoutu (ang. wyglądu).
RWD- responsiveness- są to błędy związane z responsywnością strony, czyli np. jeśli strona się nie wczytuje, jest to błąd RWD.
Usability- błędy użyteczności- czyli np. jeśli coś jest nielogiczne, lub jeśli coś jest nieużyteczne
Tekstowe- czyli najzwyczajniej w świecie literówki w tekście.

Jak już napisałam, rodzajów błędów jest dużo, dużo więcej, jednak w pracy testera, a szczególnie na początku jest ogrom wiedzy do przyswojenia, stąd wiedza co to jest RWD czy GUI wydaje się by dostateczna.

Kolejną bardzo istotną wiedzą praktyczną są priorytety błędów. Zaznacza się je przy raportowaniu buga, aby programista wiedział, czy jest to błąd, który należy naprawić "na już", czy jest to mały defekt, którego naprawa może poczekać, bo nie zagraża on funkcjonowaniu aplikacji (np. literówka).
Wyróżniamy:

BLOCKER- aplikacja nie działa, nie ma jak testować

CRITICAL- nie działają główne funkcje, ale można testować

MAJOR- nie działają kluczowe funkcjonalności, ale można je obejść- testowanie jest możliwe

MINOR- nie działają kluczowe funkcje, jednak jest on naprawiany dopiero po poprawkach ważniejszych błędów

TRIVAL/SMALL- kosmetyczne błędy, literówki

Zgłaszanie błędu powinno się pisać według scenariusza, który ułatwi zarówno zreprodukowanie (odtworzenie) defektu jak i da programiście jasny znak, gdzie wystąpił błąd, kiedy, z jakim priorytetem itp.

Scenariusz powinien wyglądać mniej więcej tak:

Tytuł: powinien być krótki, ale treściwy

Priorytet: blocker/critical/major/minor/trival/small

Środowisko testowe: wersja aplikacji, wersja systemu, wersja przeglądarki

Kroki reprodukcji: scenariusz, kroki, które doprowadzą developera do odtworzenia błędu

Rezultat: co okazało się być błędne

Oczekiwany rezultat: jako powinno wyglądać działanie funkcji

Powtarzalność: (reprodukowalność), ile razy błąd wystąpił

Załącznik: zrzuty ekrany, filmik

Narzędzi do testowanie jest w tym momencie od groma i trochę. Wystarczy znać dobrze jedno, aby umieć posługiwać się każdym innym, ponieważ w gruncie rzeczy wszystkie są do siebie podobne i spełniają jedną funkcję- pozwalają raportować błędy

• Jira Software
• GitHub
• Google Sheets
• Trello
• GitLab
• Mantis
• Bugzilla
• Redmine
• Target Proccess

          Na dzisiaj to koniec, mam nadzieję, że fakt iż zaczęłam pisać trochę nie od początku Was nie zrazi, a wręcz przeciwnie- zachęci do poznania pięknego świata testowania :-)