Зачем тест кейсу одна идея?

Взаимоотношения «я» и «тестирование» начались давно..  Не скажу, что они были сложными.. но иногда хотелось ну так высказаться.. ну так.. что аж сил не хватало.  Но.. почему-то.. желания оставались желаниями..  терпела-держала всё  в себе долгое время. Последней каплей стало начало обучения тестированию одного человека.

У него нет опыта тестирования.

Нет никакого компьютерного образования.

Есть некоторое примитивное знание английского языка.

Я не знаю, что из этого получится. Но я решила попробовать.

В виду отсутствия свободного времени решила для начала дать ему прочитать книгу Романа Савина «Тестирование dot com» Книга до гениальности проста, как мне казалось. Позиционируется по большей части для новичков.. Ан нет.. Даже в ней есть вопросы.  Почти каждую часть необходимо пояснять своим собственным языком. Своим примером.

Начинаем..

- Зачем тест кейсу одна идея? (идеей автор книги назвал summary, title.. у кого как.. Я называю это просто заголовком.. или кратким описанием того, что тестируем)

- За тем же, зачем и один ожидаемый результат.

- Так ведь он же жирными буквами выделяет даже, что это нормально, когда ожидаемых результатов много.

- Да. Это нормально на практике. Но в идеале…  ты таким описанием  ожидаемых результатов можешь  не протестировать как работающий, так и неработающий функционал..

Пример.. нужно проверить некую expired password policy :

1.              Минимальная длина пароля 7 символов

2.              В пароле должны быть  как цифры, так и буквы

3.              Новый пароль не должен быть таким же, как предыдущий.

В, наверное, 90% случаях человек, начинающий тестировать данную функциональность создаст следующий тест:

Тест 1. Изменение пароля.

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
3	Установить пароль состоящий только из цифр. (больше 7 символов) и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
4	Установить пароль состоящий только из букв. (больше 7 символов) и сохранить	Появляется соответствующая ошибка о не сохранении пароля.
5	Установить старый пароль и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
6	Установить новый пароль состоящий как из цифр так и из букв длиною больше 7 символов	В течение 3х секунд на странице отображается сообщение о сохранении пароля. Вместо страницы редактирования открывается страница со списком всех пользователей.

Здесь я сделаю пометку, что это очень-очень упрощенная ситуация, где нам достаточно проверить сообщение, подтверждающее факт сохранения. (Наивно верим, что всё действительно сохранилось и сообщение нам не врёт)

А сейчас по делу.. Всё кажется хорошо: один тест и сразу всё проверили. И не нужно описывать пре-степы, где мы создаём пользователя , не нужно повторять шаг 1, где мы идем на страницу редактирования.. кажется, меньше текста – больше дела. Но.. а если уже на шаге 2м наш тест фейлится:  пароль длиною меньше 7 символов сохраняется, страница закрывается и нет больше перед глазами тех полей, что нужно редактировать.

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

А другой, скорее всего уже неопытный, решит что найденный баг блокирует тестирование оставшегося функционала и остановится.

Следствие 1: баг найден, баг записан, кто нашёл - доволен.

Следствие 2: не протестирован функционал, который мог бы быть протестирован. О нём забыли до момента фикса найденного бага.

Прошло время. Баг пофиксили.. тестирование можно продолжать. К примеру, тот же тестировщик, проверяет баг и продолжает выполнение теста.. ну а если здесь опять.. для кого-то счастье, для кого-то нет: шаг 3 фейлится.

Следствие 3: если тест больше нашего, то этот цикл может продолжаться ещё очень долго.

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

Вывод: не нужно лениться, надеяться на «авось»  и думать, что кто-то догадается протестировать оставшиеся после неожиданного фейла шаги. Нужно просто с самого начала создать несколько тестов. :) У каждого из которых своя идея и один ожидаемый результат:

Тест  1. Ошибка при сохранении пароля, длина которого меньше 7 символов

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.

Тест  2. Ошибка при сохранении пароля, состоящего только из цифр

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из цифр. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

Тест 3. Ошибка при сохранении пароля, состоящего только из букв

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из букв. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

И т.д.

- А когда можно совмещать несколько результатов?

- Когда вследствие одних и тех же действий ты можешь проверить несколько точек функционала. Банальный пример:

Шаг	Действие	Ожидаемый результат
1	Открыть страницу редактирования пользователя	Поле «Имя» должно присутствовать на странице
		Поле «Фамилия» должно присутствовать на странице
2	Изменить имя и сохранить.	Сообщение «Имя отредактировано»  должно появится на странице
		Поле «Имя» должно стать не редактируемым.

Т.е. ожидаемым следствием шага 1 являются 2 результата:  «Поле «Имя» должно присутствовать на странице» и «Поле «Фамилия» должно присутствовать на странице»

Важно понимать, что в данном случае мы не теряем последовательности действий, нам не нужно переделывать какие-то шаги дабы «доделать» тест в случае неожиданной неудачи:  мы можем просто двигаться, отмечая полученный результат как  PASS или FAIL.

Важно всегда помнить об оформлении теста: неправильное оформление ведёт к неправильному восприятию, а это – лишние ошибки.