Ewolucja praktyk zapewniania jakości w Microsoft. Case study, cz. 1

Ewolucja praktyk zapewniania jakości w Microsoft. Case study, cz. 1
Microsoft, jako jeden z gigantów branży technologicznej, odegrał poważną rolę w kształtowaniu praktyk zapewniania jakości w przemyśle oprogramowania. Firma ta nie tylko stworzyła niektóre z najpowszechniej używanych systemów operacyjnych i aplikacji na świecie, ale także zrewolucjonizowała podejście do testowania oprogramowania.

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:

  1. Software Development Engineers (SDE) - odpowiedzialni za pisanie kodu produkcyjnego.
  2. Software Development Engineers in Test (SDET) - skupieni na pisaniu kodu testowego i budowaniu infrastruktury testowej.
  3. Product Managers (PM) - zarządzający funkcjonalnościami i wymaganiami produktu.
  4. 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 opowiemy w części II. 

Źródła:
https://newsletter.pragmaticengineer.com/p/how-microsoft-does-quality-assurance

To powinno Cię zainteresować