Публикувано на: 11 май, 2022*Текстът е предоставен от DataArt
Автор: Дария Бояджиева, QA Team Lead в DataArt България
Все повече компании от софтуерния бранш осъзнават, че качеството на продукта, който разработват, е от ключово значение за техния бизнес. Професията “QA специалист“ придоби значителна популярност както в глобален план, така и в България.
Много професионалисти от други сфери у нас се преквалифицираха и успяха да се реализират успешно в областта на Quality Assurance. Самата аз, като човек, стартирал в този бранш без никакъв технически опит, съм пример за това, че с постоянство, упоритост и много практика, всичко е възможно.
В тази статия ще поговорим повече за основната терминология в областта на QA – с цялата условност, че списъкът може да се доразвива и допълва. Термините по-долу са част от ежедневната работа, свързана със софтуерното тестване, и могат да са от полза на всеки начинаещ специалист, решил да се насочи към тази професия.
Bug, Error, Defect и Failure
Първо, нека започнем с ключовото разграничение между понятията bug, error и defect.
Тестването е процес на идентифициране на дефекти. По дефиниция дефектът е всяка разлика между действителния и очаквания резултат (expected vs actual result). Error от своя страна се отнася за грешка в кода.
Грешка, открита от QA, се нарича дефект. Дефектът, приет от екипа за разработка, се нарича Bug. В този ред на мисли, ако изграждането не отговаря на изискванията, тогава става дума за Failure. Това е състояние, което възпрепятства софтуера да изпълнява очакваната функция. Говорим за Failure, когато е налице неспособност на дадена система или компонент да функционират според спецификацията си.
При тестване на софтуер, когато очакваното и действителното поведение не съвпадат, трябва да се създаде инцидент (accident). Това е грешка на програмист, когато той възнамерява да реализира определено поведение, но кодът не успява правилно да се съобрази с това поведение поради неправилна реализация в кодирането. Тогава говорим за дефект.
Error е резултат от кодираща грешка, а дефектът е отклонение от изискванията. Дефектът не означава непременно, че има грешка в кода. Може просто да е конкретна функция или модул, която не е внедрена правилно от разработчиците, но е дефинирана в изискванията на софтуера от бизнес анализаторите и product owner-ите.
SDLC
SDLC (Software Development Life Cycle) е процес от началото на проекта до доставянето и поддръжката на софтуера в производствената среда.
Има няколко фази в жизнения цикъл на софтуера. Всяка от фазите има своите тънкости и специфики.
SDLC включва следните фази:
• Фаза на изискване
• Фаза на анализ
• Фаза на проектиране
• Фаза на развитие
• Фаза на тестване
• Фаза на внедряване и поддръжка
STLC
STLC (Software Testing Life Cycle) е процесът, следван от екипа за тестване, за да се стигне до създаването на качествен софтуерен продукт. STLC е неразделна част от SDLC процеса, но се фокусира само върху тестването.
STLC включва следните фази:
• Анализ на изискванията
• Фаза на планиране
• Разработване на тестови случаи
• Настройка на тестова среда
• Фаза на изпълнение
• Затваряне на тестовия цикъл на STLC
Smoke testing
Smoke testing е друг термин в QA, който се използва за тестване, което се прави след някакъв софтуерен build и целта му е да ни увери, че критичните и основните функционалности на програмата или продукта работят както трябва. А също, и че отговарят на изискванията на Product owner-a, описани от бизнес анализатора.
Smoke testing се извършва преди всякакви подробни функционални или регресивни тестове. Този тип тестване има една мисия и тя е да отхвърли „счупено“ или неработещо приложение, така че да спести време на разработчиците и QA екипите за инсталация и тестване.
Loading …
София
Hybrid
Fully RemoteRegression testing
Регресионното тестване има за цел да провери дали промяната на кода на софтуера не засяга съществуващата функционалност на продукта. Това се прави, за да се гарантира, че продуктът работи добре с всяка нова функционалност, поправки на грешки или някаква промяна в съществуващата функция. Изпълнените преди това тестови сценарии се изпълняват повторно, за да се провери въздействието на промяната в софтуера.
Видове тестове за регресия:
1) Регресия на единица
2) Частична регресия
3) Пълна регресия
Sanity check
Sanity check или казано на български „проверка за здрав разум“ , представлява тестване/валидиране на нещо, което трябва да спазва много ясна и проста логика. Образно казано, това е като да се допитаме до някой, който да валидира дали дадено нещо е рационално и нормално и дали следва логиката според неговите виждания. Този тип проверка не се прилага само в сферата на QA, но и в редица други направления и професии. Едно от предимставата на този тип тестване е бързината му.
Sanity check се използва в QA, когато искаме да направим някаква елементарна проверка, с която да проверим дали самият продукт е рационален, но очевидно това изключва грешните резултати. Рационален продукт или софтуер означава, че този продукт следва логиката, като не съдържа критични бъгове. Бъговете могат да са налични, но да са незначителни и да не са критични за целия процес по реализацията на продукта.
Sanity check/testing се прави, когато хората от екипа по разработката искат набързо да видят състоянието, в което се намира продуктът (в кой етап на проекта са), като обикновено това се прави след промяна в кода.
Black Box Testing
При Black Box тестването не е задължително QA специалистът да е изцяло запознат с вътрешната имплементация, структурата и дизайна на приложението или системата, която трябва да се провери. Този тип тестване може да бъде сравнено с черна кутия, чието съдържание е неизвестно, но трябва да провери и валидира цялостното ѝ поведение на база на различни изисквания и критерии (Requirements). Има различни техники, с които да се гарантира покриването на съответните функционални и нефункционални изисквания към системата за конкретен момент.
White Box Testing
При White Box Testing-a се тества всяко малко парче код (unit) от имплементацията на дадената система или продукт. При този тип тестване се обхващат всички методи или функции в кода, всички бранчове, workflows и data flows. Тук вече със сигурност се изискват знания и умения по програмиране. Често този тип тестване се поема от програмистите в екипа, но може да се извършва и от Automation QA. Използва се при Unit и Integration Testing.
Unit testing
Това е метод за тестване, който проверява дали индивидуалните единици от изходния код работят правилно. Единица (или един unit) е най-малката част от едно приложение, която може да се тества самостоятелно.
Unit тестовете са малки кодови фрагменти, създадени от програмистите, а понякога и от white box тестерите в процеса на разработката. Този тип тестове обикновено се пишат и се извършват от програмистите, които искат да се уверят, че кодът работи както трябва.
Unit тестването e от важно значение, тъй като дава възможност проблемите да се открият своевременно.
