Каждому из нас свойственно допускать ошибки. Поэтому сегодня мы поговорим о наиболее распространенных багах, которые постоянно допускают мануальные тестировщики во время создания тест-кейсов.
1. Максимально упрощают тест-кейсы
Порой тестировщики могут настолько упростить тест-кейсы до такого технического состояния, что их не получается выполнить по алгоритму.
Вот наглядный пример подобной работы. Выбираем пользователя в таблице, выпадет контекстное меню с параметрами Edit, Create, Delete и Copy. Надо протестировать, что все доступные опции корректно функционируют.
Довести подобное до автоматизма будет крайне сложно. Во-первых, если тестировщик нажмет на Delete, то он закроет все контекстное меню. Его потом придется открывать заново. Схожие сценарии нигде не описаны.
Во-вторых, пользователь будет удален. Дабы протестировать работу других функций, необходим аккаунт еще одного пользователя. И опять же, подобные вещи нигде в спецификации не указаны.
2. Пересылка в одном шаге на содержание другого
Категорически не рекомендуется в шаге под номером 10, к примеру, создавать тест «Стоит повторить шаги 8 и 9 для пользователя группы admin».
Либо данная проверка вообще должна отсутствовать, либо стоит вынести ее в отдельный шаг. Подобные ссылки могут значительно увеличивать время сдачи поставленного теста в 2, а то и в 3 раза.
3. Допущение ветвления внутри одного тест-кейса
Банальный пример. Перейти на страницу пользователей. Протестировать, что таблица с выбранными колонками email, name и type отображается. Если пользователей нет, провести проверку того, что таблица присутствует.
Подобные действия не нужно делать. Тест должен содержать исключительно один путь; и такой путь определяется некоторыми предусловиями.
4. Попытка автоматизировать неактуальные тест-кейсы
Нужно перетестировать тест-кейсы перед тем, как отсылать их на стадию автоматизированной проверки. Всегда помните, что автоматические тесты разрабатываются значительно медленнее по сравнению с тест-кейсами. А значит, вместо того, чтобы сразу отдавать на автоматизацию до 30 автотестов, стоит передавать их малыми партиями по 4-5 тестов. Вот тогда и не потребуется много времени на актуализацию и выяснение потенциальных причин некорректной работоспособности тестов.
Как же поступать правильно в данной ситуации?
Вот простые, но действенные советы:
- Всегда пишите тест-кейсы внутри корпоративной тест-трекинговой системы;
- Создавайте их в очень детализированном виде;
- Старайтесь избегать повторяющихся тестов и тестовых шагов;
- Описывайте все возможные вспомогательные данные для проверки;
- Старайтесь распределять тест-кейсы так, чтобы автоматизация стартовала с наиболее важных проверок;
- Не нужно объединять массу проверок (тем более сложных) в один тест.
Можно задаться логичным вопросом: почему всегда нужно подстраивать создаваемые тест-кейсы под автоматические проверки, а не наоборот?
Ответ прост: все дело в том, что автоматизация – процесс очень тщательный и очень дорогой в бюджетном отношении. Именно от того, какие конкретные тест-кейсы будут все же переданы в работу автоматизатору, во многом зависит скорость и качество разработки решения по процессу автоматизации.
Жаль, но многие тест-кейсы, которые создаются мануальными тестировщиками, не могут быть автоматизированы. Подобные проверки приходится переделывать и переписывать. А вот у автоматизаторов для подобных вещей не всегда достаточно ни времени, ни желания.
Одним словом, вся надежда на ручных тестировщиков. Если автоматизаторы на входе будут получать качественные тест-кейсы — на выходе будут хорошие автотесты. А это значит, программное обеспечение будет являться качественным и востребованным среди конечных пользователей.
Оставить комментарий