Невъзможно е да се определи цялостна инвестиция за даден проект, без да се знаят какви техники и инструменти ще са необходими за тестване на уебсайт или приложение.
Конкретните тестове изискват внимателно разбиране на кода и съответната система, на която се изпълнява. Някои тестовете трябва да се изпълнят ръчно, докато други могат да бъдат автоматизирани. Различните стратегии за тестване изискват специфични нива на технически умения, знания и инструменти.
Нека се запознаем с различните типове стратегии и техните предимства.
Статичният тест оценява качеството на системата, без тя все още действително да работи. Разглеждат се части или системни елементи, за да се открият проблеми възможно най-рано. Например, разработчиците преглеждат кода си след писане – това се нарича настолна проверка, и е форма на статичното тестване. Друг пример би била среща за преглед и оценка на изискванията, дизайна и кода. Като предимството тук е, че ако проблем бъде открит в изискванията, преди да се превърне в грешка при системата, това ще спести време на екипа и пари на инвеститорите.
Възможно е да се извършват и автоматизирани статични тестове с правилните инструменти.
Статичните тестове се провеждат не само от технически персонал, но и от други ангажирани лица. Експертите в областта на бизнеса трябва да прегледат изискванията, системните архитекти трябва да прегледат дизайна и т.н., като обратната връзка от тестерите е наложителна, тъй като те са обучени да откриват несъответствия, липсващи детайли, неясна функционалност и т.н.
Въпреки, че статичните тестове са доста полезни, те не са докрай адекватни. Софтуерът трябва да работи на реални устройства и системата трябва да се стартира изцяло, за да бъдат открити още грешки, поради което структурните тестове са една от техниките при модулно тестване.
Изпълняват се от тестери със задълбочени познания за устройствата и системите, на които софтуерът ще функционира. Често се изпълняват на отделни компоненти и интерфейси, за да се идентифицират и локализират грешки и в потоците от данни.
Добър практика би било използването на автоматизирани тестови сценарии за многократна употреба при сходни системи.
Тъй като създаването на структурни тестове изисква задълбочено разбиране на тествания софтуер, те трябва да се изпълняват от разработчици или висококвалифицирани тестери.
В най-добрия случай разработчиците и тестерите работят заедно, за да са максимално ефективни. Тестерите са особено полезни при разработването на тестови скриптове и случаи за многократно използване и споделяне, които намаляват времето и усилията в дългосрочен план.
Поведенческото тестване се фокусира върху това как действа системата, а не върху механизма зад нейните функции. Фокусира се върху работни потоци, конфигурации, производителност и всички елементи от преживяването на потребителя. Целта на тези тестове, често наричани тестове на „черна кутия“, е да тестват уебсайта или приложението от гледна точка на крайния потребител. Подобен тип тестване трябва да обхваща множество потребителски профили и сценарии на използване.
Поведенческите тестове се провеждат предимно ръчно, въпреки че някои могат да бъдат и автоматизирани.
Тестерите трябва да вникнат в бизнес страната на софтуера, особено за това какво искат целевите потребители. За да създадат тестови сценарии, те трябва да знаят какво вероятно ще направят потребителите, след като влязат в уебсайт или приложение.
Стратегическият подход към тестването на софтуера трябва да вземе предвид:
Когато мислим за рисковете трябва да отговорим на въпроса има ли възможност тестовете да нарушат работата на софтуера. Например, ако дадено приложение вече е на пазара, тестовете за нови функции или актуализации могат ли да изложат приложението на риск от срив? В този случай може да се наложи тестерите да разгледат стратегии, които не са склонни към регресия.
Под цели се разбира, че тестовете не трябва просто да измерват дали всички функции на софтуера работят според очакванията и дали отговарят на бизнес изискванията, а и дали наистина ще са от полза за потребителите.
Не на последно място тестваният софтуер трябва да отговаря на всички разпоредби, свързани с неговата индустрия. Обикновено едно и също приложение или уебсайт ще бъдат предмет на различни разпоредби в различни географски региони. Например приложение за мобилно кредитиране. Ето защо тестери и QA инженери трябва да са отлично запознати с местните разпоредби, така че софтуерът да не наруши закона по невнимание.