Когато дадена компания реши да премине от тестване „Водопад“ към „Agile“, кои са най-важните области, върху които да се концентрира за ефективно Agile тестване?
Как се сравнява тестването в Agile с това на модела Waterfall? Какъв набор от дейности е важно за тестерите да знаят и правят?
Първото нещо, което трябва да разберете е, че при пъргавото развитие тестването е интегрирано през целия жизнен цикъл; тестване на софтуера непрекъснато през цялото му развитие.
В традиционния модел Waterfall тестването е голямо усилие и се оставя към края на разработката, докато при Agile тестването е малко, но по-често и се случва по време на разработката.
Тестването по време на разработката също означава, че софтуерът е в освобождаемо състояние по време на разработката, така че може да бъде изпратен, когато е подходящо.
В модела на водопада ни учат да мислим на фази, като фаза на проектиране, фаза на разработка и фаза на тестване. Agile разработката няма отделна фаза на теста като такава. Разработчиците са много по-силно ангажирани с тестване, като пишат автоматизирани повтарящи се модулни тестове, за да валидират своя код.
С автоматизираните модулни тестове тестването може да се извърши като част от компилацията, като се гарантира, че всички функции работят правилно всеки път, когато се произвежда компилацията. Със солидна основа на добро покритие на единични тестове, разработчиците ще се чувстват по-уверени да рефакторират и кода.
Тестването в Agile също означава да започнете рано. Това означава, че QA трябва да се включи още от етапа на проектиране, като разбере характеристиките и историите и започне да подготвя и дори да пише тестове предварително.
Друг важен аспект е автоматизацията на тестовете, за да може тестовете да се извършват непрекъснато, докато продуктът се разработва. Това не са само единични автоматизирани тестове, но и API и UI автоматизирани тестове.
Преминаването към Agile е междуфункционална дейност на проектния екип. Това съвместно усилие не се ограничава до тестовите дейности. Разработчиците трябва да съдействат за тестване на рамки и да създават функции, бизнес анализаторите да съдействат за прецизиране на историята.
Всеки член на екипа работи върху история, докато цялата история не бъде завършена, което означава да бъде разработена и тествана. Дизайнерите, разработчиците и тестерите работят заедно паралелно, така че постигат обща цел и всички те трябва да знаят какво е необходимо, за да се направят нещата.
Изпълнението като екип е основната ключова точка, преминаваща от водопада към пъргавото тестване. Компанията може да реши да премине към Agile Testing, но хората трябва да подкрепят тази промяна, за да успеят.
Стремете се към предотвратяване на дефекти, а не към откриване на дефекти.
С ранното участие на тестерите в проекта те могат да помогнат при идентифицирането на ключови сценарии, които са необходими за тестване на история. Доста често критериите за приемане се пишат като съвместни усилия между собственик на продукт, разработчик и тестер - Трите амиго.
Това гарантира, че каквото и да се изгражда, е проверимо и разбираемо от всички заинтересовани страни. Освен това, тъй като все повече хора участват в определянето на критериите за приемане и „Определението за свършено“, грешките могат да бъдат поправени по-рано и в крайна сметка правилният продукт е изграден правилно.
Всички са ангажирани и са отговорни за качеството на продукта.
В Agile разработката се набляга повече на разговорите и сътрудничеството за изясняване на изискванията повече от традиционния подход на спецификациите и документацията.
Въпреки че изискванията могат да бъдат изяснени до известна степен при пъргавото развитие, все още е възможно изискванията да бъдат двусмислени и непълни, а членовете на екипа да имат различно разбиране за изискванията.
И така, какво означава това за Agile Tester? Обща грижа за тестерите, преминаващи към Agile разработка, е, че те не знаят точно за какво тестват. Те нямат подробни спецификации, срещу които да тестват, така че как могат да ги тестват?
Не е необходимо да имате подробна документация, за да започнете да тествате. Много пъти приличните тестери могат да използват своята преценка и здрав разум, за да валидират даден продукт. Знанието за домейн става изключително важно.
Тестерите трябва да бъдат уверени да работят повече от собствените си познания за това как изглежда доброто. Със сигурност не става въпрос само за следване на тестов скрипт, като се уверите, че софтуерът прави това, което пише в спецификацията.