Меню

Що повинен знати тестувальник якості про процес випуску та розгортання

what qa tester should know about release

Спробуйте Наш Інструмент Для Усунення Проблем

На сьогоднішній зустрічі нашої команди менеджер уточнив у всіх своїх готовність до виконання тесту . Він зазначив, що 'код буде готовий до контролю якості завтра вранці'. Що він мав на увазі, коли сказав: 'Код буде готовий', чи означає це, що розробники збираються написати код в середовищі контролю якості сьогодні?

Він насправді мав на увазі, що розгортання планується робити вночі, і новий код буде розгорнуто в середовищі контролю якості для тестування.

Зараз багато хто з вас може запитати, що таке розгортання та що вони насправді роблять у ньому?

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

Що ви дізнаєтесь:

Загальний процес управління випуском та розгортанням та значення для команди контролю якості

  • Чому ми справді підтримуємо різні середовища?
  • Як код переноситься з одного середовища в інше?

У цій статті я розгляну наступні теми

  1. Чому тестувальникам важливо знати про процес випуску та розгортання?
  2. Різні середовища
  3. Що ви маєте на увазі під побудовою та розгортанням?
  4. Планове та екстрене розгортання
  5. Контрольний список контролю якості - до та після розгортання

№1. Чому тестерам важливо знати про процес розгортання?

Наша основна робота з виконання тесту залежить від того, наскільки успішним було розгортання. Якщо команда розгортання зіткнулася з проблемами і зіткнулася з кількома проблемами, і не змогла належним чином розгорнути код, це, безсумнівно, вкаже на те, що команда з контролю якості збирається виявити багато помилок, які можуть бути пов'язані із середовищем або процесом розгортання.

  • Якщо тестувальники знають про процес розгортання, вони зрозуміють важливість виконання своїх завдань у заплановані терміни.
  • Тестери отримають уявлення про те, чи проблема насправді є помилкою функціональності або чимось, що спричинено під час розгортання, кажуть, що призначений тестер для тестування функції звіту, але коли він намагається увійти на веб-сайт, він бачить помилку, що означає, що середовище не працює , такі проблеми не можна розглядати як функціональні, а як екологічні. Якщо тестувальник знає про розгортання, він може пов’язати проблему як проблему розгортання.
  • Багато інших питань можна уникнути, якщо тестувальники дійсно знають про розгорнутий список. Іноді трапляється, що ви тестуєте та повідомляєте про проблему для областей, які ніколи не були розгорнуті.

№2. Різні середовища

Різні середовища

У наведеній вище класифікації я висвітлив 4 найважливіших середовища, яких дотримується більшість організацій, однак, багато клієнтів підтримують набагато більше середовищ, таких як індексація, попереднє індексування тощо. Крім того, правила іменування можуть відрізнятися.

  • DEV - Середовище розробників - це середовище, створене та підтримуване командою розробників для написання коду. Доступ до цього середовища надається лише команді розробників. Зазвичай команда контролю якості не має доступу до цього середовища. Це середовище в основному використовується командою розробників для їх модульного тестування.
  • QA - Середовище контролю якості - це те, де насправді відбувається тестування. Це середовище належить команді QA. Команда DEV не має доступу до цього середовища. Після завершення проектування та кодування код переміщується до середовища контролю якості для команди контролю якості для проведення тесту.
  • UAT - Тест прийнятності користувача - це середовище, де тестування проводять ділові користувачі. Це робиться після завершення тестування системи. Основним наміром є тестування системи з точки зору бізнесу. Доступ до цього середовища надається лише діловим користувачам. Однак іноді вони звертаються за допомогою до контролю якості, за таких обставин команда з контролю якості отримує тимчасовий доступ до навколишнього середовища.
  • PROD - Середовище PROD - це фактичне середовище реального часу, яке піддається реальним користувачам, і жодна з команд DEV та QA не має доступу для читання / запису до цього середовища. Для вирішення питань, пов’язаних із виробничим середовищем, підтримуються команди постійної підтримки.

Також читайте=> Як ефективно підготувати «тест-стіл» та мінімізувати дефекти тестового середовища

№3. Що ви маєте на увазі під побудовою та розгортанням

Збірка в основному містить скомпільований пакет, який може включати виконуваний файл bat, exe, бібліотеки, такі як dll, lib та архіви, такі як zip-файли. Команда розробників створює збірку та надає її команді розгортання для встановлення.

Компіляцією вихідного коду в основному опікується команда розробників, і після того, як вони згенерували збірку, вони розміщують її в певному місці, яке доступне команді розгортання для розгортання в іншому середовищі.

Після розгортання збірки команда QA отримує повідомлення про те, щоб виконати побудувати перевірочне тестування (BVT), і якщо це успішно, команда виконує решту функціональне тестування .

У деяких організаціях, де вони не підтримують окрему команду з розгортання, команда розробників надає збірку до контролю якості, а команда з контролю якості сама завершує розгортання. Існує великий ризик, у таких випадках ресурси контролю якості повинні бути технічно надійними, щоб зрозуміти загальний процес розгортання збірки, а також повинні знати, як усунути проблему.

Збірки підтримуються з використанням чисел, наприклад, 1.0.01 або 1.0.03. Отже, можливо, що збірка 1.0.01 може працювати з DLL v0.2, а збірка 1.0.03 може працювати з DLL v0.5. Для команди контролю якості стає важливо переконатися, що правильна збірка розгорнута в середовищі перед початком тестування. Завжди корисно відстежувати зміни, надані як частина кожної збірки.

Ведення окремої команди розгортання - це завжди хороша практика, оскільки це допомагає плавно переміщувати код з одного середовища в інше.

Розгортання - це процес, за допомогою якого код / ​​збірка переміщується з одного середовища в інше. Велика частина організації в наші дні дотримується належного каналу для розгортання та підтримує окрему групу, яка піклується про все це.

Як перевірити сумісність браузера - -

Збірка та розгортання

До дня розгортання зустрічається команда, що складається з розробника, менеджера з розробки, інженера з розгортання, керівника тестування та інших зацікавлених сторін бізнесу. На зустрічі розробника зазвичай просять описати свої зміни. Зазвичай їм потрібно заповнити конкретну форму з деталями змін та плану відкоту.

У разі пропуску деяких деталей зміни не затверджуються для розгортання. Потім команда вирішує, чи можуть зміни бути частиною розгортання наступного дня. Провідного тестувача якості просять схвалити, щоб переконатися, що зміни не вплинуть на жоден із існуючих тестів. На засіданні заплановано остаточні пункти розгортання.

Затверджений перелік опрацьовується командою з розгортання в день розгортання. Команда запускає набір програм, як визначено у кожній формі змін (надається розробниками), а потім надсилає повідомлення як завершення розгортання.

Повідомлення про завершення розгортання вказує команді контролю якості, що зміни / новий код готовий до тестування.

Команда розгортання відповідає за переміщення змін із DEV на QA. Після завершення тестування контролю якості код переміщується до UAT. Переміщення даних PROD є найважливішою частиною, і це повинно здійснюватися в неробочий час, оскільки під час розгортання середовище повинно бути зруйновано, і це повинно бути зроблено з максимальною обережністю, оскільки це може мати серйозний вплив на бізнес.

Більшість розгортань Prod виконуються пізно ввечері, коли шанси ураження середовища кінцевими користувачами менші.

No4. Планове та екстрене розгортання

Кожна організація веде календар розгортання. Багато клієнтів дотримуються раз на тиждень розгортання, і багато хто ходить на раз на два тижні, кажучи, що заплановане розгортання повинно відбуватися лише у вівторок або може відбутися у вівторок та п’ятницю. Дні розгортання можуть змінитися, якщо запланований день розгортання припадає на вихідні.

У наведеному вище розділі я розглянув процес, який виконується для будь-якого заплановане розгортання .

Заплановані розгортання можуть мати власну проблему. Подумайте про випадок, коли новий код буде розгорнуто в середовищі контролю якості, і під час перевірки на розумність команда виявить дефект блокатора, і тестування має бути припинено. Чи чекає команда випробувачів тиждень до наступного розгортання?

Для вирішення таких ситуацій виконуються аварійні виправлення та розгортання там, де команді розгортання не потрібно чекати запланованого дня розгортання. Їм потрібно стежити і шукати схвалення навіть для екстрених розгортань, але ці схвалення зазвичай відбуваються швидко, і нові зміни можуть бути застосовані до середовища контролю якості того самого дня або якомога швидше.

№5. Контрольний список контролю якості - до та після розгортання

Перед розгортанням -

Все етап проектування тесту має місце до того, як код фактично переміститься в середовище. Це виконання тесту залежить від наявності коду в середовищі контролю якості, в той час як команда розгортання працює над тим, щоб розгорнути код у системі контролю якості, команда контролю якості повинна забезпечити виконання наступних дій -

  • Переконайтеся, що тестові кейси переглянуті та схвалені
  • Переконайтесь, що команда тестування доступна, і планування ресурсів завершено
  • Забезпечте Визначено потреби в даних тестів

Після розгортання -

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

  • Команда контролю якості повинна була отримати повідомлення від команди з розгортання про успішне розгортання та готова до контролю якості.
  • Команда контролю якості повинна стежити за розгорнутою збіркою.
  • Переконайтеся, що команда контролю якості має перелік успішно розгорнутих змін, а також елементів, які не були розгорнуті, навіть якщо вони були заплановані. Може трапитися так, що команда розгортання не змогла розгорнутись через відсутність деталей тощо.

Висновок

Сподіваюся, вищевказана стаття дала вам уявлення про загальний процес управління випуском та розгортанням, який виконувався як частина загального циклу розробки програмного забезпечення. Це була лише загальна процедура, якої дотримувались у більшості організацій, однак у багатьох клієнтів є різні протоколи.

Автор : Ця чудова стаття написана членом команди STH Приєю Р.

Чи знайшов ви цей процес корисним? Повідомте нас про процес розгортання, якого ви дотримуєтесь у своїй організації.

Рекомендована література

^