Панайот Солаков има над 9 години опит в тестването на софтуер, а понастоящем е QA team lead в Playtech Bulgaria. Лектор е по „Основи на софтуерното тестване“ в Soft Academy, а в  свободното си време обича да се занимава с музика. На предстоящото събитие на DEV.BG „Описание и управление на тестови сценарии – проблеми и решения“ Панайот ще говори за това какво и защо да оптимизираме, как детайлите при писане на test cases влияят на ефективността при тестване, какви са често срещаните проблеми и полезни съвети/решения при създаването на test cases и др. Вижте какво разкрива той по темата, непосредствено преди събитието:

В кои случаи е за предпочитане да се работи с test cases и в кои с тест сценарии?

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



 

Събитие на фокус:

Multithreading with Swift 3.0

 


 

С две думи, да определим какво ще тестваме на едно „по-високо“ ниво. Тест кейсите, на свой ред, конкретизират сценария, те са „по-ниското“ ниво, на което дефинираме как точно ще тестваме и опитваме да покрием сценария от всички възможни страни. Все пак, ако нямаме достатъчно време, за да напишем детайлни тест кейси, или пък сложността на продукта не го налага, можем да се задоволим и само с използването на тестови сценарии. Все по-широката употреба на Agile методите също често налага по-гъвкав подход при планиране и тестване, в това число акцентиране повече върху exploratory testing, отколкото подробно и детайлно описание на тест кейси.

Кое е най-важното, което трябва да съобразим при разработката на тестови сценарии?

Когато говорим за тестови сценарии, трябва да опитаме да се поставим в ролята на крайния потребител – как той ще използва системата, кои са най-важните и функции и характеристики. Това, от своя страна, изисква максимално близка работа с всички участници в проекта – от представителите на бизнеса (по възможност и самия клиент) до програмистите. Само така можем да подсигурим, че сме фокусирали тестването на правилните места, както и че всички са „на една страница“, и наистина разработваме правилният продукт.

Какви стъпки е необходимо да бъдат извършени за един цялостен софтуерен тест?

Цялостен тест, за мен, означава възможността да повлияем продукта, да го тестваме на всяко едно ниво – от първоначалните изисквания до завършения резултат. В начало е важно да добием ясна представа за софтуера и качествата, които трябва да притежава. На ранен етап можем да предотвратим потенциални проблеми, още при дефинирането на изискванията и самия дизайн. На тази основа трябва да определим и къде ще фокусираме вниманието си, какви видове тестове ще изпълним и каква тестова стратегия ще бъде най-ефективна. Самото тестване най-често включва комбинация от unit, integration и system testing, както и различни нефункционални тестове, които да покрият набелязаните изисквания към системата. Тестването не би било пълно, ако процесът не включва и адекватна форма на user acceptance testing, чрез който да получим навременна обратна връзка от клиента/крайния потребител.

Кои са нещата, които правят един test case добър?

За мен лично това са фокус, яснота и леснота на поддръжка. Всеки тест кейс тряба да тества нещо конкретно, да има ясна цел. Трябва да е написан максимално кратко и ясно, така че да бъде разбираем за всички в екипа, без да дава широко поле за интерпретация/тълкувания. Третото много важно нещо е поддръжката – особено, когато става дума за големи системи и огромен брой тестове. Като цяло понятието „добър тест кейс“ често е доста субективно и също като всяка друга креативна дейност (в това число и писането на код) е процес на постоянно усъвършенстване и търсене на оптималното. Но в крайна сметка именно това прави тази част от тестовия процес толкова разнообразна и интересна.

Стани част по потребителската група Software Quality Assurance. Абонирай се и ще ти изпращаме информация за всичко, което предстои в групата.

Други интересни статии:
„Автоматизацията в сегашната ера е като измислянето на трактора“ – Антон Ангелов, QA Architect, Progress
Петър Събев, QA Manager: „Mалка инвестиция, направена по-рано, се изплаща многократно по-късно“

Автор: Стеляна Луизова
Визия: Личен архив

Share This