Гъвкава методология в софтуерното тестване

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

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

👉 Запишете се за безплатен проект за тестване на софтуер на живо

Основни принципи и ценности на гъвкавото тестване

Гъвкавото тестване се ръководи от набор от принципи и ценности, които насърчават сътрудничеството, адаптивността и непрекъснатото усъвършенстване по време на разработката.

Сътрудничество с клиенти: Гъвкавото тестване набляга на тясното взаимодействие с клиентите, за да се гарантира, че софтуерът отговаря на реалните нужди.

Непрекъснато тестване: Тестването се случва в началото и по време на разработката, не само в края.

Адаптивност към промяна: Приветства променящите се изисквания, насърчавайки гъвкавостта и по-бързата доставка.

Работен софтуер върху документацията: Фокусира се върху функционалните резултати, а не върху дългата документация.

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

Постоянна обратна връзка: Редовните цикли на обратна връзка помагат за бързото идентифициране и разрешаване на проблеми.

Простота и ефективност: Приоритизира важни задачи, за да увеличи максимално стойността и да сведе до минимум разхищението.

Устойчиво темпо: Promoтества балансирани работни натоварвания, за да поддържа дългосрочна производителност и качество.

Жизнен цикъл на Agile тестването

Ето кратко обяснение на жизнения цикъл на agile тестването:

1. Планиране на тестове

В този начален етап, екипът по agile определя обхвата на тестването, целите, ресурсите и сроковете. Тестерите си сътрудничат с разработчици и заинтересовани страни, за да съгласуват целите на тестването с изискванията на спринта.

2. Дизайн на теста

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

3. Изпълнение на теста

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

4. Докладване на дефекти и повторно тестване

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

5. Регресионно тестване

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

6. Затваряне на теста

След края на спринта, екипите преглеждат тестовите показатели, документират извлечените поуки и гарантират, че резултатите отговарят на определението за „Готово“.

Гъвкав процес

Проверете процеса на Agile методология, даден по-долу, за да създадете бързо успешни системи:

Има различни Гъвкави методи присъстват в гъвкавото тестване и те са изброени по-долу:

Спорна топка

SCRUM е agile метод за разработка, който се концентрира конкретно върху това как да се управляват задачи в екипна среда за разработка. По принцип Scrum произлиза от концепция, която се появява по време на мач по ръгби. Scrum вярва в овластяването на екипа за разработка и препоръчва работата в малки екипи (например от 7 до 9 членове). Agile и Scrum се състоят от три роли, а техните отговорности са обяснени, както следва:

Scrum магистър

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

Собственик на продукта

Собственикът на продукта (Product Owner) създава продуктовия backlog, приоритизира backlog-а и е отговорен за предоставянето на функционалността на всяка итерация.

Скръм екип

Екипът управлява собствената си работа и я организира, за да завърши спринта или цикъла.

Продуктов бекъп

Това е хранилище, където са изискванията tracс подробности за броя на изискванията (потребителски истории), които трябва да бъдат изпълнени за всяко издание. Той трябва да се поддържа и приоритизира от Собственика на продукта и трябва да се разпространява до Scrum екипа. Екипът може също да поиска добавяне, промяна или изтриване на ново изискване.

Scrum практики

Практиките са описани подробно в този раздел:

Процесен поток на методологиите на Scrum:

Процесен поток на Scrum тестване е както следва:

• Всяка итерация на scrum е известна като Sprint
• Списъкът с неизпълнени задачи е списък, в който са въведени всички подробности, необходими за получаване на крайния продукт.
• По време на всеки Sprint, най-добрите потребителски истории от продуктовия backlog се избират и се превръщат в Sprint запас
• Екипът работи по дефинирания спринт backlog
• Екип проверява за ежедневната работа
• В края на спринта екипът предоставя функционалността на продукта.

Екстремно програмиране (XP)

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

Бизнес изискванията са събрани по отношение на истории. Всички тези истории се съхраняват на място, наречено паркинг.

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

Фази на екстремното програмиране

В метода Agile XP има 6 фази, които са обяснени по следния начин:

Планиране

• Идентифициране на заинтересовани страни и спонсори
• Изисквания за инфраструктура
• Охрана-свързана информация и събиране
• Споразумения за ниво на обслужване и техните условия

Анализ

• Заснемане на истории на паркинга
• Приоритизирайте историите на паркинга
• Пречистване на истории за оценка
• Дефиниране на итерация SPAN (време)
• Планиране на ресурсите както за екипите за разработка, така и за екипите за осигуряване на качеството

Дизайн

• Разбивка на задачите
• Подготовка на тестов сценарий за всяка задача
• Регресионна автоматизирана рамка

Изпълнение

• Кодиране
• Единично тестване
• Изпълнение на ръчни тестови сценарии
• Генериране на отчет за дефекти
• Преобразуване на ръчни в автоматизирани регресионни тестови случаи
• Преглед в средата на итерацията
• Преглед на края на итерацията

Увийтеping

• Малки издания
• Тестване на регресия
• Демонстрации и рецензии
• Разработвайте нови истории въз основа на нуждите
• Подобрения в процеса, базирани на коментари от прегледа в края на итерацията

Закопчаване

• Пилотно стартиране
• Обучение
• Стартиране на производство
• Гарантиране на SLA гаранция
• Revт.е. SOA стратегия
• Поддръжка на производството

Налични са два сценария track работата ежедневно и те са изброени по-долу за справка.

Story Cardboard

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

Онлайн Storyboard

Онлайн инструментът Storyboard може да се използва за съхраняване на историите. Няколко отбора могат да го използват за различни цели.

Кристални методологии

Кристалната методология се основава на три концепции

1. Чартиране: Различните дейности, включени в тази фаза, са създаване на екип за разработка, извършване на предварителен анализ на осъществимостта, разработванеping първоначален план и усъвършенстване на методологията за разработка
2. Циклична доставка: Основната фаза на разработка се състои от два или повече цикъла на доставка, по време на които
   1. Екипът актуализира и усъвършенства плана за пускане на пазара.
   2. Реализира подмножество от изискванията чрез една или повече итерации на интеграция на програмни тестове
   3. Интегрираният продукт се доставя на реални потребители
   4. Revт.е. на плана на проекта и приетата методика на разработка
3. Завършване: Дейностите, извършвани в тази фаза, са внедряване в потребителската среда, както и прегледи и рефлексии на внедряването.

Динамичен метод за разработка на софтуер (DSDM)

DSDM е a Бързо разработване на приложения (RAD) подход към разработката на софтуер и осигурява гъвкава рамка за изпълнение на проекти. Важният аспект на DSDM е, че от потребителите се изисква активно участие, а на екипите се дава правомощията да вземат решения. Честата доставка на продукт става активен фокус с DSDM. Техниките, използвани в DSDM, са

1. Време BoxING
2. Правила на MOSCoW
3. Прототиping

Проектът DSDM се състои от 7 фази

1. Предпроект
2. Предпроектно проучване
3. Бизнес проучване
4. Итерация на функционален модел
5. Проектиране и изграждане на итерация
6. изпълнение
7. Следпроект

Разработено от функции (FDD)

Този метод е фокусиран върху „проектиране и изграждане“ на функции. За разлика от други Agile методи в софтуерното инженерство, FDD описва много специфични и кратки фази на работа, които трябва да се изпълняват отделно за всяка функция. Той включва преглед на домейна, проверка на дизайна, промотиране до изграждане, проверка на кода и проектиране. FDD разработва продуктов ключ.ping имайки предвид следните неща

1. Моделиране на обекти в домейн
2. Развитие по признак
3. Собственост на компонент/клас
4. Екипи за функции
5. Инспекциите
6. Управление на конфигурацията
7. Редовни компилации
8. Видимост на напредъка и резултатите

Lean Разработка на софтуер

Методът за Lean разработка на софтуер се основава на принципа „Производство точно навреме“. Целта му е да увеличи скоростта на разработване на софтуер и да намали разходите. Lean разработката може да се обобщи в седем стъпки.

1. Премахване на отпадъците
2. Усилване на обучението
3. Отлагане на ангажимент (вземане на решение възможно най-късно)
4. Ранна доставка
5. Овластяване на екипа
6. Изграждане на Integrity
7. Оптимизирайте цялото

Kanban

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

Какви са предимствата на Agile тестването?

Ето защо agile тестването е полезно:

• Ранна и непрекъсната обратна връзка: Тестването започва от самото начало на проекта, така че грешките и недостатъците в дизайна се откриват рано - преди да се превърнат в скъпоструващи бедствия.
• По-бърза доставка: Тестването протича успоредно с разработката, което позволява по-бързи пускания на пазара и гарантира, че използваемият софтуер се доставя в по-кратки, непрекъснати цикли.
• По-добро сътрудничество: Тестерите, разработчиците и собствениците на продукти работят в тясно сътрудничество, насърчавайки споделеното разбирателство и намалявайки недоразуменията.
• Подобрено качество: Честото тестване и автоматизацията помагат за поддържане на постоянно качество и откриване на проблеми в ранен етап на всяка итерация.
• Гъвкавост за промяна: Гъвкавото тестване се адаптира лесно към променящите се изисквания, позволявайки на екипите да се променят, без да провалят целия проект.
• По-висока удовлетвореност на клиентите: Редовните цикли на обратна връзка гарантират, че крайният продукт отговаря на очакванията на потребителите и реалните нужди.

Как да преодолеем предизвикателствата на Agile тестването?

Ето най-добрите начини за преодоляване на предизвикателствата, които възникват при agile тестването:

• Предизвикателство: Бързите промени в изискванията затрудняват поддържането на стабилни планове за тестване.
  Решение: Внедрете адаптивни стратегии за тестване с гъвкави рамки за автоматизация и непрекъснати цикли на обратна връзка, за да се съобразите ефективно с променящите се изисквания.
• Предизвикателство: Кратките цикли на разработка намаляват времето, необходимо за цялостно тестване.
  Решение: Приоритизирайте тестването, базирано на риска, автоматизирайте регресионните пакети и интегрирайте непрекъснатото тестване в ранен етап от разработката.
• Предизвикателство: Честите промени в кода затрудняват поддържането на достатъчно тестово покритие.
  Решение: Използвайте автоматизирани модулни и интеграционни тестове, подкрепени от инструменти за непрекъсната интеграция, за да осигурите последователно покритие и бърза валидация.
• Предизвикателство: Липсата на сътрудничество води до недоразумения между разработчиците и тестерите.
  Решение: Насърчавайте сътрудничеството чрез ежедневни срещи, споделена документация и междуфункционално сдвояване, за да съгласувате целите на тестването с целите за разработка.
• Предизвикателство: Управлението на последователни и точни тестови данни става все по-предизвикателно.
  Решение: Използвайте генериране на синтетични данни и тестови набори от данни с контролирани версии, за да осигурите повтаряеми и надеждни тестови среди.
• Предизвикателство: Балансиране на бързите срокове за доставка с поддържането на високо качество.
  Решение: Интегрирайте контролери за качество в рамките на CI/CD тръбопроводите и наложете автоматизирани проверки на качеството, без да забавяте циклите на доставка.
• Предизвикателство: Agile екипите често изпитват затруднения поради минимална или липсваща документация.
  Решение: Поддържайте лека, динамична документация, свързана с потребителски истории и тестови случаи, за да запазите яснотата, без да жертвате гъвкавостта.
• Предизвикателство: Тестовите среди често не са синхронизирани с производствените настройки.
  Решение: Приемете контейнеризирани среди и инструменти за управление на конфигурацията, за да поддържате последователни настройки по време на разработка, тестване и производство.

Гъвкав модел срещу модел на водопад

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

Гъвкав модел	Модел на водопад
Дефиниция на Agile методология в софтуерното тестване: Agile методологиите предлагат постепенен и итеративен подход към софтуерния дизайн.	Разработката на софтуера протича последователно от началната до крайната точка
- Гъвкав процес в софтуерното тестване се разделя на отделни модели, върху които работят дизайнерите	Процесът на проектиране не е разделен на отделни модели
Клиентът има ранни и чести възможности да разгледа продукта и да вземе решения и промени в проекта.	Клиентът може да види продукта само в края на проекта
Гъвкавият модел при тестване се счита за неструктуриран в сравнение с водопадния модел	Моделите „Капаците“ са по-сигурни, защото са толкова ориентирани към плана.
Малките проекти могат да бъдат реализирани много бързо. За големи проекти е трудно да се оцени времето за разработка.	Всякакви проекти могат да бъдат оценени и завършени
Грешката може да бъде поправена по средата на проекта	Едва накрая се тества целият продукт. Ако се открие грешка в изискването или трябва да се направят някакви промени, проектът трябва да започне отначало.
Процесът на разработка е итеративен и проектът се изпълнява в кратки (2-4 седмици) итерации. Планирането е много малко.	Процесът на разработка е поетапен, а фазата е много по-голяма от итерация. Всяка фаза завършва с подробно описание на следващата фаза.
Документацията получава по-малък приоритет от разработка на софтуер	Документацията е основен приоритет и може дори да се използва за обучение на персонала и надграждане на софтуера с друг екип.
Всяка итерация има своя собствена фаза на тестване. Това позволява прилагането на регресионно тестване всеки път, когато се пускат нови функции или логика.	Едва след фазата на разработка се изпълнява фазата на тестване, тъй като отделните части не са напълно функционални.
При гъвкавото тестване, когато една итерация приключи, на клиента се доставят функции на продукта, които могат да бъдат доставени. Новите функции са използваеми веднага след доставката. Това е полезно, когато имате добър контакт с клиентите.	Всички разработени функции се предоставят наведнъж след дългата фаза на внедряване
Тестерите и разработчиците работят заедно	Тестерите работят отделно от разработчиците
В края на всеки спринт се извършва приемане от потребителя	Приемането от потребителя е извършва в края на проекта
Изисква тясна комуникация с разработчиците и съвместен анализ на изискванията и планиране	Разработчикът не участва в процеса на изисквания и планиране. Обикновено има забавяне във времето между тестовете и кодирането.

Също така проверете: - Agile срещу Waterfall: Познайте разликата между методологиите

Въпроси и Отговори