Jak współpracować z innymi dostawcami pracując nad jednym produktem

Wbrew temu co można sądzić, testerzy wciąż są niedoceniani przez firmy zamawiające usługi IT. Programista – ok, tworzy kod, coś konkretnego. BA – zbiera i określa wymagania. PM – trzyma to wszystko w kupie. Tester? Po co nam tester?

Pewnie z podobnego założenia wyszedł klient, dla którego mam przyjemność pracować. Oprócz mojego obecnego pracodawcy zatrudnił 3 inne firmy (z Polski, Indii i Hiszpanii). Ich zadaniem było dostarczenie kolejnych funkcjonalności i usprawnień, których my po prostu nie zdążylibyśmy wprowadzić w wyznaczonym czasie. Problem polegał na tym, że inni dostawcy nie posiadali w swoich szeregach działu QA. Niosło to następujące konsekwencje:

  • wpuszczaliśmy obce osoby do swojego kodu, nie bardzo wiedząc jaki jest zakres ich zmian
  • nie wiedzieliśmy czy wprowadzone zmiany nie wpłyną na resztę naszego kodu
  • wprowadzenie nieprzetestowanych zmian mogło być powodem dużej ilości błędów
  • kto w takim razie będzie odpowiedzialny za jakość aplikacji?
  • czy powinniśmy testować nie swój kod?

Z tymi wszystkimi rzeczami musieliśmy się zmierzyć określając dalsze warunki współpracy.

Ostatecznie udało się wypracować następujące wnioski:

  • Każda a firm jest odpowiedzialna za swój kod
  • Zespół developerów z mojej firmy będzie odpowiedzialny za kod review innych vendorów
  • Zespół QA nie ponosi odpowiedzialność za nowe funkcjonalności  od builda XYZ, gdzie zostały one wprowadzone
  • Zespół QA może wykonywać testy nowych funkcjonalności, za które oczywiście klient zapłaci, z zaznaczeniem że nie mając dokumentacji/mocków/designów testy mogą nie pokrywać wszystkiego i w żaden sposób nie świadczą o jakości ( mieliśmy w końcu swoje własne zadania związane z naszymi funkcjonalnościami)

Jak to zwykle w życiu bywa problemy zaczęły się już od pierwszego builda. W ciągu tygodnia powstało ponad 80 bugów, większość krytycznych. Nie łatwiej mieli programiści, którzy bezlitośnie punktowali każdą słabość kodu. Oczywiście klient był na bieżąco informowany o całej sytuacji, widział listę błędów i doskonale zdawał sobie sprawę z niskiej jakości kodu dostarczonego przez innych dostawców. W końcu doszło do sytuacji, gdy zostaliśmy poproszeni przez klienta o poprawienie bugów w kodzie jednego z dostawców. Niosło to za sobą wiele konsekwencji i pytań:

  • wykonując to zadanie pokazalibyśmy się jako rycerz na białym koniu, który w trudnych chwilach  potrafi wyjść i znaleźć rozwiązanie w rudnych chwilach
  • z drugiej strony przyzwyczailibyśmy klienta do tego, że można brać tańszych dostawców, a dopiero w sytuacji kryzysowej wziąć nas droższych, którzy ugaszą pożar
  • czy robiąc poprawkę w nieswoim kodzie, zaczynamy być za niego odpowiedzialni pod względem QA?

Bardzo ważne we współpracy okazało się jasne przedstawienie granic i odpowiedzialności. Z jednej strony nie mogliśmy zostawić klienta z niedziałającą aplikacją, z drugiej chcieliśmy pokazać, że taniej nie zawsze znaczy lepiej i czasami nie ma co skąpić na zespół QA. Warto też być asertywnym i nie dać się wykorzystywać przez dostawców. Oczywiście pomagaliśmy im wykonując testy, natomiast prośby pisane personalnie z pominięciem klienta w stylu: „Czy moglibyście nam wysłać WSZYSTKIE strony z całej aplikacji, na których występuje błąd” spotykały się z naszą odmową. Co najwyżej robiliśmy krótkie sesje eksploracyjne, gdzie staraliśmy się wyłapać ile się dało.  Natomiast nie chcieliśmy robić testów za plecami klienta, za które nie mielibyśmy zapłacone.

Podsumowując, warto zawsze określić granicę odpowiedzialności. Warto też przemyśleć jak bardzo chcemy wpuszczać innych do swojego kodu i czy warto testować nie swoje zmiany. Każda z tych decyzji niesie za sobą konsekwencje, które wpływają na relacji z klientem.