Menu

Co to jest dług techniczny i dlaczego testerzy kontroli jakości powinni się nim przejmować?

what is technical debt

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Dług techniczny to metaforyczny pomysł, który dowodzi, że tak jak można napotkać problemy z zadłużeniem w finansach, organizacje programistyczne napotykają na coś podobnego w gromadzeniu się niedokończonych prac podczas poprzednich projektów i wydań wersji / sprintów.

Co to jest dług techniczny?

Reprezentuje wysiłek potrzebny do naprawienia problemów / defektów, które pozostają w kodzie po wydaniu aplikacji. Krótko mówiąc - jest to różnica (pod względem błędów) między tym, czego się oczekuje, a tym, co jest dostarczane.

Kiedy zespół programistów jest zajęty pracą nad projektem i naprawianiem błędów, niestety pojawia się wiele nowych błędów. Poza te, niektóre są naprawione, a inne różnią się w późniejszym wydaniu. Kiedy ta różnorodność problemów rośnie, w pewnym momencie naprawdę trudno jest wypuścić produkt na czas bez żadnych problemów. To jest najgorsza konsekwencja Dług techniczny jeśli nie zostanie rozwiązany na czas.

W tym artykule dowiesz się - czym jest dług techniczny, dlaczego zespół QA powinien się nim przejmować i co najważniejsze, jak nim zarządzać.

czym jest dług technologiczny

wizerunek źródło

Ward Cunningham , założyciel oprogramowania wiki, zrodzony z tego pomysłu już w latach 90., porównując się z wpływem nieściągalnego długu na branżę finansową, dosłownie nawiązując do nieprzyjemnego doświadczenia związanego z koniecznością płacenia nadmiernych odsetek po niespłaceniu pożyczek.

co to jest aplikacja jednostronicowa w angularjs

Wyzwanie, jakim jest rosnące zadłużenie technologiczne na sprint, można zobrazować na rysunku 1.

Należy tu jednak wspomnieć, że istnieje niewielka różnica w znaczeniu długu technicznego (znanego również jako dług kodowy lub dług projektowy) w porównaniu z jego analogią w świecie finansów - ten pierwszy przypomina bardziej abstrakcyjny pomysł , bez matematycznych równań, które pozwolą zobrazować, jak naprawdę narasta zainteresowanie.

narastający dług techniczny

Rys 1: Wizualizacja skalowalnego wzrostu zadłużenia technicznego w trakcie sprintów

Czego się nauczysz:

Dlaczego zespoły kontroli jakości najbardziej cierpią z powodu zadłużenia technicznego

Podczas typowego cyklu projektowania i rozwoju oprogramowania jest kilka rzeczy, które mogą prowadzić do „ dług techniczny ”Jak sytuacja– niewłaściwa dokumentacja , nieodpowiednie testy i naprawianie błędów, brak koordynacji między zespołami, dziedzictwo kod i opóźniona refaktoryzacja , brak ciągła integracja i inne czynniki niekontrolowane.

Na przykład, zaobserwowano, że powielanie kodu może prowadzić do czegoś pomiędzy 25 do 35% dodatkowa praca.

jaki jest najlepszy program do pobierania muzyki dla Androida

Jednak nigdzie nie ma wyzwania wynikające z zadłużenia technicznego są bardziej widoczne niż w przypadku testów zapewniania jakości gdzie zespoły testowe muszą dotrzymywać nieoczekiwanych terminów i wszystko może zostać wyrzucone z biegu.

Jakże często twoi testerzy mierzyli się z rozterkami w ostatniej chwili, kiedy niespodziewanie przychodził kierownik dostawy i powiedział im: „Zespół! Musimy wprowadzić nasz produkt w ciągu tygodnia, przepraszam, że nie możemy tego przekazać na czas. Proszę jak najszybciej zakończyć wszystkie zadania testowe, abyśmy mogli przygotować wersję demonstracyjną ”.

Zasadniczo wszelkie pominięte testy lub podejście „rozwiąż to później” mogą prowadzić do długu technologicznego, takiego jak problem. Brak pokrycia testowego , duże historie użytkowników, krótkie sprinty i inne przykłady „ograniczania możliwości” z powodu presji dostaw odgrywają ogromną rolę w akumulacji długu technicznego w praktyce zapewniania jakości.

Przykład z prawdziwego świata

Sprzedawca internetowy z siedzibą w USA, który jest obecny w wielu witrynach internetowych i aplikacjach mobilnych, znalazł się w prawdziwym wyzwaniu związanym z „długiem technicznym”, gdy złożoność siatki testowej zaczęła się komplikować z każdą nową sprint .

Stało się tak z powodu nagłego zrywu liczby testowanych urządzeń mobilnych, obsługi wielu języków i wykorzystania ponad pół tuzina serwisów społecznościowych.

Przy pokryciu automatyzacji poniżej 40%, wyzwanie związane z długiem technologicznym pojawi się w następujący sposób:

  • Nadmierne zużycie czasu podczas testowania wersji - Wraz ze wzrostem liczby przeglądarek, urządzeń i skryptów z każdym sprintem testowym cykl wydawania byłby coraz bardziej opóźniany, prowadząc do utraty czasu wprowadzenia produktu na rynek.
  • Rosnące koszty zatrudnienia - Liczba testerów potrzebnych do obsługi projektu wzrosła prawie dwukrotnie, co przełożyło się na dodatkowe koszty o wartości 500 tys. USD
  • Złożoność projektu - Wraz z rosnącą złożonością projektu śledzenie przypadków testowych i błędów stało się wyzwaniem
  • Zbyt dużo czasu straconego na szukanie fałszywych trafień - Ponownie, konsekwencja rosnącej złożoności projektów.
  • Zwiększenie nakładu pracy na tworzenie testów aż o 60% - To pasuje do terytorium

Zarządzanie długiem technologicznym w praktyce QA

Większość menedżerów ds. Kontroli jakości impulsywnie postrzega dług technologiczny jako rozsądną konsekwencję skupienia całej energii tylko na bieżącym sprincie, co prowadzi do osiągnięcia pokrycia testu w jakiś sposób ręcznie i całkowicie ignoruje automatyzację.

Jest to znane jako szybkie i brudne podejście co zostało opisane na blogu Martina Fowlera, autora kwadrant zadłużenia technicznego .

Zasady zwinne nakazują wizualizować problem zadłużenia technicznego jako niezdolność do podtrzymania i spełnienia Testy jakości .

W rzeczywistości, na podstawie ankiety przez National Institute of Standards and Technology (NIST) niewystarczające narzędzia i metody testowania co roku kosztują amerykańską gospodarkę 22,2 USD i 59,5 miliarda dolarów , przy czym mniej więcej połowa tych pieniędzy została wydana na dodatkowe testy przez twórców oprogramowania i około połowę przez użytkowników oprogramowania w celu uniknięcia awarii.

Zamiast reagować na awarie w momencie wystąpienia incydentu, proaktywnym podejściem byłoby identyfikowanie usterek po każdym działaniu lub zadaniu, które można zmierzyć. Możesz to wszystko zrobić ręcznie, ale biorąc pod uwagę tysiące scenariuszy testowych dla przeciętnego projektu, automatyczna kontrola testów jest koniecznością.

Wyraźnie, skuteczne testowanie może pomóc ci zdobyć poważny grunt w wojnie z długiem technicznym. Więc co to w zasadzie oznacza? Oznacza to, jak dobrze Twój system jest wyposażony w identyfikację usterek w całej aplikacji.

skuteczność testowania

Jak pokazuje powyższe równanie, efektywność przypadku testowego może teoretycznie zbliżyć się nawet do 100%, jeśli liczba defektów wykrytych przez klienta (tj. Defektów poprodukcyjnych) została dokładnie odwzorowana na liczbę defektów znalezionych na każdym etapie pokrycia testowego.

Aby mieć dobrze zaprojektowane stanowisko testowe, które może dokładnie zmierzyć defekty, gdy tylko się wkradną, niezbędna jest automatyzacja.

Automatyzacja testów pomaga zminimalizować liczbę wykonywanych skryptów poprzez raportowanie wyników i porównywanie ich z wcześniejszymi przebiegami testów. Metoda lub proces używany do wykonywania automatyzacji nazywany jest testem automatyzacja struktura .

Typowe przykłady to gotowe narzędzia komercyjne lub bezpłatne, takie jak Selenium, MonkeyTalk, roboty , Borland SilkCentral, HP Quality Center i IBM Rational Rose .

W przeszłości QA / testowanie było często postrzegane przez organizacje i ich zespoły programistyczne jako działanie wspierające ważniejsze produkty biznesowe, a nie zdyscyplinowana praktyka sama w sobie, która wymagałaby rdzenia, poświęconego skupienia. W rzeczywistości podejście non-core do zapewniania jakości / testowania jest właśnie tym, co doprowadziło przede wszystkim do ciągłego wyzwania związanego z długiem technicznym.

Biorąc pod uwagę szybkie tempo ewolucji umiejętności zapewniania jakości / testowania, które miało miejsce w ciągu ostatniej dekady, organizacjom jest naprawdę ciężko podnieść swoje umiejętności i kompetencje do minimalnych pożądanych poziomów, zgodnie z aktualnymi wzorcami branżowymi.

W rzeczywistości istnieje rosnący trend w branży polegający na tym, że nie mniej niż najbardziej doświadczeni profesjonaliści w dziedzinie automatyzacji testów - coś w rodzaju elitarnych komandosów testowania / zapewniania jakości; są znani jako inżynierowie oprogramowania w teście ( Od ) i testowani programiści ( SDiT ). Tych specjalistów cieszy się dużym zainteresowaniem ze względu na duże doświadczenie w wybranej branży (np. E-commerce) lub w określonej kategorii zawodowej.

Większość firm zajmujących się tworzeniem oprogramowania i produktów, jak teraz mówimy, ma trudności ze znalezieniem pożądanych, wykwalifikowanych zasobów technicznych w obliczu krótszych czasów dostaw. Rozwiązaniem tego wyzwania jest współpraca z zagranicznym graczem zajmującym się automatyzacją QA, który może zająć się brakiem umiejętności dzięki odpowiedniej puli zasobów SDiT / SEiT.

Inne pożądane cechy podmiotu outsourcingowego w zapewnianiu jakości / testowaniu, które okazują się pomocne, obejmują zwinne, zdyscyplinowane podejście do realizacji projektów, wystarczające doświadczenie branżowe, w tym praktyczny dostęp do struktur automatyzacji wielokrotnego użytku i przypadków testowych, a także jasny zamiar oraz umiejętność radzenia sobie z wyzwaniami zespołu na odległość i zderzeniami kulturowymi tak, aby klient nie był obciążony dodatkową pracą w zarządzaniu kontrahentami.

Wniosek

Jak każdy inny dług, dług techniczny może okazać się zmorą przedsiębiorstw, a główną przyczyną jego kumulacji jest brak wdrożenia proaktywnej praktyki zapewniania jakości, która usuwa wszystkie zaległości w automatyzacji.

najlepsze narzędzie do przeglądania kodu dla git

O autorze: To jest post gościnny autorstwa zespołu eInfochips. Wymyślili unikalne podejście zwane Zero zadłużenia technicznego co jest jednym z najbardziej ustrukturyzowanych i skutecznych sposobów stopniowej eliminacji długu technicznego w działaniach QA / automatyzacji. Aby dowiedzieć się więcej o długu technicznym, Obejrzyj ten film na podejściu do redukcji działu technicznego.

Mam nadzieję, że masz jasne pojęcie o tym, czym jest dług techniczny. Daj nam znać, jeśli masz jakieś pytania z tym związane lub jak zarządzać tym w praktyce.

rekomendowane lektury

^