Гъвкаво тестване: методология и жизнен цикъл

Какво е Agile тестване?

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

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

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

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

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

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

Жизненият цикъл на гъвкаво тестване се осъществява в пет фази, както е показано по-долу.

Фазите са:

• Фаза 1: Оценка на въздействието. Събиране на информация от заинтересовани страни и потребители. Това се нарича още фаза на обратна връзка, защото помага на тестовите инженери да определят цели за следващия жизнен цикъл.
• Фаза 2: Планиране на гъвкаво тестване. Всички заинтересовани страни се обединяват, за да планират графика, обхвата и резултатите от тестването.
• Фаза 3: Готовност за пускане на пазара. Revпрегледайте внедрените функции и решете кои са готови за пускане на пазара и кои трябва да се върнат за разработка.
• Фаза 4: Ежедневни Scrum-ове. Сутрешната среща на живо, където екипът обсъжда състоянието на тестовете и си поставя цели за деня.
• Фаза 5: Тествайте ловкостта Review. Седмични срещи със заинтересованите страни за оценка на напредъка спрямо целите и коригиране на стратегията.

Гъвкав тестов план

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

• Обхват на тестване.
• Тества се нова функционалност.
• Ниво или вид тестване въз основа на сложността на характеристиките.
• Тестване на натоварване и производителност.
• Съображения, свързани с инфраструктурата.
• План за намаляване на риска и смекчаване на последиците.
• Осигуряване на ресурси.
• Резултати и етапи.

Стратегии за гъвкаво тестване

Жизненият цикъл на гъвкавото тестване обхваща четири стратегически етапа.

Итерация 0

По време на първия етап изпълнявате първоначални задачи за настройка. Те включват идентифициране на хора за тестване, инсталиране на инструменти за тестване и планиране на ресурси, като например лаборатория за тестване на използваемостта. Целите на Итерация 0 са:

• Създайте бизнес казус за проекта.
• Дефинирайте граничните условия и обхвата на проекта.
• Очертайте ключовите изисквания и случаите на употреба, които ще доведат до компромиси в дизайна.
• Очертайте една или повече кандидат-архитектурни варианти.
• Идентифицирайте рисковете.
• Оценете разходите и подгответе предварителен план на проекта.

Строителни итерации

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

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

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

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

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

Фаза на освобождаване, край на играта или преход

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

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

производство

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

Квадрантите за гъвкаво тестване

Квадрантите за гъвкаво тестване разделят целия процес на четири области и помагат на екипите да разберат как се извършва гъвкавото тестване.

Гъвкав квадрант I

Квадрант I се фокусира върху качеството на вътрешния код с технологично ориентирани тестове, които подкрепят екипа:

• Единични тестове.
• Компонентни тестове.

Гъвкав квадрант II

Квадрант II съдържа бизнес ориентирани тестове, които подкрепят екипа и се фокусират върху изискванията. Типичната работа в този квадрант включва:

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

Гъвкав квадрант III

Квадрант III предоставя обратна връзка към Квадранти I и II. Тестовите случаи тук често формират основата за автоматизация, а многократните итерационни прегледи изграждат доверие в продукта. Типичната работа включва:

• Тестване за използваемост.
• Проучвателно тестване.
• Сдвоете тестването с клиентите.
• Съвместно тестване.
• Тестване за приемане от потребителя.

Гъвкав квадрант IV

Квадрант IV се концентрира върху нефункционални изисквания, като производителност, сигурност и стабилност. Този квадрант гарантира, че приложението предоставя очакваните нефункционални качества. Типичната работа включва:

• Нефункционални тестове, като например стрес тестове и тестове за производителност.
• Тестване за сигурност, обхващащо удостоверяване и опити за проникване.
• Тестване на инфраструктурата.
• Тестване на миграцията на данни.
• Тестване за мащабируемост.
• Тестване на натоварване.

Предизвикателства пред QA при гъвкавото разработване на софтуер

Гъвкавото внедряване носи реални ползи, но също така създава нови предизвикателства за екипите по осигуряване на качеството:

• На документацията се дава по-нисък приоритет, така че рискът от грешки се увеличава и натискът се измества върху екипа по осигуряване на качеството.
• Новите функции пристигат бързо, което оставя на тестерите по-малко време да проверят най-новите функции спрямо изискванията и бизнес намеренията.
• Тестерите често играят ролята на полу-разработчик.
• Циклите на изпълнение на тестове са силно компресирани.
• Налично е ограничено време за подготовка на плана за тестване.
• Бюджетите за регресионно тестване стават ограничени.
• Тестерите се превръщат от пазители на качеството в партньори по качество.
• Честите промени в изискванията са присъщи на agile методологиите, което е едно от най-големите предизвикателства пред QA.

Риск от автоматизация в гъвкавия процес

Автоматизацията е от съществено значение в agile, но носи рискове, които екипите трябва да управляват активно:

• Автоматизираните тестове на потребителския интерфейс предлагат висока степен на доверие, но са бавни, крехки и скъпи за поддръжка. Повишаването на производителността се наблюдава само когато тестерите знаят как да проектират добри тестове.
• Ненадеждните тестове са сериозен проблем. Коригирането на ненадеждните тестове и фалшиво положителните резултати трябва да остане основен приоритет.
• Автоматизираните тестове, които се изпълняват ръчно, а не чрез CI, рискуват да се отклонят безшумно и да дадат остарели резултати.
• Автоматизацията не замества проучвателното ръчно тестване. За очакваното качество е необходима комбинация от видове и нива на тестване.
• Инструментите за заснемане и повторно възпроизвеждане насърчават скриптове, управлявани от потребителския интерфейс, които са крехки и трудни за поддръжка. Тестовете, съхранявани извън контрола на версиите, добавят ненужна сложност.
• Лошо планираната автоматизация, предприета с цел „спестяване на време“, често се проваля напълно.
• Процедурите по настройка и демонтиране на тестовете са лесни за пропускане при автоматизиране, докато ръчното тестване се справя с тях по естествен път.
• Показатели за производителност като „тестови случаи на ден“ могат да подведат екипите да провеждат безполезни тестове.
• Екипът по автоматизация трябва да бъде ефективен консултант – достъпен, кооперативен и находчив – в противен случай практиката ще се провали.
• Решения, които изискват сериозна текуща поддръжка, могат да надхвърлят стойността, която предлагат.
• Автоматизираните тестове може да не разполагат с необходимия експертен опит за предоставяне на ефективни решения.
• Успешната автоматизация може да изчерпи важните проблеми за решаване и да се отклони към по-малко ценна работа.

Най-добри практики за ефективно Agile тестване

Следните практики поддържат гъвкавото тестване бързо, надеждно и ценно за екипа:

• Shift наляво: започнете тестването по време на изискванията, а не в края на итерацията.
• Свържете се с разработчиците: прегледайте критериите за приемане заедно, така че дефектите да бъдат проектирани, а не кодирани.
• Автоматизация на слоевете: изградете здравословна пирамида от модулни, сервизни и потребителски интерфейсни тестове.
• Поддържайте тестовете независими: изолирайте всеки тест, така че неуспехите да сочат към една-единствена първопричина.
• Track нестабилни тестове: поставяйте под карантина и своевременно коригирайте нестабилните тестове, за да предотвратите ерозия на доверието в пакета.
• Използвайте анализи, подпомогнати от изкуствен интелект: Нека инструментите маркират засегнати тестове, групират неуспехи и предлагат стабилни локатори след всяко сливане.

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