Прыклад шаблону стратэгіі тэставання Agile



Agile Test Strategy

У гнуткім асяроддзі, дзе мы працуем у кароткіх спрынтах ці ітэрацыях, кожны спрынт сканцэнтраваны толькі на некалькіх патрабаваннях альбо гісторыях карыстальнікаў, таму натуральна, што дакументацыя можа быць не такой шырокай з пункту гледжання колькасці і зместу.

Мэта дакумента па гнуткай тэставай стратэгіі - пералічыць лепшыя практыкі і некаторыя формы структуры, якіх каманды могуць прытрымлівацца. Памятайце, што спрыт не азначае неструктураванасць.

Тут мы разгледзім прыклад стратэгіі тэставання Agile і тое, што трэба ўключыць у дакумент.


Стратэгія тэставання звычайна мае місію, якая можа быць звязана з больш шырокімі бізнес-мэтамі і задачамі.

Тыповай заявай місіі можа быць:


Пастаянна пастаўляць працуючае праграмнае забеспячэнне, якое адпавядае патрабаванням кліента _ шляхам _забеспячэння хуткай зваротнай сувязі _ і _прафілактыкі дэфектаў, а не выяўлення дэфектаў.



Падтрымлівае:


  • Ні адзін код не можа быць напісаны для матэрыялу, пакуль мы не ўпершыню вызначым яго крытэрыі / выпрабаванні

  • Матэрыял не можа лічыцца завершаным, пакуль не пройдуць усе яго прыёмныя выпрабаванні

У дакуменце Agile Test Strategy я хацеў бы таксама ўключыць напамін усім аб забеспячэнні якасці


  • QA - гэта набор мерапрыемстваў, накіраваных на забеспячэнне таго, каб прадукты сістэматычна і надзейна задавальнялі патрабаванні кліентаў.



  • У SCRUM (спрытны) кантроль якасці - гэта адказнасць усіх, а не толькі тэсціроўшчыкаў. ЯК - гэта ўсе віды дзейнасці, якія мы робім для забеспячэння правільнай якасці пры распрацоўцы новых прадуктаў.



Тэставыя ўзроўні

Адзінкавае тэставанне

ЧАМУ: Каб код быў распрацаваны правільна

СУСВЕТНАЯ АРГАНІЗАЦЫЯ ПА АХОВЕ ЗДАРОЎЯ: Распрацоўшчыкі / тэхнічныя архітэктары


ШТО: Увесь новы код + перапрацоўка састарэлага кода, а таксама тэставанне модуляў Javascript

КАЛІ: Як толькі новы код напісаны

ДЗЕ: Лакальны Dev + CI (частка зборкі)

ЯК: Аўтаматызаваны, Junit, TestNG, PHPUnit




API / тэставанне паслуг

ЧАМУ: Для забеспячэння сувязі паміж кампанентамі працуюць

СУСВЕТНАЯ АРГАНІЗАЦЫЯ ПА АХОВЕ ЗДАРОЎЯ: Распрацоўшчыкі / тэхнічныя архітэктары

ШТО: Новыя вэб-сэрвісы, кампаненты, кантролеры і г.д.

КАЛІ: Як толькі новы API будзе распрацаваны і гатовы


ДЗЕ: Лакальны Dev + CI (частка зборкі)

ЯК: Аўтаматызаваны, мыльны інтэрфейс, кліент для адпачынку



Прыёмныя выпрабаванні

ЧАМУ: Каб забяспечыць апраўданне чаканняў кліента

СУСВЕТНАЯ АРГАНІЗАЦЫЯ ПА АХОВЕ ЗДАРОЎЯ: Распрацоўшчык / SDET / Кіраўніцтва па кантролі якасці

ШТО: Праверка прыёмных выпрабаванняў сюжэтаў, праверка функцый

КАЛІ: Калі функцыя гатовая і выпрабавана

ДЗЕ: CI / Тэставае асяроддзе

ЯК: Аўтаматызаваны (агурок)



Тэставанне сістэмы / Рэгрэсія / UAT

ЧАМУ: Каб уся сістэма працавала ў інтэграваным рэжыме

СУСВЕТНАЯ АРГАНІЗАЦЫЯ ПА АХОВЕ ЗДАРОЎЯ: SDET / Кіраўніцтва па кантролі якасці / Бізнес-аналітык / Уладальнік прадукту

ШТО: Тэставанне сцэнарыяў, карыстацкія патокі і тыповыя падарожжы карыстальнікаў, тэставанне прадукцыйнасці і бяспекі

КАЛІ: Пасля завяршэння прыёмных выпрабаванняў

ДЗЕ: Пастановачнае асяроддзе

ЯК: Аўтаматызаванае (Webdriver) даследчае тэсціраванне



Адставанне прадукту

Часцей за ўсё прычына збою ў распрацоўцы праграмнага забеспячэння звязана з незразумелымі патрабаваннямі і рознай інтэрпрэтацыяй патрабаванняў розных членаў каманды.

Гісторыі карыстальнікаў павінны быць простымі, кароткімі і адназначнымі. У якасці добрага арыенціру лепш за ўсё прытрымлівацца мадэлі INVEST для напісання гісторый карыстальнікаў.

Добрая гісторыя карыстальніка павінна быць:

Я незалежны (ад усіх астатніх)

N дагаворны (не канкрэтны кантракт на функцыі)

V прыдатны (альбо вертыкальны )

ЁСЦЬ ацэньваемы (да добрага набліжэння)

S гандлёвы цэнтр (каб змясціўся ў межах ітэрацыі)

Т. 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 павінны ўдзельнічаць.

Варта прадумаць сцэнарыі (сапраўдныя, несапраўдныя і краявыя выпадкі) (кантроль якасці можа дадаць тут велізарнае значэнне, абстрактна падумаўшы пра гісторыю) і запісаць у файлы функцый.

Важна адзначыць, што менавіта сцэнарыі (больш за ўсё астатняе) выявяць дэфекты пры тэставанні прадукту, таму чым больш сіл і часу затрачана на гэтую дзейнасць, тым лепшыя вынікі ў выніку.

Паколькі большасць дэфектаў звязана з незразумелымі і расплывістымі патрабаваннямі, гэта таксама дапаможа прадухіліць ужыванне некарэктных паводзін, паколькі ўсе павінны аднолькава разумець гісторыю.

Акрамя таго, на сустрэчах па планаванні спрынту ацэнкі, прыведзеныя для гісторыі, павінны ўключаць у сябе і тэставанне, а не толькі намаганні па кадаванні. Якасць кантролю якасці (ручная і аўтаматызацыя) таксама павінна прысутнічаць на сустрэчах па планаванні спрынтаў даць каштарыс для тэставання гісторыі.



Развіццё

Калі распрацоўка пачнецца, новы вытворчы код і / або мадыфікацыя старога кода павінны быць падтрыманы адзінкавыя тэсты, напісаныя распрацоўшчыкамі і рэцэнзуецца іншым распрацоўшчыкам альбо кваліфікаваным SDET.

Любая фіксацыя ў сховішчы кода павінна выклікаць выкананне модульных тэстаў з сервера CI. Гэта забяспечвае хуткі механізм зваротнай сувязі з камандай распрацоўшчыкаў.

Адзінкавыя тэсты гарантуюць, што сістэма працуе на тэхнічным узроўні і не мае памылак у логіцы.



Тэставанне распрацоўшчыка

Як распрацоўшчык паводзіце сябе так, быццам у вас няма ніякай якасці ў камандзе ці арганізацыі. Гэта праўда, што кантроль якасці мае розны склад мыслення, але вы павінны праверыць, наколькі гэта магчыма.

Вы думаеце, што эканоміце час, хутка пераходзячы да наступнай гісторыі, але на самой справе, калі дэфект знойдзены і паведамлены, выпраўленне праблемы займае больш часу, чым марнаванне некалькіх хвілін на тое, каб функцыя працавала добра.

Любы новы код і / або рэфактарынг састарэлага кода павінны мець адпаведныя модульныя тэсты, якія будуць часткай тэсту рэгрэсіі адзінак.



Аўтаматызаваныя прыёмныя і нефункцыянальныя выпрабаванні

Аўтаматызаваныя прыёмныя выпрабаванні ўключаюць інтэграцыйныя і службовыя выпрабаванні і тэсты карыстацкага інтэрфейсу, якія накіраваны на тое, каб даказаць, што праграмнае забеспячэнне працуе на функцыянальным узроўні і адпавядае патрабаванням і спецыфікацыям карыстальніка.

Аўтаматызаваныя прыёмныя выпрабаванні звычайна пішуцца на мове корнішонаў і выконваюцца з выкарыстаннем інструмента BDD, напрыклад агурка.

Памятай : Не ўсе тэсты павінны быць аўтаматызаваны!

Паколькі гэтыя тэсты звычайна патрабуюць сувязі праз HTTP, яны павінны выконвацца ў разгорнутым дадатку, а не запускацца ў рамках зборкі.

Нефункцыянальныя тэсты такія як тэсты прадукцыйнасці і бяспекі не менш важныя, як і функцыянальныя, таму іх трэба выконваць пры кожным разгортванні.

Тэсты прадукцыйнасці павінны правяраць паказчыкі прадукцыйнасці пры кожным разгортванні, каб гарантаваць адсутнасць пагаршэння прадукцыйнасці.

Тэсты бяспекі павінны правяраць наяўнасць асноўных уразлівасцяў бяспекі OWASP

Вельмі важна, каб гэта быў цалкам аўтаматызаваны працэс з вельмі невялікім абслугоўваннем, каб атрымаць максімальную карысць ад аўтаматызаванага разгортвання. Гэта азначае, што не павінна быць перыядычных збояў у тэставанні, праблем са сцэнарыямі выпрабаванняў і парушэнняў асяроддзя.

Збоі павінны быць звязаны толькі з сапраўднымі дэфектамі кода, а не з праблемамі сцэнарыя, таму любы няўдалы тэст, які не звязаны з сапраўднымі збоямі, павінен быць неадкладна выпраўлены альбо выдалены з пакета аўтаматызацыі, каб атрымаць нязменныя вынікі.



Рэгрэсійнае тэставанне

Не разлічваючы знайсці шмат дэфектаў. Іх мэта складаецца толькі ў прадастаўленні зваротнай сувязі аб тым, што мы не парушылі асноўныя функцыянальныя магчымасці. Павінна быць вельмі мала ручнога рэгрэсійнага тэсціравання.

Дымавая шашка - павінна быць не больш за 15 хвілін

Гэты пакет змяшчае толькі функцыянальныя магчымасці высокага ўзроўню, каб пераканацца, што прыкладанне дастаткова стабільнае для далейшай распрацоўкі або тэставання.

Напрыклад, для вэб-сайта электроннай камерцыі тэсты, уключаныя ў гэты пакет, могуць быць:

  • Пошук прадукту,
  • Агляд прадукту
  • Элемент пакупкі
  • Стварэнне ўліковага запісу / Уліковы запіс

Поўная рэгрэсія - павінна складаць не больш за 1 гадзіну

Гэты пакет утрымлівае поўны набор рэгрэсійных выпрабаванняў і змяшчае ўсё астатняе, што не ўваходзіць у дымавы пакет.

Тут мэта - атрымаць хуткую зваротную сувязь з большым наборам тэстаў. Калі зваротная сувязь займае больш за 1 гадзіну, гэта не хутка. Альбо паменшыце колькасць тэстаў, выкарыстоўваючы методыку парных тэстаў, стварыце тэставыя пакеты на аснове рызыкі альбо паралельна запускайце тэсты.



UAT і пошукавыя выпрабаванні

Няма прычын, па якіх UAT і пошукавыя выпрабаванні не могуць працаваць паралельна з аўтаматызаванымі прыёмнымі выпрабаваннямі. У рэшце рэшт, гэта розныя віды дзейнасці і імкнуцца знайсці розныя праблемы. Мэта UAT - гарантаваць, што распрацаваныя функцыі маюць дзелавы сэнс і карысныя для кліентаў.

PO (уладальнік прадукту) павінен праводзіць тэсты прыёму карыстальнікамі або Прыёмныя тэсты для пацверджання ўбудаванага прадукту - гэта тое, што чакалася, і адпавядае чаканням карыстальніка.

Даследчае тэсціраванне павінна быць сканцэнтравана на сцэнарыях карыстальнікаў і павінна знайсці памылкі, якіх не хапае пры аўтаматызацыі. Даследчае тэсціраванне не павінна выяўляць банальных памылак, а павінна выяўляць тонкія праблемы.



Выкананыя крытэрыі

Пасля таго, як усе вышэйпералічаныя мерапрыемствы будуць завершаны і праблем не знойдзена, гісторыя ёсць Гатова!

Вышэй прыведзены некаторыя рэкамендацыі па тым, што можна ўключыць у дакумент Стратэгіі тэставання Agile. Відавочна, што гэта трэба адаптаваць да патрэб вашай арганізацыі, але, спадзяюся, гэты шаблон дапаможа вам стварыць уласны дакумент Agile Test Strategy.