Redakcja
Jako pierwsza duża firma technologiczna, Microsoft wprowadził specjalistyczną rolę inżynierską skupioną na testowaniu, wykraczającą daleko poza tradycyjne manualne testowanie. To podejście stało się wzorem dla wielu innych firm w branży, kształtując standardy QA na całym świecie. Historia zapewnienia jakości w Microsoft sięga wczesnych lat istnienia firmy. W miarę jak produkty Microsoft stawały się coraz bardziej złożone i wszechobecne, firma zdała sobie sprawę z kluczowego znaczenia rygorystycznego testowania dla zapewnienia niezawodności i jakości oprogramowania. W latach 90. Microsoft wprowadził rolę SDET (Software Development Engineer in Test), co było przełomowym momentem w historii QA firmy. Nowa rola łączyła umiejętności programistyczne z głębokim zrozumieniem procesów testowania. W kolejnych dekadach Microsoft kontynuował ewolucję swoich praktyk QA, dostosowując je do zmieniających się potrzeb rynku i nowych paradygmatów rozwoju oprogramowania. Od ery SDET, przez okres intensywnej automatyzacji testów, aż po najnowsze podejście integrujące QA z ogólnym procesem rozwoju oprogramowania - Microsoft nieustannie kształtował i redefiniował znaczenie jakości w branży IT.
Rola SDET wykraczała daleko poza tradycyjne testowanie manualne. Do głównych obowiązków SDET należało:
- pisanie zautomatyzowanych testów, w tym testów jednostkowych, integracyjnych i end-to-end
- projektowanie i implementacja narzędzi i systemów testowych
- analiza funkcjonalności i architektury produktu w celu opracowania skutecznych strategii testowania
- udział w planowaniu funkcjonalności, ze szczególnym uwzględnieniem aspektów związanych z testowaniem i jakością
- prowadzenie manualnych testów w przypadkach, gdy automatyzacja nie była możliwa lub praktyczna
- współpraca z deweloperami w celu poprawy testowalności kodu.
Stosunek liczbowy SDET do SDE
W szczytowym okresie ery SDET, Microsoft utrzymywał typowy stosunek SDET do SDE (Software Development Engineer) na poziomie 1:2. Oznaczało to, że na każdych dwóch deweloperów przypadał jeden SDET. Ten stosunek odzwierciedlał znaczenie, jakie Microsoft przywiązywał do jakości oprogramowania, zapewniając, że testowanie otrzymuje odpowiednią ilość zasobów i uwagi.
Typowa struktura zespołu w Microsoft w erze SDET wyglądała następująco:
- Software Development Engineers (SDE) - odpowiedzialni za pisanie kodu produkcyjnego.
- Software Development Engineers in Test (SDET) - skupieni na pisaniu kodu testowego i budowaniu infrastruktury testowej.
- Product Managers (PM) - zarządzający funkcjonalnościami i wymaganiami produktu.
- Engineering Manager (EM) - nadzorujący cały zespół inżynieryjny.
SDET pracowali ściśle z SDE, ale byli organizacyjnie odrębni. Ta struktura miała na celu zapewnienie niezależności testowania, jednocześnie umożliwiając bliską współpracę między deweloperami a testerami. SDET często mieli własnego lidera, który koordynował wysiłki testowe i współpracował z kierownictwem inżynieryjnym w celu zapewnienia odpowiedniej jakości produktu.
Era SDET w Microsoft trwała przez wiele lat, kształtując podejście do QA nie tylko w samej firmie, ale także w całej branży. Jednak z czasem, wraz z ewolucją praktyk rozwoju oprogramowania, Microsoft zaczął dostrzegać potrzebę zmiany tego modelu, co doprowadziło do kolejnych transformacji w podejściu do zapewniania jakości.
Wyzwania związane z rolą SDET
Mimo że wprowadzenie roli SDET przyniosło wiele korzyści, z czasem zaczęto dostrzegać pewne wyzwania związane z tym modelem. Do głównych problemów, które pojawiły się w erze SDET, należały:
1. Dylematy dotyczące odpowiedzialności za testy jednostkowe
Jednym z głównych punktów spornych był podział odpowiedzialności za pisanie testów jednostkowych. Pojawiły się pytania:
- czy testy jednostkowe powinni pisać deweloperzy (SDE), czy SDET?
- jeśli SDET piszą testy jednostkowe, czy nie prowadzi to do oddzielenia odpowiedzialności za kod od odpowiedzialności za jego jakość?
- czy deweloperzy nie powinni być bardziej zaangażowani w proces testowania swojego kodu?
Te dylematy często prowadziły do nieefektywności i niejasności w procesie rozwoju oprogramowania.
2. Dynamika "my kontra oni" w zespołach
Podział na role SDE i SDET czasami prowadził do niezamierzonej rywalizacji i podziałów w zespołach. SDET byli postrzegani jako "wrogowie", którzy szukają błędów w pracy deweloperów, z kolei deweloperzy mogli czuć się sfrustrowani, gdy ich kod był często odsyłany z powodu błędów znalezionych przez SDET. Taka dynamika mogła w rezultacie prowadzić do napięć w zespole i utrudniać efektywną współpracę.
3. Opóźnienia w procesie rozwoju oprogramowania
Model SDET, mimo swoich zalet, czasami prowadził do opóźnień w procesie rozwoju. Po zakończeniu pracy przez dewelopera kod musiał przejść przez proces testowania prowadzony przez SDET, co wydłużało cykl rozwojowy. Często dochodziło do "ping-pongowania" błędów między deweloperami a SDET, co dodatkowo wydłużało cały proces. Testy end-to-end, które były domeną SDET, mogły być czasochłonne i trudne do utrzymania, co wpływało na ogólną szybkość dostarczania oprogramowania.
Te wyzwania skłoniły Microsoft do przemyślenia swojego podejścia do QA i poszukiwania bardziej zintegrowanego modelu, o którym szerzej opowiedzieliśmy w części II.
