Що таке пілотне тестування? Визначення, значення, приклади

⚡ Розумний підсумок

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

🎯 Позиція в циклі: Пілотний проект запускається після тестування користувачами та перед тим, як система буде випущена для всіх користувачів.
👥 Учасники: Важливий зворотний зв'язок створює невелика, репрезентативна група справжніх кінцевих користувачів, а не команда проекту.
🧭 П'ять кроків: Планування, підготовка, розгортання та тестування, оцінка, а потім підготовка до розгортання у виробничому середовищі.
🔀 П'ять результатів: Зміна виконання, відкат, призупинення, виправлення та продовження або розгортання.
📊 Критерії виходу: Узгодьте порогові значення дефектів, продуктивності та задоволеності до початку пілотного проекту, а не після отримання даних.
🇧🇷 Не бета-тестування: Пілотний проект контролюється, вимірюється та проводиться всередині обраного об'єкта; бета-релізи доступні для громадськості.

Детальніше

Що таке пілотне тестування?

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

Це тестування проводиться саме між UAT і виробництвом.

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

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

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

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

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

In Розробка програмного забезпеченняПілотне тестування також відповідає на комерційне питання, а саме, чи має продукт або послуга потенційний ринок.

Чому пілотне тестування важливе

Пілотний проект – це остання можливість навчитися чогось дешево. Все, що відбувається після нього, є виробничим інцидентом. Зокрема, пілотний проект забезпечує наступне:

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

Як провести пілотне тестування

Рівень пілотного тестування залежить від розміру та обсягу вашого проекту міграції. Фактичне пілотне тестування проводиться у спеціальній зоні чи лабораторії, де користувачі запускають численні процедури, транзакції та звіти, симулюючи функціональність програмного забезпечення.

Пілотне тестування може проводитися залежно від контексту проекту:

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

Незалежно від контексту, пілотне тестування проводиться за письмовим планом тестування, побудованим з п'яти кроків.

Крок 1: Створення пілотного плану

Крок 2: Підготовка до пілотного тестування

Крок 3: Розгортання та тестування пілотного тесту

Крок 4: Оцінка пілотного тесту

Крок 5: Підготовка до розгортання у виробничому середовищі

Перш ніж проводити пілотне тестування, необхідно врахувати наступне:

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

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

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

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

Критерії входу та виходу з пілотного тестування

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

Критерії участі – пілотний проект може розпочатися, коли:

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

Критерії виходу – пілотний проект завершується, коли узгоджені вимірювання доступні, зазвичай:

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

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

Пілотне тестування проти бета-тестування

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

Аспект	Пілотне випробування	Бета-тестування
Аудиторія	Обрана, репрезентативна група на відомому місці	Будь-який член громадськості, який погоджується
Навколишнє середовище	Виробниче середовище, контрольоване командою	Власні пристрої та мережі користувача
Синхронізація	Після тестування користувачами, перед розгортанням	Після пілотного випуску, ближче до загального релізу
Мета	Доведіть доцільність, вартість, ризик та готовність до розгортання	Збирайте широкий зворотний зв'язок та виявляйте рідкісні проблеми навколишнього середовища
Вимірювання	Формальні критерії входу та виходу з узгодженими показниками	Повідомлення про проблеми та телеметрія використання
Скасування	Сплановано та відрепетировано для пілотної групи	Користувачі самостійно видаляють або відновлюють попередній налаштування

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

Переваги та недоліки пілотного тестування

Компроміс простий: пілот купує докази, а потім оплачує їх за допомогою графіка та координаційних зусиль.

Переваги	Недоліки
Виявляє дефекти в реальних умовах використання, які лабораторія не може відтворити	Додає фазу до розкладу між UAT та випуском
Перевіряє кроки встановлення, навчальні матеріали та процедури підтримки	Потрібне середовище, подібне до виробничого, та спеціальна підтримка
Надає виміряні докази для рішення про те, чи варто, чи ні	Результати є репрезентативними лише настільки, наскільки обрана пілотна група
Обмежує радіус вибуху від несправності однією групою, а не кожним користувачем	Короткий пілотний проект може пропустити кінець місяця, пікове навантаження та сезонну поведінку
Зміцнює довіру зацікавлених сторін перед ширшим розгортанням	Учасники можуть вагатися повідомляти про проблеми у власній роботі в режимі реального часу

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

Хороша практика пілотного тестування

Заплануйте пілотний тест за два дні до тесту зручності використання.
Не розпочинайте пілотне тестування, доки всі користувачі, клієнти та команда проекту не домовляться про критерії успішного результату.
Попросіть користувачів позначити будь-які проблеми на своїх копіях матеріалів, опишіть свої проблеми та запропонуйте пропозиції (якщо вони є) щодо покращення.
Повідомте користувачів про мету, тривалість та хід пілотного проекту.
Оберіть учасників, які відображають реальну аудиторію користувачів, включаючи менш впевнених у собі, оскільки група ентузіастів повідомляє про схвальний результат.
Ведіть єдиний журнал проблем, відгуків та рішень, щоб вихідний огляд працював з одного запису.

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

Приклад пілотного тестування

Нижче наведено кілька типових прикладів пілотного тестування:

Microsoft працює Windows Інсайдерська програма, випускаючи передреліз Windows збірки для волонтерських каналів, перш ніж ці збірки стануть загальнодоступними.
Google працює Android Бета-програма, який реєструє підтримувані пристрої Pixel для попереднього пробного випуску Android будується перед публічним релізом.
HP запускає онлайн-пілотні програми для своїх продуктів і послуг.

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

Поширені запитання

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

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

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

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

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

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

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

Так, для механічних частин — формування форми зворотного зв'язку, запити моніторингу, сценарії відкату та чернетки контрольних списків з існуючих сценаріїв. Обсяг пілотного проекту, вибір учасників та пороги виходу — це бізнес-рішення, які не повинен приймати жоден помічник.