Dekalog PM’a i testera – porozumienie w służbie jakości

Dekalog PM'a i testera

Testerzy stanowią część zespołu projektowego, choć często do projektu włączani są zbyt późno. Nie znają wymagań aplikacji, często nawet nie znają zespołu wdrożeniowego. Pomijani na etapie implementacji, nagle muszą przetestować nowe oprogramowanie. W efekcie piętrzą się pytania, jeśli nie zostaną zadane, testy oprogramowania wypadną słabo. Jak temu zapobiec? Zastosuj poniższe przykazania. Aby miały moc skuteczności, zawrzyj porozumienie co do ich stosowania – obydwie strony powinny być świadome tego, do czego się zobowiązują i co najważniejsze – powinny się z tym zgadzać.

JEŚLI JESTEŚ PM’EM

  1. Zapoznaj testera z aplikacją – przed rozpoczęciem testów zorganizuj spotkanie zespołu projektowego z udziałem testerów – przedstaw cele biznesowe aplikacji, omówcie to, co będzie szczególnie ważne / trudne w trakcie testowania, odpowiadaj na pytania.
  2. Tester nie jest jasnowidzem  – przygotuj możliwie jak najbardziej kompletne i szczegółowe zlecenie testów (opisy zadań, dołączanie dokumentacji, lista osób pracujących w projekcie), wskaż na jakich testach Ci zależy.
  3. Tester nie wie, czym się różni aplikacja od specyfikacji – przekaż zaktualizowaną dokumentację lub wskaż funkcje, które się zmieniły oraz te, o które została rozszerzona specyfikacja na etapie implementacji
  4. Tester to nie haker – przekaż dostępy do aplikacji, baz danych (crony, logi, wgląd do bazy danych) lub poinformuj, kto może je przekazać.
  5. Tester to nie generator danych, tester musi mieć dane – dostarcz poprawne dane wejściowe, jeśli są wymagane, np. pliki do importu. Postaraj się zapewnić testy na rzeczywistych danych.
  6. Aby praca testera miała sens, zapewnij, aby testowane aplikacje nadawały się do tego (wcześniejsza weryfikacja na poziomie programistów oraz team leader’a, testy dymne / peer review).
  7. Wstrzymaj aktualizacje oprogramowania oraz zablokuj dostęp do aplikacji osobom korzystającym z niej, np. klientowi, w trakcie trwania testów, do czasu ich zakończenia.
  8. Tester jest częścią zespołu – zapraszaj testerów na cykliczne spotkania zespołu, angażuj ich w projekt.
  9. Zapewnij sprawną współpracę między zespołem testerów a zespołem programistów na etapie testów, wdrożenia i stabilizacji.
  10. Tester nie wprowadza błędów do aplikacji, tylko je ujawnia – nie obwiniaj testera o błędy.

JEŚLI JESTEŚ TESTEREM

  1. Bądź dokładny i dociekliwy – nie domyślaj się, tylko pytaj, pytaj, jeszcze raz pytaj!
  2. Dokumentacja też ma luki – wykaż się inicjatywą.
  3. Jeśli nie jesteś pewien, jak coś ma działać – pytaj, ale nie pomijaj tego w testowaniu.
  4. W zgłaszaniu błędów nie używaj zwrotów: prawdopodobnie, przypuszczalnie, chyba, wydaje się, że… Dajesz dowód na to, że sam nie jesteś pewien czy opisujesz błąd.
  5. Nie zakładaj, że jeśli coś zazwyczaj działało, to teraz też na pewno działa.
  6. Wczuj się w rolę użytkownika systemu, odpowiedz sobie na pytanie czemu służy aplikacja, którą będziesz testował.
  7. Myśl niestandardowo – użytkownicy końcowi są bardzo kreatywni, myśl tak, jak oni, wykonuj akcje niedozwolone, wyjdź poza przewidziane w dokumentacji ścieżki procesowe.
  8. Jeśli aplikacja działa zgodnie ze specyfikacją, ale niezgodnie np. pod kątem użyteczności – zgłoś to.
  9. Jeśli z jakiegoś powodu nie jesteś pewien, czy znaleziony problem jest błędem – pytaj.
  10. PM jest jak aplikacja, też popełnia błędy – bądź wyrozumiały.
Więcej wpisów autora: Karolina Jarocka

Poker planning – granie w planowanie

Znasz zakres, chcesz oszacować budżet i czas. Chcesz wiedzieć ile “man-days’ów” (ang....
Czytaj dalej

1 komentarz

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *