Меню

Какво е технически дълг и защо тестерите за QA трябва да се притесняват за това?

what is technical debt

Опитайте Нашия Инструмент За Премахване На Проблемите

Технически дълг е метафорична идея, която твърди, че точно както човек може да срещне проблеми с дълга във финансите, софтуерните организации срещат нещо подобно при натрупването на недовършена работа по време на минали проекти и издания / спринтове на версии.

Какво е технически дълг?

Той представлява усилието, необходимо за отстраняване на проблемите / дефектите, които остават в кода, когато дадено приложение бъде пуснато. С прости думи - това е разликата (по отношение на грешки) между очакваното и доставеното.

Когато екипът за разработки е зает да работи по проект и да отстранява грешки, за съжаление се появяват много нови грешки. Извън тези, някои са фиксирани, а други се различават за по-късно издаване. Когато това различно от проблемите продължава да се увеличава, в един момент става наистина трудно да пуснете продукта навреме без никакви проблеми. Това е най-лошата последица от Технически дълг ако не се реши навреме.

В тази статия ще научите - какво е технически дълг, защо екипът за QA трябва да се тревожи за него и най-важното как да го управлявате.

какво е технологичен дълг

изображение източник

Уорд Кънингам , основателят на wiki софтуер, замислена от тази идея още през 90-те години, провеждайки паралели с въздействието на лошия дълг върху финансовата индустрия, буквално намеквайки за неприятния опит да се налага да плащате прекомерни лихви след неизпълнение на задълженията по заемите.

най-добрият софтуер за клониране на устройства windows 10

Предизвикателството за нарастване на технологичния дълг на спринт може да бъде визуализирано на фиг. 1.

Тук обаче трябва да се спомене, че има малка разлика в значението на техническия дълг (известен също като кодов дълг или дълг по дизайн) от съответната му аналогия в света на финансите - първият е по-скоро като абстрактна идея , без математически уравнения, които да визуализират как наистина се натрупва лихвата.

нарастващ технически дълг

Фиг. 1: Визуализиране на мащабируемото увеличение на технологичния дълг през спринтовете

Какво ще научите:

Защо екипите за QA страдат най-много поради технически дълг

По време на типичен цикъл на проектиране и разработка на софтуер има няколко неща, които могат да доведат до „ технически дълг ”Подобна ситуация– неправилна документация , неадекватно тестване и отстраняване на грешки, липса на координация между отбори, наследство код и забавено рефакториране , отсъствие на непрекъсната интеграция и други извън контролни фактори.

Например, беше забелязано, че усилията за дублиране на код могат да доведат до нещо между 25 да се 35% допълнителна работа.

как да създам графика в java -

Никъде обаче няма предизвикателствата поради технически дълг са по-очевидни, отколкото при тестването на QA където тестовите екипи трябва да спазват неочаквани срокове и всичко може да бъде изхвърлено от съоръжения.

Колко често вашите тестери се сблъскват със затруднения в последния момент, когато неочаквано мениджърът на доставките дойде и им каза: „Екип! Трябва да пуснем продукта си след седмица, съжаляваме, че не успяхме да го съобщим навреме. Моля, приключете с всички тестови задачи спешно, за да сме готови с демонстрацията. “

По принцип, всички пропуснати тестове или подходът „решете го по-късно“ може да доведе до проблем като технологичен дълг. Липса на покритие на теста , големи потребителски истории, кратки спринтове и други примери за „рязане на ъглите“, дължащи се на натиска при доставката, играят огромна роля зад натрупването на технически дълг в QA практиката.

Пример от реалния свят

Базиран в САЩ онлайн търговец на дребно със значително присъствие в множество уебсайтове и мобилни приложения се озова в реално предизвикателство за „технически дълг“, когато сложността на тестовата мрежа започна да се усложнява с всяка нова спринт .

Това се случи поради внезапния скок в броя на мобилните устройства, които трябва да бъдат тествани, няколко езика, които трябва да се поддържат, и повече от половин дузина сайтове за социални мрежи, които трябва да бъдат използвани.

С покритие на автоматизацията по-малко от 40%, предизвикателството с технологичния дълг ще се появи по следните начини:

  • Прекомерна консумация на време при тестване на освобождаване - С нарастването на броя браузъри, устройства и скриптове с всеки тестов спринт, цикълът на пускане ще продължи да се забавя, което води до загуба на време за пускане на пазара.
  • Нарастващите разходи за наемане - Броят на тестерите, необходими за подкрепа на проекта, се удвои почти два пъти, което доведе до допълнителни разходи в размер на 500 000 долара
  • Сложност в проекта - С нарастващата сложност на проекта, проследяването на тестови случаи и грешки се превръщаше в предизвикателство
  • Твърде много време се губи в преследване на фалшиви положителни резултати - Отново, отпадане от нарастващата сложност на проекта.
  • Увеличение на усилията за разработване на тестове с до 60% - Върви с територията

Техническо управление на дълга в практиките за осигуряване на качеството

Повечето мениджъри на QA импулсивно разглеждат технологичния дълг като разумна последица от фокусирането на цялата си енергия само върху текущия спринт, което води до постигане на тестовото покритие по някакъв начин чрез ръчни средства и напълно игнорира автоматизацията.

Това е известно като бърз и мръсен подход което е отразено в блог от Мартин Фаулър, авторът на технически дългов квадрант .

Agile принципите диктуват, че ние визуализираме проблема с технологичния дълг като невъзможност да го поддържаме и да се срещнем QA еталони .

Всъщност, въз основа на проучване от Националния институт за стандарти и технологии (NIST), недостатъчните инструменти и методи за тестване ежегодно струват на американската икономика $ 22,2 и 59,5 милиарда долара , с приблизително половината от тези пари, изразходвани за допълнителни тестове от разработчици на софтуер и около половината от софтуерни потребители, за да се избегнат грешки.

Вместо да реагираме на неуспехи, когато и когато се случи инцидентът, проактивен подход би бил идентифицирането на дефекти след всяка дейност или задача, които могат да бъдат измерени. Можете да направите всичко това ръчно, но като се имат предвид хилядите сценарии за тестови случаи за среден проект, автоматизираният контрол на тестовете е необходимост.

Ясно е, ефективно тестване може да ви помогне да спечелите сериозни позиции във войната с технически дълг. И така, какво всъщност означава това? Това означава колко добре е оборудвана вашата система за идентифициране на дефекти в цялостното приложение.

най-добрият безплатен компютър за почистване и ремонт

тестване на ефективността

Както показва горното уравнение, ефективността на тестовите случаи може теоретично да се доближи дори до 100%, ако броят на намерените от клиента дефекти (т.е. дефекти в постпродукцията) е бил точно съпоставен с броя на дефектите, открити на всеки етап от тестовото покритие.

За да имате добре проектирано тестово легло, което може точно да измерва дефектите веднага щом проникнат, автоматизацията е задължително условие.

Автоматизация на тестване ви помага да сведете до минимум броя на изпълняваните скриптове, като отчитате резултатите и ги сравнявате с по-ранни тестови изпълнения. Методът или процесът, който се използва за изпълнение на автоматизацията, се нарича тест автоматизация рамка .

Типични примери са търговски готови или безплатни инструменти като Selenium, MonkeyTalk, роботи , Borland SilkCentral, Център за качество на HP и IBM Rational Rose .

В миналото QA / тестовете често се възприемаха от организациите и техните софтуерни екипи като помощна дейност за по-важните бизнес резултати, а не като дисциплинирана практика сама по себе си, която ще изисква ясен, специален фокус. Всъщност несъщественият подход към QA / тестване е именно това, което е довело до продължаващото предизвикателство на техническия дълг на първо място.

Като се има предвид бързият темп на развитие на QA / уменията за тестване, настъпили през последното десетилетие, организациите изпитват реални трудности да надградят своите умения и компетенции до минималните нива, желани според настоящите отраслови критерии.

Всъщност има нарастваща тенденция в индустрията да се задоволява с не по-малко от най-опитните професионалисти в автоматизацията на тестовете - нещо като елитните командоси на тестване / QA; те са известни като софтуерни инженери в тест ( От ) и разработчици на софтуер в тест ( SDiT ). Тези специалисти са много търсени поради техния богат опит в избрана вертикала (например електронна търговия) или определена професионална категория.

Повечето компании за разработка на софтуер и продукти, както говорим сега, се борят да намерят желаните, квалифицирани технически ресурси в условията на по-кратки срокове за доставка. Решението на това предизвикателство е да си партнирате с офшорни автоматични плейъри за QA, които могат да се справят с недостига на вашите умения с правилния набор от SDiT / SEiT ресурси.

Други желани атрибути на аутсорсинг играч в QA / Тестване, които се оказват полезни, включват пъргав, дисциплиниран подход към изпълнението на проекта, достатъчен опит в индустрията, включително практически достъп до рамки за автоматизация за многократна употреба и тестови случаи, и не на последно място, ясно намерение и способност за справяне с предизвикателствата на отдалечения екип и културните сблъсъци, така че клиентът да не бъде обременен с допълнителна работа в управлението на изпълнители.

Заключение

Подобно на всеки друг дълг, техническият дълг може да се окаже проклятието на предприятията и основната причина за натрупването му е неприлагането на проактивна QA практика, която премахва всички изоставания в автоматизацията.

За автора: Това е гост публикация от екипа на eInfochips. Те са измислили уникален подход, наречен Технически дълг нула което е един от най-структурираните и ефикасни начини за постепенно премахване на техническия дълг в QA / дейности по автоматизация. За да научите повече за технологичния дълг, гледай това видео относно подход за намаляване на технологичния отдел.

Надявам се да получите ясна представа за това какво е Технически дълг. Уведомете ни, ако имате някакви въпроси, свързани с него, или как да го управлявате на практика.

Препоръчително четене

^