Тестови анализатори - кои са те?

Каня читателя да се присъедини към мен и да види какво прави тестовият анализатор през деня (моите задължения включват не само работа като тестер, но и като тестов анализатор). И така, добре дошли в света на анализа!

Как изглежда типичният ми ден като тестов анализатор

На сутринта получавам по пощата писмо от клиента с данни за получаване на комплекта за разпространение на продукти и формални изисквания за него. Лошата новина е, че нямаме техническа спецификация като такава. Добра новина - представителят на клиента се оказа млад мъж, отворен за комуникация.

изследвайте продукта;
създайте логическа карта на продукта;
разбийте софтуерния продукт на съставните му части;
приоритизиране на тестването.

Изследване на софтуерни продукти

И така, след като сварих чаша ароматно кафе, започвам да изследвам продукта. Проучвам цялата документация, с която разполагам, опитвайки се да разбера как клиентът иска да види продукта. На този етап най-активно участвам в дискусията на представителя на клиента: при липса на ясна техническа спецификация само той може да каже какво точно трябва да направи продуктът.

На първо място, трябва да разбера целта на създаването на този продукт. По какви начини трябва да се постигне? Какви са основните и спомагателните възможности на продукта за потребителите? Едва след това инсталирам дистрибуционния комплект и се опитвам да преценя дали разработчикът е разбрал клиента.

Логическа карта

След като оформих предварителна идея за продукта, съставям логическа карта (мисловна карта).

Този подход ви позволява да постигнете няколко цели едновременно.

Първо, цялостен поглед върху целия проект дава възможност да се проследят логическите връзки в продукта и да се идентифицират така наречените "тесни места".

Второ, когато картата е подробна, функциите се разделят на най-малките, атомни компоненти (всъщност продуктът се разлага), представени в графична форма.

Картата показва функционални модули на продукта, които след това са разделени на най-малките части (до отделни формуляри, полета, отметки и т.н.). Ако е възможно, картата трябва да се побере изцяло в зрителното поле. В центъра е централното звено (система). Клоните се изтеглят по посока на часовниковата стрелка от централния блок (започвайки от дясната страна). От клоновете на първото ниво има разделение на по-дълбоки нива. Препоръчително е да използвате 5 до 7 клона на ниво.

Всички те се различават по лекота на използване, набор от параметри и цена (има и безплатни опции). Най-простият инструмент е лист на Whatman и флумастер, но все пак е по-удобно да се коригира и допълни карта в електронен вид. Повече подробности по темата за мисловните карти са разкрити тук. Имайте предвид, че по време на процеса на изграждане на карта е много желателно да получите обратна връзка от клиента.

Разлагане

Процесът на изграждане на карта е неразривно свързан с извършването на разлагане на продукта. Както бе споменато по-горе, тъй като продуктът е изследван и неговата карта е изградена, функционалността е разделена на най-малките части. Най-често, когато се разлагам, използвам следните правила:

2. Системата е дезагрегирана само по един атрибут, постоянен за всички нива.
Изключително трудно е да се постигне това разделение при тестване на софтуер, така че това правило може да бъде леко модифицирано: всички обекти от едно и също ниво, които са подсистеми на една и съща система, трябва да бъдат разделени според един атрибут. С други думи, те трябва да отговорят на същия въпрос за своя родител. Например за онлайн магазин това могат да бъдат продуктови каталози, продукти, информационни блокове на самия продукт (характеристики, рецензии, снимки и т.н.).

Кликването върху снимката ще отвори пълната версия.

Дълбочина на разлагане

Дълбочината на разлагането (броят на нивата) се определя от удобството за възприемане на получената йерархична структура от определен специалист. За човек с добро познаване на системата разлагането може да бъде плитко и по-малко подробно. Ако резултатът от разлагането е предназначен за специалист, който преди това не е работил със системата, тогава разлагането трябва да се извърши по-подробно и по-задълбочено.

Кликването върху снимката ще отвори пълната версия.
Както можете да видите на илюстрацията по-горе, за някои модули е достатъчно да се подразделят на второ ниво (така нареченото "Пакетно инсталиране"), а за други до четвърто (така нареченото "Разширено инсталиране"). Случва се, че за някои модули е достатъчно едно ниво. В нашия пример ще координираме с клиента разпределението на няколко функционални блока, които са от най-голямо значение за продукта; всички те са подразделени до елементарни части. Ние разглеждаме „малки“ блокове на ниво големи модули. По този начин се повдига и въпросът за приоритизиране на продуктите.

Приоритизиране

Разглеждайки получения (макар и малък) проект, разбирам, че дори при цялото ни желание да тестваме абсолютно всичко в определената времева рамка, ние физически няма да имаме време. Какво да правим в такава ситуация? Мога да предложа на клиента няколко опции: например, можем да увеличим времето за тестване или да разширим екипа. Но дори такива мерки не могат да гарантират, че ще проверим абсолютно цялата функционалност.

Като алтернатива можем да изберем най-приоритетните области и да им обърнем голямо внимание; останалата част от функционалността ще бъде покрита само от тестове за дим. След като изслуша аргументите ми, клиентът се съгласява да даде приоритет.

По принцип приоритизирането може да се извърши съгласно следните критерии:
1. Изисквания на клиента.
Изискванията на клиентите са много важни и са свързани с промоцията на продукти и продажбите.
2. Степен на риск.
Функционалността, чийто отказ ще донесе най-големи загуби, трябва да бъде тествана първо и най-задълбочено.
3. Сложност на системата.
Най-сложните свойства трябва първо да бъдат тествани. Това ще помогне да се избегне преразход на бюджет и време.
4. Времеви ограничения.
Много е важно да се тестват всички необходими свойства преди освобождаването. Можете да отложите свойствата, планирани за следващото издание. Полезна информация за тестовото определяне на приоритетите може да се намери в беседата на Наталия Рукол.

Кликването върху снимката ще отвори пълната версия.
И така, работният ми ден почти приключи. Остава да предадем цялата получена и обработена информация на тестовия дизайнер за разработване на стратегия и писане на тестове.

Заключение

Обобщавайки, можем да кажем, че тестовият анализатор е вид връзка между клиента и останалата част от екипа за тестване. Той е първият, който се запознава с нов материал, систематизира и поставя на рафтовете цялата информация, която попада на един простосмъртен тестер, когато получи продукт за тестване.

В компания с пълен цикъл, където целият процес на разработка от идея до предаване на готовия продукт в ръцете на щастлив потребител не надхвърля един екип, работата на тестов анализатор започва още преди разработчиците да напишат първите редове код . Още на етапа на формиране на изискванията към продукта той открива целите на тестването, разчитайки на основната цел на разработвания софтуер, заложената в него логика, целевата аудитория и възможните специални желания на клиента.