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