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

Кои се најчестите предизвици за агилно тестирање со кои се соочуваат софтверските тестери или ОК во агилните проекти? Како е да се биде ОК во агилен тим?

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

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




Предизвици за агилно тестирање

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

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


Промена на барањата / Промени во последен момент

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

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

Како да се надминат:

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


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

Нема доволно информации за приказната

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

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

Како да се надминат:


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

Континуирано тестирање

Во подвижност, тестирањето не е фаза, тоа е активност. Тестирањето започнува од самиот почеток, дури и пред да започне развојот.

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

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


Како да се надминат:

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

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

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


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

Технички вештини / Тест автоматизација

Работа во агилна средина, значи дека тестерите треба да бидат технички компетентни да им помагаат на развивачите со интеграција на тестирање и тестирање на API, како и скриптирање проверки за автоматизација на интерфејс со селен или слична алатка.

Ако тестерите доаѓаат од чисто рачно или истражувачко потекло, ќе им биде тешко да го следат темпото на испорака бидејќи треба да тестираат на континуирано тестирање.

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

Како да се надминат:

Започнете со учење неколку скрипти или програмски јазици, како што се Руби и Јава - ова се најпопуларните јазици во заедницата за техничко тестирање.

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

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

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

Повеќе прелистувачи / повеќе уреди

Во денешно време, архитектурата на многу веб-страници се состои од „заден крај“ и „преден крај“. Предниот дел е во голема мера заснован на JavaScript и CSS, што потенцијално може да се однесува поинаку кога се гледа од различни прелистувачи или уреди.

Да се ​​обезбеди веб-страница да функционира како што се очекуваше во сите поголеми прелистувачи и популарни мобилни уреди или таблети е навистина врвен предизвик за тестерите во агилните проекти.

Како да се надминат:

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

Можете да користите Селениумска мрежа со Докер да управувате и да ги извршувате вашите автоматски тестови паралелно на повеќе прелистувачи.

Друга одлична алатка за тестирање на повеќе прелистувачи е BrowserSync .

Комуникација

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

Како да се надминат:

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

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