Про документацию понятную всем

На заре моей карьеры руководительница наставляла: тест-кейсы должны быть написаны так, чтобы было понятно человеку с улицы. Чрезвычайно живучая формулировка! Прошло немало лет, но неизменно в голове вопрос: зачем человеку с улицы воспроизводить тест-кейсы?

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

На мой взгляд, документация должна быть написана так, чтобы коллега мог быстро воспроизвести сценарий без ознакомления с документацией. Коллега — это вовлеченный человек. Он знает как создать подключение к разным БД, как сгенерировать необходимые тестовые данные. Ни о каком человеке с улицы не может идти речи. Посыл простой: при написании документации нужно думать о коллеге, а не об абстрактном человеке. Мой коллега сможет воспроизвести этот кейс? Все остальное скорее ведет к неврозу и избыточной детализации тестовых сценариев.

А вот то, что действительно важно:

Заголовок. Кратко, но ёмко описывает конкретную цель тест-кейса ― что именно нужно проверить

Предусловия. Условия, которые нужно соблюсти перед началом тест-кейса. Например:
— создать тестовые данные
— добавить системные настройки
— авторизоваться/перейти в нужный раздел

Окружение. Где именно работал тестировщик: на каком устройстве, в каком браузере, в какой ОС.

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

Шаги ― последовательность шагов, которую нужно проделать для проверки. Шаги не должны быть размытыми или абстрактными. Лучше избегать общих фраз вроде «Зайдите в раздел», вместо этого разумно указать точный путь

Ожидаемый результат. Чёткое описание того, что должно произойти в результате каждого шага. Это помогает быстро выявить расхождения между фактическим и ожидаемым поведением

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

ставь 👍 и пиши в комментариях какие формулировки в тестировании раздражают тебя :)

Багов бояться — в прод не ходить

Про документацию понятную всем

На заре моей карьеры руководительница наставляла: тест-кейсы должны быть написаны так, чтобы было понятно человеку с улицы. Чрезвычайно живучая формулировка! Прошло немало лет, но неизменно в голове вопрос: зачем человеку с улицы воспроизводить тест-кейсы?

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

На мой взгляд, документация должна быть написана так, чтобы коллега мог быстро воспроизвести сценарий без ознакомления с документацией. Коллега — это вовлеченный человек. Он знает как создать подключение к разным БД, как сгенерировать необходимые тестовые данные. Ни о каком человеке с улицы не может идти речи. Посыл простой: при написании документации нужно думать о коллеге, а не об абстрактном человеке. Мой коллега сможет воспроизвести этот кейс? Все остальное скорее ведет к неврозу и избыточной детализации тестовых сценариев.

А вот то, что действительно важно:

Заголовок. Кратко, но ёмко описывает конкретную цель тест-кейса ― что именно нужно проверить

Предусловия. Условия, которые нужно соблюсти перед началом тест-кейса. Например:
— создать тестовые данные
— добавить системные настройки
— авторизоваться/перейти в нужный раздел

Окружение. Где именно работал тестировщик: на каком устройстве, в каком браузере, в какой ОС.

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

Шаги ― последовательность шагов, которую нужно проделать для проверки. Шаги не должны быть размытыми или абстрактными. Лучше избегать общих фраз вроде «Зайдите в раздел», вместо этого разумно указать точный путь

Ожидаемый результат. Чёткое описание того, что должно произойти в результате каждого шага. Это помогает быстро выявить расхождения между фактическим и ожидаемым поведением

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

ставь 👍 и пиши в комментариях какие формулировки в тестировании раздражают тебя :)

hottg.com/go_to_production/40

324 viewsApr 24 at 09:44