Въведение
Добър ден, хабровчане. Решавах тук наскоро тестова задача за вакансията QA Lead в една финтек компания. Първата задача, да съставя тестов план с пълен чеклист и примери за тестови случаи за проверка на електрическа чайник, е лесна за решаване:
Трудно е да измисля по-добър тестов план с пълен чеклист.
Но втората част се оказа въпрос: “Има ли някакви общи проблеми за всички тестери, които пречат да работят по-ефективно?”
Първото, което ми дойде на ум: да изброя всички по-значителни проблеми, с които съм се сблъсквал при тестовете, да отсея маловажните, а останалото да обобщя. Но бързо разбрах, че индуктивният метод ще отговори на въпрос, който се отнася не до „всички“, а, в най-добрия случай, само до „повечето“ тестери. Затова реших да подходя по друг начин, дедуктивно, и ето какво се получи.
Определения
Първото, което обикновено правя, когато решавам нова задача, е да опитам да разбера за какво точно става дума, а за това трябва да разбера смисъла на думите, с които е формулирана. Ключовите думи, които трябва да изясня, са следните:
- проблем
- тестировщик
- работа на тестировщика
- ефективност на работата на тестировщика
Нека се обърнем към Википедия и здравия разум:
(древногръцки πρόβλημα) в широк смисъл — сложен теоретичен или практичен въпрос, който изисква изучаване, разрешаване; в науката — противоречива ситуация, която се проявява под формата на противоположни позиции в обяснението на някакви явления, обекти, процеси и изисква адекватна теория за нейното разрешаване; в живота проблемът се формулира в разбираем за хората вид „зная какво, не зная как“, т.е. известно е какво трябва да се получи, но не е известно как да стане. Произхожда от латинското problēma, от гръцкото πρόβλημα „изхвърлено напред, поставено отпред“; от προβάλλω „хвърлям напред, поставям пред себе си; обвинявам“.
Смисълът не е много, всъщност, “проблема” = “всякакво нещо, с което трябва да се разбера”.
— специалист (без да разделяме на видове, тъй като ни интересуват всички тестери), участващ в тестването на компонент или система, чийто резултат е:
— комплекс от мероприятия, свързани с тестването.
(лат. effectivus) — съотношение между постигнатия резултат и използваните ресурси (:2015).
— последствие от поредица действия (или събития), изразено качествено или количествено. Възможните резултати включват предимства, неудобства, ползи, загуби, стойности и победи.
Както и с „проблемата“, смисълът е малък: нещо, което произтича от работата.
— количествено измерима способност да се извършва определена дейност от човек или хора; условия, които позволяват с помощта на определени преобразувания да се получи желан резултат. Тестерът е човек и съгласно теорията за жизнените ресурси, всеки човек притежава четири икономически актива:
парични средства (приходи) — ресурс, който е обновяем;
енергия (жизнена сила) — ресурс, който е частично обновяем;
време — ресурс, който е фиксиран и принципно невъзможно да се обнови;
знания (информация) — ресурс, който е обновяем, част от човешкия капитал, който може да нараства или да се разрушават..
Искам да подчертая, че определението за ефективност в нашия случай не е напълно коректно, тъй като колкото повече знания използваме, толкова по-ниска е ефективността. Следователно бих препоределил ефективността като "съотношение между постигнатия резултат и изразходваните ресурси". Тогава всичко е коректно: знанията по време на работа не се харчат, но намаляват разходите на единствения принципно невъзобновяем ресурс на тестера — неговото време.
Решение
И така, търсим глобалните проблеми на тестерите, които влошават ефективността на тяхната работа.
Най-същественият ресурс, който се изразходва при работата на тестера, е неговото време (останалите по един или друг начин могат да бъдат свързани с него), а за да можем да говорим за коректно изчисление на ефективността, трябва да приведем и резултата към времето.
За целта ще разгледаме система, чиято жизнеспособност тестировчикът осигурява със своята работа. Такава система е проект, в който екипът включва тестировчик. Жизненият цикъл на проекта може грубо да се представи с следния алгоритъм:
- Работа с изискванията
- Формиране на техническото задание
- Разработка
- Тестиране
- Пускане в производство
- Поддръжка (върнете се към т. 1)
При това целият проект може рекурсивно да бъде разделен на подпроекти (функции), с идентичен жизнен цикъл.
От гледна точка на проекта, ефективността на неговото реализиране е по-голяма, колкото по-малко време е изразходвано за него.
По този начин стигаме до определението за максимално възможната ефективност на тестировчика от гледна точка на проекта — това е състояние на проекта, при което времето за тестване е равно на нула. Общият проблем за всички тестировчици е невъзможността да се постигне това време.
Как да постъпим с това?
Изводите са напълно очевидни и отдавна се използват от много хора:
- Разработването и тестването трябва да започват и завършват почти едновременно (обикновено с това се занимава отделът ). Идеалният вариант е, когато всичката разработена функционалност в момента на завършването вече е покрита с автоматизирани тестове, организирани в регресионно (а при възможност и пред-комитно) тестване с помощта на някое .
- Колкото повече функции в проекта (колкото по-сложен е той), толкова повече време ще се наложи да отделим, за да проверим, че новата функционалност не е повредила старата. Оттук следва, че колкото по-сложен е проектът — толкова повече автоматизация е необходима .
- Всеки път, когато пропуснем бъг в продукция, и потребителят го открие, — трябва да отделим допълнително време за преминаване през жизнения цикъл на проекта, започвайки от т. 1 (Работа с изискванията, в конкретния случай, на потребителите). Тъй като причините за пропускането на бъга обикновено са неизвестни, остава само един път за оптимизация — всеки бъг, открит от потребителите, трябва да бъде включен в регресионното тестване, за да сме сигурни, че той повече не ще се появи.
Източник: habr.com
