Модерно тестирање - Еволуцијата на улогата на ОК

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

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

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


Тестирањето може да стане само поинтересно!

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


Разочарувачки е да се види дека сè уште има многу луѓе во ИТ индустријата што ги гледаат ОК или тестерите како крајна линија. На тестерите честопати се гледа како на само функционални тестери кои тестираат само откако програмерите ќе завршат со работата на некоја од карактеристиките. „Обезбедување на квалитет“ се смета како тестирање, наоѓање и пријавување на грешки и давање на зелено светло за ослободување.

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



Традиционално тестирање на софтвер

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

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


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



ОК во ерата на агилните

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

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

„Квалитетот“ престана да станува единствена одговорност на тестерите и стана заедничка одговорност на сите вклучени во развојот и испораката на производот.


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

Фокусот се пресели од наоѓање дефекти во вградениот софтвер за да спречи дефекти да влезат во софтверот пред се.

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

Поврзано:


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

Но, додека Агил направи долг пат да ги комбинира активностите и практиките на развој и тестирање, оперативниот тим сепак беше испратен до плоштад. Двете струја на работа (Dev & Ops) честопати не беа свесни за меѓусебните активности.

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



Добредојдовте во DevOps

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


DevOps овозможува методи на континуирана интеграција и испорака на вредност на крајниот корисник.

Движењето DevOps поттикна нова перспектива за тестирање и создаде нови можности за самите тестери.

Во оваа нова ера тестерите треба да бидат усогласени и со развојот и со работењето.

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

Континуирана интеграција (ЦИ) и континуирана испорака (ЦД), станаа де факто стандард во развојот и испораката на софтвер, и затоа голем дел од напорите за тестирање сега се трошат на обезбедување ЦИ / ЦД-цевковод, околини и инфраструктура.

Ова е 'рбетот што го поддржува и развојот и испораката.

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



Современо тестирање - развој управувано од квалитет

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

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

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

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

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

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

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

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



Кој е модерниот ОК

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

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

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

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

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

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

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

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

За да го имаме тоа интимно знаење, треба постојано да учиме и да ги следиме новите технологии и начини на работа. Што е најважно, ОК треба да бидат прилагодливи.

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