Меню

Какво трябва да знае QA тестерът за процеса на управление на пускане и внедряване

what qa tester should know about release

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

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

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

Много от вас сега могат да попитат какво е внедряване и какво всъщност правят в него?

процес на управление на пускане и внедряване за qa

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

Цялостен процес на управление на пускането и внедряването и значение за екипа за осигуряване на качеството

  • Защо наистина поддържаме различна среда?
  • Как се мигрира кодът от една среда в друга?

Ще разгледам следните теми в тази статия

  1. Защо е важно тестерите да са наясно с процеса на пускане и внедряване?
  2. Различни среди
  3. Какво имате предвид под изграждане и внедряване?
  4. Планирано спрямо аварийно разполагане
  5. QA контролен списък - преди и след внедряване

# 1. Защо е важно тестерите да са наясно с процеса на внедряване?

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

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

# 2. Различни среди

Различни среди

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

  • DEV - Dev среда е тази, създадена и поддържана от екипа за разработка за писане на кода. Достъпът до тази среда се предоставя само на екипа за разработка. Обикновено екипът на QA няма достъп до тази среда. Тази среда се използва най-вече от екипа на Dev за тяхното тестване.
  • QA - QA среда е тази, в която всъщност се провежда тестването. Тази среда е собственост на екипа за QA. Екипът на DEV няма достъп до тази среда. След завършване на проектирането и кодирането кодът се премества в QA среда, за да може екипът на QA да извърши тестово изпълнение.
  • UAT - Тест за приемане от потребителя е среда, в която тестването се провежда от бизнес потребителите. Това се прави след приключване на тестването на системата. Основното намерение е да се тества системата от бизнес гледна точка. Достъп до тази среда се дава само на бизнес потребителите. Въпреки това, в някои случаи те търсят съдействие за осигуряване на качеството, при такива обстоятелства екипът за осигуряване на качеството получава временен достъп до околната среда.
  • PROD - PROD средата е действителната среда на живо, която е изложена на реалните потребители и никой от екипите на DEV и QA няма достъп за четене / запис в тази среда. Поддържат се предварителни екипи за поддръжка за решаване на проблеми, свързани с производствената среда.

Прочетете също=> Как да подготвим ефективно „Тестово легло“ и да сведем до минимум дефектите на тестовата среда

# 3. Какво имате предвид под изграждане и внедряване

Компилацията съдържа основно компилирания пакет, който може да включва изпълнимия bat, exe, библиотеките като dll, lib и архиви като zip файлове. Екипът за разработка създава компилацията и я предоставя на екипа за внедряване за инсталиране.

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

След като компилацията бъде внедрена, екипът на QA се уведомява да направи тестване за проверка на компилация (BVT) и ако е успешен, екипът изпълнява останалата част от функционално тестване .

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

Компилациите се поддържат с помощта на числа, които казват 1.0.01 или 1.0.03. Така че, възможно е компилация 1.0.01 да работи с DLL v0.2 и компилация 1.0.03 може да работи с DLL v0.5. За екипа за QA става важно да се увери, че правилната компилация е внедрена в околната среда, преди да започне тестването. Винаги е добра идея да следите промените, предоставени като част от всяка компилация.

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

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

Изграждане и внедряване

фаза на жизнения цикъл на разработването на софтуер

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

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

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

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

Отговорността на екипа за внедряване е да премести промените от DEV към QA. След завършване на QA тестването кодът се премества в UAT. Преместването на данни на PROD е най-важната част и трябва да се извършва в извънработно време, тъй като по време на внедряването средата трябва да бъде разрушена и трябва да се извършва с изключително внимание, тъй като това може да има сериозно въздействие върху бизнеса.

Повечето от внедряванията на Prod се извършват късно вечер, когато шансовете околната среда да бъде засегната от крайните потребители са по-малко.

# 4. Планирано спрямо аварийно разполагане

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

В горния раздел разгледах процеса, който се следва за всеки планирано разполагане .

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

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

# 5. QA контролен списък - преди и след внедряване

Преди разполагане -

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

След разполагане -

как да декларирам масив от обекти в java

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

  • Екипът за QA трябва да е получил известие от екипа за внедряване за успешно внедряване и готов за QA.
  • Екипът на QA трябва да следи внедрената компилация.
  • Уверете се, че екипът на QA има списък на промените, успешно внедрени, както и на елементи, които не са разположени, дори ако са били планирани. Може да се случи така, че екипът за внедряване да не може да се разположи поради липсващи подробности и т.н.

Заключение

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

Автор : Тази страхотна статия е написана от член на екипа на STH Прия Р.

Смятате ли, че този процес е полезен? Уведомете ни за процеса на внедряване, който следвате във вашата организация.

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

^