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

Предизвикателство №1: Спазване на изискванията

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

Трябва ли да актуализирате тестовите случаи веднага след получаване на актуализираните изисквания? Кои тестови случаи ще трябва да се актуализират? Трябва ли да актуализирате за регресионни тестове? Какъв е процесът за уведомяване на QA екипа за промени в изискванията? – На всички тези въпроси може да се отговори чрез дефиниране на процес за актуализиране на документацията.

В идеалния случай екипът за разработка трябва да разполага с план за оценка на актуализациите и предприемане на действия. Понякога изискванията се променят на 11-ия час и тестването трябва да се извърши бързо, за да се постигне резултат. В тези случаи QA трябва да бъде гъвкав, но непоколебим в тестовата документация. Задаването на планирано време за редовни тестови актуализации е ключът към поддържането на върха в тази област. Това планирано време може да се основава на работата на Sprint в рамките на Agile среда, където всяка потребителска история се разглежда за тестова актуализация. Друг метод може да бъде актуализиране на тестове за всяка версия.

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

Предизвикателство №2: Балансиране на спринтовата работа
Тестването на софтуер в Agile рамка за разработка носи няколко предизвикателства пред QA страна на нещата и ролята на QA в един гъвкав екип може да се различава в сравнение с други методологии за управление на проекти. Едно от предимствата на тестването в Agile е възможността да се разглеждат промените рано и често, което означава, че софтуерът трябва да е готов за QA екипа да тества по-бързо, след като изискванията са създадени или актуализирани. Този бърз обрат дава шанс на QA екипа да открие проблемите навреме и да предостави обратна връзка на екипа веднага. Предизвикателството може да бъде поддържането на спринтовата работа, като същевременно се приспособява регресионното тестване за издание.

Работата, извършена в рамките на спринта, обикновено е различен набор от задачи от тези, необходими за регресионно тестване и сертифициране на издание. QA трябва понякога да отделя ресурси за освобождаване на тестове и да жертва време от спринтова работа. Спринтовата работа е разработката и тестването, която се извършва (обикновено в среда за разработка) в рамките на даден период от време. При пъргав спринт може да продължи от 1 до 3 седмици. Ако част от работата по спринта се извършва за скорошно издание и QA тества за незабавно издание, тогава вниманието, отделено на спринта, може да намалее.

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

Често QA ще трябва да отдели допълнителни часове, за да поеме редовната спринтова работа. В крайна сметка правилното планиране и комуникация трябва да облекчат необходимостта от извънреден труд или оставяне на пропуски в тестването.

Предизвикателство №3: Решете къде да тествате
Решаването къде да тествате може да не изглежда като често срещано предизвикателство, но помислете за предишния проблем, който разгледахме – балансиране на тестването на версията и спринтовото (разработващо) тестване. Тестването на версията обикновено се извършва в среда, отделна от спринтовата работа. И така, „къде“ в този случай е конструкцията и околната среда.

Често има множество среди за тестване като разработка, QA, етапи и производство. Производствената среда обикновено е запазена за производствените потребители, но трябва да е достъпна и за тестване. Сценичната среда обикновено е настроена да бъде най-подобна на производствената, така че тестването тук е запазено за извършване на тази окончателна проверка преди пускане на живо. Средите за разработка и QA са настроени по различен начин, но и двете се използват основно за тестване.

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

Ключовете към това предизвикателство са оценка на приоритетите, оценка на риска и разбиране на околната среда. В идеалния случай QA може да следва промените през цикъла на разработка и да ги тества във всяка точка от пътя. В реалния свят има дни, в които трябва да се вземе решение за тестване на предстоящата компилация на кандидат за освобождаване, вместо на компилацията в разработката. Трябва да се формулира план с екипа за разработка, за да се разберат рисковете и приоритетите. Настройката на средата е от решаващо значение, когато тествате клиент. Ако средата не е настроена за функцията, която се тества, в крайна сметка ще пропуснете грешки, ще докладвате невалидни грешки или няма да можете да тествате в тази среда.