Годишният Доклад за световното качество създаден от Capgemini показва, че 42% от анкетираните посочват „липсата на професионален опит в тестовете“ като предизвикателство при прилагането на тестове за Agile развитие. Докато появата на Пъргав донесе увеличената скорост на повторения за разработване на софтуер, в някои случаи това се дължи на качеството.

Жестоката конкуренция притиска екипите непрекъснато да доставят нови продуктови актуализации, но това понякога идва със собствени разходи, включително намалено внимание към тестването. Някои, като Роб Мейсън, отиват още по-далеч и твърдят това Agile убива тестването на софтуер . Наскоро Facebook промени девиза си от „движи се бързо и чупи нещата“ на „бързо се движи със стабилна инфраструктура“ в опит да разреши изкушенията да жертва качеството.

И така, как може тестването да бъде по-добре интегрирано в новия свят на разработката на софтуер Agile? Пъргаво тестване.

Традиционното тестване е доста тромаво и зависи от много документация. Agile тестване е подход към процеса на тестване, който имитира принципите на Agile софтуерна разработка, като:

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

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

Формализирайте процеса на тестовия цикъл на освобождаване

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

Много отбори правят само едно изграждане след всеки спринт, което не е идеално за Agile проекти. Преминаването към издания веднъж седмично може да бъде от полза, като постепенно се премине към множество компилации на седмица. В идеалния случай, компилациите и тестовете за разработка трябва да се извършват ежедневно, което означава, че разработчиците изпращат код към хранилището всеки ден и компилациите са планирани да се изпълняват в точно определено време. За да направят тази стъпка по-нататък, разработчиците ще могат да внедрят нов код при поискване. За да приложат това, екипите могат да използват процес на непрекъсната интеграция и непрекъснато внедряване (CI / CD). CI / CD ограничава възможността за неуспешно изграждане в деня на голямото издание.

Когато CI / CD и тестовата автоматизация се комбинират, е възможно ранното откриване на критични грешки, което позволява на разработчиците да имат достатъчно време да поправят критични грешки преди планираното освобождаване на клиента. Един от принципите на Agile гласи, че работещият софтуер е основната мярка за напредък. В този контекст формализираният цикъл на издаване прави процеса на тестване по-гъвкав.

Осигурете тестери с инструменти за внедряване

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

Например в един от моите екипи използвахме Git за контрол на версиите и Slack за комуникация. Разработчиците създадоха Slackbot, който имаше достъп до Git, скриптове за разполагане и една виртуална машина. Тестерите успяха да изпратят пинг на бота с име на клон, придобито от GitHub или Jira, и да го разположат в променителна среда.

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

Експериментирайте с TDD и ATDD

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

Развитие, ръководено от тест за приемане (ATDD) следва подобна логика като TDD, но, както подсказва името, се фокусира върху тестове за приемане. В този случай тестовете за приемане се създават преди разработването в сътрудничество с разработчици, изпитатели и заявител (клиент, собственик на продукт, бизнес анализатор и др.). Тези тестове помагат на всички от екипа да разберат изискванията на клиента, преди да се напише код.

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

Открийте неефективността чрез проследяване на движението на картата със задачи

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

Понякога разработчиците бързат с работата си в опит да извлекат функции възможно най-скоро и да „възложат” качеството на тестерите. Такава настройка само премества препятствието по-надолу по спринта. Осигуряването на качеството (QA) е най-важната мрежа за безопасност, която екипът има, но това може да означава, че съществуването на QA дава на разработчиците възможността да се откажат от съображения за качество.

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

• Неговите задачи прекараха почти двойно повече време в тестовата колона на нашата дъска;
• Неговите задачи много по-често биха се връщали от QA за втори или трети кръг на фиксиране.

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

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

Добавете тестова автоматизация към екипа от умения на екипа за QA

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

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

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

Управление на приоритетите за тестване

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

Причината, поради която тестерите понякога работят по множество проекти, е очевидна - рядко има постоянен поток от задачи за тестване, за да запълнят роля на пълен работен ден. Следователно може да е трудно да убедите заинтересованите страни да разполагат със специален ресурс за тестване, разпределен на екип. Има обаче разумни задачи, които тестващият може да изпълни, за да запълни престоя си, когато не се ангажира с тестови дейности.

Поддръжка на клиенти

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

Управление на продукти

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

Тестова автоматизация

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

Резюме: Качествено пъргаво тестване

Правенето на тестовете по-гъвкави е неизбежност, пред която са изправени много екипи за разработка на софтуер. Качеството обаче не трябва да бъде накърнено, като се приеме начин на мислене „възможно най-бързо“. Наложително е Agile преходът да включва преминаване към Agile тестване и има няколко начина да се постигне това:

• Формализирайте процеса на тестовия цикъл на освобождаване.
• Осигурете тестери с инструменти за разполагане.
• Експериментирайте с разработено от тестове и приемане, разработено с тест.
• Открийте неефективността чрез проследяване на движението на картата със задачи.
• Добавете автоматизация на теста към набора от умения на екипа за QA.
• Управлявайте приоритетите на тестера.

Всяка година софтуерът се подобрява и очакванията на потребителите се увеличават. Освен това, тъй като клиентите свикват с висококачествени продукти на водещи софтуерни марки като Google, Apple и Facebook, тези очаквания се пренасят и в други софтуерни продукти. По този начин акцентът върху качеството вероятно ще бъде още по-важен през следващите години. Тези подобрения в процеса на разработка могат да направят тестването по-гъвкаво и да осигурят високо ниво на качество на продукта.

Разбиране на основите

Какви са гъвкавите нива на тестване?

Има няколко нива на тестване, които могат да се използват в Agile: единица, интеграция, система и приемане.

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

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

Имаме ли планове за тестове в Agile?

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

Какво представлява гъвкавата стратегия за тестване?

Една гъвкава стратегия за тестване трябва да посочва как софтуерът се тества в пъргавия екип.