how improve test release process
Нека да видим типичния процес, свързан с доставката на софтуер от „фаза на разработка“ до „фаза на тестване“ за a успешно издаване на софтуер без грешки за производство / клиент .
Тези процеси се пренебрегват или пропускат от софтуерните компании, което води до лошо управление на тестовете и по този начин „ бъги ”Софтуерът се издава на клиента, което води до“ недоволни клиенти ”.
Въпреки че много време и големи усилия се отделят от екипа за тестване за всяко издание , когато пуснатият софтуер няма качеството, както е дефинирано или е маркирано или не отговаря на очакваните критерии, това не само ще повлияе на репутацията на компанията сред клиентите, но също така ще демотивира и деморализира екипа на проекта, най-важното екипът за тестване като цяло .
Ако сте част от екип за тестване в този сценарий, може да продължите да си мислите „как да подобря възможностите си за тестване и има ли по-добър начин за преодоляване на тази ситуация“.
Искам да дам някои съвети и предложения въз основа на моя опит с различни екипи за тестване, участващи в софтуерни приложения и издания на корпоративни продукти с множество домейни и платформи и с множество рамки за тестване, на как да подобря процесите на освобождаване на теста , което ще опрости професионалния ви живот като тестов инженер или тестов мениджър за предоставяне на софтуер от световна класа.
Какво ще научите:
- Процес на тестово освобождаване
- Подобряване на процеса на освобождаване на теста:
- Управление и контрол на съдържанието на тестовото издание
- Примерен шаблон за доклад за издаване:
- Заключение:
- Препоръчително четене
Процес на тестово освобождаване
Таблицата по-долу дава преглед на тестовия процес на освобождаване с три универсални фази като Input, Process & Output.
най-добрите шпионски телефонни приложения за android
| ВХОД | ПРОЦЕС | ИЗХОД |
|---|---|---|
| 7 | Контролният списък за преглед на кода е актуализиран и наличен във VSS? | |
| Предишен процес Развитие | Процесът започва с • Инсталиране на освободен софтуер в сървъра за тестване | Следващ процес се нуждае • Софтуер, който е преминал изпитване за дим / здравословен разум |
| Справка за информация / документ • Документ за потребителски изисквания • Спецификации на софтуерните изисквания • План за единично тестване • Стандарти за кодиране • Контролен списък за преглед на кода • План за развитие • План за осигуряване на качеството • Разпределение на задачите • Работен пакет • График на проекта • Проектен план • План за управление на конфигурацията • План за управление на риска. | Подпроцеси • Подготовка на тестови случаи за всички блокове • Разработка и тестване на модули • Работа с процедури за несъответствие • Прилагане на план за управление на конфигурацията. • Прилагане на план за управление на риска • Мониторинг на напредъка на проекта • Коригиране на грешки и отзиви | Вътрешни нужди на клиента • Изграждане на софтуер с номер на версия • Доклад за освобождаване • Тестови случаи / Документ на тестовия пакет • Планиране на тестовото изпълнение • Матрица за проследимост • Тестови данни |
| Проверка на входящия вход • Проектните документи се преглеждат и одобряват? • Стандарти за кодиране, контролен списък за преглед на кода са налични за справка? • Разпределена задача и актуализиран работен пакет? • Функционалната спецификация, планът за развитие и планът за качество са прегледани и одобрени? • Планът за управление на риска има смекчаване и непредвидени ситуации за справяне с риска? • Ефективност на графика на проекта за доставяне на продукта в срок? | Спецификация на процеса • Казусите за единични тестове трябва да се състоят от всички критерии за влизане и излизане • Спазване на кода със стандартите за кодиране • NCP трябва да се обработва съгласно Насоките • Стъпките за управление на конфигурацията трябва да се придържат към плана за управление на конфигурацията • Управлението на риска трябва да се придържа към плана за управление на риска • Изпитването на дим преминава всички основни характеристики и функционалности | Нужди на външни клиенти • Софтуер без грешки |
| Поддържащи процеси • Разпределение на хора / хардуер / софтуер / ресурси • Поддръжка на хардуерна разбивка • Обучение за членове на екипа | Процесът завършва с • Изпълнение на тестове за дим / здрав разум на освободената сграда | Параметри на ефективност • Всяка единица трябва да премине първия кръг на тестване • Задачи, които трябва да бъдат изпълнени съгласно графика на проекта • Тестът за дим трябва да се премине преди освобождаването • Тестване на екипната страст за тестване на софтуера |
Всеки екип за тестване трябва да създаде a уникален контролен списък за издаване на софтуер, според домейна и платформата на софтуера и методологията за управление на проекти (като Agile Scrum и др.) и според ръчната / автоматизирана рамка за тестване, за да приемете освободената компилация, преди да започнете изпълнението на теста, за да спестите време и усилия.
Това е един от най-важните параметри на ефективност във фазата на тестване.
Подобряване на процеса на освобождаване на теста:
1) Прегледайте доклада за освобождаване за новата функционалност, персонализиране / модификация на съществуваща функционалност, поправки на грешки от предишната компилация, които ще решат да започнат изпълнението на тестване на дим или тестване на здравословното състояние или комбинация от двете.
2) Прегледайте актуализацията Документи за тестване според новата функционалност и корекциите на грешки, ако вече не са актуализирани. Обикновено по време на жизнения цикъл на разработката на софтуер тези документи се актуализират от екипа за тестване въз основа на редовните седмични срещи за преглед на проекти.
3) Прегледайте софтуера за изграждане на хранилище за конфигурация се актуализира за номера на компилация, номера на версията, етикетиран или коментиран с името на версията съгласно стандартите, дефинирани в плана на проекта. Също така, уверете се, че компилацията е успешно компилирана и инсталирана на сървъра за тестване.
4) Насрочете среща за бърз преглед на проекта след пускането да обсъдим плюсовете и минусите на пуснатата компилация, известни грешки и критична функционалност и т.н., за да избегнем всякакви грешки и да прегледаме всички важни изисквания на клиента. Строго избягвайте всяка устна комуникация между екипите за разработка и тестване, тъй като това силно влияе върху качеството на издаването на софтуера.
5) Уверете се, че инструментът за проследяване на грешки е конфигуриран правилно , за разпределения екип за тестване и екип за разработка на проекта, номера за изграждане и издаване на софтуер, както и модулите / функционалността на софтуера, които ще помогнат за ефективното регистриране на грешките. В противен случай трябва да бъде ескалиран до мениджъра на проекта или тестовия мениджър с висок приоритет.
6) Върнете компилацията на екипа за разработка без никакви компромиси, ако компилацията се провали в Smoke или Sanity Testing. Строго, тестването не трябва да продължава, когато системата се провали при тестване на дим. Това ще спести много време и усилия и ще подобри качеството на софтуера, пуснат в следващите версии.
7) Планирайте издаването на проекта на 1улДен от седмицата което ще помогне на тестовия мениджър да планира предстоящия тестов цикъл въз основа на стабилността на компилацията, а също и да изпрати бърз доклад за теста на мениджъра на проекта, който ще ескалира качеството на софтуера доста предварително. Ако екипът за разработки планира пускането на проекта в петък, уикендът може да се използва за всякакви изплъзвания, както и за всякакви проблеми с изграждането в ръчна или автоматизирана рамка за изграждане.
8) Уверете се, че тестерите са обучени правилно в домейна което ще помогне на екипа за тестване да спазва графика за тестване и да събере време за следващия кръг на тестване. Също така, екипът за тестване трябва да бъде обучен и да има излагане на необходимата технология като скриптове и SQL, ако проектът изисква бял бокс.
9) Избягвайте разпределението на тестери в множество проекти тъй като силно влияе върху качеството на изпълнението на теста в реално време. На практика дори опитните тестери пренебрегват характеристиките и функционалността, както и пропускат тестовите случаи, като приемат, че някои тестови случаи никога не се провалят, когато са претоварени с работа или разпределени по множество проекти със срокове.
10) Оценявайте екипа за тестване, за да имате страст тъй като тестерите не трябва да работят за „Ден“ или да коментират „Наречете го ден“. Когато софтуерът има множество модули и функционалистът е изцяло или частично интегриран или взаимосвързан, тестерите трябва да имат страстта да пишат / изпълняват тестовите случаи с голямо покритие и матрица за проследяване, насочени към качеството на крайния софтуер / продукт. Защото дори козметичният проблем е „грешка“ и се брои като „1 грешка“.
единадесет) Уверете се, че инсталацията на софтуера е лесна и ясна тъй като помага на екипа за тестване да преинсталира софтуера, когато е необходимо, вместо да чака мениджърът на разработката или мениджърът на инсталацията да свършат същата работа, което излишно ще убие наличното време за тестване. Например, въпреки че инсталацията на Windows е лесна, но когато включва множество уеб сървъри и широкообхватни мрежи в многостепенна среда за тестване, тестерите може да отнемат часове, за да инсталират софтуера. Ако обхваща софтуерно тестване и инсталиране, деинсталиране , кръпки или актуализации на софтуера, е по-вероятно да бъде обсъден подробно процесът на изпълнение на тестовите случаи с екипа за тестване.
12) Уверете се, че автоматизираните инструменти са достъпни с лиценз за рамка за тестване на автоматизация . Изпълнението на тестови случаи в автоматизирана рамка е лесно в сравнение със сценария за ръчно тестване, при условие че автоматизираните инструменти са правилно конфигурирани и лицензирани за множество потребители. Особено, когато планът за тестване включва тестване на производителността и натоварването, освен редовното тестване на тестови случаи и тестване на регресия, тестерите трябва да обхващат изпълнение на тестови случаи в множество среди като множество сървъри, множество браузъри, множество потребители и т.н.
13) Уверете се, че Ghosted Machines са настроени за тестване преди да започне изпълнението на теста. Призрачните машини са машини с различна среда за тестване. Например, софтуер за уеб приложения може да бъде планиран да тества в множество среди като Windows 7 & Access DB или Windows 2008 & SQL Server или Windows 8 & Oracle или Mainframe & DB2 и т.н., с всички браузъри като Chrome, Firefox, Internet Explorer , Safari и др., Някои „Тестване на системата“ дори изисква напълно да форматирате твърдия диск и да инсталирате нов софтуер или да актуализирате съществуващия софтуер с корекции и актуализации и т.н.
14) Избягвайте да прилагате новите функции / заявка за промяна като спрете изпълнението на теста и повторно пуснете софтуера за повторно заявяване на фазата на тестване. Това е много лоша практика в много софтуерни организации според бизнес изискванията за задоволяване на външните клиенти или поне за удовлетворяване на изискванията на управителния управителен комитет или понякога екипите за продажби / маркетинг. Въпреки че заявките за промяна от клиентите винаги се насърчават в среда на проект „Agile“, тя трябва да бъде правилно планирана и внедрена преди пускането на софтуера на екипа за тестване.
Управление и контрол на съдържанието на тестовото издание
Управлението и контролът на съдържанието на тестовото издание е най-важно за всеки ИТ софтуер или дори за всяка друга софтуерна среда, която ще бъде изобразена на фигурата по-долу.
- Ръководителите на проекти и / или ръководният комитет на проекта зависи от правомощията на организационната матрица, отговаря за избора на съдържанието за всяко издание.
- След като бъговете и / или новите функции и искането за промяна от клиентите бъдат идентифицирани и одобрени, то ще бъде приложено от екипа за разработка, който трябва да бъде информиран до заинтересованите страни по проекта, преди да започне разработването / внедряването.
- Въз основа на внедрената окончателна версия, екипът за тестване ще актуализира свързаните документи и ще се подготви за тестването съответно.
- Екипът за тестване ще започне тестване на Smoke / Sanity съгласно определените изисквания в доклада за освобождаване.
- След като Sanity премине, екипът за тестване ще започне изпълнението на теста според графика и разпределените задачи, а именно, Функционално тестване, Нефункционално тестване, Тестване на сигурността, Тестване на системата, Тестване на производителността, Тестване на товара, Тестване за приемане от потребителя и т.н.
- След приключване на първия кръг от тестовия цикъл, докладите от тестовете ще бъдат изпратени до всички заинтересовани страни и ръководителя на екипа за разработка, за да планират следващата итерация на изпълнението на теста.
- В зависимост от състоянието на докладите от тестовете и тежестта и сложността на грешките, ще бъде планиран пълен цикъл от втори кръг на тестване на изпълнение или регресия, заедно с теста за приемане от потребителя.
- След завършване на планираните цикли за изпълнение на теста, тестовите отчети ще бъдат изпратени на всички заинтересовани страни в проекта за преминатите / неуспешните / пропуснатите функции, функционалност и корекции на грешки.
Примерен шаблон за доклад за издаване:
Забележка : Примерен шаблон на MS Word за отчет за изданието също е достъпен за изтегляне по-долу.
Намерете по-долу „ Примерен доклад за издаване ”, Който обхваща основните аспекти на процеса на издаване, което прави професионалния живот на целия проект много по-щастлив от всякога.
GPSNavigation_Release_Report_Ver_1.0.7_Release_14.0_Build_105.25.03
# 1) Обхват
GPS навигацията за XYZ Company Limited се пуска за вътрешно тестване. Издадената версия е 1.0.7, номерът на изданието е 14.0 и номерът на компилация 105.25.03. Тази версия на софтуера включва новите функции и основните корекции на грешки от предишната версия. Изпитването на дим се преминава от фазата на разработка, но се изисква Smoke & Sanity преди да отидете на тестване за регресия.
# 2) Референции
GPSNavigation_URD_1.0.12, GPSNavigation_FFD_2.17, GPSNavigation_BusinessUseCases_1.23.10, GPSNavigation_TestPlan_1.44, GPSNavigation_TestSuites_2.10, GPSNavigation_UnitTesting_23.3
# 3) Описание на изданието
Тази версия е контролирана версия на GPS навигация и съдържа следните функции и функционалност.
Функциите, отбелязани с *, са нови в тази версия.
Следните функции не са внедрени в тази версия.
1. Модул 1
1.1 Функция 1
1.1.1 Функционалност 1
# 4) Управление на конфигурацията
Използваме Visual Source Safe като инструмент за управление на конфигурацията. Компилацията е достъпна по следния път.
Вътрешна връзка: http://234.23.45.111/internalbuild/gpsnavigation/release1.0.13
Външна връзка: https: // 234.23.45.111/externalbuild/gpsnavigation/release1.0.13
# 5) Инструкции за инсталиране и стъпки
Дайте подробна информация за инсталирането на компилацията на екипа за QA / тестване.
# 6) Отстранени проблеми / грешки
Състоянието на грешките се актуализира в системата за проследяване на дефекти.
# 7) Проблеми / грешки, които трябва да бъдат отстранени
# 8) Резултати
# 9) Известни грешки / проблеми
# 10) Списък за проверка на изданията
| Да не / | Описание | Д / Н |
|---|---|---|
| един | Всички файлове ли са проверени в Visual Source Safe? | |
| две | Поставен ли е етикетът в правилната папка във VSS съгласно вътрешните стандарти? | |
| 3 | Идентификацията може ли да бъде идентифицирана като „външна“ / „вътрешна“ версия във VSS? | |
| 4 | В коментарите спомената ли е версията във VSS? | |
| 5 | В коментарите споменато ли е кратко описание във VSS? | |
| 6 | Кодът е прегледан и проблемите с прегледа на кода се регистрират в Clear Quest? | |
| 8 | Документът за единичен тест е подготвен и прегледан? | |
| 9 | Изпълнени случаи на единични тестове и резултатите актуализирани за състоянието? | |
| 10 | Актуализиран документ за единичен тест е наличен във VSS? | |
| единадесет | Всички проблеми с Clear Quest за това издание са разрешени / затворени? | |
| 12 | Всички задачи на работния пакет завършени и актуализирани във VSS? | |
| 13 | Извършено ли е и премина ли тестването на дим? |
=> Изтегли: Щракнете тук, за да изтеглите примерен шаблон за доклад за издание във формат MS Word.
Заключение:
Как да подобрявам процеса на непрекъснато освобождаване
Съвет # 1) Създайте инженерен екип за издания, който ще се погрижи за критичните фактори за поддържане на изданията и компилациите на софтуера и отговаря за централизираните системи за управление на конфигурацията на софтуера.
Съвет №2) Мотивирайте и оценете екипите на проекта за проследяване на процеса, включен в жизнения цикъл на разработката на софтуер, жизнения цикъл на разработването на продукти и жизнения цикъл на тестване на софтуер. Можем да дефинираме процеса, но докато и освен ако не бъде последван от участващи хора, няма полза от дефинирането на процеса.
Съвет # 3) Оценете усилията за тестване въз основа на опита и предишната история. Писането на тестови случаи е напълно различно от изпълнението на едни и същи. Тестерите трябва да разберат какво да тестват, как да тестват и кога да тестват, в противен случай усилията, дадени на тестовия цикъл, се губят, въпреки че са се случили множество кръгове на тестовия цикъл.
Съвет # 4) И накрая, ако е възможно и осъществимо, автоматизирайте фазата на тестване, като използвате някои общоприети инструменти за тестване. Използването на автоматизирани инструменти за изграждане и автоматизирани инструменти за тестване намалява усилията за тестване с повече от 50%, подобрявайки качеството на софтуера и гарантира 100% качество, ако рамката за автоматизация е правилно проектирана.
Съвет # 5) Не на последно място, тестовото издание не е просто работа, а изкуство да се направи животът на всички заинтересовани страни по-лесен и по-удобен.
За автора: Balu A. е опитен технически функционален ИТ специалист с над две десетилетия опит в ИТ софтуера и десетилетие опит в управлението на проекти и тестове, предоставящи корпоративни приложения и решения за мобилност в различни домейни, използващи технологии на Microsoft, Oracle, Java и Mobile. Той е основно лидер със страст да насърчава хората да станат лидери с правилното отношение и обича да работи в ориентирана към процеса среда и вярва, че процесът подобрява ефективността, качеството и производителността на служителите.
Вследващ урок, ще научим - Как да Подобрете ефективността на тестовите случаи.
Споделете вашите мисли / запитвания в коментарите по-долу.
Имате издание на софтуер според процеса!
Пълно тестване по график с голяма производителност и усилия !!
Опитайте се да постигнете доставяне на софтуер без грешки, гарантирано качество !!!
Ако харесвате тази статия, помислете дали да не я споделите с приятелите си!
Препоръчително четене
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Какво е тестване на маймуни при тестване на софтуер?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- Примерен доклад за грешка
- Практически софтуер за тестване на QA процес (изисквания за освобождаване)