Вовед
Добро попладне, жители на Хабровск. Баш сега решавав тест-задача за слободно работно место QA Lead за Финтех компанија. Првата задача, да се создаде тест план со комплетна листа за проверка и примери на тест случаи за тестирање на електричен котел, може да се реши тривијално:
Тешко е да се замисли подобар план за тестирање со комплетна листа за проверка.
Но, вториот дел се покажа како прашање: „Дали има некои заеднички проблеми за сите тестери што ги спречуваат да работат поефикасно?
Првото нешто што ми падна на ум беше да ги набројам сите повеќе или помалку забележливи проблеми со кои наидов за време на тестирањето, да ги отстранам малите нешта и да ги сумираме останатите. Но, брзо сфатив дека индуктивниот метод ќе одговори на прашање кое не важи за „сите“, туку, во најдобар случај, само за „мнозинството“ тестери. Затоа, решив да и пријдам од другата страна, дедуктивно, и ете што се случи.
Дефиниции
Првото нешто што обично го правам кога решавам нов проблем е да се обидам да разберам за што се работи, а за да го направам тоа треба да го разберам значењето на зборовите што го поставуваат. Клучните зборови за разбирање се следниве:
- проблем
- тестер
- тестерска работа
- ефикасност на тестерот
Да се свртиме кон Википедија и здравиот разум:
(старогрчки проблем) во широка смисла - сложено теоретско или практично прашање кое бара проучување и решавање; во науката - контрадикторна ситуација која се појавува во форма на спротивставени позиции во објаснувањето на какви било појави, предмети, процеси и бара соодветна теорија за нејзино разрешување; во животот, проблемот е формулиран во форма што е разбирлива за луѓето: „Знам што, не знам како“, односно се знае што треба да се добие, но не се знае како да се направи тоа. . Доаѓа од доцна. лат. проблем, од грчки. проблем „фрлен напред, поставен напред“; од προβάλλω „фрли напред, стави пред тебе; Вина".
Нема многу смисла, всушност, „проблем“ = „се што треба да се реши“.
- специјалист (нема да се делиме на типови, бидејќи сме заинтересирани за сите тестери) кој учествува во тестирање на компонента или систем, чиј резултат е:
— збир на активности поврзани со тестирањето.
(лат. effectivus) - односот помеѓу постигнатиот резултат и искористените ресурси (: 2015).
- последица на синџир (серија) дејства (резултат) или настани, изразени квалитативно или квантитативно. Можните исходи вклучуваат предност, недостаток, добивка, загуба, вредност и победа.
Како и со „проблемот“, има мало значење: нешто што излезе како резултат на работа.
- квантитативно мерливата можност за вршење на каква било активност на лице или луѓе; услови кои овозможуваат користење на одредени трансформации за да се добие посакуваниот резултат. Тестерот е личност и во согласност со теоријата за витални ресурси, секое лице е сопственик на четири економски средства:
готовината (приходот) е обновлив ресурс;
енергија (животна сила) е делумно обновлив ресурс;
времето е фиксен и суштински необновлив ресурс;
знаењето (информациите) е обновлив ресурс, тоа е дел од човечкиот капитал кој може да расте и да се уништи.
Би сакал да забележам дека дефиницијата за ефикасност во нашиот случај не е сосема точна, бидејќи колку повеќе знаење користиме, толку е помала ефикасноста. Затоа, јас би ја редефинирал ефикасноста како „однос помеѓу постигнатите резултати и потрошените ресурси“. Тогаш сè е точно: знаењето не се троши за време на работата, но ги намалува трошоците на единствениот фундаментално необновлив ресурс на тестерот - неговото време.
Решение
Значи, бараме глобални проблеми на тестери кои ја нарушуваат ефикасноста на нивната работа.
Најзначајниот ресурс што се троши на работата на тестерот е неговото време (остатокот може да се сведе на него на овој или оној начин), а за да зборуваме за правилно пресметување на ефикасноста, резултатот исто така мора да се сведе на време .
За да го направите ова, размислете за систем чија одржливост тестерот ја обезбедува преку неговата работа. Таков систем е проект чиј тим вклучува тестер. Животниот циклус на проектот може грубо да се претстави со следниов алгоритам:
- Работа со барања
- Формирање на технички спецификации
- Развој
- Тестирање
- Пуштање во производство
- Поддршка (одете на ставка 1)
Во овој случај, целиот проект може рекурзивно да се подели на потпроекти (карактеристики), со ист животен циклус.
Од гледна точка на проектот, колку помалку време е потрошено на него, толку е поефективна неговата имплементација.
Така, доаѓаме до дефиниција за максимална можна ефикасност на тестерот од гледна точка на проектот - ова е состојбата на проектот кога времето за тестирање е нула. Чест проблем за сите тестери е неможноста да се постигне ова време.
Како да се справите со ова?
Заклучоците се сосема очигледни и се користат од многумина долго време:
- Развојот и тестирањето треба да започнат и да завршат речиси истовремено (ова обично го прави одделот ). Идеалната опција е кога целата функционалност што се развива е веќе покриена со автотестови до моментот кога ќе биде подготвена, организирана во регресивно (и, ако е можно, претходно извршување) тестирање со користење на некој вид .
- Колку повеќе функции има проектот (колку е покомплексен), толку повеќе време ќе треба да се потроши за да се провери дали новата функционалност не ја раскинува старата. Оттука, колку е покомплексен проектот, толку повеќе автоматизација е потребна .
- Секој пат кога ќе пропуштиме грешка во производството и некој корисник ќе ја најде, мораме да потрошиме дополнително време поминувајќи го животниот циклус на проектот почнувајќи од точка 1 (Работа со барања, во овој случај, корисници). Бидејќи причините за промашување на грешка се генерално непознати, ни останува само една патека за оптимизација - секоја грешка што ќе ја најдат корисниците мора да биде вклучена во тестирањето за регресија за да бидете сигурни дека нема да се појави повторно.
Извор: www.habr.com