Меню

Как се различава планирането на тестове за ръчни проекти и проекти за автоматизация?

how does test planning differ

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

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

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

=> Щракнете тук за пълна серия уроци за план за тестване

Планиране на тестове

Добър комикс на Дилбърт за планирането:

планиране на проекти

Преди да продължим по-нататък, искам да установя за какво няма да става дума в тази статия.

# 1) Това не е задълбочена дискусия на рамките за автоматизация. Различните проекти използват различни рамки в зависимост от естеството на техния AUT, архитектура, сложност, опит на екипа и т.н.

Информацията относно рамките може да бъде намерена на връзките по-долу:

Тестови рамки за автоматизация, част 1 и част 2 .

# две) Тук също не става въпрос за шаблон, формат или създаване на Документ за план за изпитване . Ще разгледаме съображенията за предварителна документация за проект за автоматизация, по-скоро в редовете на анализ за осъществимост.

# 3) Това също не са инструменти специално. Всяка дейност в SDLC отнема време, усилия, инфраструктура - с други думи - ПАРИ.

За проект за ръчно тестване факторите, отнемащи разходите, са:

  • Хора
  • Инструменти - Управление на тестове / дефекти
  • Инфраструктура - околна среда
  • Време
  • Обучение

За проект за автоматизация, в допълнение към горните елементи, той се нуждае от разходи за:

  • Инструменти за автоматизация
  • Добавка за интегриране на инструмента за управление на тестове
  • Добавка за поддръжка на AUT (като SAP, Oracle и т.н.)
  • Създадена рамка
  • Обучение за конкретни инструменти

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

Недей.

Има един и единствен въпрос, който определя успеха - „Можете ли да генерирате по-добра възвръщаемост на инвестициите (възвръщаемост на инвестициите) в сравнение с ръчния маршрут“? - Ако не веднага, в крайна сметка.

Ако отговорът на този въпрос е „НЕ“, значи сте планирали неправилно проекта за автоматизация.

Обикновено планът за изпитване има следните раздели. Ще обсъдим всеки един от тях, като се фокусираме върху специфични аспекти на автоматизацията, които да разгледаме:

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

Раздели на плана за тестване на автоматизацията

Секция 1:Обхват

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

Раздел # 2: Тестова стратегия

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

Раздел # 3:Ресурси / Роли и отговорности

  • Първата стъпка в тази посока е да се разберат възможностите на екипа и да се предвиди обхватът на автоматизацията, който влиза в картината. Това ще ви помогне да изберете екип, който отговаря както на нуждите на автоматизацията, така и на ръчното тестване. Също така изберете хора, които имат правилното отношение - тези, които не смятат, че ръчното тестване е под техния ръст.
  • Изберете екип, добре запознат с AUT, управление на тестове, управление на дефекти и други SDLC дейности
  • Раздел # 1: Обхват

Раздел # 4:Инструменти

Изберете инструменти за автоматизация въз основа на следните правила:

  • Има ли компанията вече лицензи за определен инструмент, опитайте и вижте дали можете да го използвате
  • Потърсете инструменти с отворен код (но надеждни)
  • Членовете на екипа познават ли инструмента вече или трябва да привлечем някой нов? Или да обучавате съществуващите?

Раздел # 5: Графици

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

Раздел # 6:Заобикаляща среда

  • Целевата среда, която вашият AUT ще работи, и инструментът за автоматизация, който искате да използвате, трябва да са съвместими. Това е един от факторите, които трябва да се считат за предварително лицензиране на инструмента.
  • Също така анализирайте дали останалата част от Инструменти за управление на място и инструментът за автоматизация, който се опитвате да въведете, са взаимосвързани за допълнителна полза.

Раздел # 7:Резултати

  • Вашите тестови скриптове са вашите резултати. Не всеки обаче е разбиран за автоматизация / език за програмиране. И така, планирайте да създадете документ „Как да“, който ще помогне на настоящите потребители и бъдещите членове на екипа да могат да разберат този скрипт, дори когато не сте наоколо.
  • Включете и коментари във вашия скрипт.

Раздел # 8: Рискове

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

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

Ето защо, ако предлагате автоматизиране на система, изберете тази, която е

  • Стабилна и не прекалено много поддръжка
  • Има възможност за огромни регресионни апартаменти
  • Няма прекалено много ръчна намеса или не зависи от човешката интуиция

Раздел # 9:Данни от теста

  • Вземете под внимание аспектите на сигурността на данните
  • Не кодирайте твърди данни за тестове в скриптовете. Това просто води до твърде много поддръжка на скриптове и може да предизвика грешки по време на модификацията.
  • Бъдете много конкретни. За стъпка за ръчно тестване - „въведете собственото име“, можете да кажете въведете произволно име от 5 знака. Докато тествате, тестер може да напише „Swati“ или „Seela“ или нещо друго. Но за инструмент той не може да прави такива предположения. Затова предоставете точни стойности.

Раздел # 10:Доклади / резултати

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

Ние, като ентусиасти на автоматизацията, можем да мислим, че клиентите / ръководството не купуват лесно предложенията за автоматизация.

урок на Microsoft за динамична брадва за начинаещи

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

Планирането и задълбоченият анализ на всички изброени по-горе фактори могат да бъдат наш съюзник в това пътуване. Отново ROI означава всичко.

Тази публикация е написана от член на екипа на STH автори Swati Seela.

Имате въпроси или неща за обсъждане? Чувствайте се свободни да публикувате в коментарите по-долу.

=> Посетете тук за пълна серия уроци за план за тестване

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

^