Как сделать ключ к тесту

Обновлено: 07.07.2024

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

Сразу надо отметить, что все ФИГУРЫ СЛЕВА (1, 3, 5, 7) — это ваше прошлое и настоящее.

ФИГУРЫ СПРАВА (2, 4, 6, 8) - ваше будущее. То есть в каждой паре фигур представлено и прошлое и будущее, и это очень важно учитывать при трактовке полученных значений.

ПЕРВАЯ ПАРА ФИГУР - это ваши мысли, склонность к рефлексии и способность к самоанализу, адекватное восприятие мира. Если вы ЗАКРАСИЛИ ФИГУРУ СЛЕВА, то это значит, что мыслями вы постоянно возвращаетесь к своему прошлому, снова и снова переживаете свои ошибки, критикуете себя и занимаетесь самоедством. Если вы ЗАКРАСИЛИ ФИГУРУ СПРАВА, то это означает, что вы способны извлекать уроки из своих ошибок и, не зацикливаясь на них, стремитесь вперед, к своей цели.
ВТОРАЯ ПАРА ФИГУР - это ваши чувства, эмоции, дружеские и любовные привязанности. Если вы ЗАКРАСИЛИ ФИГУРУ СЛЕВА, то это говорит о том, что вы живете прошлым, вы не способны самовольно отказаться даже от обременительных отношений, освободиться от гнета и груза проблем. Зачастую вы становитесь пленником своих же чувств, от которых не можете избавиться. Если же вы ЗАКРАСИЛИ ФИГУРУ СПРАВА, то можно предположить, что вы свободно распоряжаетесь своими чувствами и никто и ничто не заставит вас цепляться за отношения, отжившие свой срок.
ТРЕТЬЯ ПАРА ФИГУР — это ваши желания и потребности. Если вы ВЫДЕЛИЛИ ФИГУРУ СЛЕВА, то это говорит о том, что вы не развиваетесь как личность, все ваши установки незыблемы, ваши желания и потребности не меняются или меняются еле заметно. Вы просто не задумываетесь над тем, что пора бы что-то изменить в себе и своей жизни, вы довольствуетесь тем, что у вас есть. Если вы ЗАКРАСИЛИ ФИГУРУ СПРАВА то это признак вашего постоянного развития. А вместе с вами изменяются и ваши жизненные установки.
ЧЕТВЕРТАЯ ПАРА - это ваши действия. Если вы ЗАКРАСИЛИ ФИГУРУ СЛЕВА, то это значит, что вы боитесь действовать самостоятельно, вы нуждаетесь в руководителе. Если же вы ВЫДЕЛИЛИ ФИГУРУ СПРАВА, то это говорит о том, что вы самостоятельный и уверенный в себе человек.

^ ВАШИ ЖИЗНЕННЫЕ ЦЕННОСТИ

^ Ключ к тесту

Внимательно посмотрите на ХАРАКТЕР ЛИНИЙ вашего рисунка.

Если все ЛИНИИ на вашем рисунке ТОНКИЕ И НЕБРЕЖНЫЕ, то, скорее всего, вы легкий в общении и веселый человек. Однако если ЛИНИЙ ОЧЕНЬ МНОГО и они неряшливо ПУТАЮТСЯ и налезают друг на друга, то это значит, что вы слишком легкомысленный и ветреный человек, что называется, без царя в голове.

Если вы сделали главный упор на ВНЕШНОСТИ ЧЕЛОВЕКА, тщательно прорисовав все детали лица, конечностей, волос и так далее, то это говорит о вашем желании нравиться противоположному полу. Чем резче ваш рисунок, тем активнее вы себя ведете на любовном поприще. Вы не представляете себе жизни без любви, а любовь — без секса.
Если вы основное внимание уделили ОДЕЖДЕ ЧЕЛОВЕКА, то это означает не что иное, как ваш страх быть самим собой. Вы стараетесь спрятать от людей свою истинную сущность, все время играете какую-то роль, придумываете себе имиджи, лишь бы никому не показать себя настоящего. Возможно, это следствие вашей ранимости — вы не хотите, чтобы вам причинили боль. Или же вы неуверены в себе, стеснительны и робки. Как бы там ни было, вы оберегаете от окружаю свой внутренний мир, поскольку это ваше главное богатство.
Если вы нарисовали рядом с человеком другого ЧЕЛОВЕКА, СОБАКУ, какое-то иное ЖИВОТНОЕ, то сразу можно понять, что вы нуждаетесь в общении. Для вас главная жизненная ценность — это отношения с другими людьми, любовь, дружба, взаимопонимание.
Если вы нарисовали рядом с человеком ДОМ, то это говорит о вашем стремлении достигнуть хорошего положения в обществе, для вас очень важен социальный статус.

Тест 7

^ ОТЫЩИТЕ В СЕБЕ ЗВЕРЯ

Тестовое задание

1. При принятии важных решений вы:

а) советуетесь с коллективом;

б) стремитесь не брать на себя ответственность за принятие решения;

в) принимаете решение единолично.

2. При организации выполнения задания:

а) предоставляете свободу выбора способа выполнения задания подчиненным, оставив за собой только общий контроль;

б) не вмешиваетесь в ход выполнения задания, полагая, что коллектив сам сделает все как надо;

в) регламентируете деятельность членов коллектива, строго определяя, как надо делать.

3. При осуществлении контроля деятельности подчиненных:

а) жестко контролируете каждого из них;

б) доверяете осуществление контроля самим подчиненным;

в) считаете, что контроль не обязателен.

4. В экстремальной для коллектива ситуации:

а) советуетесь с коллективом;

б) берете все руководство на себя;

в) полностью доверяете решение лидерам коллектива.

5. Строя взаимоотношения с членами коллектива:

а) оказываете помощь подчиненным в их личных делах;

б) общаетесь в основном, если к вам обратятся;

в) поддерживаете свободу общения между вами и подчиненными.

6. При управлении коллективом:

а) оказываете помощь подчиненным в их личных делах;

б) читаете, что в личные дела подчиненных нет необходимости вмешиваться;

в) интересуетесь личными делами подчиненных скорее из вежливости.

7. В отношениях с членами коллектива:

а) стараетесь поддерживать хорошие личные отношения даже в ущерб деловым;

б) поддерживаете только деловые отношения;

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

8. По отношению к замечаниям со стороны коллектива:

а) не допускаете замечаний в свой адрес;

б) выслушиваете и учитываете замечания;

в) относитесь к замечаниям безразлично.

9. При поддержании дисциплины:

а) стремитесь к беспрекословному послушанию подчиненных;

б) поддерживаете дисциплину без напоминания о ней подчиненным;

в) учитываете, что поддержание дисциплины – это не ваш конек, и не оказываете давление на подчиненных.

10. В отношении того, что о вас подумает коллектив:

а) вам безразлично;

б) стремитесь всегда быть хорошим для подчиненных, не идете на обострение;

в) вносите коррективы в свое поведение, если оценка негативная.

11. Распределив полномочия между собой и подчиненными:

а) требуете, чтобы вам докладывали обо всех деталях;

б) полагаетесь на исполнительность подчиненных;

в) осуществляете только общий контроль.

12. При возникновении затруднений при принятии решения:

а) обращаетесь за советом к подчиненным;

б) не советуетесь с подчиненными, так как все равно отвечать за все придется вам;

в) принимаете советы подчиненных, даже если их не просили.

13. Контролируя работу подчиненных:

а) хвалите исполнителей, отмечаете их положительные результаты;

в) осуществляете контроль от случая к случаю (зачем вмешиваться?).

14. Руководя подчиненными:

а) приказываете так, что задания выполняются беспрекословно;

б) в основном используете просьбу, а не приказ;

в) вообще не умеете приказывать.

15. При недостатке знаний для принятия решения:

а) сами решаете – ведь вы же руководитель;

б) не боитесь обратиться за помощью к подчиненным;

в) стремитесь отложить решение: может, все образуется само собой.

16. Оценивая себя как руководителя, можете предположить, что вы:

а) строги, даже придирчивы;

б) требовательны, но справедливы;

в) не очень требовательны.

17. В отношении нововведений:

а) скорее консервативны (как бы чего не вышло);

б) если они целесообразны, то охотно их поддерживаете;

в) если они полезны, добиваетесь их внедрения в приказном порядке.

18. Вы считаете, что в нормальном коллективе:

а) подчиненные должны иметь возможность работать самостоятельно, без постоянного и жесткого контроля руководителя;

б) должен осуществляться жесткий и постоянный контроль, так как на совесть подчиненных рассчитывать не приходится;

в) исполнители могут быть предоставлены сами себе.

Бланк ответа

Ключ к тесту самодиагностики стиля управления

Описание теста

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

Интерпретация результата

А – автократический стиль руководства;

Д – демократический стиль руководства;

Л – либеральный (попустительский) стиль руководства.

Что пишут в блогах

• Девять золотых правил написания комментариев к коду.

Онлайн-тренинги

Что пишут в блогах (EN)

Testing at the Crime Scene, Part 3
Five for Friday – January 21, 2022
Writing API tests in JavaScript with Pactum
Get Early Access to Full Site Editing!
Scaling Testing Bubbles
Cypress basics: API testing
yet again. " target="_blank" rel="nofollow">What About Expected Results?
Advice for the New Tester
wordle is fun, quick. " target="_blank" rel="nofollow">Five for Friday – January 14, 2022
first post in this series, we’ll leverage the forensic techniques we started with and apply those to a code crime. " target="_blank" rel="nofollow">Testing at the Crime Scene, Part 2

Разделы портала

Про инструменты

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

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

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

Стандартные атрибуты тест-кейса

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

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

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

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

Шаги

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

Ожидаемый результат

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

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

Недостатки (вытекают один из другого):

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

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

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

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

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

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

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

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

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

Шаги:

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

Ожидаемый результат

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

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

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

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

Шаги:

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

Ожидаемый результат

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

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

Шаги:

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

Ожидаемый результат

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

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

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

Тест-кейсы нужны:

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

Тест-кейсы не нужны:

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

Познакомьтесь со своей системой и потом уже решайте, что подходит именно для нее — творческие чек-листы, формальные тест-кейсы или микс из этих подходов.

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

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

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

Шаги:

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

Ожидаемый результат — карточка создана.

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

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

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

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

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

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

6. Нет нужной информации - непонятно, как авторизоваться
Есть пункт "Залогинься с правами администратора" — отлично, но как это сделать? Увидев этот пункт, я пойду искать кого-нибудь, кто в курсе, есть ли тестовый пользователь с такими правами и какие у него логин и пароль.
Если такой пользователь присутствует всегда (или создается каждый раз для тестирования), то есть его логин и пароль "статические" (не меняются), то их всегда надо прописывать, чтобы не возникало дополнительных вопросов.
Тест-кейсы составляются тогда, когда нужно, чтобы любой человек со стороны, не знающий проекта, мог присоединиться и помочь, выполнить тест-кейсы. Не задавая коллегам при этом дополнительные вопросы.
Тест-кейс я должна уметь выполнять, впервые увидев проект, там должна быть ВСЯ нужная мне информация.

7. Нет описания проверки
"Карточка создана" — кратко, но не емко. Не имея знаний о проекте, тестировщик может только предполагать, что включает в себя этот пункт.
Достаточно ли того, что карточка закрылась без ошибок? Или она должна теперь отображаться в списке карточек? А сколько в системе таких списков? Должна ли система отображать введенные данные, если открыть карточку на просмотр? Что конкретно нужно проверять?

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

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

Шаги:

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

Уже хорошо, но можно ли еще улучшить этот тест-кейс?

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

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

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

Шаги:

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

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

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.

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

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.

Цель спецификации тест-кейсов — описать в деталях каждый тест-кейс. Она состоит из следующих секций:

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

Любой тест должен включать две составляющие:

описание входных данных программы;
точное описание корректных выходных данных для каждого набора входных данных.

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

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

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

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

Для начинающих поясним, что такое тест-кейс озвучив определение из глоссария терминов ISTQB:

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

Определение тест-кейса языком обывателя:

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

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

Обязательные атрибуты для заполнения

Номер тест-кейса — уникальный идентификатор тест-кейса (такие системы как TestRail, TestLink и подобные автоматически присваивают тест-кейсам уникальные номера). Если у вас тысячи тест-кейсов, то при общении с коллегами, вам будет удобнее сообщить номер тест-кейса ссылаясь на него, а не пытаться словами рассказать, где и как найти определённый тест-кейс.
Заголовок — краткое, понятное и ёмкое описание сути проверки.
Предусловия — описание действий, которые необходимо предварительно выполнить или учесть, и которые не имеют прямого отношения к проверке.
Шаги проверки — описание последовательности действий, которые необходимо выполнить для проверки.
Ожидаемый результат — проверка, которая устанавливает, что мы ожидаем получить, после выполнения определённых действий в соответствующем шаге.

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

Правила написания тест-кейсов

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

Примеры

Для наглядности приведу пару примеров. Рассмотрим на примере сайта, на котором вы сейчас находитесь.

Тест-кейс №1. Корректный

Тест-кейс №2. Некорректный

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

Главное в нашем деле практика. Практикуйтесь в написании тест-кейсов.

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

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