Powrót do bloga
Technology

Znalazłeś błąd na produkcji systemu? Sprawdź, jak zgłosić ten fakt dostawcy, aby mógł szybko zareagować.

Autor Beata Miętka Quality Assurance
Znalazłeś błąd w aplikacji na produkcji? Dowiedz się, jak prawidłowo zgłosić problem dostawcy, aby zapewnić jego sprawną naprawę.

Zakup aplikacji dedykowanej jest rezultatem długotrwałego procesu analizy i wyboru. Inwestycja ta wiąże się z kosztami, ale także stanowi kluczowy element strategii biznesowej.

To naturalne, że firma oczekuje, iż dostarczone rozwiązanie będzie spełniać wszystkie ustalone kryteria, zapewniając przy tym oczekiwane rezultaty. Inwestując, przedsiębiorca oczekuje nie tylko dostarczenia produktu, ale także kompleksowego wsparcia w procesie wdrożenia oraz utrzymania oprogramowania. Obawy te dotyczą zatem nie tylko samego oprogramowania, ale także jakości usług świadczonych przez dostawcę.  

W związku z tym, proces odbioru oprogramowania po zakupie staje się krytycznym punktem w relacji między dostawcą a klientem. Przedsiębiorca oczekuje, że dostarczone rozwiązanie nie tylko spełni techniczne specyfikacje, ale będzie również pozbawione błędów. I tak, o ile błędy krytyczne, mające wpływ na użytkowanie systemu nie są dopuszczalne, o tyle drobne błędy zdarzają się, i to dosyć często, nawet w najlepszych aplikacjach.

Jedna z 7 zasad testowania oprogramowania mówi, że "testowanie gruntowne jest niemożliwe".

Oznacza to, że przetestowanie wszystkiego nie jest możliwe. Manualnie czy też automatycznie – nie jesteśmy w stanie przetestować wszystkich kombinacji danych wejściowych i warunków wstępnych w aplikacji.

Nawet jeśli podjęlibyśmy się próby realizacji takiego wyzwania, to nie byłoby to nieefektywe w kontekście czasu oraz budżetu. 

Co zatem robić, jeśli aplikacja funkcjonuje już na produkcji (jest dostępna dla użytkowników?), a nasze oko wyłapie błąd w jej działaniu? Przede wszystkim – nie wpadać w panikę. Warto przyjrzeć się przede wszystkim, czy występujący błąd jesteśmy w stanie zreplikować (odtworzyć), a następnie zgłosić ten fakt dostawcy.

I tu nasuwa się pytanie jak to zrobić?

Sam kontakt telefoniczny będzie tutaj niewystarczalny, oczywiście możemy zadzwonić do dostawcy i poinformować go o tym fakcie, ale i tak odeśle nas do opisania błędu mailowo lub poprzez zgłoszenie przez system supportujący.

Jakie informacje przygotować, aby dostawca mógł w krótkim czasie naprawić usterkę?

Wystarczy trzymać się poniższego schematu, zawierającego kluczowe informacje o wystąpieniu błędu:

1. Tytuł

W kilku słowach określ, jakiego problemu dotyczy błąd. Dostawca już po tych słowach będzie w stanie przekierować zgłoszenie do osoby, która się nim zajmie.

2. Opis

Postaraj się odtworzyć sytuację, w której natrafiłeś na błąd. Krok po kroku opisz, najlepiej w punktach sekwencję wykonywanych kroków np.

  1. wejdź na stronę (podaj adres strony)

  2. kliknij zakładkę ‘Moje konto’

  3. wprowadź login i hasło

  4. kliknij przycisk ‘Zaloguj’

3. Oczekiwany rezultat a rzeczywisty wynik

Określ, jakie jest działanie aplikacji po wykonaniu powyższych kroków, a jakie powinno być np.

Oczekiwany rezultat

Powinienem zostać zalogowany do mojego konta.

Rzeczywisty wynik

Otrzymuje błąd w postaci komunikatu: “Nieprawidłowy login lub hasło”.

4. Priorytety

Określenie priorytetu jest bardzo ważnym aspektem, od tego zależeć może jak szybko dostawca zajmie się jego rozwiązaniem, bowiem określa on jak bardzo błąd jest znaczący na tle całej aplikacji.

Przyjęta została poniższa skala priorytetyzacji:

  1. blokujący - blokuje korzystanie z aplikacji,

  2. krytyczny - awaria kluczowych funkcji aplikacji,

  3. wysoki - błąd o dużym znaczeniu,

  4. średni - nie jest dużym zagrożeniem dla aplikacji, ale należy do stosunkowo szybko poprawić,

  5. niski - błąd niemający znaczenia dla poprawnego działania aplikacji.

5. Środowisko

Jest ważnym elementem, ponieważ błąd może dotyczyć bezpośrednio środowiska lub jego konfiguracji. Wskaż tutaj system operacyjny z którego korzystasz (np. Windows 10), a w przypadku aplikacji webowych podaj przeglądarkę internetową, której używasz do otwierania aplikacji (np. Mozilla Firefox).

6. Dodatkowe pliki

Są bardzo istotne, szczególnie w sytuacjach, kiedy błąd jest trudny do odtworzenia lub występuje tylko czasami – może to być screen z komunikatem o błędzie lub nagranie video wskazujące, że błąd rzeczywiście wystąpił.

Powyższy screen zawiera, przykład opisanego błędu krytycznego, znalezionego w sklepie internetowym.

Pamiętajmy o tym, że skuteczna komunikacja oraz dostarczenie kompleksowych informacji są niezbędne dla szybkiego rozwiązania problemu przez dostawcę. Zamiast panikować, złapmy oddech i skorzystajmy z powyższego schematu, aby przyczynić się do szybkiej eliminacji błędu z produkcji. 

Beata Miętka
Quality Assurance
Beata to doświadczona ekspertka QA, posiadająca także wykształcenie z fizyki. Jej precyzja i świetne oko do szczegółów, w połączeniu z różnorodnymi zainteresowaniami sprawiają, że jest nieoceniona w dbaniu o wysoką jakość naszych usług.
Udostępnij

Pomożemy Ci osiągnąć cele biznesowe

Pomożemy Ci osiągnąć cele biznesowe

Porozmawiajmy o Twoich wyzwaniach
Podobne artykuły

Czym są “user stories” i dlaczego warto w nie inwestować?
User Stories są kluczowe dla tworzenia oprogramowania, ponieważ jasno definiują potrzeby użytkown...
6 najważniejszych kryteriów wyboru dostawcy IT
Współpraca z zewnętrznymi dostawcami rozwiązań IT stała się integralną częścią strategii wielu pr...
Code review, co to takiego?
Każdy programista na początku swojej drogi zawodowej, (choć zapewne i później) spotka się z pojęc...