Еј Хабр!
Имаме нова важна тема - висококвалитетен развој на ИТ производи. На HighLoad++ често зборуваме за тоа како да ги направиме зафатените услуги брзо, а на Frontend Conf зборуваме за кул кориснички интерфејс што не успорува. Редовно имаме теми за тестирање и DevOpsConf за комбинирање на различни процеси, вклучително и тестирање. Но, за тоа што може да се нарече квалитет воопшто, и како сеопфатно да се работи на тоа - не.
Ајде да го поправиме ова до — ќе развиеме култура на размислување за квалитетот на финалниот производ за корисникот во секоја фаза на развој. Навика да не се фокусирате на вашата област на одговорност и да го поврзувате квалитетот не само со тестери.
Под сечењето ќе разговараме со шефот на програмскиот комитет, раководител на тестирање во Tinkoff.Business, креатор на заедницата за ОК што зборува руски Анастасија Асеева-Нгуен за состојбата на индустријата за ОК и мисијата на новата конференција.
- Настија здраво. Ве молиме кажете ни за себе.
Анастасия: Управувам со тестирање во банка, одговорен сум за многу голем тим - ние сме повеќе од 90 луѓе. Имаме важна деловна линија, ние сме одговорни за екосистемот за правните лица.
Студирав механика и математика и на почетокот сакав да станам програмер. Но, кога добив интересна понуда, решив да се пробам како тестер. Доволно чудно, ова се покажа како мојот повик. Сега ја гледам целата моја работа во оваа индустрија.
Јас сум жесток приврзаник на дисциплината за обезбедување квалитет. Не сум рамнодушен на тоа какви производи се создаваат, како се третира квалитетот во компанијата, во тимот и, во принцип, во процесот на развој.
Тоа ми е очигледно заедницата во оваа насока не е доволно зрела, барем во Русија. Не секогаш разбираме дека обезбедувањето квалитет не е само факт на тестирање на апликација за усогласеност со барањата. Би сакал да ја сменам оваа ситуација.
— Ги користите зборовите Обезбедување квалитет и тестирање. Во очите на просечниот човек, овие два поима многу често се преклопуваат. Како се разликуваат ако копате длабоко?
Анастасија: Напротив, тие не се разликуваат. Тестирањето е дел од дисциплината за обезбедување квалитет, тоа е директна активност - самиот факт дека нешто тестирам. Всушност, постојат многу видови на тестирање, а различни луѓе се одговорни за различни типови на тестирање. Но, овде во Русија, кога се појави бран на аутсорсери кои снабдуваат тестери на компаниите, тестирањето беше сведено на еден тип.
Во повеќето случаи, тие се ограничени само на функционално тестирање: тие проверуваат дали она што го кодирале програмерите е во согласност со спецификацијата и тоа е сè.
— Ве молиме кажете ни кои други дисциплини за обезбедување квалитет постојат? Што друго, покрај тестирањето, е вклучено овде?
Анастасия: Обезбедувањето квалитет е, пред сè, за создавање квалитетен производ. Односно, се прашуваме какви квалитетни атрибути треба да има нашиот производ. Според тоа, ако го разбереме ова, можеме да споредиме кој влијае на овие квалитетни атрибути. Нема врска, развивач, проект менаџер или специјалист за производи е личност која влијае на развојот на производот, неговото заостанување и неговата стратегија.
Тестерот станува посвесен за својата улога. Тој разбира дека неговата задача не е само да тестира за усогласеност со барањата, туку и да ги тестира барањата, да ги преиспитува формулациите што доаѓаат од специјалистот за производи и да ги открие сите имплицитни барања и очекувања на клиентот. Кога испорачуваме нова функционалност на нашите клиенти, мораме вистински да ги исполниме нивните очекувања и да ја решиме нивната болка. Ако размислиме за сите атрибути на квалитет, клиентот ќе биде задоволен и ќе разбере дека компанијата чиј производ го користи навистина се грижи за неговите интереси и не работи на принципот „само да се ослободи карактеристика“.
— Се чини дека она што штотуку го опишавте е задача на специјалист за производи. Ова, во принцип, не е за тестирање и не за квалитет - генерално се работи за управување со производи, нели?
Анастасия: Вклучувајќи. Обезбедувањето квалитет не е дисциплина за која е одговорно едно конкретно лице. Сега постои популарна насока во тестирањето, пристап наречен Агилно тестирање. Неговата дефиниција јасно кажува дека ова е тимски пристап кон тестирањето, кој вклучува одреден сет на практики. Целиот тим е одговорен за спроведување на овој пристап, дури и не е неопходно да има тестер во тимот. Целиот тим е фокусиран на испорака на вредност на клиентот и обезбедување дека вредноста ги исполнува очекувањата на клиентите.
— Излегува дека квалитетот се вкрстува со речиси сите околни дисциплини, наметнувајќи рамка на сè наоколу?
Анастасия: Точно. Кога размислуваме за тоа како сакаме да создадеме квалитетен производ, почнуваме да размислуваме за различните атрибути на квалитет. На пример, како да провериме дали навистина сме ја направиле функцијата што му треба на нашиот клиент.
Еве каде доаѓа овој тип на тестирање: UAT (тестирање за прифаќање на корисникот). За жал, тоа ретко се практикува во Русија, но понекогаш е присутно во тимовите на SCRUM како демо за крајниот клиент. Ова е прилично вообичаен тип на тестирање во странски компании. Пред да ја отвориме функционалноста за сите клиенти, прво правиме UAT, односно го покануваме крајниот корисник кој тестира и веднаш дава повратна информација - дали производот навистина ги исполнува очекувањата и ја решава болката. Само после ова се случува скалирање на сите други клиенти.
Односно, се фокусираме на бизнисот, на крајниот клиент, но во исто време не заборавајте за технологијата. Квалитетот на производот, исто така, во голема мера зависи од технологијата. Ако имаме лоша архитектура, нема да можеме брзо да ги ослободиме функциите и да ги исполниме очекувањата на клиентите. Може да има многу грешки кога се обидуваме да скалираме, или кога се обидуваме да рефакторираме може да скршиме нешто. Сето ова ќе влијае на задоволството на клиентите.
Од оваа гледна точка, архитектурата треба да биде таква да можеме да напишеме чист код што ќе ни овозможи брзо да правиме промени и да не се плашиме дека ќе скршиме сè. Така што повторувањата на ревизијата не се протегаат во текот на неколку месеци, едноставно затоа што имаме толку многу наследство и треба да направиме долги фази на тестирање.
- Севкупно, веќе се вклучени програмери, архитекти, научници за производи, менаџери на производи и самите тестери. Кој друг е вклучен во процесот на обезбедување квалитет?
Анастасия: Сега да замислиме дека веќе сме ја испорачале функцијата на клиентот. Очигледно, квалитетот на производот треба да се следи дури и кога е веќе во производство. Во оваа фаза, може да се појават ситуации со неочигледни сценарија, таканаречени грешки.
Првото прашање е како да се справиме со овие грешки откако веќе ќе го пуштиме производот? Како ние, на пример, реагираме на стрес? Клиентот нема да биде многу среќен ако страницата трае повеќе од 30 секунди за да се вчита.
Тука стапува во игра експлоатацијата или, како што ја нарекуваат сега, DevOps. Всушност, тоа се луѓето кои се одговорни за управување со производот кога тој е веќе во производство. Ова вклучува различни видови на мониторинг. Постои дури и подтип на тестирање - тестирање на производство, кога си дозволуваме да не тестираме нешто пред да се појави и да го тестираме веднаш при производство. Ова е серија мерки од гледна точка на организирање на инфраструктурата што ви овозможуваат брзо да одговорите на инцидент, да влијаете на него и да го поправите.
Инфраструктурата е исто така важна. Честопати има ситуации кога за време на тестот е невозможно да се увериме дека навистина имаме се што би сакале да му дадеме на клиентот. Го пуштаме во производство и почнуваме да фаќаме неочигледни ситуации. И сето тоа затоа што инфраструктурата во тестот не одговара на инфраструктурата во производството. Ова води до нов тип на тестирање - тестирање на инфраструктурата. Тоа се различни конфигурации, поставки, миграција на базата на податоци итн.
Ова го покренува прашањето - можеби тимот треба да користи инфраструктура како код.
Сметам дека инфраструктурата директно влијае на квалитетот на производот.
Се надевам дека на конференцијата ќе има извештај со реален случај. Пишете ни ако сте подготвени да ни кажете од сопственото искуство како инфраструктурата како код влијае на квалитетот. Инфраструктурата како код го олеснува проверувањето на сите поставки и тестирањето работи кои инаку едноставно не се можни. Затоа, работењето е вклучено и во процесот на развој на квалитетен производ.
- Што е со аналитиката и документацијата?
Анастасия: Ова повеќе се однесува на системите на претпријатијата. Кога зборуваме за претпријатие, луѓе како што се аналитичари и системски аналитичари веднаш доаѓаат на ум. Тие понекогаш се нарекуваат технички писатели. Тие добиваат задача да напишат спецификација и да ја завршат, на пример, еден месец.
Повеќепати е докажано дека пишувањето таква документација води до многу долги развојни повторувања и долги повторувања на префинетост, бидејќи во текот на процесот на тестирање се идентификуваат грешки и започнуваат враќањата. Како резултат на тоа, има многу јамки кои ги зголемуваат трошоците за развој. Покрај тоа, ова може да внесе ранливости. Се чини дека напишавме референтен код, но потоа направивме промени кои ја кршат совршено осмислената архитектура.
Крајниот резултат е не сосема квалитетен производ, бидејќи веќе се појавија закрпи во архитектурата, кодот на некои места не е доволно покриен со тестови, бидејќи роковите истекуваат, сите грешки треба брзо да се затворат. И сето тоа затоа што оригиналната спецификација не ги зема предвид сите точки што треба да се имплементираат.
Програмерите не се штетници и не пишуваат код со грешки намерно.
Ако првично размислувавме за спецификација која ќе ги опфати сите потребни точки, тогаш сè ќе беше имплементирано точно по потреба. Но, ова е утопија.
Веројатно е невозможно да се напише совршена спецификација од 100 страници. Затоа треба да се размислува за алтернативни начини на пишување документација, спецификации, поставување задачи што би нè доближиле до осигурување дека развивачот го прави токму она што е потребно.
Тука доаѓаат на ум пристапите од Agile - кориснички приказни со критериуми за прифаќање. Ова е повеќе применливо за тимови кои се развиваат во мали повторувања.
— Што е со тестирањето на употребливост, употребливоста на производот, дизајнот?
Анастасия: Ова е многу важен момент, бидејќи има дизајнери во тимот. Најчесто, дизајнерите се користат како услуга - или од оддел за дизајн или од аутсорсинг дизајнер. Често има ситуации кога се чини дека дизајнерот го слушал специјалистот за производи и го направил она што тој го разбирал. Но, кога ќе започнеме со повторувањето, излегува дека она што всушност е направено не било она што се очекувало: дизајнерот заборавил нешто, не размислил целосно за однесувањето, бидејќи тој не е во тимот и не е во контекстот или предниот дел. -end програмерот не го разбра целосно неговиот распоред. Може да потрае неколку повторувања само затоа што има проблем со разбирањето на дизајнот од страна на развивачот на предниот дел.
Плус има уште еден проблем. Дизајнерските системи сега добиваат популарност. Тие се во возбуда, но придобивките од нив не се сосема очигледни.
Наидувам на мислење дека системите за дизајн, од една страна, го поедноставуваат развојот, но од друга страна, наметнуваат многу ограничувања на интерфејсот.
Како резултат на тоа, ние не ја правиме функцијата што ја сака клиентот, туку онаа што ни е погодна, бидејќи веќе имаме одредени коцки од кои можеме да ја направиме.
Мислам дека ова е тема што вреди да се погледне и да се запрашаме дали во обидот да го олесниме дизајнот, всушност ја решаваме болката на клиентот.
— Има изненадувачки број на теми поврзани со осигурување на квалитет. Дали има конференција во Русија каде што може да се разговара за сите нив?
Анастасия: Таму е најстарата конференција за тестирање, која ќе се одржи по 25-ти пат оваа година и се вика Конференција за обезбедување квалитет на денови на SQA. Главно разговара за алатките и специфичните пристапи за тестирање за функционалните тестери. Како по правило, извештаите на SQA Days длабоко испитуваат специфични области во областа на одговорноста на самите тестери, но не и сложени активности.
Ова многу помага во разбирањето на различни алатки и пристапи, како да се тестираат базите на податоци, API, итн. Но, во исто време, од една страна, тоа не мотивира да вклучи повеќе од само тестирање во создавањето на подобар производ. Од друга страна, тестерите не се повеќе вклучени во процесот за да размислуваат за глобалната цел на производот и неговата деловна компонента.
Водам голем оддел и спроведувам многу интервјуа кои навистина даваат увид во состојбата на индустријата како целина. Како по правило, нашите момци работат во претпријатија и имаат јасна област на одговорност. Колегите кои работат во странски проекти користат различни типови на тестирање: тие самите можат да вршат тестирање на оптоварување, тестирање на перформанси, па дури и понекогаш безбедносно тестирање, бидејќи тие навистина му помагаат на тимот да го обезбеди квалитетот на производот.
Би сакал и момците во Русија да почнат да мислат дека индустријата не завршува со функционално тестирање.
— За таа цел организираме нова конференција QualityConf која е посветена на квалитетот како интегрална дисциплина. Кажете ни повеќе за идејата, која е главната цел на конференцијата?
Анастасия: Сакаме да создадеме заедница на луѓе заинтересирани за производство на квалитетни производи. Понудете им платформа каде што ќе можат да дојдат, да слушаат извештаи и да заминат по конференцијата со специфично разбирање за тоа што треба да се промени за да се подобри квалитетот.
Во денешно време често слушам барање од консултации за тоа што да правам кога има проблеми со тестирањето и квалитетот. Кога почнувате да комуницирате со тимовите, гледате дека проблемот не е во самите тестери, туку во тоа како е структуриран процесот. На пример, кога програмерите веруваат дека тие се одговорни само за пишување код, нивната одговорност завршува токму во моментот кога ќе ја предадат задачата на тестирање.
Не секој размислува за фактот дека лошо напишаниот, неквалитетен код со лоша архитектура се заканува со големи проблеми за проектот. Тие не размислуваат за цената на грешките, дека грешките што завршуваат во производството може да резултираат со големи трошоци за компанијата и тимот. Нема култура да се размислува за ова. Сакам да почнеме да го дистрибуираме на конференцијата.
Разбирам дека ова не е иновација.Едвард Деминг, авторот на 14-те принципи за квалитет, пишуваше за цената на грешката уште во минатиот век. Обезбедувањето квалитет како дисциплина се заснова на оваа книга, но, за жал, современиот развој заборава на тоа.
- Дали планирате директно да допирате теми за тестирање и алатки?
Анастасия: Признавам дека ќе има извештаи за алатки. Постојат доста универзални алатки со кои компаниите и тимовите можат да влијаат на производот.
Сите извештаи ќе бидат глобално обединети со една заедничка мисија: да се пренесе на публиката дека со помош на овој пристап, алатка, метод, процес, тип на тестирање, влијаевме на квалитетот на производот и го подобривме животот на клиентот.
Дефинитивно нема да имаме извештаи за алатка за доброто на алатката. Сите извештаи вклучени во програмата ќе бидат обединети со заедничка цел.
- Кого ќе го интересира за што зборувате, кого гледате како гости на конференцијата?
Анастасия: Ќе имаме извештаи за програмери кои се грижат за судбината на нивниот проект, производ, систем. Исто така, ќе биде од интерес за тестерите и, ми се чини, особено за менаџерите. Под менаџери, мислам на луѓе кои носат одлуки и можат да влијаат на судбината и развојот на производот, системот, тимот исто така.
Тоа се луѓе кои се прашуваат како да го подобрат квалитетот на некој производ или систем. На нашата конференција, тие ќе научат за различни групи мерки и ќе можат да разберат што не е во ред со нив сега и што треба да се промени.
Мислам дека главниот критериум е да разбереш дека нешто не е во ред со квалитетот и да сакаш да влијаеш на тоа. Веројатно нема да можеме да допреме до луѓето кои мислат дека тоа ќе го направи првиот пат.
- Дали мислите дека индустријата како целина е зрела да зборува не само за тестирање, туку и за култура на квалитет?
Анастасия: Мислам дека созреав. Сега многу компании се оддалечуваат од традиционалниот пристап на Водопад кон Agile. Постои фокус на клиентите, луѓето во тимови навистина почнуваат да размислуваат како да создадат квалитетен производ. Дури и претпријатијата повторно се фокусираат на подобрување на квалитетот.
Судејќи според бројот на барања кои се појавуваат во заедницата, верувам дека е време. Се разбира, не сум сигурен дека ова ќе биде револуција од големи размери, но би сакал да се случи оваа револуција во свеста.
- Договорено! Ќе всадиме култура и ќе ја промениме свеста.
Конференција за висококвалитетен развој на ИТ производи се одвива во Москва на 7 јуни. Знаете кои фази го сочинуваат висококвалитетниот производ, имаме случаи на успешна борба против грешки во производството, тестиравме популарни методи во нашата пракса - ни треба вашето искуство. нивните апликации пред 1 мај, а Програмскиот комитет ќе помогне да се фокусира темата за севкупниот интегритет на конференцијата.
Поврзете се со , во која разговараме за прашањата за квалитетот и конференцијата, претплатете се на да бидете во тек со новостите на програмата.
Извор: www.habr.com