Меню

Коли припиняти тестування (критерії виходу при тестуванні програмного забезпечення)

when stop testing

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

Критерії виходу при тестуванні:

'Добре розпочате - наполовину зроблено' - застосовується скрізь, навіть тестування програмного забезпечення.

Часто ми бачимо тестувальників програмного забезпечення з великим ентузіазмом на початку проекту. Ми творимо тестування документів такі як Стратегія випробувань, План випробувань або Тестові справи з бажанням та захопленням.

Тоді ми переходимо до тестування програмного забезпечення за допомогою BANG! Це лише підсилюється цікавими дефектами, які ми знаходимо на початку проекту. Їх вирішення лише додасть нашим досягненням.

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

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

найкращі книги для вивчення кібербезпеки

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

Б'юся об заклад, ви, мабуть, почувались так само і запитували: 'Коли припиняти тестування?', Принаймні один раз. Я б сказав, що питання в цьому 'Коли, де і як зупинити тестування?' :)

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

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

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

Коли достатньо тестування?

Коли можна сказати, що цього тестування достатньо? Чи можна коли-небудь завершити тестування?

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

Давайте подумаємо, що ви починаєте тестування нового проекту.

Початкова діяльність:

  • Команда тестування отримує вимоги.
  • Команда тестування починає роботу планування та проектування.
  • Документи початкового тесту готові та переглянуті.

Тестовий запуск №1)

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

Тестовий запуск №2)

  • Тестувальна група розпочинає другий цикл тестування, і подібні дії виконуються як Запуск 1.
  • У цьому процесі під час другого тестування виявляється ще кілька дефектів.
  • Дефекти розробники виправляють і повертають назад до тестової групи для повторного тестування.
  • Випробувальна група повторно перевіряє дефекти і виконує регресія .

Це може тривати вічно. Запустіть 3, запустіть 4 і далі, поки не будуть виявлені всі дефекти програмного забезпечення, і програмне забезпечення не стане помилковим.

Якщо ми хочемо скласти блок-схему для цих видів діяльності, це буде виглядати приблизно так, як показано нижче:

Тестовий запуск Блок-схема

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

Але питання в тому, - чи можна знайти кожен окремий дефект програмного забезпечення? Спробуємо знайти відповідь на це питання на мільйон доларів :).

Зупинка при виявленні всіх дефектів: чи можливо це?

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

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

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

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

Чесно кажучи, тестування нескінченне, і цикли тестування триватимуть до прийняття рішення, коли і де зупинитись. Тепер стає ще складніше приймати рішення про припинення тестування. Якщо «зупинка при виявленні всіх дефектів» не є критерієм припинення тестування, то на якій підставі це слід вирішити?

Рішення припинити тестування: Критерії виходу

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

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

Подивимось ізприклад.

Сценарій тесту:

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

Сценарій No1)

Тиждень 1: Ви виявляєте дефект showstopper / тяжкості 1 на 1-й день, і все тестування блокується на 3 дні. Отже, ви не зможете виконати жоден із сценаріїв, поки не буде усунуто дефект серйозності 1. Після втрати 3 днів блокатор вирішується, і ви продовжуєте виконувати.

Наприкінці тижня ви виконуєте 20 сценаріїв з кількома ще важливими максимумами пріоритетні дефекти .

Тиждень 2: Ви починаєте тестувати програмне забезпечення, приділяючи більше уваги виявленню дефектів. Ви відкриєте ще кілька дефектів серйозності 1, серйозності 2 та серйозності 3 протягом другого тижня, а наприкінці тижня ви зможете охопити 70 сценаріїв.

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

На цей час усі дефекти високого пріоритету вже знайдені та повідомлені про них. Отже, у вас залишились лише дефекти серйозності 3.

Тиждень 4: До 4-го тижня потрібно повторно перевірити більшість відкритих дефектів та 80 сценаріїв, що залишились. Завдяки цьому до кінця 4-го тижня ви зможете виконати до 180 сценаріїв з усіма виправленими та повторно перевіреними дефектами високого та середнього пріоритету.

Розміщення цієї інформації у табличній формі:

ТижніВиконані тестові заходиРезультат в кінці тижня
Тиждень 1• День 1 - Показати виявлений дефект пробки.
• Тестування заблоковано через дефект серйозності 1, виявлений у день 1.
• Дефект блокувальника усунутий на 4 день.
• Виконання тесту продовжувалось до кінця тижня 1.		• Відкрито дефекти з високим пріоритетом / критичні дефекти.
• 20 сценаріїв виконано.
2 тиждень• Більша увага при пошуку дефектів.
• Виконання решти сценаріїв тесту.
• Повторне тестування виправлених дефектів.		• Відкрито дещо більше дефектів серйозності 1, серйозності 2 та серйозності 3.
• Загальний обсяг 70 висвітлених сценаріїв.
3 тиждень• Повторне тестування всіх дефектів високого пріоритету.
• Виконання решти сценаріїв випробувань.
• Залишилось знайти лише дефекти серйозності 3.		• Відкрито дещо більше дефектів серйозності 1, серйозності 2 та серйозності 3.
• Загальний обсяг 120 охоплених сценаріїв.
4 тиждень• Повторне тестування всіх дефектів високого та середнього пріоритету.
• Виконання решти сценаріїв тесту.		• Відкрито ще кілька дефектів серйозності 3.
• Загальний обсяг 180 охоплених сценаріїв.

Зупинись тут?

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

  • Сценарії виконуються не повністю.
  • Мало потоків навіть не перевіряється один раз.
  • Усі охоплені сценарії виконуються лише один раз.
  • Програмне забезпечення все ще має дефекти.
  • Регресія не охоплюється.

Сценарій No2)

Тиждень 1: Ви виявляєте дефект серйозності 1 на 1 день, і повне тестування блокується на 3 дні. Отже, ви не зможете виконати жоден із сценаріїв, поки не буде усунуто дефект серйозності 1. Після втрати 3 днів блокатор вирішено, і ви продовжуєте виконувати.

Наприкінці тижня ви виконуєте 20 сценаріїв із невеликою кількістю дефектів. Цей тиждень залишається однаковим із сценарієм 1.

Тиждень 2: Ви відкриваєте ще кілька дефектів серйозності 1, серйозності 2 та серйозності 3 протягом другого тижня, але основна увага полягає в тому, щоб охопити більше сценаріїв, щоб покрити відставання з 1-го тижня. Наприкінці тижня ви зможете охопити 120 сценаріїв.

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

Тепер ви можете повідомляти лише про дефекти серйозності 2 та серйозності 3.

Розміщення цієї інформації у табличній формі:

ТижніВиконані тестові заходиРезультат в кінці тижня
Тиждень 1• День 1 - Показати виявлений дефект пробки.
• Тестування заблоковано через дефект серйозності 1, виявлений у день 1.
• Виправлено дефект блокатора на 4 день.
• Виконання тесту продовжувалось до кінця тижня 1.		• Відкрито дефекти з високим пріоритетом / критичні дефекти.
• 20 сценаріїв виконано.
2 тиждень• Основна увага приділяється виконанню більше сценаріїв, щоб покрити відставання від попереднього тижня.
• Повторне тестування виправлених дефектів.		• Відкрито дещо більше дефектів серйозності 1, серйозності 2 та серйозності 3.
• Загальний обсяг 120 охоплених сценаріїв.
3 тиждень• Повторне тестування всіх дефектів високого пріоритету.
• Виконання решти сценаріїв випробувань.
• Залишилось знайти лише дефекти серйозності 3 та декілька дефектів серйозності 2.		• Відкрито дещо більше дефектів серйозності 1, серйозності 2 та серйозності 3.
• Висвітлено всі сценарії.

Зупинись тут?

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

Не насправді через наведені нижче причини:

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

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

Ці критерії називаються критеріями завершення або виходу. Це відповідь на наше запитання - “Коли припиняти тестування?”.

Що таке критерії завершення чи виходу?

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

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

Що повинно бути в критеріях виходу?

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

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

Тестування можна зупинити, коли:

Вимоги:

  • Досягається 100% покриття вимог.

Дефекти:

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

Покриття тесту:

  • Покриття тесту має бути досягнуте на 95%.
  • Коефіцієнт проходження тесту повинен становити 95%. Це можна розрахувати за формулою
    • (Загальна кількість прийнятих ТК / Загальна кількість ТК) * 100.
  • Всі критичні тестові випадки проходять.
  • 5% тестових випадків можуть бути проваленими, але випадки невдалих тестів мають низький пріоритет.
  • Досягається повне функціональне покриття.
  • Усі основні функціональні / ділові потоки успішно виконуються з різними вхідними даними і працюють нормально.

Терміни:

  • Термін завершення проекту або закінчення тесту закінчено.

Тестові документи:

Бюджет:

  • Повний бюджет тестування вичерпано.

Наради 'Go / No Go':

  • ' Go / No Go ' зустрічі було проведено із зацікавленими сторонами, і приймається рішення, чи проект повинен переходити до виробництва чи ні.

Висновок:

Зробіть це дуже просто в кінці.

Будь ласка, відповідайте на запитання простим Так чи Ні.

питання та відповідь на співбесіду з php для досвіду

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

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

Про автора: Це гостьова стаття Ренуки К. Вона має понад 11 років досвіду тестування програмного забезпечення.

Сподіваюся, ця стаття була для вас корисною. Я також хотів би почути ваші думки / коментарі з даної теми.

Щасливого тестування!

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

^