what is acceptance testing
Вступ до приймально-здавальних випробувань (Частина I):
У цій серії підручників ви дізнаєтесь:
- Що таке прийомне тестування
- Приймальні випробування та план випробувань
- Приймальні випробування Статус та зведені звіти
- Що таке тестування прийнятності користувача (UAT)
Ви закінчили тестування системи? Чи виправлено більшість ваших помилок? Чи помилки перевірені та закриті? Отже, що далі?
Далі у списку йде Прийомне тестування, яке є останньою фазою процесу тестування програмного забезпечення . Це фаза, на якій вирішує замовник ПЕРЕЙТИ / НІ-ПЕРЕЙТИ для продукту, і за ним слід обов'язково стежити перед випуском Продукту на ринок. Спільні зусилля команди розробників та випробувачів будуть винагороджені замовником шляхом прийняття або відхилення розробленого Продукту.
Цей унікальний навчальний посібник з прийомних випробувань дасть вам повний огляд значення, типів, застосувань та різних інших факторів, що беруть участь у випробувальному прийомі, простим та легким способом для кращого розуміння.
Що ви дізнаєтесь:
- Що таке прийомне тестування?
- Чому приймальні тести?
- Типи
- # 1) Тестування прийняття користувача (UAT)
- # 2) Тестування на прийняття бізнесу (НДТ)
- # 3) Тестування прийняття контракту (CAT)
- # 4) Нормативи / Тестування на відповідність вимогам (RAT)
- # 5) Тестування на прийомку в експлуатацію (OAT)
- # 6) Альфа-тестування
- # 7) Бета-тестування / Польові тестування
- Хто проводить приймальне тестування?
- Якості приймальних приладів
- Використовуйте
- Різниця між тестуванням системи, тестом приймання та тестуванням приймання користувачами
- Приймальні випробування
- Приймальна ліжка
- Критерії входу та виходу для AT
- Процес перевірки прийнятності
- Фактори успіху для цього тестування
- Висновок
- Рекомендована література
Що таке прийомне тестування?
Одного разу Процес тестування системи заповнена командою тестувальників і підписана, весь Продукт / додаток передається замовнику / декільком користувачам клієнтів / обом, щоб перевірити його прийнятність, тобто Продукт / додаток повинен бути бездоганним, відповідаючи як критичним, так і основні вимоги бізнесу. Крім того, наскрізні потоки бізнесу перевіряються так само, як у сценарії реального часу.
Виробниче середовище буде середовищем тестування для прийняття тестування (зазвичай називається етапним, попереднім випуском, відмовою, середовищем UAT).
Це техніка тестування чорної скриньки де перевіряється лише функціональність, щоб переконатися, що виріб відповідає зазначеним критеріям прийнятності (відсутність необхідності в знаннях щодо проектування / впровадження).
Чому приймальні тести?
Незважаючи на те, що тестування системи було успішно завершено, замовник вимагає перевірки прийнятності. Тести, що проводяться тут, повторюються, оскільки вони охоплювали б тестування системи.
Тоді, чому це тестування проводять замовники?
Це відбувається тому:
- Щоб отримати впевненість у продукті, який виходить на ринок.
- Щоб продукт працював належним чином.
- Забезпечити відповідність товару чинним ринковим стандартам та достатню конкурентоспроможність з іншими подібними товарами на ринку.
Типи
Існує кілька видів цього тестування.
Нижче перелічено кілька з них:
# 1) Тестування прийняття користувача (UAT)
UAT має оцінити, чи працює Продукт для користувача, правильно для використання. Конкретні вимоги, які досить часто використовуються кінцевими споживачами, в першу чергу вибираються з метою тестування. Це також називається тестуванням кінцевого користувача.
Термін 'Користувач' тут означає кінцевих користувачів, яким призначений Продукт / додаток, а отже, тестування проводиться з точки зору кінцевих користувачів та з їх точки зору.
=> Також Читати: Що таке тестування прийняття користувача (UAT)?
# 2) Тестування на прийняття бізнесу (НДТ)
Це призначено для оцінки того, чи відповідає Товар комерційним цілям та цілям чи ні.
BAT головним чином фокусується на вигодах для бізнесу (фінансах), які є досить складними через зміну ринкової кон'юнктури / прогресивних технологій, так що поточне впровадження може зазнати змін, що призведе до додаткових бюджетів.
генератор випадкових чисел від 0 до 1
Навіть Продукт, що відповідає технічним вимогам, може не відповісти BAT з цих причин.
# 3) Тестування прийняття контракту (CAT)
Цей контракт визначає, що як тільки Продукт увійде в дію, протягом заздалегідь визначеного періоду, повинен бути проведений тест приймання, який повинен пройти всі випадки використання приймання.
Підписаний тут контракт називається Угодою про рівень обслуговування (SLA), що включає умови, коли оплата буде здійснена лише у тому випадку, якщо послуги з Продукту відповідають усім вимогам, а це означає, що контракт виконаний.
Іноді цей контракт може трапитися до того, як Продукт з’явиться в дію. У будь-якому випадку, контракт повинен бути чітко визначений з точки зору періоду тестування, областей тестування, умов з питань, що виникають на пізніших етапах, платежів тощо.
# 4) Положення /ВідповідністьПрийомне тестування (RAT)
Це має на меті оцінити, чи не порушує Продукт правила та норми, визначені урядом країни, де він випускається. Це може бути ненавмисно, але негативно позначиться на бізнесі.
Зазвичай розроблений Продукт / додаток, який планується випустити у всьому світі, повинен пройти RAT, оскільки різні країни / регіони мають різні правила та норми, визначені його керівними органами.
Якщо будь-які правила та норми порушені для будь-якої країни, тоді ця країна або конкретний регіон у цій країні не матиме права використовувати Продукт і вважається Помилкою. Постачальники Продукту нестимуть безпосередню відповідальність, якщо Продукт випущений, навіть якщо є порушення.
# 5) Тестування на прийомку в експлуатацію (OAT)
Це для оцінки експлуатаційної готовності Продукту та є нефункціональним тестуванням. Це в основному включає тестування відновлення, сумісності, ремонтопридатності, наявності технічної підтримки, надійності, відмов, локалізації тощо.
OAT в основному забезпечує стабільність продукту перед тим, як випустити його на виробництво.
# 6) Альфа-тестування
Це для оцінки Продукту в середовищі розробки / тестування спеціалізованою групою тестувальників, яку зазвичай називають альфа-тестерами. Тут відгуки тестувальників, пропозиції допомагають покращити використання Продукту, а також виправити певні помилки.
Тут тестування відбувається контрольовано.
=> Також прочитайте: Що таке альфа-тестування?
# 7) Бета-тестування / Польові тестування
Це полягає в оцінці Продукту шляхом виставлення його реальним кінцевим споживачам, які зазвичай називаються бета-тестерами / бета-користувачами, у їхньому середовищі. Збираються постійні відгуки користувачів і вирішуються проблеми. Крім того, це допомагає вдосконалювати / вдосконалювати Продукт, щоб забезпечити багатий досвід користувачів.
Тестування відбувається безконтрольно, а це означає, що користувач не має обмежень щодо способу використання Продукту.
=> Також прочитайте: Що таке бета-тестування?
Усі ці типи мають спільну мету:
- Переконайтеся, що ви отримуєте / збагачуєте довіру до продукту.
- Переконайтесь, що Продукт готовий до використання реальними користувачами.
Хто проводить приймальне тестування?
Для типу Alpha тестування проводять лише члени організації (які розробляли Продукт). Ці учасники безпосередньо не є частиною проекту (менеджери / керівники проектів, розробники, тестувальники). Групи управління, продажів та підтримки зазвичай проводять тестування та надають відповідний відгук.
Окрім типу Alpha, усі інші типи прийняття, як правило, виконуються різними зацікавленими сторонами. Як і клієнти, клієнти клієнтів, спеціалізовані тестери з організації (не завжди).
Також добре залучати бізнес-аналітиків та експертизу предметних питань під час проведення цього тестування на основі його типу.
Якості приймальних приладів
Тестери з наведеними нижче якостями кваліфікуються як приймальні тестери:
- Здатність мислити логічно та аналітично.
- Хороші знання домену.
- Здатний вивчити конкурентоспроможну продукцію на ринку та проаналізувати те саме в розробленому продукті.
- Сприйняття кінцевим користувачем під час тестування.
- Зрозумійте необхідність бізнесу для кожної вимоги та протестуйте відповідно.
Вплив проблем, виявлених під час цього тестування
Будь-які проблеми, що виникають на етапі перевірки приймання, слід розглядати як пріоритетні та негайно усувати. Це також вимагає проведення аналізу корінних причин щодо кожного виявленого питання.
Команда тестування відіграє важливу роль у наданні RCA з питань приймання. Вони також допомагають визначити, наскільки ефективно проводиться тестування.
Крім того, обгрунтовані проблеми в тесті приймання вплинуть як на тестування, так і на зусилля команди розробників з точки зору враження, рейтингів, опитувань клієнтів тощо. Іноді, якщо виявляється будь-яке незнання командою тестувальників щодо перевірок, це також призводить до ескалації.
Використовуйте
Це тестування корисно з кількох аспектів.
Деякі з них включають:
- Щоб з’ясувати проблеми, пропущені на етапі функціонального тестування.
- Наскільки добре розроблений Продукт.
- Продукт - це те, що насправді потрібно споживачам.
- Відгуки / опитування, проведені, допомагають покращити продуктивність продукту та зручність користування.
- Удосконалити процес, за яким слід використовувати RCA як вхідні дані.
- Мінімізуйте або усуньте проблеми, що виникають із виробничим продуктом.
Різниця між тестуванням системи, тестом приймання та тестуванням приймання користувачами
Нижче наведено основні відмінності між цими 3 типами приймально-здавальних тестів.
Тестування системи | Прийомне тестування | Тестування прийняття користувача |
---|---|---|
Проводяться позитивні та негативні тести | Зазвичай проводяться позитивні тести | Проводяться лише позитивні тести |
Наскрізне тестування проводиться, щоб перевірити, чи відповідає Продукт усім зазначеним вимогам | Тестування проводиться, щоб перевірити, чи відповідає Продукт вимогам замовника щодо прийнятності | Тестування проводиться, щоб перевірити, чи виконуються вимоги кінцевих користувачів щодо прийнятності |
Продукт випробовується у цілому, орієнтуючись лише на функціональні та нефункціональні потреби | Продукт перевірений на бізнес-потреби - прийнятність користувача, бізнес-цілі, правила та норми, операції тощо. | Продукт тестується лише на прийнятність користувача |
Команда тестування виконує тестування системи | Клієнт, клієнти клієнтів, тестер (рідко), керівництво, відділ продажів, служби підтримки виконують приймально-здавальне тестування залежно від типу проведеного тестування | Клієнт, замовник Клієнта, тестувальники (рідко) проводять тестування прийнятності користувачами |
Тестові кейси складаються та виконуються | Приймальні тести складаються та виконуються | Прийомні тести користувачів складаються та виконуються |
Може бути функціональним і нефункціональним | Зазвичай функціональний, але нефункціональний у випадку RAT, OAT тощо | Тільки функціональний |
Для тестування використовуються лише дані тесту | Для тестування використовуються дані в режимі реального часу / виробничі дані | Для тестування використовуються дані в режимі реального часу / виробничі дані |
Виявлені проблеми розглядаються як помилки та виправляються на основі серйозності та пріоритетності | Виявлено, що виріб позначає продукт як помилку та вважається виправленим негайно | Виявлено, що виріб позначає виріб як збій і вважається виправленим негайно |
Контрольований спосіб тестування | Може контролюватися або не контролюватися залежно від типу тестування | Неконтрольована манера тестування |
Тестування на середовищі розробки | Тестування на середовище розробки або передвиробниче середовище, або виробниче середовище на основі типу | Тестування завжди проводиться на передвиробничому середовищі |
Ніяких припущень, але якщо такі є, їх можна повідомити | Жодних припущень | Жодних припущень |
Приймальні випробування
Подібно до тестів продуктів, ми маємо приймальні тести. Приймальні тести походять від критеріїв прийнятності історій користувачів. Зазвичай це сценарії, які написані на високому рівні з деталізацією того, що повинен робити Продукт за різних умов.
Це не дає чіткого уявлення про те, як проводити тести, як у тестових випадках. Приймальні тести складаються тестерами, які повністю володіють Продуктом, як правило, знаннями предметних питань. Усі написані тести переглядаються замовником та / або бізнес-аналітиками.
Ці випробування виконуються під час приймально-здавальних випробувань. Разом із приймально-здавальними випробуваннями повинен бути підготовлений детальний документ про будь-які налагодження, які потрібно зробити. Він повинен включати деталі щохвилини з належними знімками екрана, значеннями налаштування, умовами тощо.
Приймальна ліжка
Тест для цього тестування подібний до звичайного тесту, але є окремим. Платформа з усім необхідним обладнанням, програмним забезпеченням, операційними продуктами, налаштуванням і конфігурацією мережі, налаштуванням і конфігурацією серверів, налаштуванням і конфігурацією баз даних, ліцензіями, плагінами тощо повинна бути налаштована однаково виробниче середовище.
Приймально-здавальний стенд - це платформа / середовище, де будуть виконуватися розроблені приймальні випробування. Перш ніж передавати замовнику середовище прийняття, є гарною практикою перевірити наявність екологічних проблем та стабільності Продукту.
Якщо для приймально-здавальних випробувань не створено окремого середовища, для цього можна використовувати звичайне середовище випробувань. Але тут буде брудно, оскільки дані тестування від регулярного тестування системи та дані в режимі реального часу від приймального тестування зберігаються в єдиному середовищі.
Приймальна площадка зазвичай встановлюється на стороні замовника (тобто в лабораторії) і матиме обмежений доступ до команд розробників та випробувань.
Команди повинні будуть отримувати доступ до цього середовища за допомогою віртуальних машин / або спеціально розроблених URL-адрес із використанням спеціальних облікових даних доступу, і весь доступ до них буде відстежуватися. У цьому середовищі нічого не слід додавати / змінювати / видаляти без дозволу замовника, і вони повинні бути повідомлені про внесені зміни.
Критерії входу та виходу для AT
Як і будь-яка інша фаза в STLC, тестування приймання має набір критеріїв входу та виходу, які мають бути чітко визначені в Плані тестування приймання (який висвітлений у подальшій частині цього посібника).
Це фаза, яка починається відразу після тестування системи і закінчується до запуску виробництва. Отже, критерії виходу системного тестування стають частиною критеріїв входу для AT. Подібним чином критерії виходу AT стають частиною критеріїв входу для запуску виробництва.
Критерії вступу
Нижче наведені умови, які слід виконати перед початком:
- Вимоги бізнесу повинні бути чіткими та доступними.
- Фаза тестування системи та регресії повинна бути завершена.
- Усі критичні, основні та звичайні помилки повинні бути виправлені та закриті (незначні помилки приймаються переважно косметичними помилками, які не заважають використанню продукту).
- Перелік відомих проблем повинен бути підготовлений та переданий зацікавленим сторонам.
- Потрібно встановити контрольно-здавальний майданчик і провести перевірку на високому рівні на відсутність екологічних проблем.
- Фаза тестування системи повинна бути підписана, дозволяючи продукту перейти до фази AT (Зазвичай це відбувається за допомогою електронної пошти).
Критерії виходу
AT має виконувати певні умови, щоб дозволити продукт розпочати виробничий запуск.
Вони такі:
- Повинні бути проведені прийомні випробування, і всі випробування повинні пройти.
- Критичні / основні дефекти не залишились відкритими. Усі дефекти слід негайно виправити та перевірити.
- Усі включені зацікавлені сторони повинні підписати AT Go / No-Go Рішення щодо товару.
Процес перевірки прийнятності
В V-модель , Фаза AT паралельна фазі вимог.
Фактичний процес AT відбувається, як показано нижче:
Аналіз бізнес-вимог
Вимоги бізнесу аналізуються, посилаючись на всі наявні документи в рамках проекту.
Деякі з них:
- Технічні вимоги до системних вимог
- Документ про ділові вимоги
- Використовуйте кейси
- Діаграми робочого циклу
- Розроблена матриця даних
План випробувального проекту
Є деякі пункти, які повинні бути задокументовані в План приймальних випробувань.
Давайте розглянемо деякі з них:
- Стратегія та підхід до перевірки прийнятності.
- Критерії в'їзду та виїзду повинні бути чітко визначеними.
- Сфера AT повинна бути добре згадана, і вона повинна охоплювати лише бізнес-вимоги.
- Підхід до проекту приймального тесту повинен бути детально розроблений, щоб кожен, хто пише тести, міг легко зрозуміти спосіб його написання.
- Створено випробувальний стенд, слід зазначити фактичний графік / терміни випробувань.
- Оскільки тестування проводять різні зацікавлені сторони, слід зазначити деталі щодо помилки реєстрації, оскільки зацікавлені сторони можуть не знати про дотриману процедуру.
Розробка та перевірка приймально-здавальних випробувань
Приймальні тести повинні бути написані на рівні сценарію із зазначенням того, що потрібно зробити (не детально, щоб зазначити, як це робити). Вони повинні бути написані лише для визначених областей, що відповідають бізнес-вимогам, і кожен тест повинен бути відображений відповідно до вимог щодо посилань.
Усі письмові приймальні тести повинні бути переглянуті для досягнення високого охоплення вимог бізнесу.
Це робиться для того, щоб переконатися, що будь-які інші тести, крім згаданого обсягу, не беруть участі, щоб тестування знаходилось у запланованих термінах.
Приймальна ліжка встановлена
Тестовий стенд повинен бути встановлений аналогічно виробничому середовищу. Для підтвердження стабільності навколишнього середовища та використання необхідні дуже високі перевірки. Поділіться даними про використання середовища лише із зацікавленою стороною, яка проводить це тестування.
Налаштування даних приймального тесту
Дані про виробництво повинні бути підготовлені / заповнені як тестові дані в системах. Крім того, повинен бути детальний документ таким чином, щоб дані мали використовуватися для тестування.
Не майте даних тестів, таких як TestName1, TestCity1 тощо, натомість використовуйте Альберт, Мексика тощо. Це дає багатий досвід даних у режимі реального часу, і тестування буде найсучаснішим.
Запитання та відповіді на співбесіду для html5
Виконання приймального тесту
На цьому етапі на навколишнє середовище повинні бути виконані розроблені приймальні тести. В ідеалі, всі тести повинні пройти з першої ж спроби. Не повинно бути жодних функціональних помилок, що виникають внаслідок приймально-здавальних випробувань, якщо такі є, тоді про них слід повідомляти з високим пріоритетом, які слід виправити.
Знову ж, виправлені помилки повинні бути перевірені та закриті як високопріоритетне завдання. Звіт про виконання тесту повинен передаватися щодня.
Помилки, зареєстровані на цьому етапі, повинні обговорюватися на нараді щодо виправлення помилок і повинні пройти процедуру аналізу корінних причин. Це єдиний момент, коли приймальні випробування оцінюють, чи справді товар відповідає всім бізнес-вимогам чи ні.
Бізнес-рішення
Виходить a Go / No-Go рішення щодо запуску продукту у виробництво. Іди Рішення призведе до випуску товару на ринок. Ні-Go рішенням позначено товар як Помилка.
Кілька факторів прийняття рішення про заборону:
- Низька якість товару.
- Забагато відкритих функціональних помилок.
- Відхилення від вимог бізнесу.
- Не відповідає ринковим стандартам і потребує вдосконалення, щоб відповідати поточним ринковим стандартам.
Фактори успіху для цього тестування
Після того, як це тестування заплановано, підготуйте контрольний список, який підвищує рівень успішності його. Існує декілька дій, яких слід дотримуватися перед початком перевірки.
Вони є:
- Майте чітко визначений обсяг і переконайтеся, що існує ділова потреба в обсязі, визначеному для цього тестування.
- Виконуйте приймальні тести на самій фазі тестування системи принаймні один раз.
- Виконувати екстенсивно спеціальне тестування для кожного із сценаріїв приймальних випробувань.
Висновок
У двох словах, прийомне тестування допомагає з'ясувати ефективність команд розробників та випробувань.
Існує кілька інструментів для проведення цієї діяльності, але зазвичай переважно робити це вручну, оскільки залучаються реальні користувачі та різні зацікавлені сторони, які не мають технічного досвіду, і це може бути для них нездійсненним.
Що далі?
У нашому наступному підручнику ми зупинимося на наступних темах:
- Приклади критеріїв перевірки прийнятності.
- Як написати план приймальних випробувань.
- Відповідний шаблон для написання приймальних тестів.
- Як написати прийомні тести з прикладами.
- Визначення сценаріїв приймальних випробувань.
- Звіти про приймальні випробування.
- Прийомне тестування в Agile та тестова розробка.
ДАЛІШЕ Підручник №2: План приймальних випробувань
Ви проводили прийомну перевірку? Ми були б раді почути ваш досвід !!
Рекомендована література
- Альфа-тестування та бета-тестування (повний посібник)
- Що таке тестування прийнятності користувача (UAT): Повне керівництво
- Повне керівництво з тестування перевірки складання (тестування BVT)
- Функціональне тестування проти нефункціонального тестування
- Найкращі засоби тестування програмного забезпечення 2021 р. (Засоби автоматизації тестування якості)
- Типи тестування програмного забезпечення: різні типи тестування з деталями
- Підручник з тестування сховища даних ETL (повний посібник)
- Посібник із тестування безпеки веб-додатків