Меню

Що таке пошукове тестування при тестуванні програмного забезпечення (повний посібник)

  • Головна
  • Інший
  • Що таке пошукове тестування при тестуванні програмного забезпечення (повний посібник)

what is exploratory testing software testing

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

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

«Дослідницьке тестування» - як випливає з назви, - це одночасне навчання, дизайн тесту та процес виконання тесту. Можна сказати, що в цьому тестуванні планування тестів, аналіз, проектування та виконання тестів виконуються разом і миттєво.

Це тестування стосується вивчення системи та заохочення реального часу та практичного мислення тестера.

У цій серії ми розглянули наступні підручники:

Підручник No1: Що таке пошукове тестування при тестуванні програмного забезпечення (Цей підручник)
Підручник No2: Використання турів для забезпечення повного пошукового тестування
Підручник No3: Дослідницьке тестування проти сценарію
Підручник No4: Дослідницьке тестування за допомогою HP Sprinter
Підручник No5: Топ 17 інструментів дослідницького тестування

************************************
Пошукове тестування

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

Огляд

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

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

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

Свідомо чи несвідомо кожен випробувач провів би дослідницьке тестування у певний момент своєї кар’єри.

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

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

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

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

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

Про тестування потрібно пам’ятати кілька речей:

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

Рекомендована служба пошукових випробувань

# 1) Digivante Direct

Логотип Digivante Direct

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

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

Особливості:

  • 24 робочі дні тестування всього за 24 години або 90 робочих днів за 72 години, і неперевершений, всебічний рівень тестування неможливий будь-якими іншими способами.
  • Низька вартість , легкий для розуміння ціновий пакет без прихованих додаткових функцій.
  • Самообслуговування Інтернет-портал, який не вимагає постійних зобов’язань.
  • Реальні люди тестують на реальних пристроях - набагато більше охоплення пристроями та браузерами, ніж ви можете досягти власними силами, і все це за швидший час виконання.
  • Повне охоплення дослідницькими тестами - зменшити ризик та покращити задоволеність кінцевих споживачів та коефіцієнт конверсії, тим самим збільшуючи дохід, одночасно зменшуючи витрати.
=> Відвідайте веб-сайт Digivante Direct

Приклади пошукових випробувань

Приклад №1:

Веб-сайт постачальника послуг з догляду на дому із такими компонентами:

  • Увійти
  • Послуги
  • Кошик
  • Оплата
  • Історія Замовлень
  • Наділ техніка

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

Як охоплювати тестові справи?

Тестові кейси для дослідницького тестування

як зробити Java відкрити файли jar - -

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

Приклад №2:

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

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

Вищезазначена мета стала моїм статутом на цій тестовій сесії.

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

  • Тестування, щоб переконатись, що до програми додано новий ПІФ.
  • Нова МФ куплена успішно.
  • Оцінка нового МФ правильна.
  • Спробував придбати новий МФ для існуючого портфоліо.
  • Чи можна додати нові МФ до всіх портфоліо?
  • Вплив нової МФ на оцінку існуючих.
  • Отже, в інших тестових випадках були розвинені.

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

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

Приклад №3:

Дослідницьке тестування веб-сайту IRCTC

=> Клацніть тут, щоб завантажити зразки тестових випадків дослідницьких випробувань веб-сайту IRCTC.

Підхід до тестування

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

Переваги

Переваги цього тестування включають:

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

Недоліки

Недоліки перелічені нижче:

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

Сесійне пошукове тестування

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

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

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

Підхід:

Тестові завдання поділяються на сесії.

Нижче наведено компоненти сеансового тестування (SBT):

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

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

Приклад тестового статуту на функціональність входу

  • Сесія: Попередньо визначений сеанс тестування без обмежень. Кожен сеанс може мати таку тривалість:
    • “Короткий” (60 хв.)
    • 'Звичайний' (90 хв.)
    • “Довгий” (120 хв)
  • Звіт сесії: Додайте примітки та легкий звіт, щоб надати метрики керівникам та менеджерам. У ньому подаються подробиці про залишковий чи виконаний чартерний сеанс, час налаштування сеансу, перевірений сценарій, про процес тестування, список помилок та знайдені проблеми та іншу інформацію для метрик.
  • Короткий огляд сесії: Коротка зустріч або стендант між тестувальником та керівником тесту / менеджером для перегляду результатів тестування.

Менеджери можуть отримати наступні показники на основі звіту про сеанс:

  • Кількість завершених та залишених сесій.
  • Кількість повідомлень про помилки.
  • Час, витрачений на налаштування сеансу.
  • Час, витрачений на тестування.
  • Час, витрачений на аналіз проблем чи проблем.
  • Покриті особливості.

Підсумовуючи вищезазначене:

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

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

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

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

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

Переваги парного тестування

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

Методи пошукових випробувань

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

Турист може взяти такі тури:

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

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

Нижче наведено кілька порад / підказок, які ви можете використовувати в ET:

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

Фактори, що впливають на ЕТ, такі:

  • Мета проекту
  • Стратегія тестування
  • Мета тестування конкретного етапу
  • Доступні інструменти та обладнання
  • Роль і навички тестувальників
  • Доступний час
  • Підтримка управління
  • Підтримка однолітків
  • Доступні ресурси (навчальні матеріали, умови тестування тощо)
  • Зацікавленість клієнтів
  • Зрозумілість продукту.
  • Інтерфейс користувача програми
  • Функціональність програми
  • Попередні результати тесту
  • Ризики, пов’язані із заявкою
  • Попередні дефекти
  • Останні зміни
  • Типи даних, які слід використовувати для тестування
  • Тип користувача, який буде ним користуватися

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

Різниця між пошуковим та спеціальним тестуванням

Не плутайте ET з Спеціальний тест .

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

Дослідницьке автоматизоване тестування (EAT)

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

Є два типи підходу EAT:

  • Пасивне ЇЖИТИ
  • Активне харчування

Пасивне ЇЖИТИ

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

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

Встановлений відеоінструмент допомагає тестувальнику в записі тестових випадків та повідомленні про дефекти.

Він також має кілька інших переваг, таких як:

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

Ось ще кілька моментів, які слід врахувати перед пасивним харчуванням:

  • Рекомендується виконати пілотне тестування, перш ніж повністю адаптувати інструмент для автоматизованого харчування. Це робиться для того, щоб час, необхідний для перепроектування тестових журналів, створених під час тестового сеансу, не перевищував виконання тесту. Якщо так, тоді команда повинна прийняти спільне рішення щодо наступного:
    • Якщо взагалі потрібна автоматизація тестування для конкретного проекту.
    • Якщо використовуваний інструмент потрібно змінити.
    • Якщо продуктивність використовуваного інструменту може бути оптимізована.
  • Інструмент, що використовується для автоматизованого EAT, повинен бути встановлений на кожному ресурсі тестування, який бере участь у тестуванні. Також непогано залучити розробників, чого можна досягти, надавши розробникам VPN або віддалений доступ до тестових машин, або встановивши інструмент у середовищі розробки.
  • Завжди є гарною ідеєю організувати об’єкт графічного інтерфейсу програми в тестовому інструменті, щоб, коли настає час аналізу помилки або проблеми, об’єкт можна було впізнати через значущу назву.
  • Це чудова практика - давати значуще ім’я об’єкту графічного інтерфейсу, який використовується в AUT, і тримати їх організованими для подальшого використання.

Тепер перейдемо до другого підходу.

Активне харчування

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

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

Фаза закриття виконується в кінці сеансу тестування. І він повинен мати наступні завдання:

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

Переваги EAT

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

Види пошукових випробувань

Нижче наведено декілька типів ЕТ:

1) Фрістайл І:

Дослідження програми в спеціальному стилі.

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

2) ET за сценарієм:

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

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

3) Стратегіяна основі ET:

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

Швидке пошукове тестування

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

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

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

Переваги дослідницької роботи в Agile

  • Якнайшвидше надати відгук розробникам.
  • Розкрито широкий спектр дефектів.
  • Різноманітна група ресурсів, така як розробник, тестувальник, BA, дизайнери можуть виконувати ET, оскільки немає сценаріїв тестових випадків, і кожен приносить різні точки зору.
  • Скаутинг, проведений в ET, допомагає досліджувати нові території та викривати критичних помилок.
  • У випадку ітеративного кодування програми, ET може зосередитись на тестуванні нових функцій, тоді як автоматизація проводить регресію та тестування зворотної сумісності.
  • У разі нестабільної потреби ЕТ може допомогти у випробуванні нової вимоги протягом обмеженого часу.

Потрібно пам’ятати:

1. Потрібні різні навички: Тестери, які виконують ЕТ, повинні мати хороші навички слухання, читання, мислення та складання звітів. Необхідний досвід роботи з доменом, оскільки відсутні сценарії та тестові кейси.

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

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

4. Це можна зробити на всіх етапах тестування: Ми можемо впровадити ET перед початком будь-якого етапу тестування. Ви можете проводити ЕТ ще до етапу функціонального тестування.

5. Швидкий зворотний зв'язок: ET вимагає швидкого зворотного зв'язку щодо проблем та будь-яких аномалій.

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

Як мислити за межами традиційних меж тестування при дослідницькому тестуванні

«Я дуже вдячний вашій турботі про товар і допомозі нам зрозуміти перспективу кінцевого користувача. Це буде дуже корисно. Дякуємо за хорошу роботу і продовжуйте продовжувати !!! '

Це було останнє повідомлення електронної пошти з 21 електронного листа від нашого клієнта. Була опівноч, і випуск нашого продукту затримався через критичну помилку, яку ми виявили. Можна подумати, що нового в цьому? Це може траплятися багато разів. Але це було насправді інакше, оскільки критична помилка, про яку ми повідомляли, не була результатом жодного задокументованого тестового випадку.

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

Проведене дослідницьке тестування виявило критичну помилку, пов’язану з проблемою зависання сервера, роблячи щось несподіване.

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

'Він повинен робити те, що повинен робити, і не повинен робити те, що не повинен робити'.

Процес пошукових випробувань

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

Як поглянути на товар з різних точок зору?

пошукові випробування

№1. Зрозумійте клієнта / кінцевого користувача

Тестування програмного забезпечення полягає у перевірці якості продукту з точки зору задоволеності споживачів. Звідки ви знаєте точку зору замовника? Відповідь проста - ви повинні бути замовником. Добре, дозвольте мені зробити виправлення. Бути замовником буде недостатньо. Ви повинні розуміти, як замовник хоче поводитися з товаром. Жоден клієнт, який придбав однакову сировину, не приготує однаковий рецепт. Так, продукт, який ми розробляємо / постачаємо, є сировиною для бізнесу клієнтів, і вони мають інше мислення під час його використання.

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

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

  • Ножиці ніколи не обмежувались лише вирізанням паперу. Різання - це мета, а не папір (об’єкт).
  • Стільникові телефони ніколи не обмежувались лише дзвінками, але “можливість дзвонити” завжди була основною метою.
  • Ящики для зберігання використовуються для зберігання, але безпека зберігається матеріалів так само важлива, як і зберігання.

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

№2. Мислення

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

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

Я пам’ятаю один класичний приклад:

У Linux команда «cat» використовується для перевірки вмісту файлу, а команда «ls» - для перевірки вмісту каталогу. Працюючи з Linux і пробуючи тестування програмного забезпечення протягом п’яти років, я ніколи не думав займатися котами, бо мій розум налаштований; якщо мені потрібен вміст dir, мені потрібно використовувати 'ls'. Це спрацювало, але зворотна сторона очікувань полягає в тому, що товар не повинен був поводитися так, як він не повинен, був неправильним. Один з наших клієнтів, який погано знав Linux, помилково котів, і система вийшла з ладу. Ми заплатили за це мислення.

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

Подумайте про ці сценарії та надайте відгуки про тестування. Життя програмного забезпечення і вашого (як тестувальника) потрясе.

№3. Знати конкурентів

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

Ось декілька реальних прикладів, щоб ви зрозуміли суть справи:

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

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

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

Висновок

Дослідницьке дослідження не підпадає під звичайний спосіб тестування, але все ж це дуже потужний спосіб тестування.

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

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

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

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

Наступний підручник No2: Як користуватися турами для забезпечення повного пошукового тестування

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

^