Redakcja
Część pierwszą przeczytasz >>tutaj.
Zespoły webowe w Microsoft, takie jak zespół Skype for Web, były pierwszymi, które zaczęły eksperymentować z nowym podejściem. Zauważono, że tradycyjny model SDET nie nadążał za szybkim tempem rozwoju aplikacji webowych. Zespoły webowe zaczęły wdrażać praktyki ciągłej integracji i dostarczania (CI/CD), które wymagały bardziej elastycznego podejścia do testowania, zaczęto również eksperymentować z łączeniem ról deweloperów i testerów, aby przyspieszyć cykl rozwoju i poprawić jakość kodu.
Ważnym elementem nowego podejścia było stopniowe łączenie ról SDET i SDE. Dzięki niemu, SDET zaczęli brać udział w pisaniu kodu produkcyjnego, a nie tylko testowego, a deweloperzy stali się odpowiedzialni za pisanie testów jednostkowych do swojego kodu. Zaczęto również promować kulturę, w której każdy członek zespołu był odpowiedzialny za jakość kodu, a także wprowadzono praktyki takie jak programowanie w parach i przeglądy kodu, które pomagały w integracji umiejętności testowych i rozwojowych.
Przejście do zintegrowanego modelu QA miało znaczący wpływ na szybkość i efektywność procesu rozwoju oprogramowania. Eliminacja "ping-pongowania" błędów między deweloperami a testerami przyspieszyła cykl rozwojowy, a dzięki temu, że deweloperzy sami pisali i uruchamiali testy jednostkowe uzyskiwano szybszą informację zwrotną o jakości kodu. Lepsza współpraca w zespole i wymiana wiedzy między byłymi SDET a SDE poprawiła ogólną jakość kodu i umożliwiła szybsze wdrażanie zmian, co było szczególnie ważne dla zespołów webowych pracujących w modelu ciągłego dostarczania.
Ta zmiana była początkiem większej transformacji w całym Microsoft, która ostatecznie doprowadziła do formalnego wycofania roli SDET i wprowadzenia nowego podejścia do zapewniania jakości w całej firmie.
Formalne wycofanie roli SDET
W połowie 2014 roku Microsoft oficjalnie ogłosił decyzję o wycofaniu roli SDET. To przełomowe ogłoszenie było kulminacją długotrwałego procesu ewolucji praktyk QA w firmie i odzwierciedlało szersze zmiany w branży IT. Kluczowe punkty ogłoszenia zawierały rezygnację z dedykowanej roli testowej na rzecz zintegrowanego podejścia do jakości i wprowadzenie nowej roli SE (Software Engineer), łączącej kompetencje deweloperskie i testowe. Podkreślało ono również znaczenie jakości jako odpowiedzialności całego zespołu inżynieryjnego.
Przejście z modelu SDET na zintegrowane podejście do QA było złożonym procesem, który obejmował:
- przekwalifikowanie SDET, którzy mieli możliwość przejścia na rolę SE, co wymagało rozszerzenia ich umiejętności deweloperskich
- reorganizację zespołów, podczas której zlikwidowano odrębne zespoły testowe, integrując SDET z zespołami deweloperskim
- zmianę procesów, obejmujących wprowadzenie nowych praktyk, takich jak pair programming i code reviews, aby zapewnić jakość kodu
- organizację warsztatów i szkoleń, aby pomóc inżynierom w dostosowaniu się do nowych ról i odpowiedzialności.
Niestety, tak znacząca zmiana w strukturze organizacyjnej wiązała się również z pewnymi trudnościami obejmującymi dużą liczbę zwolnień, szczególnie wśród pracowników pełniących role testowe. Niektórzy SDET, którzy nie byli w stanie lub nie chcieli przejść na rolę SE, opuścili firmę. Cała restrukturyzacja dotknęła także inne działy, w tym dział Nokia, który Microsoft niedawno przejął.
Korzyści z nowego podejścia
Wbrew początkowym obawom, nowe podejście przyniosło pozytywne efekty w zakresie jakości oprogramowania. Wzrosła liczba testów jednostkowych pisanych przez deweloperów, zaobserwowano również lepsze zrozumienie kodu przez wszystkich członków zespołu, co prowadziło do wcześniejszego wykrywania błędów. Głębsza znajomość kodu przez osoby odpowiedzialne za testy testowanie stało się bardziej efektywne. Zintegrowany model QA przyczynił się również do zwiększenia elastyczności zespołów. Brak podziału na odrębne zespoły dev i test zapewniło szybsze reagowanie na zmiany wymagań, a wdrażanie praktyk DevOps i ciągłego dostarczania stało się o wiele łatwiejsze. Zmiany umożliwiły także bardziej elastyczne przydzielanie zasobów do różnych zadań w zależności od bieżących potrzeb projektu.
Nowe podejście miało również pozytywny wpływ na satysfakcję pracowników. Zaobserwowano lepszą współpracę i komunikację w zespołach, co prowadziło do bardziej satysfakcjonującego środowiska pracy. Wszyscy członkowie zespołu zaczęli odczuwać większe poczucie odpowiedzialności za jakość produktu. Dla wielu inżynierów atrakcyjna stała się możliwość rozwoju szerszego zakresu umiejętności. Mimo początkowych wyzwań związanych z wycofaniem roli SDET, Microsoft zdołał osiągnąć znaczące korzyści dzięki nowemu, zintegrowanemu podejściu do QA. Ta transformacja nie tylko poprawiła jakość oprogramowania, ale także przyczyniła się do stworzenia bardziej elastycznych i zadowolonych zespołów inżynieryjnych.
Zmiany w strategii testowania
Wraz z wycofaniem roli SDET, Microsoft znacząco zmienił swoje podejście do strategii testowania. Te zmiany miały głęboki wpływ na cały proces rozwoju oprogramowania. Przede wszystkim, zredukowano liczbę kompleksowych testów end-to-end. Wcześniej SDET skupiali się głównie na tworzeniu obszernych testów end-to-end. Nowe podejście kładło nacisk na mniejsze, bardziej ukierunkowane testy. Zwiększono nacisk na testy jednostkowe, co skutkowało zobowiązaniem deweloperów do pisania testów dla swojego kodu. Wprowadzono metryki pokrycia kodu testami jednostkowymi jako standard jakości. Skupiono się również na rozwoju testów integracyjnych, zwiększając ich liczbę. Stały się one kluczowym elementem procesu ciągłej integracji (CI).
Zmiana strategii testowania w organizacji wiązała się również z nowym podejściem do automatyzacji testów. Pojawiła się demokratyzacja automatyzacji, co oznaczało, że wszyscy inżynierowie (nie tylko specjaliści od testów) byli odpowiedzialni za tworzenie zautomatyzowanych testów. Jako dodatkowy element, wprowadzono także narzędzia i frameworki ułatwiające tworzenie testów automatycznych. Zautomatyzowane testy były uruchamiane jako część procesu CI/CD, normą stała się praktyka „fail fast”, czyli szybkie wykrywanie i naprawianie błędów. Dużą zmianą było traktowanie testów jako kodu produkcyjnego, dzięki czemu podlegały one tym samym standardom i procesom przeglądu. Wprowadzono praktyki takie jak refaktoryzacja testów i zarządzanie długiem technicznym w testach.
Wnioski
Transformacja praktyk QA w Microsoft dostarczyła cennych lekcji i ukształtowała przyszłe kierunki rozwoju zapewniania jakości w firmie. Uzgodniono, ze jakość nie jest odpowiedzialnością całego zespołu, należy również stale utrzymywać zdolność do zmiany ugruntowanych praktyk i ciągłego doskonalenia procesów i narzędzi QA w odpowiedzi na zmieniające się wymagania rynku. Konieczne jest także zrozumienie, że nie wszystko można (i powinno się) zautomatyzować.
Podsumowując, transformacja praktyk QA w Microsoft nie tylko zmieniła sposób, w jaki firma podchodzi do zapewniania jakości, ale także wpłynęła na cały przemysł IT. Firma nadal ewoluuje swoje podejście, starając się znaleźć optymalne rozwiązania w dynamicznie zmieniającym się środowisku technologicznym.
