Примерен шаблон за стратегия за пъргав тест
Agile Test Strategy
В гъвкава среда, където работим на кратки спринтове или итерации, всеки спринт е фокусиран само върху няколко изисквания или потребителски истории, така че е естествено документацията да не е толкова обширна, както по брой, така и по съдържание.
Целта на документа за гъвкава стратегия за тестване е да изброи най-добрите практики и някаква форма на структура, която екипите могат да следват. Не забравяйте, че пъргав не означава неструктуриран.
Тук ще разгледаме примерен Agile Test Strategy и какво да включим в документа.
Тестовата стратегия обикновено има мисия, която може да бъде свързана с по-широките бизнес цели и задачи.
Типично изявление на мисията може да бъде:
Постоянно доставяне на работещ софтуер, който отговаря на изискванията на клиента _с помощта на _Осигуряване на бърза обратна връзка _и _Предотвратяване на дефекти, а не откриване на дефекти.
С подкрепата на:
- Не може да се пише код за материал, докато първо не дефинираме критериите / тестовете за приемане
- Историята може да не се счита за завършена, докато не преминат всички нейни тестове за приемане
В документа Agile Test Strategy бих включил и напомняне на всички за осигуряване на качеството
QA е набор от дейности, предназначени да гарантират, че продуктите отговарят на системните и надеждни изисквания на клиентите.
В SCRUM (пъргав) QA е отговорност на всички, а не само на тестерите. QA е всички дейности, които правим, за да гарантираме правилно качество по време на разработването на нови продукти.
Тестови нива
Единично тестване
ЗАЩО: За да се гарантира, че кодът е разработен правилно
КОЙ: Разработчици / Технически архитекти
КАКВО: Всички нови кодове + префакторинг на стария код, както и Javascript тестване на единица
КОГА: Веднага след като е написан нов код
КЪДЕТО: Локален Dev + CI (част от компилацията)
КАК: Автоматизиран, Junit, TestNG, PHPUnit
API / тестване на услуги
ЗАЩО: За да се гарантира, че комуникацията между компонентите работи
КОЙ: Разработчици / Технически архитекти
КАКВО: Нови уеб услуги, компоненти, контролери и др
КОГА: Веднага след като бъде разработен и готов нов API
КЪДЕТО: Локален Dev + CI (част от компилацията)
КАК: Автоматизиран, потребителски интерфейс за сапун, клиент за почивка
Изпитване за приемане
ЗАЩО: За да се гарантира, че очакванията на клиента са изпълнени
КОЙ: Програмист / SDET / Ръчен QA
КАКВО: Проверка на тестове за приемане на историите, проверка на характеристиките
КОГА: Когато функцията е готова и е тествана
КЪДЕТО: CI / Тестова среда
КАК: Автоматизиран (краставица)
Тестване на системата / Тестване на регресия / UAT
ЗАЩО: За да се гарантира, че цялата система работи, когато е интегрирана
КОЙ: SDET / Ръчен QA / Бизнес анализатор / Собственик на продукт
КАКВО: Тестване на сценарии, потребителски потоци и типични потребителски пътувания, тестване на производителността и сигурността
КОГА: Когато изпитването за приемане приключи
КЪДЕТО: Средна сцена
КАК: Автоматизирано (Webdriver) изследователско тестване
Натрупване на продукти
Най-честата причина за неуспех при разработването на софтуер се дължи на неясни изисквания и различно тълкуване на изискванията от различни членове на екипа.
Потребителските истории трябва да бъдат прости, кратки и недвусмислени. Като добра насока е най-добре да следвате INVEST модела за писане на потребителски истории.
Една добра потребителска история трябва да бъде:
Аз независим (от всички останали)
н договаряне (не е конкретен договор за функции)
V разтворим (или вертикален )
Е възможен за зачитане (до добро приближение)
С търговски център (така че да се побере в рамките на итерация)
T estable (по принцип, дори ако все още няма тест за него)
Следният формат трябва да се използва за писане на потребителски истории
As a [role] I want [feature] So that [benefit] Важно е да не забравяте частта „Ползи“, тъй като всеки трябва да е наясно каква стойност добавя, като развива историята.
Критерии за приемане
Всяка от потребителските истории трябва да съдържа критерии за приемане. Това е може би най-важният елемент, който насърчава комуникацията с различни членове на екипа.
Критериите за приемане трябва да бъдат написани едновременно с създаването на потребителската история и трябва да бъдат вградени в тялото на историята. Всички критерии за приемане трябва да бъдат проверявани.
Всеки критерий за приемане трябва да има редица тестове за приемане, представени като сценарии, написани във формат корнишони, напр.
Scenario 1: Title Given [context] And [some more context]... When [event] Then [outcome] And [another outcome]... Исторически семинари / Планиране на спринт
Във всеки семинар за истории всички в екипа научават подробностите за историите, така че разработчиците и QA да знаят обхвата на работата. Всички трябва да имат едно и също разбиране за какво става дума в историята.
Разработчиците трябва добре да разбират техническите подробности, които участват в предоставянето на историята, а QA трябва да знае как ще бъде тествана историята и дали има някакви пречки за тестването на историите.
Предотвратяване на дефекти
В семинари по истории, PO, BA, Dev и QA трябва да бъдат включени.
Трябва да се обмислят сценарии (валидни, невалидни и крайни случаи) (QA може да добави огромна стойност тук, като се мисли абстрактно за историята) и да се запишат във функционални файлове.
Важно е да се отбележи, че именно сценариите (повече от всичко друго) ще разкрият дефекти при тестването на продукта, така че колкото повече усилия и време се отделят за тази дейност, най-добри резултати в края.
Тъй като по-голямата част от дефектите се дължат на неясни и неясни изисквания, тази дейност също ще помогне да се предотврати прилагането на неправилно поведение, тъй като всички трябва да имат еднакво разбиране за историята.
По същия начин, в срещите за планиране на спринта, оценките, дадени за една история, трябва да включват и усилията за тестване, а не само усилията за кодиране. QA (ръчно и автоматизиране) също трябва да присъства по време на срещите за планиране на спринта, за да се предостави оценка за тестване на историята.
Развитие
Когато стартира разработката, трябва да се подкрепи нов производствен код и / или модификация на стария код модулни тестове, написани от разработчици и рецензиран от друг разработчик или квалифициран SDET.
Всеки ангажимент към кодовото хранилище трябва да задейства изпълнение на модулните тестове от CI сървъра. Това осигурява бърз механизъм за обратна връзка на екипа за разработка.
Единичните тестове гарантират, че системата работи на техническо ниво и че няма грешки в логиката.
Тестване за разработчици
Като разработчик, дръжте се така, сякаш нямате никаква QA в екипа или организацията. Вярно е, че QA имат различен начин на мислене, но трябва да тествате доколкото е възможно.
Мислите, че спестявате време, като бързо преминавате към следващата история, но в действителност, когато дефект бъде открит и докладван, отнема повече време, за да се отстрани проблемът, отколкото да се отделят няколко минути, за да се уверите, че функцията работи добре.
Всеки нов код и / или рефакторинг на наследения код трябва да има подходящи модулни тестове, които ще бъдат част от теста за регресия на единици.
Автоматизирани тестове за приемане и нефункционално тестване
Автоматизираните тестове за приемане включват тестове за интеграция и сервизни тестове и тестове за потребителски интерфейс, които имат за цел да докажат, че софтуерът работи на функционално ниво и че отговаря на изискванията и спецификациите на потребителя.
Автоматизираните тестове за приемане обикновено се пишат на език Корнишон и се изпълняват с помощта на BDD инструмент като краставица.
Помня : Не всички тестове трябва да бъдат автоматизирани!
Тъй като тези тестове обикновено изискват комуникация през HTTP, те трябва да бъдат изпълнени в разгърнато приложение, вместо да се изпълняват като част от компилацията.
Нефункционални тестове като тестовете за производителност и сигурност са също толкова важни, колкото и функционалните тестове, поради което трябва да се изпълняват при всяко разполагане.
Тестовете за производителност трябва да проверяват показателите за производителност при всяко внедряване, за да се гарантира, че няма влошаване на производителността.
Тестовете за сигурност трябва да проверяват за основни уязвимости на сигурността, получени от OWASP
Изключително важно е това да бъде напълно автоматизиран процес с много малко поддръжка, за да се извлекат максимални ползи от автоматизираните внедрявания. Това означава, че не трябва да има периодични неуспехи на теста, проблеми със скрипта на теста и нарушена среда.
Неизправностите трябва да се дължат само на истински дефекти на кода, а не на проблеми със скрипта, следователно всеки неуспешен тест, който не се дължи на истински грешки, трябва да бъде незабавно отстранен или премахнат от пакета за автоматизация, за да може да се получат постоянни резултати.
Тестване на регресия
Не очаквайте да откриете много дефекти. Целта им е само да предоставят обратна връзка, че не сме нарушили основната функционалност. Трябва да има много малко количество ръчно тестване за регресия.
Пакет дим - трябва да бъде не повече от 15 минути
Този пакет съдържа само функционалности на високо ниво, за да се увери, че приложението е достатъчно стабилно за по-нататъшно развитие или тестване.
Например за уебсайт за електронна търговия тестовете, включени в този пакет, могат да бъдат:
- Търсене на продукти,
- Преглед на продукта
- Артикул за покупка
- Създаване на акаунт / влизане в акаунт
Пълен пакет за регресия - трябва да бъде не повече от 1 час
Този пакет съдържа пълния набор от тестове за регресия и съдържа всичко останало, което не е включено в димния пакет.
Тук целта е да получите бърза обратна връзка с по-голям набор от тестове. Ако обратната връзка отнема повече от 1 час, тя не е бърза. Или намалете броя на тестовете, като използвате двойна тестова техника, създайте тестови пакети въз основа на риска или изпълнете тестовете паралелно.
UAT и изследователско тестване
Няма причина UAT и изследователските тестове да не могат да се извършват успоредно с автоматизираните тестове за приемане. В крайна сметка те са различни дейности и целят да открият различни проблеми. Целта на UAT е да гарантира, че разработените функции имат бизнес смисъл и са полезни за клиентите.
PO (Собственик на продукта) трябва да изпълнява тестове за приемане от потребителя или Тестове за бизнес приемане, за да потвърдят, че вграденият продукт е това, което се очаква и отговаря на очакванията на потребителя.
Изследователското тестване трябва да се съсредоточи върху потребителските сценарии и да открие грешки, които автоматизацията пропуска. Изследователското тестване не трябва да открива тривиални грешки, а трябва да открива фини проблеми.
Изпълнени критерии
След като всички горепосочени дейности приключат и не бъдат открити проблеми, историята е такава Свършен!
Горните са някои насоки за това какво може да бъде включено в документ за стратегия за гъвкаво тестване. Очевидно това трябва да бъде съобразено с нуждите на вашата организация, но се надяваме, че този шаблон ще ви помогне да създадете свой собствен документ за Agile Test Strategy.
