пятница, 15 августа 2014 г.

Интервью для Факабы!

А я тут вчера дала интервью Факабе, самому крупному новостному агрегатору и информационному ресурсу о системе менеджмента качества, обеспечении качества и тестировании ПО в Беларуси! Smile :)

Почитать его можно, пройдя по ссылке.




вторник, 12 августа 2014 г.

Искусство обучать. Джули Дирксен

Ссылка на OZON.
Отзыв Натальи Руколь.

Чумовая книжка!

Нет, правда! Достаточно лишь сказать, что я взяла ее с собой в отпуск с желанием начать читать, а прочитала всю! Я просыпалась рано утром и уже не могла уснуть, понимая, что, если я сейчас встану, у меня будет время почитать до завтрака! Лень уговаривала поваляться еще немножко, но интерес выталкивал меня из постели. Я вставала утром (!) в отпуске (!!), чтобы почитать эту книжку!

Она меня невероятно вдохновляла. Я обычно загибаю странички с интересными мыслями, чтобы потом написать о них в блоге, но в этой книжке у меня каждая вторая страница с загнутым уголком, настолько много там полезной информации!


Пожалуй, теперь придется купить специальные стикеры-закладки и обклеить книжку ими... А еще в некоторых местах я просто подскакивала с места, когда меня озаряла ИДЕЯ! Все внутри бурлило и кипело и уже за одно это я благодарна этой книжке и считая, что прочитала ее не зря.

А еще, еще я в паре мест поставила восклицательные знаки на полях, ручкой! Давно уже не портила книги, но тут не могла устоять, настолько важными мне казались эти идеи!

Я веду курсы для начинающих тестировщиков, поэтому старалась сразу приложить полученную информацию к ним. И я выписала себе на бумажку 10 идей по улучшению курса! А еще вдохновилась на написание этого блог-поста. Теперь попробую на ближайшем тренинге внедрить улучшения и посмотреть на результат. Постараюсь отписаться потом, дали ли мои идеи нужный эффект...

Книга начинается с замечательной истины - когда вас спрашивают о любимом занятии, что чаще всего можно услышать в ответ? Вряд ли это "я увидел крутую презентацию в паверпоинте", скорее "у меня был замечательный преподаватель".


И вы знаете, это радует! Это говорит о том, что, даже если ваши курсы попробуют сплагиатить, это не поможет, если вы - потрясающий педагог, а плагиатчик не очень. Так что все в ваших руках, будьте лучшими! Smile :)

Я даже не знаю, что можно выписать из данной книжки, уж очень много там полезной информации. Так что, лучше прочитайте сами и насладитесь чтением!

Автор прекрасно раскрывает следующие темы:
  • С чего начать?
  • Как мы запоминаем информацию?
  • Как привлечь внимание студентов?
  • Как развить навыки?
  • Как замотивировать на обучение?
  • И многое, многое другое...

При этом книга "живая", со множеством картинок и ее интересно читать, там нет заунывных и нудных строчек, разве что в качестве примера "как не надо делать". Все показано на запоминающихся примерах.

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

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

Но что будет, когда ее нужно будет извлечь? Первый человек легко его найдет и достанет, а вот второму придется покопаться... Джули учит нас, как помочь студентам разложить знания по полочкам, а не скинуть все в общую кучу-малу.

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

Она много чему нас учит! Я могу сказать лишь, что сейчас сокращаю свою библиотеку, отдавая прочитанные книги друзьям и коллегам, потому что люблю читать бумажные варианты, а хранить их особо негде. Но эту книгу я не отдам, она займет место среди лучших из лучших.

И я к ней еще обязательно вернусь! Когда сделаю новый курс, перечитаю и усовершенствую. Или даже если не сделаю новый курс, перечитаю ее попозже и снова улучшу свой курс для начинающих. Потому что нельзя стоять на месте, надо пробовать "заинтересовать слона". Попробуйте и вы! Wink ;)

Я считаю, что всем тренерам эту книжку читать обязательно, просто must have!
Но и студентам будет чему поучиться, вот Наталья Руколь прочитала и изменила свое отношение как студента и ей помогло! Так что кто хочет развиваться, обязательно найдет там что-то интересненькое.


Книги, которые рекомендует автор (с ее же комментариями)


Дизайн:
  • Дизайн для недизайнеров, Робин Уильямс — "отличное пособие об основах графического дизайна", "есть несколько полезных книг по подготовке наглядных материалов, но особенно хороши книги Уильямса и Маламеда".
  • Visual Language for Designers, Connie Malamed — "эта книга особенно хороша" (см предыдущий коммент)
  • Дизайн привычных вещей, Дональд А. Норман — "прекрасная и уже ставшая классикой книга".
  • Emotional Design, Don Norman — Джули приводит примеры из этой книги.
Мотивация:
Остальные:

Где начинающим тестировщикам получать опыт?

Все начинающие тестировщики задаются вопросом - где набраться опыта? Где применять полученные знания? А ведь способов то много!


1. Работаем за еду, то есть за опыт


Самый лучший способ получения опыта - устроиться на работу. Но так как это "привет, капитан очевидность", то данный пункт будет явно не в начале списка. На работу ведь не берут как раз из-за отсутствия опыта. Что же делать?

Можно работать бесплатно, получая опыт и проходя обучение на реальном проекте. Такие проекты, как правило, open source и времени просят всего по 6+ часов в неделю. Можно совмещать с основной работой, получая драгоценный опыт и не теряя свой заработок.

Open source проект, которому нужны тестировщики - полезная ссылка.
Хомячки — проект, направленный специально на получение опыта начинающими.

Бесплатная практика в тестировании — тема на форуме, которая пополняется ссылками, там сейчас как раз open-source проект и «Хомячки».
Теория и практика для студентов — бесплатная школа в Питере, очная.

понедельник, 11 августа 2014 г.

Регистрация по EMAIL


Нерушимое правило

Тестировщикам, особенно начинающим, важно всегда помнить следующий принцип:

Никогда не используйте "левые" email'ы для тестирования.

Не должно быть вымышленных email'ов или email'ов, которые не принадлежат вам, если система рассылает по ним почту. Потому что вы один раз зарегистрировались, а система будет слать туда письма.

Допустим, форма регистрации следующая:


Чтобы ее протестировать, надо ввести N уникальных значений почты:

  • Можно ли оставить имя пустым?
  • Можно ли ввести "Ольга"?
  • А "Олечка"?
  • А "Olga"?
  • А "Киселева-Иванова Раисия Ивановна"?
  • А "%:;*Ц;(*;?%"?
  • А можно ли создать пароль в 1 символ?
  • А можно ли ... ?
Статья не о принципах тест-дизайна, поэтому остановимся на данном списке. Но понятно, что он будет больше раз в 10. И каждый раз регистрировать новый email? Да ну-у-у-у... Если формат эл. почты не проверяется, можно и "123" туда записывать, пока тестируются другие поля. А если проверяется, то "123@mail.ru".

Чем это плохо?

  1. Система на каждый такой "левый" адрес высылает почту, то есть фактически спамит mail.ru по несуществующим адресам. Mail.ru банит такого отправителя как злостного спамера. А менеджер проекта уже отрывает руки тому вредителю, благодаря которому их занесли в черные списки. Вы же не хотите быть таким вредителем, правда? Smile :)
  2. Тексты писем, которые отправляются пользователям, тоже надо тестировать. Если все время вбивать в поле всякую фигню, почту мы в итоге не получим и не сможем ее проверить.
Поэтому неважно, работаете вы на проекте или просто учитесь (в рамках курса для тестировщиков или просто для самообразования выбрали сайт), не портите карму создателям, помните правило!

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

Но, если вы не знаете точно, есть такое или нет - следуйте правилу, не указывайте "левые" email`ы!

А что же тогда делать?

Страдать!


На самом деле не надо страдать, есть выход Smile :)
И даже не надо каждый раз заводить новую почту!


У gmail есть хинт - берете свою почту и добавляете к ней часть с плюсиком.

Например, myMail@gmail.com - это моя почта, так вот
  • myMail+1@gmail.com
  • myMail+2@gmail.com
  • myMail+10@gmail.com
  • maMail+test@gmail.com
будет приходит на myMail@gmail.com.

Пользуйтесь на здоровье и берегите нервы своих менеджеров! Smile :)

PS - Уже скоро стартует мой курс "Онлайн-интенсив для начинающих тестировщиков", в котором мы будем злыми менеджерами, отрывающими головы за невыполнение этого правила Wink ;) Записаться на курс 1-7 сентября.

четверг, 7 августа 2014 г.

Что такое тест-кейс и как его писать

Тест-кейс — это проверка. "Выполни тест-кейс по вводу отрицательных значений" = проведи проверку такую-то и проверь, что результат будет такой-то.

Устоявшегося русско-язычного определения нет, помните об этом. Главное — понимать суть.
Тест-кейс  это такое описание проверки работы системы, которое может выполнить любой человек из команды, будь то тестировщик, разработчик, аналитик или даже бизнес-заказчик.
Набор тест-кейсов называется тестовым набором (test suite).
Иногда этот набор некорректно называют тест-планом. Тест-план   это именно план: когда, что, зачем, какими ресурсами. (тут будет ссылка на статью про тест-план)

Стандартные атрибуты тест-кейса
  1. Номер  уникальный идентификатор тест-кейса. Его удобно использовать для одинакового понимания, о какой проверке идет речь (например, дать ссылку в баге).
  2. Название  краткое описание сути проверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко.
  3. Предварительные шаги —  описание действий, которые необходимо выполнить, но прямого отношения к проверке они не имеют (например, зарегистрироваться в системе для проверки создания элемента). Если предварительных шагов нет, то секция не заполняется.
  4. Шаги — описание действий, необходимых для проверки (например, создание элемента).
  5. Ожидаемый результат (ОР) — сама проверка: что мы ожидаем получить после выполнения шагов ("Элемент создан").
Пример оформления (один ожидаемый результат)

Есть внутренний сайт компании, которая проводит интернет "Самый_лучший_в_своем_роде" — www.test.ru. Тестовый стенд, на котором проверяются доработки перед выкладкой в PROD (он же production, окружение для пользователей) находится по другому адресу — www.dev_test.ru.
Примечание: www.test.ru — абстрактное обозначение некоего сайта, не надо туда заходить и искать эту систему Smile :). Приводится здесь, чтобы показать ошибки в написании тест-кейсов.

На сайте можно заводить карточки обслуживаемых зданий и карточки их жильцов. Карточки создает администратор, на тестовой машине всегда есть пользователь с правами админа, логин / пароль — admin / 1. При входе на тестовый сервер есть дополнительная авторизация, чтобы туда не могли попасть люди "извне", с логином и паролем test / test.


Тест-кейс № 1. Создание жильца без ФИО.

Шаги
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы".
  4. Нажать на кнопку "Создать карточку жильца".
  5. Нажать на кнопку "Сохранить", не заполняя никакие данные.
Ожидаемый результат
Появляется сообщение об ошибке "Заполните обязательные поля, отмеченные *", карточка не сохраняется.

Преимущества и недостатки тест-кейсов

Преимущества: тест-кейсы можно доверить выполнять новичку или призванному на помощь коллеге из другого отдела, который ничегошеньки о проекте не знает. Дополнительных вопросов с его стороны будет по минимуму — все и так (должно быть Wink ;) ) понятно!

Недостатки (вытекают один из другого):
  1. Очень много копипасты много копипасты копипасты. В примере выше заполняется поле "ФИО". Тест-кейсы "ввести в поле только символы, только числа, строку нулевой длины и т. д." будут очень похожи друг на друга, первые шаги одинаковые и, положа руку на сердце, будут копипаститься. Попробуйте написать хотя бы три тест-кейса на один функционал и сразу увидите эту проблему.
  2. Сложно поддерживать. Представьте, что вкладку "Жильцы" переименовали в "Заказчики". Чтобы актуализировать тест-кейсы, надо внести изменения в сотни сценариев, что утомительно даже в режиме "Ctrl + C, Ctrl + V".
  3. Неактуальное состояние. Тест-кейсы копипастятся друг от друга, и часто в них остаются неактуальные части из исходного кейса, которые забыли изменить.
Последний недостаток перечеркивает достоинства. Тестировщик, который уже год как работает на проекте, поймет и неактуальный кейс, тем более если выполняет их подряд, начиная с первого. А тестировщик, который ничего о проекте не знает и получил пару кейсов из середины тестового набора, не сможет понять, о чем в них идет речь.

Чтобы тест-кейсы честно выполняли свою роль, их надо поддерживать, периодически проверять на правильность и дорабатывать... Это отнимает очень много времени и сил.

Чтобы упростить этот процесс, могут быть использованы тест-кейсы с одним сценарием выполнения, но несколькими входными параметрами и разными ожидаемыми результатами. Фактически мы получаем мини чек-листы с предварительными шагами.

Примеры оформления (несколько ожидаемых результатов)

Рассматриваем все тот же абстрактный сайт www.test.ru. Допустим, что поле "ФИО" по ТЗ решили ограничить 40 символами (тут будет ссылка почему так не надо делать).

Когда говорят о нескольких ожидаемых результатах, это может означать:
  • Даны несколько вариантов вводимых данных и для каждого прописан свой ожидаемый результат.
  • Несколько шагов, а не только последний, содержат ожидаемый результат.
  • После одного сценария выполняются сразу несколько проверок.

Несколько вариантов вводимых данных


Тест-кейс № 2Создание жильца, проверка поля "ФИО".

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, , пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Заполнить поле ФИО (см "Ожидаемый результат")
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат


Вводимое значение
Ожидаемый результат
Киселева Ольга Евгеньевна
Ок, карточка сохраняется
<Оставить поле пустым>
Ошибка – «Заполните обязательные поля, отмеченные *», карточка не сохраняется
2*4*6*8*11*14*17*20*23*26*29*32*35*38*41*
Ошибка – «Максимальная длина поля – 40 символов, введено - 41», карточка не сохраняется. (Такую строчку легко сформировать с помощью инструмента perlclip)
&*%#(^$@*&
Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется
Kiseleva Olga Evgenievna
Ошибка – «Поле ФИО может содержать только буквы русского алфавита» (см. статью про идиотов и ограничения), карточка не сохраняется

Для этого варианта тест-кейса запись в виде таблички: данные – результат — наше всё!

Результаты для нескольких шагов из кейса

Другой вариант записи тест-кейса с несколькими ожидаемыми результатами — когда результаты пишутся на разные пункты шагов выполнения проверки, то есть на разные этапы сценария.


Тест-кейс № 3Создание жильца с худым полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести корректные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой "Войти" и сообщением "Для входа в систему введите, пожалуйста, свои данные".

2. Вход в систему успешно осуществлен. В правом верхнем углу отображается надпись "Здравствуйте, admin". Открыта главная страница сайта.

4. Открылась страница "Создание нового жильца" с полями "Фамилия", "Имя" и "Отчество" и кнопкой "Сохранить".

6. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка. Эту карточку можно открыть и на ней отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".

Несколько проверок после одного сценария


Тест-кейс № 4Создание жильца с самым полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учеткой администратора (логин - admin, , пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести корректные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".

Области применения

Так как тест-кейсы очень сложно поддерживать, то чаще используют чек-листы (тут будет ссылка на статью по чек-листам) или комбинацию "чек-листы & тест-кейсы".

В последнем случае большинство проверок пишут в виде чек-листов, а особо сложные (пойди туда, не знаю куда, принеси то, не знаю что, кувыркнись три раза и громко крикни "ДЕДЛАЙН!", только тогда формочка и откроется) уже в виде тест-кейсов, чтобы каждый раз не вспоминать, как этот хитрый сценарий работает.

Тест-кейсы нужны:
  1. Жизненно важные системы, ошибка в которых может привести к гибели (самолетостроение, медицина, ПО для атомных станций). Здесь надо тестировать очень аккуратно и тщательно. 
  2. При тестировании сложных систем или сложных частей системы, чтобы не запутаться в чек-листе.
Тест-кейсы не нужны:
  1. Простые системы (веб-сайты, мобильные приложения и т. п.).
  2. Ситуации, когда в команде всего один или два тестировщика, знающие свой продукт. Время, потраченное на создание и поддержку тест-кейсов никогда не окупится.
Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее  — творческие чек-листы, формальные тест-кейсы или микс из этих подходов.

Стандартные ошибки при оформлении тест-кейсов

Читать теорию - одно, делать на практике - другое. Обычно в теории все понятно, а на практике получаем примерно такой кейс (все совпадения случайны, тест-кейс написан как агрегация различных ошибок):

Тест-кейс № 01Создание жильца.

Шаги:
  1. Зайди на сайт www.test.ru.
  2. Нажми на кнопку "Войти" в правом верхнем углу экрана.
  3. Залогинься с правами администратора.
  4. Перейди на вкладку "Жильцы".
  5. Нажми на кнопку "Создать карточку жильца".
  6. Введи корректные ФИО, например, "Иванов Иван Иванович" и сохрани карточку.
Ожидаемый результат — карточка создана.








Попробуйте, не смотря ответ, сами найти проблемные зоны в этом тест-кейсе. А потом проверите себя Wink ;)











Разберем ошибки кейса 01.

1. Абстрактное название

На первый взгляд название хорошее, короткое и понятное — мы ведь правда создаем жильца. Но! Если мы теперь создадим еще пяток тест-кейсов на ввод некорректных ФИО, то у них будет точно такое же название.

В итоге новый тестировщик, получив задание проверить кейс «Создание жильца», обнаружит в системе два десятка проверок с таким названием и впадет в ступор, какой выбирать?

Всегда помните про "кратко, но емко". По названию тест-кейса тестировщик, знающий проект, должен понять, что надо делать, не заглядывая в шаги. Так что дополняем название — Создание жильца без отчества, Создание жильца, цифры в поле "Имя" и т.д...

2. Повелительное наклонение

Чтобы коллегам было приятнее работать с тест-кейсами, лучше делать их описание обезличенным — "Выполнить, загрузить"...

3. PROD

В данном примере идет ссылка на PROD.

Никогда нельзя проводить тестирование на PROD-е! Исключение составляет дымовой тест, проводящийся после обновления PROD-системы . Тестовый набор для этого создается отдельно и тщательно выверяется.

ВСЕ остальное тестирование проводится ТОЛЬКО на тестовом стенде. В описании тест-кейсов и багов должны быть ссылки только на тестовый сервер. Иначе попросим коллегу с другого проекта помочь нам с тестированием, а он пойдет на PROD и ... или сломает что-то, или испортит реальные данные.

4. Нет ссылки на сайт

Написан URL, но не кликабельный. Нужно выделить, скопировать, открыть новую страницу, вставить... Гораздо лучше было бы просто нажать на него!

5. Слишком детализировано

Пункт "Нажми на кнопку "Войти" в правом верхнем углу экрана" содержит много подробностей про пользовательский интерфейс. Если кнопка в новой версии программы переедет в другое место, то придется вносить исправление и в тест-кейс. Чем меньше в документации зависимость от UI (user interface, пользовательский интерфейс), тем лучше.

Перепишем данный шаг: Войти под учетной записью администратора (admin/1)

Описание шага не стало менее понятным, и мы избавились от привязки к интерфейсу. Если вместо кнопки сделают ссылку или человек просто Enter нажмет, то суть шага не изменится: мы же в данном кейсе не логин проверяем, а создание жильца.

6. Нет нужной информации - непонятно, как авторизоваться

Есть пункт "Залогинься с правами администратора" — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль.

Если такой пользователь присутствует всегда (или создается каждый раз для тестирования), то есть его логин и пароль "статические" (не меняются), то их всегда надо прописывать, чтобы не возникало дополнительных вопросов.

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

Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация.

7. Нет описания проверки

"Карточка создана" — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.

Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?


Поправим тест-кейс по всем замечаниям. Вот что получилось:

Тест-кейс № 02Создание жильца с корректными ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru.
  2. Войти под учетной записью администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести корректные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".








Уже хорошо, но можно ли еще улучшить этот тест-кейс?
Сейчас снова попробуйте, не смотря ответ, найти проблемные зоны в этом тест-кейсе. А потом проверите себя Wink ;)











Итак, ошибки кейса 02:


1. Абстрактное название.

Слова "корректный", "правильный" ит.д. в названии тест-кейса такой же маркер, как "ошибка" в названии бага. Таких слов надо избегать.

Позитивных проверок можно придумать хоть сто. Но чем-то они будут различаться. «Создание жильца, у которого нет отчества», — это тоже кейс с корректным ФИО. Только из такого названия сразу ясно, про что кейс.

Поэтому забудьте про слова "корректный", "некорректный" и т.п., пытайтесь писать понятнее. И всегда помните принцип "кратко, но емко". А разделение кейсов на смысловые группы (негативные тесты, позитивные тесты, тесты на особые случаи) сделайте в системе управления тест-кейсами через флаги или отдельные наборы тестов.

2. Нет нужной информации

Зайти на сайт www.dev_test.ru

Ок, я открываю этот сайт, а там авторизация. Как мне туда попасть?
Никак! Идти и узнавать логин/пароль. А зачем, если это легко было исправить указанием логина/пароля в скобках или ссылкой на страницу со всеми логинами и паролями (они все же могут меняться и лучше менять в одном месте)?


Исправленная версия тест-кейса:

Тест-кейс № 03Создание жильца с полным ФИО.

Шаги:
  1. Зайти на сайт www.dev_test.ru (логин - test, пароль - test).
  2. Войти под учетной записью администратора (логин - admin, пароль - 1)
  3. Перейти на вкладку "Жильцы"
  4. Нажать на кнопку "Создать карточку жильца".
  5. Ввести корректные ФИО, например, "Иванов Иван Иванович".
  6. Нажать на кнопку "Сохранить".
Ожидаемый результат

1. Окно с информацией о жильце закрывается и отображается общий список, в котором присутствует новая карточка.
2. Эту карточку можно открыть.
3. В открытой карточке отображаются введенные данные, то есть в поле ФИО указано "Иванов Иван Иванович".


Определения из книг по тестированию

Ron Patton. Software Testing.
Test cases list the specific items that will be tested and describe the detailed steps that will be followed to verify the software.
Тест-кейсы перечисляют конкретные вещи, которые будут протестированы, и описывают детальные шаги, которые необходимо выполнить для проверки программного обеспечения.

Lee Copeland. A Practitioner's Guide to Software Test Design.
The purpose of the test case specification is to specify in detail each test case listed in the test design specification. The test case specification is composed of the following sections:
  • Test case specification identifier - A unique identifier so that this document can be distinguished from all other documents.
  • Test items - Identifies the items and features to be tested by this test case.
  • Input specifications - Specifies each input required by this test case.
  • Output specifications - Specifies each output expected after executing this test case.
  • Environmental needs - Any special hardware, software, facilities, etc. required for the execution of this test case that were not listed in its associated test design specification.
  • Special procedural requirements - Defines any special setup, execution, or cleanup procedures unique to this test case.
  • Intercase dependencies - Lists any test cases that must be executed prior to this test case.
Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:
  • Идентификатор тест-кейса — уникальный идентификатор, благодаря которому данный документ может быть отличен от остальных.
  • Элементы теста — идентифицирует элементы и фичи, которые необходимо протестировать по этому кейсу.
  • Входные данные — описывает каждое входное значение, необходимое для выполнения тест-кейса.
  • Выходные данные — описывает каждый результат, ожидаемый после выполнения тест-кейса.
  • Окружение — любое специальное аппаратное, программное обеспечение, аппаратура и т.д., необходимое для выполнения тест-кейса и не перечисленное в документации по тест-дизайну (верхнеуровневая документация).
  • Особые процедурные требования — описывает любые специальные действия по подготовке к тесту, его выполнению или очистке системы после выполнения кейса.
  • Зависимости — список любых тест-кейсов, которые должны быть выполнены перед данным кейсом.

Гленфорд Майерс, Искусство тестирования программ

Любой тест должен включать две составляющие:
  • описание входных данных программы;
  • точное описание корректных выходных данных для каждого набора входных данных.

На этом, пожалуй, все Smile :)

PS - Огромное спасибо Павлу Абдюшеву за ревью статьи, критические замечания и предложения по улучшению!

PPS - Уже скоро стартует мой курс Онлайн-интенсив для начинающих тестировщиков, в котором мы будем практиковаться составлять тест-кейсы, более полезные чек-листы и прочими полезными вещами! Записаться на курс 1-7 сентября.