7 principles software testing
Сім принципів тестування програмного забезпечення: включаючи докладнішу інформацію про кластеризацію дефектів, принцип Парето та парадокс пестицидів.
Я впевнений, що всі усвідомлюють “ Сім принципів тестування програмного забезпечення '.
Ці фундаментальні принципи тестування допомагають командам тестування використовувати свій час та зусилля, щоб зробити процес тестування ефективним. У цій статті ми детально дізнаємося про два принципи, тобто Кластеризація дефектів, принцип Парето та парадокс пестицидів .
Що ви дізнаєтесь:
- Сім принципів тестування програмного забезпечення
Сім принципів тестування програмного забезпечення
Перш ніж глибше розглянути ці два принципи, давайте коротко зрозуміємо сім принципів тестування програмного забезпечення.
Давайте досліджувати !!
# 1) Тестування показує наявність дефектів
Кожна програма або продукт випускається у виробництво після достатньої кількості тестувань різними групами або проходить різні етапи, такі як тестування системної інтеграції, тестування прийнятності користувачами, бета-тестування тощо.
Тому Ви коли-небудь бачили чи чули від будь-якої команди тестувальників, що вони повністю протестували програмне забезпечення, і в ньому немає дефектів ? Натомість кожна команда тестувань підтверджує, що програмне забезпечення відповідає всім бізнес-вимогам і функціонує відповідно до потреб кінцевого користувача.
У галузі тестування програмного забезпечення ніхто не скаже, що існує відсутність дефекту в програмному забезпеченні, що цілком вірно, оскільки тестування не може довести, що програмне забезпечення не містить помилок або дефектів.
Однак метою тестування є виявлення дедалі більше прихованих дефектів за допомогою різних технік і методів. Тестування може виявити невиявлені дефекти, і якщо дефектів не виявлено, це не означає, що програмне забезпечення не містить дефектів.
Приклад 1 :
Розглянемо банківську заявку, ця програма ретельно протестована і проходить різні етапи тестування, як SIT, UAT тощо, і в даний час в системі не виявлено дефектів.
Однак може існувати ймовірність того, що у виробничому середовищі фактичний клієнт спробує функціонал, який рідко використовується в банківській системі, і тестери пропустили цю функцію, отже, дотепер не виявлено дефекту або розробники ніколи не торкалися коду .
Приклад 2:
По телевізору ми бачили кілька реклам мила, зубної пасти, засобів для миття рук чи дезінфікуючих спреїв тощо.
Подумайте про рекламу ручного миття, в якій на телебаченні сказано, що 99% мікробів можна видалити, якщо використовується саме ця мийка рук. Це однозначно доводить, що продукт не містить 100% мікробів. Таким чином, у нашій концепції тестування ми можемо сказати, що жодне програмне забезпечення не має дефектів.
# 2) Дострокове тестування
Тестери повинні брати участь на ранній стадії життєвого циклу розробки програмного забезпечення (SDLC). Таким чином, можна виявити дефекти на етапі аналізу вимог або будь-які дефекти документації. Витрати, пов'язані з усуненням таких дефектів, є набагато меншими порівняно з тими, що виявляються на пізніх стадіях тестування.
Розглянемо зображення нижче, яке показує, як зростає вартість виправлення дефектів, коли тестування рухається до реального виробництва.
(зображення джерело )
Наведене зображення показує, що витрати, необхідні для виправлення дефекту, виявленого під час аналізу вимог, менші, і вони продовжують зростати, коли ми рухаємось до фази тестування або технічного обслуговування.
Тепер питання як рано розпочати тестування ?
Після того, як вимоги остаточно визначені, тестувальникам потрібно залучити для тестування. Тестування слід проводити на документах вимог, специфікації або будь-якому іншому типі документів, щоб, якщо вимоги були визначені неправильно, їх можна було негайно виправити, а не фіксувати на стадії розробки.
# 3) Вичерпне тестування неможливе
Неможливо перевірити всі функціональні можливості з усіма дійсними та недійсними комбінаціями вхідних даних під час фактичного тестування. Замість цього підходу розглядається тестування кількох комбінацій на основі пріоритету з використанням різних методів.
Вичерпне тестування вимагатиме необмежених зусиль, і більшість із цих зусиль неефективні. Крім того, часові рамки проекту не дозволять тестувати таку кількість комбінацій. Тому рекомендується перевіряти вхідні дані, використовуючи різні методи, такі як розподіл еквівалентності та аналіз граничних значень.
Наприклад ,Якщо припустимо, у нас є поле введення, яке приймає алфавіти, спеціальні символи та цифри від 0 до 1000. Уявіть, скільки комбінацій з'явиться для тестування, неможливо перевірити всі комбінації для кожного типу введення.
Спроби тестування, необхідні для тестування, будуть величезними, і це також вплине на терміни та вартість проекту. Тому завжди кажуть, що вичерпне тестування практично неможливе.
# 4) Тестування залежить від контексту
На ринку доступно кілька доменів, таких як банківська справа, страхування, медицина, подорожі, реклама тощо, і кожен домен має ряд додатків. Також для кожного домену їх додатки мають різні вимоги, функції, різну мету тестування, ризик, методи тощо.
Різні домени тестуються по-різному, тому тестування ґрунтується виключно на контексті домену або програми.
Наприклад ,тестування банківської програми відрізняється від тестування будь-якої програми для електронної комерції чи реклами. Ризик, пов’язаний із кожним типом заявки, різний, тому не ефективно використовувати один і той же метод, техніку та тип тестування для тестування всіх типів заявок.
# 5) Кластеризація дефектів
Під час тестування може статися так, що більшість виявлених дефектів пов'язані з невеликою кількістю модулів. Для цього може бути кілька причин, наприклад, модулі можуть бути складними, кодування, пов’язане з такими модулями, може бути ускладненим тощо.
Це принцип Парето при тестуванні програмного забезпечення, де 80% проблем виявляється в 20% модулів. Далі в цій статті ми дізнаємося більше про кластеризацію дефектів та принцип Парето.
# 6) Парадокс пестицидів
Принцип пестициду Парадокс говорить, що якщо один і той же набір тестових випадків виконується знову і знову протягом певного періоду часу, то цей набір тестів недостатньо здатний виявити нові дефекти в системі.
Щоб подолати цей «парадокс пестицидів», набір тестових випадків необхідно регулярно переглядати та переглядати. Якщо потрібно, можна додати новий набір тестових кейсів, а існуючі тестові кейси можна видалити, якщо вони більше не можуть знайти дефектів у системі.
# 7) Відсутність помилки
Якщо програмне забезпечення протестовано повністю і якщо до випуску не виявлено жодних дефектів, ми можемо сказати, що програмне забезпечення не містить дефектів на 99%. Але що, якщо це програмне забезпечення перевірено на неправильні вимоги? У таких випадках навіть виявлення дефектів та своєчасне їх усунення не допомогло б, оскільки тестування проводиться на неправильні вимоги, які не відповідають потребам кінцевого користувача.
Наприклад, припустимо, що додаток пов’язаний із веб-сайтом електронної комерції та вимогами до функціональності “Кошик для покупок чи кошик для покупок”, яка неправильно трактується та перевіряється. Тут навіть пошук більшої кількості дефектів не допомагає перенести програму на наступну фазу або у виробниче середовище.
Це сім принципів тестування програмного забезпечення.
А тепер давайте дослідимо Кластеризація дефектів, принцип Парето та парадокс пестицидів у деталь .
Кластеризація дефектів
Під час тестування будь-якого програмного забезпечення тестувальники здебільшого стикаються з ситуацією, коли більшість виявлених дефектів пов'язані з певною функціональністю, а решта функціональних можливостей матиме меншу кількість дефектів.
Кластеризація дефектів означає невелику кількість модулів, що містять більшість дефектів. В основному, дефекти розподіляються не рівномірно по всій програмі, а дефекти концентруються або централізуються за двома-трьома функціональними можливостями.
Іноді це можливо через складність програми, кодування може бути складним або хитрим, розробник може допустити помилку, яка може вплинути лише на певну функціональність або модуль.
Кластеризація дефектів базується на “ Принцип Парето ', Який також відомий як Правило 80-20 . Це означає, що 80% виявлених дефектів обумовлені 20% модулів у додатку. Концепція принципу Парето спочатку була визначена італійським економістом - Вільфродо Парето .
Якщо тестувальники розглядають 100 дефектів, тоді не буде зрозуміло, чи є якийсь основний сенс проти цих 100 дефектів. Але якщо ці 100 дефектів класифікуються за певними критеріями, тестери можуть зрозуміти, що велика кількість дефектів належить лише до декількох конкретних модулів.
Наприклад ,давайте розглянемо наведене нижче зображення, тестоване для одного з банківських додатків, і воно показує, що більшість дефектів пов’язані з функціональністю “Овердрафт”. Інші функції, такі як Зведення рахунків, Переказ коштів, Постійна інструкція тощо, мають обмежену кількість дефектів.
(зображення джерело )
Наведене вище зображення свідчить про наявність 18 дефектів навколо функціонування Овердрафту із загальних 32 дефектів, що означає, що 60% дефектів виявляються в модулі “Овердрафт”.
Отже, тестувальники в основному концентруються на цій області під час виконання, щоб знайти все більше і більше дефектів. Рекомендується, щоб тестери мали аналогічну увагу на інших модулях під час тестування.
Коли той самий код або модуль тестується, знову і знову, використовуючи набір тестових випадків, ніж під час початкових ітерацій, тоді кількість дефектів є великою, однак, після деякої ітерації, кількість дефектів значно зменшиться. Кластеризація дефектів вказує на те, що область, схильна до дефектів, повинна бути ретельно перевірена під час регресійного тестування.
Парадокс пестицидів
Коли в одному з модулів виявляється більше дефектів, тестери докладають додаткових зусиль для тестування цього модуля.
Після декількох ітерацій тестування якість коду покращується, і кількість дефектів починає знижуватися, оскільки більшість дефектів виправляються командою розробників, оскільки розробники також обережні, кодуючи певний модуль, де тестувальники виявили більше дефектів.
Отже, в один момент більшість дефектів виявляються та виправляються, так що в цьому модулі не виявлено нових дефектів.
Однак часом може трапитися так, що, будучи надмірно обережним під час кодування на одному конкретному модулі (тут, у нашому випадку, “ Овердрафт ”), Розробник може нехтувати іншими модулями, щоб правильно його кодувати, або зміни, внесені в цьому конкретному модулі, можуть негативно позначитися на інших функціональних можливостях, таких як Підсумок рахунків, Переказ коштів та Постійні інструкції.
Коли тестери використовують той самий набір тестових кейсів для виконання модуля, де знайдено більшість дефектів (модуль овердрафту), тоді після виправлення цих дефектів розробниками ці тестові кейси не надто ефективні для пошуку нових дефектів. Як наскрізний потік овердрафту, модуль ретельно перевіряється, і розробники також обережно написали код для цього модуля.
Необхідно переглянути та оновити ці тестові кейси. Також непогано додати нові тестові кейси, щоб нові та більше дефектів можна було виявити в різних областях програмного забезпечення чи додатків.
Профілактичні методи пестициду Парадокс
Є два варіанти, завдяки яким ми можемо запобігти пестициду Парадокс, як показано нижче:
до) Напишіть новий набір тестових кейсів, які будуть зосереджені на різних областях або модулях (крім попереднього модуля, схильного до дефектів - Приклад: 'Овердрафт') програмного забезпечення.
б) Підготуйте нові тестові кейси та додайте їх до існуючих тестових кейсів.
В ' метод А ”, Тестери можуть знайти більше дефектів в інших модулях, в яких вони не були зосереджені під час попереднього тестування або розробники не були особливо обережними під час кодування.
У наведеному вище прикладі тестувальники можуть знайти більше дефектів у модулях 'Підсумок рахунку', 'Переказ коштів' або 'Постійні інструкції', використовуючи новий набір тестових кейсів.
Але може трапитися так, що тестери можуть знехтувати попереднім модулем ( Приклад: 'Овердрафт'), де більшість дефектів були виявлені в попередній ітерації, і це може становити ризик, оскільки цей модуль (Овердрафт) міг бути введений з новими дефектами після кодування інших модулів.
В ' метод В ”, Нові тестові кейси підготовлені таким чином, щоб в інших модулях можна було виявити нові потенційні дефекти.
У нашому прикладі нещодавно створені тестові кейси зможуть допомогти у виявленні дефектів у таких модулях, як Підсумок рахунків, Переказ коштів та Постійна інструкція. Однак тестери не можуть ігнорувати попередні дефектні модулі ( Приклад: 'Овердрафт'), оскільки ці нові тестові кейси об'єднані з існуючими тестовими кейсами.
Існуючі тестові кейси були більше зосереджені на модулі “Овердрафт”, а нові тестові кейси - на інших модулях. Отже, всі набори тестових кейсів виконуються принаймні один раз, навіть коли відбувається зміна коду на будь-якому модулі. Це забезпечить виконання належної регресії та виявлення дефекту через зміну коду.
За допомогою другого підходу загальна кількість тестових випадків значно зростає, що призводить до більших зусиль та часу, необхідних для виконання. Це, очевидно, вплине на терміни проекту, а головне - на бюджет проекту.
Отже, щоб подолати цю проблему, зайві тестові приклади можна переглянути та видалити. Є багато тестових кейсів, які стають марними після додавання нових тестів та модифікації існуючих тестів.
Необхідно перевірити, які тестові кейси не пройшли, щоб виявити дефекти в останніх 5 ітераціях (припустимо 5 ітерацій), а які тестові кейси не надто важливі. Також може бути так, що одиничний потік, охоплений кількома тестовими кейсами, може бути охоплений іншим наскрізним тестовим кейсом, а ті тестові кейси, що мають одиничний потік, можуть бути видалені.
Це, в свою чергу, зменшить загальну кількість тестів.
Наприклад ,у нас є 50 тестових кейсів для охоплення одного конкретного модуля, і ми побачили, що з цих 50 тестових випадків 20 тестових кейсів не змогли виявити новий дефект за останні кілька ітерацій тестування (припустимо 5 ітерацій). Отже, ці 20 тестових випадків потрібно ретельно переглянути, і ми повинні перевірити, наскільки важливі ці тестові кейси, і відповідно може бути прийнято рішення щодо збереження 20 тестових випадків чи їх видалення.
Перш ніж вилучати будь-який тестовий приклад, переконайтеся, що функціональний потік, охоплений цими тестовими кейсами, охоплюється іншим тестовим прикладом. Цей процес потрібно дотримуватися у всіх модулях, щоб загальна кількість тестових випадків значно зменшилась. Це забезпечить зменшення загальної кількості тестових випадків, але все ще існує 100% покриття вимог.
Це означає, що всі інші тестові кейси охоплюють усі бізнес-вимоги, отже, немає жодних компромісів щодо якості.
Висновок
Тестування програмного забезпечення - важливий крок у SDLC, оскільки він перевіряє, чи працює програмне забезпечення відповідно до потреб кінцевого користувача.
Тестування виявляє якомога більше дефектів. Отже, щоб ефективно і ефективно проводити тестування, кожен повинен знати і справді розуміти сім принципів тестування програмного забезпечення, оскільки вони відомі як опори для тестування.
Більшість тестувальників впровадили і випробували ці принципи під час фактичного тестування.
хто відповідає за ділову цінність, яку надає команда сутичок
Як правило, термін принцип означає норми або закони, яких потрібно дотримуватися. Отже, кожен у галузі тестування програмного забезпечення повинен дотримуватися цих семи принципів, і якщо хтось ігнорує будь-який із цих принципів, це може коштувати величезних витрат на проект.
Щасливого читання !!
Рекомендована література
- Найкращі засоби тестування програмного забезпечення 2021 р. (Інструменти автоматизації тестування якості)
- Тестування програмного забезпечення QA Assistant Job
- Курс тестування програмного забезпечення: до якого інституту тестування програмного забезпечення слід приєднатися?
- Вибір тестування програмного забезпечення як вашу кар’єру
- Тестування програмного забезпечення Технічний вміст Writer Фрілансер Робота
- Що таке техніка тестування на основі дефектів?
- Деякі цікаві питання для тестування програмного забезпечення
- Відгуки та відгуки про курси тестування програмного забезпечення