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