На всеки тест инженер се е случвало да попадне в следната ситуация: Тествали сме нещо, положи ли сме доста усилия, мислили сме си, че всичко работи както трябва и след като инсталираме приложението готово за работа, клиент намира проблем, който ние сме пропуснали. Не можем да намираме всички грешки (бъгове) винаги, но това, което можем да направим е да увеличим броя им като си задаваме следния въпрос:
„Какво още не сме тествали?“
Много пъти съм си задавал този въпрос. Старая се да се питам същото нещо всеки път преди да преместя някоя нова функционалност в графата готова за публикуване. В повечето случаи това води до откриване на още дефекти или неща, които могат да се подобрят по съответния продукт или функционалност. Диалогът, който провеждам със себе си протича по подобен начин:
Добрият Тестер: „Какво още не е изтествано?“ „Не сме тествали с администраторски потребител.“
Мързеливият тестер: „Защо да тестваме така, каква би била разликата? Тази функционалност няма нищо общо с потребителските права за програмата“
Добрият Тестер: „Това може да е така, но по-добре да направим и тези тестове, за да имаме по-пълна и ясна картина за приложението, което тестваме“
Мързеливият тестер: „Но аз тествам тази функционалност вече втори ден! Това е достатъчно, пък и искам да продължа с другите функционалности за следващата версия на продукта.“
Добрият Тестер: „Много добре знаеш, че обикновено винаги намираме дефекти, точно в последните неща, които тестваме. За това, нека проверим и това! 😊“
Задавайки си този въпрос, излизат допълнителни въпроси, които си задавам:
1) Тествах ли с повече от един потребител?
Изглежда толкова очевидно, но когато сме „заровени“ в тестването за дадена функционалност, много често забравяме да тестваме с различен потребител от тестовия, който сме направили в началото на тестовата сесия и използваме за всички тестове. Понякога нещо толкова елементарно, като първата буква на фамилията ни може да открие различно поведение на системата, която тестваме в момента.
2) Тествах ли с различни типове потребители?
Или иначе казано, пробвах ли няколко потребителя с различни права и привилегии, от различните потребителски групи? Много често, както вече споменахме, заради наближаващи крайни срокове или нещо друго, тестваме с един единствен потребител. Най-често това е тестов потребител, който създаваме в началото на тестването, и продължаваме всички тестове с него. Още по-голяма грешка е да започнем да тестваме с потребител, който има всички привилегии, така наречения admin потребител. Тогава има вероятност да изпуснем много неща свързани с достъпа на обикновените потребители на системата, които нямат всички права върху програмата или системата.
3) Тествах ли с системата с акаунти на различни компании?
Когато тестваме приложения насочени към бизнес клиенти, или така наречените B2B системи, имаме много често компании с няколко различни потребители, така наречените акаунти, като всеки акаунт на една и съща компания има различни цели и съответно различни нива на достъп до системата. Пример за това е как в една система един акаунт може да вижда основна информация за даден клиент, така че да може да се свърже с него – имейл, телефон, и т.н. а друг акаунт да може да вижда лични данни или друга конфиденциална информация.
4) Тествах ли на мобилни устройства?
Всеки, който е тествал дадено приложение на таблет или мобилен телефон, има представа, че поведението на системата може да е много различно от това на десктоп система – лаптоп или компютър. Никой от нас не иска потребители на нашето приложение, да не виждат части от сайта, които не се показват в мобилния браузър, или още по-често срещано – да не могат да видят някой бутон, или форма за попълване, защото тя не се е показала правилно на екрана на мобилното устройство.
5) Тествах ли с повече от един браузър?
В днешно време браузърите имат доста повече подобно поведение, отколкото преди няколко години, но все пак има още някои неща, които под различните браузъри се държат по различен начин, или не работят въобще. За това е много важно да тестваме с различни браузъри, и особено с тези, които мислим, че нашите клиенти ще ползват най-често.
6) Пробвах ли да променя размера на браузъра?
Често забравям да тествам по този начин. Особено, когато тестваме на голям екран, с много висока резолюция, изпускаме много грешки, които се появяват при по малки екрани или различни резолюции от тази, която ние ползваме.
7) Тествах ли с Back бутона на браузъра?
Ще се учудите, колко грешки можете да намерите от този тест! Много често бутона „Назад“ на самото приложение прави различни неща от бутона “Back” на браузъра. Друго подобно нещо е да тестваме с бутона Enter, особено когато имаме уеб форми. Още нещо полезно е да тестваме „Отмени“ бутона на уеб формите, където го има.
8) Тази функционалност има ли я на други места/страници и тествахме ли я там?
Дадена функционалност може да се намира на няколко места в нашето приложение, и тя да се държи по леко различен начин в зависимост от контекста. За това когато тестваме някаква функционалност е добре да се запитаме на кои места в приложението ни се намира и да я проверим на всички, за да се убедим, че няма да възникнат грешки свързани с различна имплементация на една и съща функционалност на различни места.
9) Тествахме ли въпросната функционалност в комбинация с други функционалности?
Винаги мислете за комбинация от функционалности. Много често когато тестваме дадена функционалност в изолация, всичко изглежда наред и работи според очакванията ни, но когато комбинираме две функционалности(или повече) заедно нещата може да изглеждат много по-различно.
10) Имаме ли негативни тестове за тази функционалност?
Това е нещо, което лесно може да се изпусне, особено, когато се налага да тестваме някаква много сложна функционалност. Някой път самото конфигуриране на системата за тестване на една единствена функционалност отнема ден или повече и когато най-накрая се убедим, че системата прави това, което искаме, забравяме да направим негативните тестове. А те по правило откриват най-много грешки.
11) Имаме ли тестове за сигурност за тази функционалност?
Факт е, че не всички потребители на нашата система ще са добронамерени и легитимни. Част от потребителите, ще се опитат да намерят слабо място в нашата система и да извлекат ползи от тези пропуски. Това е особено в сила за системи, които съдържат лична информация на нашите потребители.
12) Проверихме ли базата данни, за да сме сигурни, че информацията се записва коректно?
Не винаги, когато попълваме форма на уеб страница и видим съобщение за успех, това ни гарантира, че нашите данни са запазени. Още по-малко, че са запазени по правилния начин. Може да има бъг, който пречи на записването на данните в базата. Може да има проблем при самото записване на данните, и те да се записват по грешен начин в самата база. Пример за това е записването на телефонен номер с тиренцата или скобите в базата и последваща грешка при извличането на данните от базата точно заради тези тирета или скоби.
13) Как крайният потребител ще използва тази функционалност? Тествахме ли точно такъв сценарий?
Много е важно да разберем точно по какъв начин потребителите ще ползват нашата система, за да може да направим тестове, които следват същия сценарий. Това, че сме тествали всички функционалности поотделно, не е гаранция, че даден потребителски сценарий ще работи безпроблемно.
Това са въпроси, които са ми помагали много при тестването, надяваме се да са полезни и за вас! Ще научите още много, ако се запишете на нашия курс по “Софтуерно тестване” Следващите начални дати можете да видите на сайта ни, както и всички подробности. Или просто ни се обадете. Очакваме ви!
Атанас Радков
Лектор на курса по „Софтуерно тестване“
