Z dziennika kapitana pokładu, czyli … jak stworzyć testową załogę i pokierować na standardy jakościowe
Wprowadzenie:
Jako osoba z dużym bagażem doświadczeń dotyczących zapewnienia jakości w projektach IT, zostałem skierowany do projektu dotyczącego aplikacji ERP w firmie, która miała problemy związane między innymi z jakością oraz procesem wytwarzania oprogramowania. Projekt składał się z aplikacji tzw Human Resources, Finanse i Księgowość oraz pomniejsze aplikacji.
Dzień 1. Gdzie ta keja?
Z chwilą, gdy rozpoczynałem współpracę, okazało się, że w firmie nigdy nie było działu testowego ani pojęcia tester oprogramowania
( firma wtedy była na rynku ponad 27 lat…).
Problemy, z którymi musiałem się zmierzyć:
– stworzenie działu testowego, do wykorzystania miałem tylko dotychczasowe zasoby z firmy
– brak narzędzia do zarządzania zadaniami: to, które było używane, to ich wewnętrzne narzędzie stworzone na podstawie aplikacji do obsługi magazynu (czy może być gorzej ?)
– brak procesu wytwarzania oprogramowania
– brak informacji, co się znajduje w publikowanych wersjach oraz publikacje ścieżkami nieoficjalnymi
– nadanie stabilności aplikacji, która nigdy nie była testowana.
– brak z mojej strony wiedzy merytorycznej odnośnie zagadnień kadrowych oraz finansowych
Moja załoga:
– analityk znający się świetnie na module urlopów z aplikacji HR
– tester bez doświadczenia
– testerka bez doświadczenia od strony IT
– student
Wszystkie osoby nie miały doświadczenia w testowaniu oprogramowania.
Warunki na morzu:
– brak narzędzia do zarządzania zadaniami
– brak dokumentacji systemu
– oczekiwanie szybkiej reakcji na różnorakie awarie w środowiskach produkcyjnych, pod groźbą kar od klienta, idących w miliony złotych
Dzień 2. 10 w skali Beauforta
W pierwszej kolejności skupiłem się na zespole, starałem się poinstruować, co należy do ich obowiązków i jak powinni podchodzić do swojej pracy. Żeby nie było zbyt łatwo okazało się, że firma „żyje swoim własnym życiem” i 20 lat złych nawyków nie jest łatwo zmienić, co skutkowało tym że różne osoby z firmie mające „pilne rzeczy do zrobienia” starały się usilnie dokładać nam nowych zadań za moimi plecami.
Ostatecznie udało się zupełnie odciąć zespół od firmy, stosując prostą zasadę: mój zespół wykonuje tylko i wyłącznie moje polecenia. Dzięki zastosowaniu umiejętności miękkich udało się to zrobić w sposób naturalny, nie robiąc sobie dodatkowych wrogów J.
W bardzo krótkim okresie czasu okazało się, że pracownicy z różnych działów, widząc zmiany zachodzące w zespole testowym, przychodziły do mnie w celu pomocy w rozwiązywaniu różnych problemów.
Dzień 3. Przechyły i przechyły
Kolejne dni i kolejne problemy:
– po publikacji kolejnych wersji gasiliśmy jeden pożar, generując pięć kolejnych
– zadania uznawane za przetestowane okazywały się nie dopracowane lub zawierały błędy, których zespół nie mógł wykryć ze względu na:
- Brak wystarczającej wiedzy merytorycznej
- Brak dokumentacji użytkownika
- Brak dokumentacji systemu
- Brak wystarczającego opisu wykonywanej zmiany
– na tym etapie współpracy mogę z czystym sumieniem stwierdzić, że niestety na pokładzie nie było analityków, tylko osoby wiedzące jak działa system, lecz bez umiejętności przekazania wiedzy w odpowiedni sposób.
– problemy techniczne z wersjami do testów
- Programiści mieli problemy z pracą z GIT
- Merge pomiędzy branchami powodowały usunięcie funkcjonalności wcześniej opublikowanej
- Bierna postawa programistów odnośnie uzyskiwania informacji od analityków
Dzień 4. Bitwa
Biorąc pod uwagę ilość awarii, brak wdrożonych metodyk wytwarzania oprogramowania i brak narzędzi ułatwiających ogarnięcie wszystkich zadań, wymusiłem planowanie zadań testowych dzięki czemu miałem listę najpilniejszych tematów. Dodatkowo udało mi się doprowadzić do sytuacji w której publikacja nowej wersji była uzależniona tylko i wyłącznie od działu testowego.
Dodatkowo aby scalić zespół wprowadziłem scruma, który świetnie się sprawdził.
Dzień 5. Zabierz nas na ląd
Mając opanowane podstawowe aspekty po paru tygodniach, firma postanowiła zmienić swoją pracę i zastosować narzędzie w postaci RedMine. Wspólnie udało się ustalić workflow oraz procedury dotyczące głównych aspektów z życia firmy.
Dzień 6. Morskie opowieści
Można by rzec że kolejny sukces, więc można walczyć dalej w imię polepszenia jakości. Dzięki wprowadzeniu RedMine w prosty i czytelny sposób można było zauważyć jak długo trwa wypuszczenie nowej poprawki czy też nowej funkcjonalności. W tym wypadku powód był bardzo prosty: najczęściej opis wymagań był bardzo skromny i niestety, było bardzo ciężko wymusić ze strony analityków zmianę sposobu pracy. Co ciekawe skromna dokumentacja nie przeszkadzała programistom, do czasu aż wszystkie nasze pytania przenieśliśmy z analityków na programistów w celu przedstawienia im, jak mogą tworzyć funkcjonalność, której nie rozumieją. Zapewniło mi to solidne wsparcie, dzięki któremu wspólnie udało się wymusić odpowiednią jakoś specyfikacji.
Podsumowując:
Powyższy przykład opisuje sytuację z życia wziętą, pokazującą, jak poradzić sobie w sytuacji gdy jakość nie istnieje, produkt nie posiada dokumentacji, firma ma problemy finansowe.
Jakość to nie tylko testerzy i przeprowadzone testy. Jakość to przede wszystkim praca zespołowa, gdzie wszyscy muszą spełniać pewne kryteria, aby każdy mógł wykonywać swoją pracę najlepiej jak potrafi. Jakość zaczyna się na stworzeniu notatki formalnej podczas spotkania z klientem, a kończy na wypuszczonej wersji do klienta – a może ciut dalej, biorąc pod uwagę serwisowanie aplikacji.