Позитивный тест кейс, как?

Question

[h8zerg]

Стажировку прохожу в сфере тестирования, перерыл много сайтов , поспрашивал людей, но чем больше инфы, тем больше я короче путаюсь.
Есть сайт todolist.ru на него надо составить тест кейсы Используюя классы эквивалентности и граничные значения минимум по одному разу при составлении тест-кейсов и при нахождении багов оформить баг репорт. Информации больше никакой нет( нет тз и критериев, просто "протестировать полностью")
Слова позитивный эквивалентный и граничное значение привело меня в тупик.
Как оформить хотя бы один тест кейс покажите пример пожалуйста.
Насчет эквивалентности и граничных значение поясните плиз тоже, я читал что это для вводимых данных, а бывает и не только.
Например то что на каждой странице сайт, есть кнопка чтобы вернуться на главную страницу, это эквивалентность? Форма регистрации там без подсказок, я сам выявил что логин 1-50 символов, а пароль 1-128, стоит ли при составление позитивного тест кейса, указывать значения граничные, 51 символ в логине?
И как вообще выглядит данный тест кейс.
Нужно ли при составлении тест кейса указывать фактический результат? Если он сходиться/ не сходиться с ожидаемым? Или просто ОР указывать, а все несхождения в баг репорт.
И последнее , если я без тест кейса нашел баг, просто ползал по сайту нашел граматическую ошибку, мне стоит под эту ошибку специально тесткейс сотавлять? или можно сразу в баг репорт?
Спасибо за внимание и понимание)

Answer 1

[Alexej Simakov]

Ох уж эти "протестируй все"...
Без спецификации вы не можете тестировать. У вас нет т.н "оракула". Оракул в тестировании это то как вы определите, что наблюдаемое поведение приложения является багом. Может это ошибка, что логин может иметь до 50 символов, может быть должно быть допустимо до 256. Не имея спецификации, как я считаю, можно проверять не изменило ли приложение своего поведения между двумя релизами, тогда вашим "оракулом" будет поведение предыдущей версии программы. И то, вы не знаете может это не регресс, а прогресс.

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

Грамматические ошибки это негативное качество. Репортить конечно. Тут у вас хоть будет на что сослаться, есть Правила Русского Языка ;-).

Вот это видео посмотрите, доходчиво обьяснено про классы эквивалентноси и граничные значения.
Разработка тест кейсов по методике Pair wise. Ники...

В тесткейсе указываются входные условия, действия и ожидаемый результат.
Если вы напишите на все приложение тесткейсы у вас получится полная спецификация. Получается что приложение определяет спецификацию, а не спецификация приложение. Значит у нас эталонная реализация. Но если она эталонная, то в ней нет ошибок, и тестировать ее не нужно. Парадокс :)

По плану тестирования (навскидку, подробности додумаете сами):
Общее:

• Нужно проверить все статичные ссылки. Можно написать для этого автоматизацию.
  
• Проверить грамматику и содержание (что в тексты не закопипастили по ошибке ерунду)
  

Функциoнальные области я бы разделил на категории, например:

1. Управление учетной записью
   1. Регистрация
      
   2. Вход
      
   3. Смена пароля
      
   4. Восстановление пароля.
      
   5. Удаление
      
   
   
2. Управление списками дел
   1. Добавление (списка или задачи)
      
   2. Просмотр
      
   3. Удаление
      
   4. Изменение
      
   
   

и т.д. каждый подпункт будет иметь множество тесткейсов .т.е то что нужно проверить при .. смене пароля, удалении элемента списка и.т.д.

Вобщем, я вам не завидую, но опыт систематического анализа функционала (как составление плана тестирования) это очень важный навык.

Answer 2

[azShoo]

Всё смешано в кашу.
Думаю вам надо основательно почитать по теории тестирования и разобраться, где и что.
Граничные значения и классы эквивалентности, а так же примеры их применения, гуглятся по запросу "Практики тест дизайна". Ну, или в любой книге по тестированию ПО.
Если коротко: это про то, что разнообразные значения параметров, приводящие к одному и тому же результату нет смысла перебирать и можно схлопнуть их до минимума проверок.
Напр. если у вас валидной датой рождения является 1910 - 2000 год -> вам нет смысла перебирать все значения от -MAX_INT до + MAX_INT, вам достаточно проверить >1910, 1910, 1911 - 1999, 2000 и > 2000.
Т.к. по сути у вас есть 3 класса эквивалентных кейсов: пользователь указывает слишком раннюю дату рождения, пользователь указывает дату рождения в допустимом промежутке и пользователь указывает слишком позднюю дату рождения.
Плюс к этому добавляется проверка границ этих интервалов - т.е. конкретных кейсов на границе каждого класса.
Это позволяет определить, что границы классов проходят именно по нужным вам значениям (1910 - 2000), а не раньше\позже.



По поводу классификации тесты на позитивные и негативные.
Здесь всё просто. Позитивные кейсы проверяют работоспособность сценариев при ожидаемом поведении пользователя.
Напр. вбил валидный емейл и пароль, они совпадают с теми, что есть у зареганного ранее пользователя -> авторизация прошла успешно.
Нажал кнопку "Восстановить пароль" -> на почту ушло письмо с восстановлением пароля.
И т.д.

Негативные сценарии покрывают ситуации, когда пользователь сознательно или случайно делает что-то не так - начиная от валидации значений, до дублирования запросов, всяческих инъекций и прочего.
Напр. кейс "Перевести деньги с карты -> Нажать назад в браузере -> Перевести ещё раз" будет негативным -> необходимо проверить, что предыдущий стейт страницы (в котором деньги ещё не выведены с карты) не даст пользователю вывести больше, чем у него есть.