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

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

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

Какво е гъвкава разработка на софтуер?

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

Гъвкавото разработване на софтуер акцентира върху четири основни ценности.

1. Индивидуални и екипни взаимодействия върху процеси и инструменти
2. Работещ софтуер върху изчерпателна документация
3. Клиентско сътрудничество за договаряне на договори
4. Реагиране на смяна след план

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

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

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

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

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

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

Спорна топка

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

• Scrum магистър
  • Scrum магистър отговаря за настройката на отбора, спринтовата среща и премахва препятствията пред прогреса
• Собственик на продукта
  • Собственикът на продукта създава натрупване на продукти, приоритизира натрупването и отговаря за предоставянето на функционалността при всяка итерация
• Скръм екип
  • Екипът управлява собствената си работа и организира работата, за да завърши спринта или цикъла

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

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

Scrum практики

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

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

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

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

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

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

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

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

Фази на eXtreme програмиране:

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

Планиране

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

Анализ

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

Дизайн

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

Изпълнение

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

Амбалаж

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

Закопчаване

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

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

• Story Cardboard
  • Това е традиционен начин за събиране на всички истории в табло под формата на бележки за проследяване на ежедневните XP дейности. Тъй като тази ръчна дейност изисква повече усилия и време, по-добре е да преминете към онлайн формуляр.
• Онлайн Storyboard
  • Онлайн инструментът Storyboard може да се използва за съхраняване на историите. Няколко отбора могат да го използват за различни цели.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kanban

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

Scrum срещу Kanban

Също така проверете: - Канбан срещу Scrum: Каква е разликата?

Гъвкави показатели

Метриките, които могат да бъдат събрани за ефективно използване на Agile, са:

• Коефициент на съпротивление
  • Усилие в часове, което не допринася за целта за спринта
  • Коефициентът на плъзгане може да бъде подобрен чрез намаляване на броя на споделените ресурси, намаляване на количеството работа, която не допринася
  • Новите оценки могат да бъдат увеличени с процент от коефициента на съпротивление -Нова оценка = (Стара оценка+коефициент на съпротивление)
• Скорост
  • Количество изоставане (потребителски истории), преобразувано във функционалност за доставка на спринт
• Брой добавени модулни тестове
• Времеви интервал, необходим за завършване на ежедневното изграждане
• Грешки, открити в итерация или в предишни итерации
• Изтичане на производствен дефект