Шаблон за пример за стратегија за агилен тест

Стратегија за агилен тест

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

Целта на документот за стратегија за агилен тест е да ги наведе најдобрите практики и одредена форма на структура што тимовите можат да ја следат. Запомнете, агилното не значи неструктурирано.

Еве, погледнеме примерок Стратегија за агилен тест и што да вклучиме во документот.

Стратегијата за тестирање обично има изјава за мисија што може да биде поврзана со пошироките деловни цели и цели.

Типична изјава за мисија може да биде:

Постојано да испорачуваме работен софтвер што одговара на барањата на клиентот _ со помош на _Обезбедување брз фидбек _ и _ Превенција на дефект, наместо Откривање дефекти.



Поддржано од:


  • Ниту еден код не смее да биде напишан за приказна се додека не ги дефинираме неговите критериуми / тестови за прифаќање

  • Приказната можеби не се смета за комплетна додека не поминат сите нејзини тестови за прифаќање

Во документот за стратегија за агилен тест, јас исто така ќе вклучам потсетник до сите за осигурување на квалитетот


  • ОК е збир на активности наменети да обезбедат дека производите ги задоволуваат барањата на клиентите на систематски, сигурен начин.


  • Во SCRUM (агилниот) ОК е одговорност на сите, не само на тестерите. ОК се сите активности што ги правиме за да обезбедиме правилен квалитет за време на развојот на нови производи.

Нивоа на тест

Единица за тестирање

ЗОШТО: За да се обезбеди правилно развивање на кодот

СЗО: Развивачи / Технички архитекти

ШТО: Целиот нов код + повторно факторирање на наследниот код, како и тестирање на единицата Javascript

КОГА: Веднаш штом ќе се напише нов код

КАДЕ: Локален Dev + CI (дел од конструкцијата)

КАКО: Автоматски, Junit, TestNG, PHPUnit

АПИ / Тестирање на услугата

ЗОШТО: За да се обезбеди комуникација помеѓу компонентите да работи

СЗО: Развивачи / Технички архитекти

ШТО: Нови веб-услуги, компоненти, контролори, итн

КОГА: Веднаш штом ќе се развие и подготви нов API

КАДЕ: Локален Dev + CI (дел од конструкцијата)

КАКО: Автоматизиран, интерфејс за сапуница, клиент за одмор

Тестирање на прифаќање

ЗОШТО: За да се осигуриме дека очекувањата на клиентот се исполнети

СЗО: Инвеститорот / SDET / Прирачник ОК

ШТО: Потврдување на тестови за прифаќање на приказните, проверка на одликите

КОГА: Кога одликата е подготвена и единицата е тестирана

КАДЕ: CI / тест околина

КАКО: Автоматски (краставица)

Тестирање на системот / Тестирање на регресија / UAT

ЗОШТО: Да се ​​осигура дека целиот систем работи кога е интегриран

СЗО: SDET / Рачен QA / деловен аналитичар / сопственик на производ

ШТО: Тестирање на сценарио, проток на корисник и типични патувања до корисник, тестирање на перформанси и безбедност

КОГА: Кога ќе заврши тестирањето за прифаќање

КАДЕ: Сценско опкружување

КАКО: Автоматско (веб-возач) истражувачко тестирање

Заостаток на производот

Најчеста причина за неуспех во развојот на софтвер се должи на нејасните барања и различното толкување на барањата од страна на различни членови на тимот.

Корисничките приказни треба да бидат едноставни, концизни и недвосмислени. Како добро упатство, најдобро е да го следите моделот INVEST за пишување кориснички приказни.

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

Јас независен (од сите други)

Н. договорено (не е специфичен договор за одлики)

В. податлив (или вертикално )

Е стимулирачки (до добра апроксимација)

С. трговски центар (за да се вклопи во повторување)

Т. сигурен (во принцип, дури и ако сè уште нема тест за тоа)

Следниот формат треба да се користи за пишување кориснички приказни

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]...

Работилници за приказни / Планирање на спринт

Во секоја работилница за приказни, секој во тимот учи за деталите на приказните, така што развивачите и ОК го знаат обемот на работата. Секој треба да го има истото разбирање за што се однесува приказната.

Програмерите треба добро да ги разберат техничките детали што се вклучени во доставувањето на приказната, а ОК треба да знае како ќе се тестира приказната и дали има пречки за тестирање на приказните.

Спречување на дефекти

Во работилниците за приказни, Мора да бидат вклучени PO, BA, Dev и QA.

Треба да се размисли за сценарија (валидни, невалидни и работни случаи) (ОК може да додаде огромна вредност тука, размислувајќи апстрактно за приказната) и да ги запише во датотеките со одлики.

Важно е да се напомене дека токму сценаријата (повеќе од што било друго) ќе открие дефекти при тестирање на производот, така што повеќе напор и време поминато на оваа активност, најдобри резултати на крајот.

Бидејќи мнозинството дефекти се резултат на нејасни и нејасни барања, оваа активност исто така ќе помогне да се спречи спроведувањето на неправилно однесување, бидејќи сите треба да имаат исто разбирање за приказната.

Исто така, на состаноците за планирање на спринт, проценките дадени за приказна треба да вклучуваат и напори за тестирање, а не само напори за кодирање. Исто така, мора да бидат присутни и QA (рачна и автоматизација) на состаноците за планирање на спринт да се обезбеди проценка за тестирање на приказната.

Развој

Кога започнува развојот, треба да бидат поддржани новиот производствен код и / или измена на наследниот код единици тестови напишани од развивачи и рецензиран од друг развивач или квалификуван SDET.

Секое извршување на складиштето за кодови треба да предизвика извршување на единичните тестови од CI серверот. Ова обезбедува механизам за брза повратна информација до тимот за развој.

Единичките тестови обезбедуваат системот да работи на техничко ниво и да нема грешки во логиката.

Тестирање на програмери

Како развивач, однесувајте се како да немате никаков ОК во тимот или организацијата. Вистина е дека квалификациите имаат различен начин на размислување, но треба да ги тестирате најдобро што можете.

Мислите дека заштедувате време со брзо преминување кон следната приказна, но во реалноста, кога ќе се најде и извести дефект, потребно е подолго време за да го поправите проблемот, отколку да поминете неколку минути за да бидете сигурни дека одликата работи добро.

Секој нов код и / или рефакторирање на наследниот код треба да има соодветни тест единици што ќе бидат дел од тестот за регресија на единицата.

Автоматски тестови за прифаќање и нефункционално тестирање

Тестовите за автоматско прифаќање вклучуваат тестови за интеграција и тестови за услуги и тестови за интерфејс кои имаат за цел да докажат дека софтверот работи на функционално ниво и дека ги исполнува барањата и спецификациите на корисникот.

Тестовите за автоматско прифаќање обично се пишуваат на јазик на корнишони и се извршуваат со употреба на алатка BDD како краставица.

Запомни : Не треба сите тестови да бидат автоматизирани!

Бидејќи овие тестови обично бараат комуникација преку HTTP, тие треба да се извршат на распоредена апликација, наместо да се извршуваат како дел од конструкцијата.

Нефункционални тестови како што се тестовите за изведба и безбедност, се подеднакво важни како и функционалните тестови, затоа треба да се извршат на секое распоредување.

Тестовите за изведба треба да ги проверат метриките на перформансите на секое распоредување за да обезбедат деградација на перформансите.

Безбедносните тестови треба да проверат за основни безбедносни слабости кои произлегуваат од OWASP

Од витално значење е ова да биде целосно автоматизиран процес со многу мало одржување за да се извлече максимум од автоматските распоредувања. Ова значи дека не треба да има повремени пропусти на тестот, проблеми со скрипти за тестирање и скршена околина.

Неуспесите треба да се должат само на оригинални дефекти на кодот отколку на проблеми со скриптата, затоа секој тест што не успеал, што не се должи на вистински дефекти, треба да се поправи веднаш или да се отстрани од пакетот за автоматизација, за да може да се добијат конзистентни резултати.

Тестирање на регресија

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

Пакет за чад - не треба да трае повеќе од 15 мин

Овој пакет содржи само функционалност на високо ниво за да бидете сигурни дека апликацијата е доволно стабилна за понатамошен развој или тестирање.

На пример, за веб-страница за е-трговија, тестовите вклучени во овој пакет може да бидат:

  • Пребарување на производи,
  • Преглед на производи
  • Предмет за набавка
  • Создавање сметка / најавување на сметка

Пакет со целосна регресија - не треба да трае повеќе од 1 час

Овој пакет содржи целосен пакет за регресија на тестови и содржи сè друго што не е вклучено во пакетот за чад.

Тука, целта е да добиете брз фидбек со поголем сет на тестови. Ако повратните информации траат повеќе од 1 час, тоа не е брзо. Или намалете го бројот на тестови со употреба на техника на парни тестови, создадете тест пакети засновани на ризик или извршете ги тестовите паралелно.

UAT и истражувачко тестирање

Нема причина зошто UAT и истражувачкото тестирање не можат да течат паралелно со тестовите за автоматско прифаќање. На крајот на краиштата, тие се различни активности и имаат за цел да најдат различни проблеми. Целта на UAT е да осигури дека развиените карактеристики имаат деловна смисла и корисни за клиентите.

PO (сопственик на производ) треба да изврши тестови за прифаќање на корисникот или Тестови за деловно прифаќање за да се потврди изградениот производ е она што се очекуваше и дека ги исполнува очекувањата на корисникот.

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

Готови критериуми

Откако ќе бидат завршени сите горенаведени активности и нема пронајдени проблеми, приказната е Направено!

Горенаведеното е неколку упатства за тоа што може да се вклучи во стратегискиот документ за агилен тест. Очигледно, ова треба да биде прилагодено на потребите на вашата организација, но се надеваме дека овој образец ќе ви помогне да креирате сопствен документ за стратегија за агилен тест.