Главните Агилен Како да поставите функција за квалитет од гребење

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

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

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

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

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

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

За целите на овој напис, ќе претпоставам дека стартапот е веб-базирана компанија, на пр. веб-страница за е-трговија.

Спроведување на процес на ОК

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

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

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

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

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

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

Паралелно има најмалку две задачи: Тестирање на нови приказни во спринт и изведување на одреден степен на тестирање на регресија.

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

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

Нема доволно време да се напишат регресивни тестови, како и да се следи тестирањето на новите карактеристики. Како можеме да го прекинеме овој циклус?

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

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

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

Што е најважно, овие сценарија за регресија треба да бидат автоматизирани.

Автоматско тестирање

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

Распоредување / изградба на гасовод

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

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

Гасоводот треба да се заснова на најдобрите практики и да ги опфаќа активностите што се случуваат во секоја фаза.

Работилници за приказни

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

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

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

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

Тестирање / Тестирање на програмери за време на развојот

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

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

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

Континуирана средина за интеграција / тест

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

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

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

Нефункционално тестирање

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

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