Меню

Кога да избера тестване за автоматизация?

when opt automation testing

Опитайте Нашия Инструмент За Премахване На Проблемите

Трябва ли да обмислим тестване за автоматизация за даден проект? Кога трябва да отидем на тестване за автоматизация?

Тестването се извършва, за да се осигурят качествени продукти на крайния потребител. Фаза на тестване е един от основните аспекти на STLC .

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

Кога да изберете автоматизирано тестване

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

Каквато и работа да бъде извършена, тя трябва да се извършва ефективно и трябва да бъде и рентабилна. Освен това трябва да има смисъл, така че клиентът да се чувства доволен от резултатите.

Какво ще научите:

Тестване на софтуера и ползи от разходите

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

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

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

Тестване на жизнения цикъл

Освен това разходите играят ефективна роля тук. Клиентите предпочитат да приемат софтуер с максимално качество при минимални разходи. Когато отидем на ръчно тестване, процесът е по-досаден и отнема много време, тъй като всичко се извършва ръчно от тестер.

Например , когато се нуждаем от ‘n’ брой тестери, за да изпълнете Регресионно тестване , може да отнеме близо 50 часа за изпълнение на всички тестови случаи. И въз основа на наличността на ресурсите тестовите случаи ще бъдат изпълнени. Но с по-малко време за автоматизирано тестване, се извършва оптимално използване на ресурсите, заедно с максималното покритие на тестовите случаи в сравнение с ръчното тестване.

Процес на ръчно тестване

Интелигентност зад тестването на софтуер

Много е важно всяка организация да знае кога да започне процеса на тестване и кога да излезе от него. Предполага се, че трябва да знаем кога да започнем с тестване, защото е безполезно да започваме тестване, когато е завършена фазата на разработка и когато не са изпълнени необходимите критерии. Винаги е най-добрата практика да започнете с фазата на проектиране на теста, докато разработката е в ход.

Софтуерно тестване на интелигентността

По-долу са дадени критериите за тестване на софтуер за влизане и излизане:

Критерии за влизане

След като проектният документ бъде подписан, плановете за изпитване трябва да бъдат изготвени във фазата на планиране. Тестовият план играе жизненоважна роля. Необходимият хардуер трябва да бъде инсталиран и конфигуриран правилно и функционалността на хардуера трябва да бъде проверена. Функционалните изисквания трябва да бъдат ясни и одобрени. Разработеният код трябва да бъде тестван и подписан от разработчиците.

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

Тестерът трябва да е на разположение. Когато някой от критериите не е постигнат, критериите за влизане при тестване се задържат.

(Забележка: Щракнете върху всяко изображение за увеличен изглед)

Автоматизация на критериите за влизане

Критерии за изход

Само когато поне 95% от задължителните тестови случаи са заключени с резултат „преминаване“, можем да излезем от фазата на тестване на продукта. Въпреки това не е толкова лесно да се определи кога тестването на софтуера може да бъде спряно или дали все още трябва да бъде изпълнено. И този вид ситуация обикновено възниква също.

Автоматизация на критериите за изход

Основните критерии са дадени по-долу:

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

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

Автоматизация на критериите за влизане

Пример: Софтуерът ABC е във фаза на проектиране. Разработването и тестването обикновено се извършват по едно и също време. След като дизайнът е замразен, разработката на софтуера започва. Завършването на разработката на софтуера, както е договорено, посочва критериите за влизане. Резултатите тук са от екипа за разработка. Той включва бележки за изданието и известни проблеми.

След няколко итерации на тестване, когато няма изчакващи разрешения големи / блокиращи / шоу запушалки и 95% от тестването са довели до преминаване, то се посочва като критерии за изход.

Автоматизацията - наистина ли е важна?

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

java програма за сортиране на масив

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

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

Важна ли е автоматизацията

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

Да предположим, че са необходими 10 дни ръчни усилия за покритие на регресионното тестване и тогава трябва да се положат максимални грижи за автоматизирането им. Това може да спести поне 60% усилия и ръчна работа 10 * 8 = 80 часа.

Автоматизацията може да завърши само 80/24 = 3,33 дни. Това спестява приблизително 6,67.

Защо автоматизация?

Автоматизацията може да бъде избрана само когато:

  • Приложението има много обширна област с висока степен на инвестиране на усилия в регресия.
  • Оптимизацията на разходите възникна поради ръчни грешки.
  • Софтуерът има множество версии и версии.
  • Това е рентабилно в дългосрочен план.
  • Рисковият фактор е по-висок за по-широк обхват на изпълнението на теста.
  • Цифрите на разходите и математическите изчисления са включени във функционалността на софтуера.
  • Наблюдава се по-голямо темпо на изпълнение, ефективност, заедно с качеството на софтуера.
  • Има по-малък обрат във времето, дори при високорискови тестове на софтуер.

Рисков фактор

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

Тук автоматизацията ще бъде много полезна при извършване на функционалните транзакции с по-добри темпове според софтуерния механизъм.

Например , в случай на индикатор за Forex пазар, факторът време е много важен и критичен. Промените в запасите и стоките се случват по отношение на времето, понякога по-малко от секунди. Тук Automation може да помогне при тестване на такъв софтуер с висок риск.

Рисков фактор в автоматизацията

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

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

Кога не трябва да се предпочита автоматизацията?

Между няколко организации има въпрос, който е - Защо 100% автоматизация не е възможна?

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

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

Пример: Софтуерът XYZ е вид сайт за електронна търговия, при който изискванията на клиента не са замразени и продължават да се променят, когато се изискват от клиентите.

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

Разходи срещу възвръщаемост на инвестициите за автоматизация

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

Помислете за дизайна на тестовите случаи по-важен при избора на автоматизация и всеки инструмент, за да сте сигурни, че няма да увеличи разходите.

Ръководство за сравнение на разходите срещу автоматизация

Къде автоматизацията може да направи НАМАЛЯВАНЕ от минимално до БЕЗ РАЗХОД

Дори автоматизацията струва, защото необходимият инструмент за тестване трябва да бъде закупен. Ресурсите трябва да бъдат обучени с конкретния инструмент. Избраният инструмент трябва да е осъществим за тестване на всички области на софтуера.

Така че изборът на инструмента трябва да се извършва внимателно от експертите по автоматизация тестване.

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

Когато изчислената сума на премията не съвпада с първоначалната премия (т.е.), когато има разлика в изчислението на премията отпред и отзад, тогава възниква голям проблем между клиента и продавача на продукта. Той може да съдържа много модули като автомобили, дома и други.

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

Заключение

Както автоматизацията, така и ръчното тестване също имат предимства и недостатъци. Само когато сме наясно с концепциите и изискванията, ще можем да изберем какъв вид тестване да извършим.

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

В горната статия може да сме пропуснали няколко фактора, любезно споделете факторите, които смятате за важни, докато избирате автоматизация или дори инструменти за автоматизация.

Междувременно не се колебайте да споделите вашите коментари / предложения относно тази статия.

Препоръчително четене

^