Меню

Спеціальне тестування: Як знайти дефекти без формального процесу тестування

ad hoc testing how find defects without formal testing process

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

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

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

Спеціальне тестування

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

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

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

Рекомендована література=> Дослідницьке тестування - як мислити за межами традиційних меж тестування?

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

Почнемо з прикладу спеціального тестування

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

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

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

Для тестування цього тестера проводиться його регулярне тестування, наприклад:

автоматизація тестування запитання та відповіді на співбесіду pdf
  • Успішно доповніть майстер усіма дійсними даними та створіть план.
  • Скасувати роботу майстра посередині.
  • Відредагуйте створений план за допомогою майстра.
  • Видаліть створений план і переконайтеся, що від нього немає залишків.
  • Введіть у майстрі від’ємне значення і перегляньте відповідні повідомлення про помилки.

Тепер для наведеного прикладу ось кілька тестових випадків для спеціальних тестів що можна було виконати виявити якомога більше дефектів:

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

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

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

Вони є:

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

Коли ми проводимо спеціальне тестування?

Справді питання на мільйон доларів!

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

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

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

На мій погляд, я б сказав це ad-hoc тестування можна проводити майже будь-коли - на початку, до середини та до кінця! Він просто знаходить своє місце в будь-який момент. Однак, коли необхідно проводити спеціальне тестування, щоб отримати максимальне значення, найкраще оцінювати досвідчений тестер, який має глибокі знання про систему, що перевіряється.

Коли не виконувати?

Якщо попереднє питання коштувало мільйон доларів, це повинно коштувати мільярд!

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

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

Види спеціального тестування

Спеціальне тестування можна розділити на три категорії нижче:

# 1) Тестування приятеля

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

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

# 2) Тестування пар

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

# 3) Тестування мавп

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

різниця між прямим порту та тригером порту

Спеціальні переваги тестування

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

Це підвищує якість та ефективність тестування, як показано нижче:

  • Найбільша перевага, що виділяється, полягає в тому, що тестер може виявити кількість дефектів, ніж при традиційному тестуванні, завдяки різним інноваційним методам, які вони можуть застосувати для тестування програмного забезпечення.
  • Ця форма тестування може застосовуватися в будь-якому місці SDLC; це обмежується не лише командою випробувачів. Розробники також можуть провести це тестування, яке допоможе їм краще кодувати, а також передбачити, які проблеми можуть виникнути.
  • Його можна поєднати з іншим тестуванням, щоб отримати найкращі результати, які іноді можуть скоротити час, необхідний для регулярного тестування. Це дозволило б сформувати тестові кейси кращої якості та в цілому покращити якість продукту.
  • Він не вимагає надання будь-якої документації, яка запобігає надмірному навантаженню тестувальника. Тестер може зосередитися на реальному розумінні базової архітектури.
  • У випадках, коли для тестування не вистачає часу, це може виявитись дуже цінним з точки зору охоплення тестом та якості.

Спеціальні недоліки тестування

Спеціальне тестування також має кілька недоліків. Давайте подивимось деякі з виражені недоліки:

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

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

Найкращі практики, щоб зробити це тестування більш ефективним

Ми довго обговорювали сильні та слабкі сторони цього тестування.

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

# 1) Визначте схильні до дефектів ділянки:

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

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

# 2) Набуття експертизи:

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

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

# 3) Створіть тестові категорії:

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

Тоді ви можете класифікувати їх за функціональністю / пріоритетом та протестувати по сегментах.

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

# 4) Майте приблизний план:

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

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

# 5) Інструменти:

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

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

# 6) Документ про більше дефектів:

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

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

Висновок

Ми детально обговорили спеціальні методи тестування - їх сильні, слабкі сторони, ситуації, коли це буде та не буде корисним.

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

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

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

Ви проводите спеціальне тестування для свого проекту? Які ваші пропозиції для успішного проведення спеціального тестування?

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

^