Пока нет оценок.
Пожалуйста, подождите...

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

1. Максимально упрощают тест-кейсы

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

Вот наглядный пример подобной работы. Выбираем пользователя в таблице, выпадет контекстное меню с параметрами Edit, Create, Delete и Copy. Надо протестировать, что все доступные опции корректно функционируют.

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

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

2. Пересылка в одном шаге на содержание другого

Категорически не рекомендуется в шаге под номером 10, к примеру, создавать тест «Стоит повторить шаги 8 и 9 для пользователя группы admin».

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

3. Допущение ветвления внутри одного тест-кейса

Банальный пример. Перейти на страницу пользователей. Протестировать, что таблица с выбранными колонками email, name и type отображается. Если пользователей нет, провести проверку того, что таблица присутствует.

Подобные действия не нужно делать. Тест должен содержать исключительно один путь; и такой путь определяется некоторыми предусловиями.

4. Попытка автоматизировать неактуальные тест-кейсы

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

Как же поступать правильно в данной ситуации?

Вот простые, но действенные советы:

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

Можно задаться логичным вопросом: почему всегда нужно подстраивать создаваемые тест-кейсы под автоматические проверки, а не наоборот?

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

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

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

Оставить комментарий

WP Facebook Auto Publish Powered By : XYZScripts.com