Хеј Хабр!
Имамо нову важну тему - квалитетан развој ИТ производа. У ХигхЛоад++ често говоримо о томе како да убрзамо заузете услуге, а на Фронтенд Цонф-у говоримо о кул корисничком интерфејсу који не успорава. Редовно имамо теме о тестирању, а ДевОпсЦонф о комбиновању различитих процеса, укључујући тестирање. Али о томе шта се уопште може назвати квалитетом и како свеобухватно радити на томе - не.
Хајде да ово поправимо — развијаћемо културу размишљања о квалитету финалног производа за корисника у свакој фази развоја. Навика да се не фокусирате на своју област одговорности и да повезујете квалитет не само са тестерима.
Испод реза ћемо разговарати са шефом програмског комитета, шефом тестирања у Тинкофф.Бусинесс, творцем руског говорног подручја КА заједнице Анастасија Асеева-Нгујен о стању КА индустрије и мисији нове конференције.
- Настиа здраво. Реците нам о себи.
Анастасија: Управљам тестирањем у банци, одговоран сам за веома велики тим - имамо више од 90 људи. Имамо важну пословну линију, одговорни смо за екосистем за правна лица.
Студирао сам механику и математику и у почетку сам желео да постанем програмер. Али када сам добио занимљиву понуду, одлучио сам да се окушам као тестер. Чудно, испоставило се да је ово мој позив. Сада видим сав свој рад у овој индустрији.
Ја сам ватрени присталица дисциплине осигурања квалитета. Није ми равнодушно какви производи настају, како се третира квалитет у компанији, у тиму и, у принципу, у процесу развоја.
То ми је очигледно заједница у овом правцу није довољно зрела, барем у Русији. Не схватамо увек да осигурање квалитета није само чињеница тестирања усаглашености апликације са захтевима. Волео бих да променим ову ситуацију.
— Користите речи Осигурање квалитета и тестирање. У очима просечног човека, ова два појма се врло често преклапају. Како се разликују ако копате дубоко?
Анастазија: Напротив, не разликују се. Тестирање је део дисциплине обезбеђења квалитета; то је директна активност – сама чињеница да нешто тестирам. У ствари, постоји много врста тестирања, а за различите врсте тестирања одговорни су различити људи. Али овде у Русији, када се појавио талас спољних сарадника који испоручују тестере компанијама, тестирање је сведено на једну врсту.
У већини случајева, они су ограничени само на функционално тестирање: проверавају да ли је оно што су програмери кодирали у складу са спецификацијом и то је то.
— Реците нам које друге дисциплине за осигурање квалитета постоје? Шта је још, осим тестирања, укључено овде?
Анастасија: Обезбеђење квалитета је, пре свега, стварање квалитетног производа. Односно, питамо се које атрибуте квалитета треба да има наш производ. Сходно томе, ако ово разумемо, можемо да упоредимо ко утиче на ове атрибуте квалитета. нема везе, програмер, менаџер пројекта или специјалиста за производе је особа која утиче на развој производа, његовог заостатка и стратегије.
Испитивач постаје свеснији своје улоге. Он разуме да његов задатак није само да тестира усаглашеност са захтевима, већ и да тестира захтеве, преиспитује формулације које долазе од стручњака за производе и открива све имплицитне захтеве и очекивања клијента. Када испоручимо нову функционалност нашим клијентима, морамо заиста испунити њихова очекивања и решити њихов бол. Ако размислимо о свим атрибутима квалитета, клијент ће бити задовољан и схватиће да компанија чији производ користи заиста брине о његовим интересима, и да не ради по принципу „само да пусти неку функцију“.
— Чини се да је ово што сте управо описали задатак стручњака за производе. Овде се, у принципу, не ради о тестирању и не о квалитету - углавном се ради о управљању производима, зар не?
Анастасија: Укључујући. Осигурање квалитета није дисциплина за коју је одговорна једна одређена особа. Сада постоји популаран правац у тестирању, приступ тзв Агилно тестирање. Његова дефиниција јасно каже да се ради о тимском приступу тестирању, који укључује одређени скуп пракси. За примену овог приступа одговоран је цео тим, чак није ни неопходно да у тиму буде тестер. Цео тим је фокусиран на испоруку вредности купцу и обезбеђивање да вредност испуњава очекивања купаца.
— Испада да се квалитет укршта са готово свим околним дисциплинама, намећући оквир свему око себе?
Анастасија: Јел тако. Када размишљамо о томе како желимо да створимо квалитетан производ, почињемо да размишљамо о различитим атрибутима квалитета. На пример, како да проверимо да ли смо заиста направили функцију која је потребна нашем клијенту.
Овде долази ова врста тестирања: УАТ (тестирање прихватања корисника). Нажалост, ретко се практикује у Русији, али је понекад присутан у СЦРУМ тимовима као демо за крајњег клијента. Ово је прилично уобичајена врста тестирања у страним компанијама. Пре отварања функционалности свим клијентима, прво радимо УАТ, односно позивамо крајњег корисника који тестира и одмах даје повратну информацију – да ли производ заиста испуњава очекивања и решава бол. Тек након тога долази до скалирања на све остале клијенте.
Односно, фокусирамо се на посао, на крајњег клијента, али у исто време не заборавите на технологију. Квалитет производа такође у великој мери зависи од технологије. Ако имамо лошу архитектуру, нећемо моћи брзо да објавимо функције и испунимо очекивања купаца. Може бити много грешака при покушају скалирања, или када покушавамо да рефакторишемо, можемо нешто да покваримо. Све ово ће утицати на задовољство купаца.
Са ове тачке гледишта, архитектура би требало да буде таква да можемо да напишемо чист код који ће нам омогућити да брзо извршимо промене и да се не плашимо да ћемо све покварити. Тако да се итерације ревизије не протежу на неколико месеци само зато што имамо толико наслеђа и морамо да урадимо дуге фазе тестирања.
— Укупно су већ укључени програмери, архитекте, научници производа, менаџери производа и тестери. Ко је још укључен у процес осигурања квалитета?
Анастасија: Сада замислимо да смо ову функцију већ испоручили клијенту. Очигледно, квалитет производа треба пратити чак и када је већ у производњи. У овој фази могу се појавити ситуације са неочигледним сценаријима, такозваним грешкама.
Прво питање је како да се носимо са овим грешкама након што смо већ објавили производ? Како, на пример, реагујемо на стрес? Клијент неће бити веома задовољан ако се страници учита више од 30 секунди.
Овде долази до изражаја експлоатација или, како то сада зову, ДевОпс. У ствари, то су људи који су одговорни за рад са производом када је већ у производњи. Ово укључује различите врсте праћења. Постоји чак и подврста тестирања – тестирање у производњи, када дозволимо себи да нешто не тестирамо пре лансирања и тестирамо одмах у производњи. Ово је низ мера са становишта организовања инфраструктуре које вам омогућавају да брзо реагујете на инцидент, утичете на њега и исправите га.
Важна је и инфраструктура. Често се дешавају ситуације када је током теста немогуће да се уверимо да заиста имамо све што бисмо желели да дамо клијенту. Стављамо га у производњу и почињемо да хватамо неочигледне ситуације. А све зато што инфраструктура у тесту не одговара инфраструктури у производњи. Ово доводи до нове врсте тестирања - испитивање инфраструктуре. То су разне конфигурације, подешавања, миграција базе података итд.
Ово поставља питање - можда тим треба да користи инфраструктуру као код.
Верујем да инфраструктура директно утиче на квалитет производа.
Надам се да ће на конференцији бити извештај са правим случајем. Пишите нам ако сте спремни да нам из сопственог искуства кажете како инфраструктура као код утиче на квалитет. Инфраструктура као код олакшава проверу свих подешавања и тестирање ствари које иначе једноставно нису могуће. Стога је и операција укључена у процес развоја квалитетног производа.
— Шта је са аналитиком и документацијом?
Анастасија: Ово се више односи на системе предузећа. Када говоримо о предузећу, људи попут аналитичара и системских аналитичара одмах нам падају на памет. Понекад се називају техничким писцима. Добијају задатак да напишу спецификацију и заврше је, на пример, месец дана.
Више пута је доказано да писање такве документације доводи до веома дугих развојних итерација и дугих итерација усавршавања, јер се током процеса тестирања идентификују грешке и почиње враћање. Као резултат тога, постоји много петљи које повећавају трошкове развоја. Поред тога, ово може довести до рањивости. Чини се да смо написали референтни код, али смо онда направили промене које разбијају савршено осмишљену архитектуру.
Крајњи резултат је не сасвим квалитетан производ, јер су се закрпе већ појавиле у архитектури, код на неким местима није довољно покривен тестовима, јер рокови истичу, све грешке треба брзо затворити. И све зато што оригинална спецификација није узела у обзир све тачке које треба имплементирати.
Програмери нису штеточине и не пишу код са грешкама намерно.
Да смо у почетку смислили спецификацију која би покрила све неопходне тачке, онда би све било имплементирано тачно онако како је потребно. Али ово је утопија.
Вероватно је немогуће написати савршену спецификацију од 100 страница. Зато треба размишљати о алтернативним начинима писања документације, спецификације, постављање задатака који би нас приближили осигурању да програмер ради управо оно што је потребно.
Овде ми на памет падају приступи из Агиле-а – корисничке приче са критеријумима прихватања. Ово је више применљиво за тимове који се развијају у малим итерацијама.
— Шта је са тестирањем употребљивости, употребљивости производа, дизајном?
Анастасија: Ово је веома важна тачка, јер у тиму постоје дизајнери. Дизајнери се најчешће користе као услуга - било од стране дизајнерског одељења или од стране спољног дизајнера. Често постоје ситуације у којима се чини да је дизајнер слушао стручњака за производе и урадио оно што је разумео. Али када започнемо итерацију, испоставило се да оно што је заправо урађено није оно што се очекивало: дизајнер је нешто заборавио, није у потпуности размислио о понашању, јер није у тиму и није у контексту, или испред -крајњи програмер није у потпуности разумео његов изглед. Може бити потребно неколико итерација само зато што постоји проблем са фронт-енд програмером да разуме дизајн.
Осим тога, постоји још један проблем. Дизајн системи сада добијају на популарности. Они су веома популарни, али користи од њих нису сасвим очигледне.
Наилазим на мишљење да системи дизајна, с једне стране, поједностављују развој, али с друге стране намећу многа ограничења интерфејсу.
Као резултат тога, не правимо ону функцију коју клијент жели, већ ону која нам одговара, јер већ имамо одређене коцке од којих можемо да је направимо.
Мислим да је ово тема коју вреди погледати и запитати се да ли покушавајући да олакшамо дизајн, заправо решавамо болну тачку клијента.
— Постоји изненађујући број тема везаних за осигурање квалитета. Да ли постоји конференција у Русији на којој се о свима може разговарати?
Анастасија: Постоји најстарија конференција о тестирању која ће се ове године одржати 25. пут и зове се СКА Даис Куалити Ассуранце Цонференце. Углавном се расправља о алатима и специфичним приступима тестирању за функционалне тестере. По правилу, извештаји са СКА Даис-а дубоко испитују специфичне области у области одговорности самих тестера, али не и сложене активности.
Ово много помаже у разумевању различитих алата и приступа, како тестирати базе података, АПИ-је итд. Али у исто време, с једне стране, то не мотивише да се укључи више од самог тестирања у стварање бољег производа. С друге стране, тестери се не укључују више у процес размишљања о глобалном циљу производа и његове пословне компоненте.
Водим велико одељење и водим много интервјуа који заиста пружају увид у стање индустрије у целини. Наши момци по правилу раде у предузећима и имају јасну област одговорности. Колеге које раде у страним пројектима користе различите врсте тестирања: они сами могу да ураде тестирање оптерећења, тестирање перформанси, а понекад и безбедносно тестирање, јер заиста помажу тиму да обезбеди квалитет производа.
Волео бих да и момци у Русији почну да мисле да се индустрија не завршава функционалним тестирањем.
— У ту сврху организујемо нову конференцију КуалитиЦонф, која је посвећена квалитету као интегралној дисциплини. Реците нам нешто више о идеји, шта је главни циљ конференције?
Анастасија: Желимо да створимо заједницу људи заинтересованих за прављење квалитетних производа. Понудите платформу где могу да дођу, саслушају извештаје и оду након конференције са специфичним разумевањем шта треба променити да би се побољшао квалитет.
Данас често чујем од консултација захтев шта да радим када постоје проблеми са тестирањем и квалитетом. Када почнете да комуницирате са тимовима, видите да проблем није у самим тестерима, већ у томе како је процес структуриран. На пример, када програмери верују да су одговорни само за писање кода, њихова одговорност престаје тачно у тренутку када предају задатак тестирању.
Не размишљају сви о томе да лоше написан, неквалитетан код са лошом архитектуром прети великим проблемима за пројекат. Не размишљају о цени грешака, да грешке које заврше у производњи могу довести до великих трошкова за компанију и тим. Нема културе да се о овоме размишља. Желим да почнемо да га дистрибуирамо на конференцији.
Разумем да ово није иновација.Едвард Деминг, аутор 14 принципа квалитета, писао је о цени грешке још у прошлом веку. Осигурање квалитета као дисциплина засновано је на овој књизи, али, нажалост, савремени развој то заборавља.
— Да ли планирате да се директно дотакнете тема о тестирању и алатима?
Анастасија: Признајем да ће бити извештаја о алатима. Постоје прилично универзални алати помоћу којих компаније и тимови могу утицати на производ.
Све извештаје ће глобално објединити једна заједничка мисија: пренети публици да смо уз помоћ оваквог приступа, алата, методе, процеса, врсте тестирања утицали на квалитет производа и унапредили живот клијента.
Дефинитивно нећемо имати извештаје о алату ради алата. Сви извештаји укључени у програм биће уједињени заједничким циљем.
— Ко ће бити заинтересован за оно о чему причате, кога видите као госте конференције?
Анастасија: Имаћемо извештаје за програмере којима је стало до судбине свог пројекта, производа, система. Исто тако, биће од интереса за тестере и, чини ми се, посебно за менаџере. Под менаџерима мислим на људе који доносе одлуке и могу утицати на судбину и развој производа, система, тима такође.
То су људи који се питају како да побољшају квалитет производа или система. На нашој конференцији ће се упознати са различитим сетовима мера и моћи ће да схвате шта им сада није у реду и шта треба променити.
Мислим да је главни критеријум схватити да нешто није у реду са квалитетом и желети да утичемо на то. Вероватно нећемо моћи да дођемо до људи који мисле да ће то успети тек први пут.
— Да ли мислите да је индустрија у целини зрела да говори не само о тестирању, већ и о култури квалитета?
Анастасија: Мислим да сам сазрео. Сада се многе компаније удаљавају од традиционалног приступа водопада ка Агиле-у. Постоји фокус на купца, људи у тимовима заиста почињу да размишљају о томе како да направе квалитетан производ. Чак се и привредна предузећа поново фокусирају на побољшање квалитета.
Судећи по броју захтева који се јављају у заједници, верујем да је време. Нисам сигуран, наравно, да ће ово бити револуција великих размера, али бих волео да се та револуција у свести деси.
- Договорено! Усадићемо културу и променићемо свест.
Конференција о висококвалитетном развоју ИТ производа ће се догодити у Москви 7. јуна. Знате које фазе чине производ високог квалитета, имамо случајеве успешног сузбијања грешака у производњи, тестирали смо популарне методе у нашој пракси - потребно нам је ваше искуство. њихов пријаве до 1. маја, а Програмски комитет ће помоћи фокусирању теме за укупни интегритет конференције.
Повезивање са , у којој расправљамо о питањима квалитета и конференције, претплатите се на да будете у току са вестима из програма.
Извор: ввв.хабр.цом