Меню

Як протестувати заявку без вимог?

how test an application without requirements

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

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

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

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

тест без вимог

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

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

Читайте також:

як виконати атаку ddos ​​на веб - сайті

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

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

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

Ось 3 найкращі методи тестування програми без вимог:

Спосіб No1:

Працюйте з будь-якою невеликою документацією, яку ви можете отримати. Це може бути базове просте відставання (у гнучких проектах), файл довідки, електронна пошта, старіша версія BRD / FRD або старі тестові кейси (перевірте їх у своїх інструментах ALM, і ви можете їх знайти) тощо.

Розслідуйте, розпитуйте, і завжди є якесь документоване дослідження, навіть якщо воно тонке.

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

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

Спосіб No2:

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

Це допомагає тримати наступні аспекти в перспективі, роблячи це:

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

Спосіб No3:

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

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

Тепер застосуємо методи в прикладі:

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

Застосувати метод №1:

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

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

  • Предмети можна додати до кошика для покупок після перегляду або пошуку
  • Як тільки я додаю товари до кошика для покупок, список товарів повинен оновитись
  • Користувач повинен мати можливість продовжувати покупки навіть після додавання кількох предметів у кошик
  • Двічі додавання одного і того ж елемента призведе до збільшення кількості доданих елементів
  • Елементи можна оновлювати
  • Предмети можна вилучити
  • Сума повинна бути еквівалентною сумі всіх доданих цін
  • Податки слід обчислювати на основі введеного поштового індексу
  • Витрати на доставку повинні бути додані відповідно

Ми можемо продовжувати продовжувати, але я впевнений, ви зрозуміли картину.

Застосувати метод No2:

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

Як ви можете бачити з екрана нижче, ці речі очевидні - назви полів, кнопки або інші присутні елементи тощо. (натисніть на зображення для збільшення)

тест без вимог

На даний момент у тестувальників є такі запитання, як:

  1. Що трапляється, коли я даю знак у полі суми?
  2. Коли я можу додати забагато елементів?
  3. Яке максимальне немає. з предметів, які це може зайняти? І т.д.

Застосувати метод No3 :

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

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

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

Про автора: Цей корисний допис написаний нашим членом команди STH Swati S.

Як завжди, ваші коментарі, запитання та пропозиції дуже вітаються.

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

^