Увядзенне
Добры дзень, хабраўчане. Вырашаў я тут надоечы тэставае заданне на вакансію QA Lead для адной фінтэх кампаніі. Першая задача, скласці тэст-план з поўным чэк-лістом і прыкладамі тэст-кейсаў для праверкі электрычнага імбрычка, вырашаецца трывіяльна:
Лепшага тэст-плана з поўным чэк-лістом прыдумаць складана.
А вось другая частка аказалася пытаннем: "Ці існуюць нейкія праблемы, агульныя для ўсіх тэсціроўшчыкаў, якія перашкаджаюць працаваць з большай эфектыўнасцю?".
Першае, што прыйшло ў галаву: пералічыць усе больш-менш прыкметныя праблемы, з якімі сутыкаўся пры тэставанні, адсеяць драбніцу, астатняе абагульніць. Але хутка зразумеў, што індуктыўны метад адкажа на пытанне, якое адносіцца не да "ўсім", а, у лепшым выпадку, толькі да "большасці" тэсціроўшчыкаў. Таму вырашыў падысці з другога боку, дэдуктыўнага, і вось што атрымалася.
вызначэння
Першае, што я звычайна раблю, вырашаючы новую задачу, - гэта спрабую зразумець пра што яна наогул, а для гэтага трэба зразумець сэнс слоў, якімі яна пастаўлена. Ключавыя словы, у якіх трэба разабрацца, наступныя:
- праблема
- тэсціроўшчык
- праца тэсціроўшчыка
- эфектыўнасць працы тэсціроўшчыка
Звернемся да вікіпедыі і разумнага сэнсу:
(інш.-грэч. πρόβλημα) у шырокім сэнсе — складанае тэарэтычнае ці практычнае пытанне, якое патрабуе вывучэння, дазволу; у навуцы - супярэчлівая сітуацыя, якая выступае ў выглядзе супрацьлеглых пазіцый у тлумачэнні якіх-небудзь з'яў, аб'ектаў, працэсаў і патрабуе адэкватнай тэорыі для яе вырашэння; у жыцці праблема фармулюецца ў зразумелым для людзей выглядзе "ведаю што, не ведаю як", гэта значыць вядома, што трэба атрымаць, але невядома, як гэта зрабіць. Адбываецца ад позн. лац. problēma, з грэч. πρόβλημα «кінутае наперад, пастаўленае наперадзе»; ад προβάλλω «кідаць наперад, выстаўляць перад сабой; вінаваціць».
Сэнсу не шмат, па сутнасці, "праблема" = "што-заўгодна, з чым трэба разабрацца".
— спецыяліст (на віды падзяляць не будзем, бо нас цікавяць усе тэсціроўшчыкі), які прымае ўдзел у тэсціраванні кампанента або сістэмы, вынікам дзейнасці якога з'яўляецца:
- Комплекс мерапрыемстваў які адносіцца да тэставання.
(лац. effectivus) - суадносіны паміж дасягнутым вынікам і выкарыстанымі рэсурсамі (: 2015).
- Наступства ланцужка (чаргі) дзеянняў (вынік) або падзей, выяўленых якасна або колькасна. Магчымыя вынікі ўключаюць перавагу, нязручнасць, выгаду, страту, каштоўнасць і перамогу.
Як і з "праблемай" сэнсу мала: нешта, што атрымалася ў выніку працы.
- колькасна вымяраная магчымасць выканання якой-небудзь дзейнасці чалавека ці людзей; умовы, якія дазваляюць з дапамогай пэўных пераўтварэнняў атрымаць жаданы вынік. Тэсціроўшчык - чалавек, а ў адпаведнасці з тэорыяй вітальных рэсурсаў, кожны чалавек з'яўляецца ўладальнікам чатырох эканамічных актываў:
грашовых сродкаў (даход) - рэсурс аднаўляльны;
энергіі (жыццёвая сіла) - рэсурс часткова аднаўляльны;
часу - рэсурс фіксаваны і прынцыпова неаднаўляльны;
ведаў (інфармацыі) - рэсурс аднаўляльны, гэта частка чалавечага капіталу, якая можа і нарастаць, і разбурацца.
Жадаю адзначыць, што азначэнне эфектыўнасці ў нашым выпадку не зусім карэктнае, бо чым больш ведаў мы выкарыстоўваем, тым ніжэй атрымліваецца эфектыўнасць. Таму я б перавызначыў эфектыўнасць як "суадносіны паміж дасягнутым вынікам і затрачанымі рэсурсамі". Тады ўсё карэктна: веды пры працы не марнуюцца, але памяншаюць выдаткі адзінага прынцыпова неаднаўляльнага рэсурсу тэсціроўшчыка - яго часу.
рашэнне
Такім чынам, шукаем глабальныя праблемы тэсціроўшчыкаў, якія пагаршаюць эфектыўнасць іх працы.
Найбольш значным рэсурсам, які траціцца на працу тэсціроўшчыка з'яўляецца яго час (астатнія так ці інакш можна да яго прывесці), а для таго, каб мы маглі гаварыць аб карэктным разліку эфектыўнасці, трэба і вынік прывесці да часу.
Для гэтага разгледзім сістэму, жыццяздольнасць якой тэсціроўшчык забяспечвае сваёй працай. Такой сістэмай з'яўляецца праект, у каманду якога ўваходзіць тэсціроўшчык. Жыццёвы цыкл праекта можна груба ўявіць наступным алгарытмам:
- Праца з патрабаваннямі
- Фарміраванне тэхнічнага задання
- Распрацоўка
- Тэставанне
- Выпуск у вытворчасць
- Падтрымка (goto п.1)
Пры гэтым увесь праект можна рэкурсіўна разбіць на падпраекты (фічы), з тым жа жыццёвым цыклам.
З пункту гледжання праекта, эфектыўнасць яго рэалізацыі тым большая, чым менш часу на яго патрачана.
Такім чынам, мы прыходзім да вызначэння максімальна магчымай эфектыўнасці тэсціроўшчыка з пункту гледжання праекта - гэта такі стан праекта, калі час на тэсціраванне роўна нулю. А агульнай праблемай для ўсіх тэсціроўшчыкаў з'яўляецца немагчымасць гэтага часу дасягнуць.
Як з гэтым быць?
Высновы цалкам відавочныя і многімі даўно выкарыстоўваюцца:
- Распрацоўка і тэсціраванне павінны пачынацца і заканчвацца практычна адначасова (гэтым звычайна займаецца аддзел ). Ідэальны варыянт, калі ўся распрацоўваная функцыянальнасць да моманту гатовасці ўжо пакрыта аўтатэстамі, арганізаванымі ў рэгрэсійнае (а па магчымасці і прад-камітнае) тэставанне з дапамогай якога-небудзь .
- Чым больш у праекце фіч (чым ён складаней) тым больш часу давядзецца марнаваць на праверку таго, што новая функцыянальнасць не паламала старой. Адсюль чым складаней праект - тым больш патрабуецца аўтаматызацыі. .
- Кожны раз, калі мы прапускаем баг у прадакшн, і карыстач яго знаходзіць, - нам прыходзіцца марнаваць дадатковы час на праходжанне па жыццёвым цыкле праекта пачынальна з п.1 (Праца з патрабаваннямі, у дадзеным выпадку, карыстачоў). Так як прычыны пропуску бага ў агульным выпадку невядомыя, нам застаецца толькі адзін шлях аптымізацыі - кожны, знойдзены карыстальнікамі баг павінен быць уключаны ў рэгрэсійнае тэсціраванне, каб быць упэўненым, што больш ён не з'явіцца.
Крыніца: habr.com