На что опираться при тестировании, если нет спецификации?

Question

[sad0990]

Здравствуйте.
Взялся за изучение тестирования. Есть такой вопрос. Если нужно полностью протестировать форму поиска на мобильной версии сайта, но спецификации нет, как правильно поступить? Опираться на здравый смысл и перебирать множество возможных вариантов, паралелльно составляя кейсы? Или же есть некий стандарт для тестировании форм?
Спасибо.

Answer 1

[Дмитрий Еремин]

1. Здравый смысл - да. Проверить, что приложение ведет себя

1. понятно.
   
   • Мы видим сообщение об ошибке - нам понятно, почему мы его видим?
     
   • На экране отображается результат вычислений - читаемо? Результат правильный? Остаются вопросы?
     
   
   
2. предсказуемо.
   
   • Понятно ли мне, что будет, если я нажму на кнопку Отправить
     
   • Если введу пустой текст - будет ли обрабатываться форма?
     
   
   

2. Держим постоянно в голове, для чего вообще создавалась эта форма - получаем примерный список ожиданий.
Например, это форма для обратной связи - понятно, что поле email должно проверять на корректность ввода. Понятно, что поле Телефон должно принимать цифры. Понятно, что поле Отзыв должно быть больше одной строки (textArea) и т.д.

3. Задаем вопросы Менеджеру/Аналитику/Заказчику (кому-то, кто лучше нас понимает, зачем эта форма нужна)

А тестирование методом черного ящика не предполагает отсутствия требований. Вам, как тестировщику, могут выдать готовое мобильное приложение. Это будет черный ящик вы не знаете, как оно работает внутри, к каким серверам обращается и т.д. Но у вас вполне могут быть требования на это приложение

Answer 2

[Валерий Глуховцев]

В дополнение к прекрасному посту выше:

1. Используйте руководство пользователя
   Тут вы и тесты в примитивном формате найдёте, и примерные требования поймёте.
   
   
2. Ориентируйтесь на саму систему
   Изучите места, в которых система может противоречить сама себе. Помните, что работа каждого элемента системы обычно похожа на соседние с ним
   
   

Answer 3

[KiT Maverik]

Вам стоит проверить компетенцию своего ментора. Утверждение "полностью протестировать" противоречит фундаментальному принципу тестирования "Exhaustive testing is impossible".
Предлагаю обеспечить достаточный уровень качества. К определению оного подойдем с менеджерской стороны.
Нет спецификации? Нужно ее сделать. Предлагаю следующий способ: представляете себе что с точки зрения бизнеса наиболее важно в этой форме (примеры: поиск существующего объекта, защита от SQL-инъекций, поиск по дополнительным настройкам, обработка ошибок таких как поиск несуществующего объекта) и засовываете это в список. ВАЖНО: включать в список только те пункты без которых форма не может считаться рабочей или удовлетворяющей требованиям бизнеса. Список озаглавливаете "Acceptance criteria" и несете заказчику на подпись. Без этой подписи он имеет полное право парить вам мозг вопросами типа: а что ты это (или то) не протестировал? А с подписью вы будете иметь документ определяющий достаточное качество на уровне user acceptance.
Тесты прошли? Значит критерии приемки соблюдены. Хотите больше тестов? Согласовываем новую спецификацию, дополнительный бюджет на тестирование и расширяем тестирование на новый уровень (надеюсь ваш ментор про уровни тестирования рассказывал?).