Меню

Як ви вирішуєте, які дефекти допустимі для запуску програмного забезпечення?

how do you decide which defects are acceptable

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

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

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

Часто ми чуємо, що тестування слід проводити до тих пір, поки ми не виконаємо критерії виходу. Ми також чуємо, що дефекти повинні бути виправлені до прийнятного рівня.

Хоча це чудові настанови, вони розпливчасті.

критерії програмного забезпечення

Якщо бути більш конкретним:

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

Рекомендована література => Коли припиняти тестування?

У вас коли-небудь виникали ці запитання? Тоді ця стаття допоможе вам відповісти на них. Читайте далі ...

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

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

  • Як ви вирішуєте розмір дефектів і тип дефектів, з якими ви можете продовжувати життя?
  • Як зробити базове програмне забезпечення для розгортання для запуску?
  • Як координатори UAT закликають до запуску чи ні?
  • За які параметри слід судити програмне забезпечення?
  • Як ми відповідаємо - чи придатне програмне забезпечення для використання та чи принесе воно значення для зацікавлених сторін?

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

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

Зазначені критерії виходу будуть більш-менш визначати прийнятний ступінь проблем у всіх сферах застосування, таких як:

  1. Функціональний
  2. Продуктивність та навантаження
  3. Юзабіліті
  4. Безпека
  5. Інтеграція із зовнішніми системами
  6. Звіти
  7. Міграція даних

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

найкращий безкоштовний блокувальник спливаючих вікон для хрому -

№1. Функціональні дефекти:

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

Функціональні дефекти потім класифікуються відповідно до тяжкість і пріоритетність .

Нижче наведено важливі міркування:

  • Дефекти високої серйозності та пріоритету, як правило, впливають на щоденне використання програмного забезпечення. Ці дефекти є тими, які необхідно виправити перед тим, як ми почнемо працювати. Ніяких винятків.
  • Іноді Функціональні дефекти класифікуються як Запити на зміну, оскільки вони не були частиною спочатку заданих вимог. Такі CR, які є обов’язковими для роботи бізнесу після запуску, також повинні бути впроваджені.
  • Класифікація дефектів та визначення пріоритетів функціональних дефектів проводяться координаторами UAT у співпраці з бізнес-користувачами та бізнес-аналітиками. Зазвичай у клієнта є критерії виходу, скільки% дефектів можуть бути відкриті для запуску.

№2. Дефекти продуктивності та навантаження:

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

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

Іноді частини програми, які не стосуються клієнта, також можуть вплинути на продуктивність.

Наприклад: Якщо існує пакетний процес, який виконується в кінці кожного дня, і якщо час реагування програми страждає, поки це триває, тоді продуктивність пакетного також є фактором, який слід враховувати.

  • Продуктивність, як правило, вимірюється з точки зору часу відгуку екранів, які відображаються та стають доступними для користувачів, коли в системі є певна кількість одночасних користувачів.
  • Тести продуктивності проводяться за допомогою таких інструментів, як LoadRunner , WebLoad , Neoload тощо
  • Продуктивність програмного забезпечення при заданому завантаженні та при прогнозованому завантаженні в майбутньому, як правило, задокументована в контракті і повинна бути продемонстрована перед запуском.
  • Екрани або частини програми, які користуються менше користувачами, переносяться на оцінки після запуску.
  • Продуктивність також залежить від типу обладнання та мережевих умов, на яких розгортається програмне забезпечення.
  • Тести продуктивності проводяться під час UAT у зазначеному обладнанні з використанням інструментів продуктивності, і їх дефекти відстежуються аналогічно функціональним дефектам. Їм також надається пріоритет і досягається консенсус щодо відповідності критеріям виходу для запуску.
  • Зазвичай тести продуктивності та навантаження в UAT проводяться після завершення функціонального UAT діловими користувачами та досягнення прийнятного критерію виходу для функціональних дефектів.

№3. Дефекти юзабіліті:

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

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

  • Рекомендації щодо зручності користування створюються ще до побудови програмного забезпечення. Програмне забезпечення має дотримуватися цих вказівок.
  • При створенні програмного забезпечення також можуть існувати обмеження щодо інструментів, які слід поламати з розумом, перш ніж програмне забезпечення буде використано кінцевими користувачами.
  • За допомогою висококорисного програмного забезпечення кінцевий користувач може вводити дані в 5 разів більше, ніж звичайне програмне забезпечення.
  • Зовнішній вигляд програмного забезпечення повинен бути чітким, а також юридичні питання слід розібрати перед запуском.
  • Багато разів призначається консультант з питань юзабіліті, щоб забезпечити користувачам безперебійну юзабіліті.
  • Документація, яка повинна виходити із програмним додатком, також повинна дотримуватися суворих вказівок щодо юзабіліті, оскільки їх можна використовувати законно.
  • Дефекти юзабіліті, зареєстровані тестувальниками UAT / зовнішніми тестерами, також мають пріоритет як функціональні дефекти та дефекти продуктивності, і вони повинні відповідати критеріям виходу для запуску.

No4. Дефекти безпеки:

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

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

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

№5. Інтеграція із зовнішніми програмними системами:

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

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

Перевірка зовнішньої взаємодії системи повинна широко проводитися на етапах системи та UAT. Це повинно бути обов'язковим щодо критеріїв виходу, які повинні бути виконані перед запуском.

№6. Звіти:

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

Наприклад: усі дані, пов’язані з виставленням рахунків, повинні складатись у залишках кредиту та дебету.

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

№7. Міграція даних:

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

Усі старі дані можуть бути недоступні в новій системі; однак у новій системі може бути доступний знімок старих даних. Ці дані повинні бути доступними за погодженням.

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

Приклад критеріїв виходу для запуску:

Це лише приклад. Це може відрізнятися від проекту до проекту.

  • 100% дефектів пріоритету 1 закрито (критичність серйозності та пріоритет 1)
  • 90% дефектів пріоритету 2 закрито (серйозність висока і пріоритет 2), а для решти 10% дефектів доступне логічне рішення. Також доступний план усунення решти 10% дефектів.
  • Контрольний перелік розгортання виробництва та осудності готовий.
  • Створена команда підтримки виробництва, яка готова до закриття квитків.
  • 70% дефектів пріоритету 3 закриті, і існує план для усунення решти 30% дефектів із низьким рівнем.

Кілька моментів, на які слід звернути увагу:

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

На закінчення

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

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

Не соромтеся розміщувати свої запити / коментарі нижче.

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

^