Пишем максимально эффективный тест-кейс Хабр

13 Feb Пишем максимально эффективный тест-кейс Хабр

Методика позволяет сократить количество тестов, при этом ничего не теряя в покрытии. Если ввод булевый (true или false), то создаются тест-кейсы для обоих значений, и true и false. Если на ввод подается набор значений («перечисление»), то тест-кейсы делаются (тоже) с 1 валидным значением и с 2-мя невалидными. Формулировки шагов тест-кейса не должны вызывать вопросов, но при этом не надо писать очевидные вещи. Это создает путаницу между различными тест-кейсами одного проекта.

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

Описание

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

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

Тест-кейсы и чеклисты

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

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

Чем отличается тест план от тест кейса?

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

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

Правило Пресмана

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

• При внедрении в работу данной документации не придется каждый раз заново придумывать проверки и бояться что-то упустить.
• Открывается окно ввода логина / пароля с соответствующими полями для ввода, кнопкой “Войти” и сообщением “Для входа в систему введите, пожалуйста, свои данные”.2.
• Чаще всего («статистически») предметом проверки тест-кейсов являются кнопки, поля ввода и т.п.
• Тестировщики должны выбрать подходящие для проекта инструменты и убедиться, что они знают, как правильно их использовать.
• Дает возможность примерно оценить трудозатраты на разработку и тестирование еще до начала работ.
• Поэтому нет необходимости каждый раз заглядывать в документацию с требованиями к ПО.

Предварительные условия (pre-condition) — шаги, которые необходимо выполнить перед началом тестирования по этому тест-кейсу. Думаю, что даже противники бумажной волокиты не будут отрицать, что описанный план проверки значительно упрощает процесс тестирования и экономит в последующем кучу времени. В те самые давние времена, когда я пришла в Утконос, у нас не было столько команд, сколько есть сейчас. Сегодня в Утконосе более 10 фича-команд, которые пилят разный функционал.

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

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

Чем отчет о дефекте отличается от чек-листа?

Тест-кейс работает как бы «на тактическом уровне». Он описывает, что QA-инженеру нужно сделать и в каком порядке, и детализирует ожидаемые результаты. А еще у нас есть специальный раздел, посвященный процессам и методологии тестирования.