tgoop.com/QA_with_a_spoon/37
Last Update:
Про идеальные тест-кейсы - 3
Какие тесты я называю “еретическими”?
Например, такие:
Summary: [Web] Authentication - Log in with valid credentials
Preconditions:
1. <precondition 1>
2. <precondition 2>
Actions
1. Open login page
2. Input valid credentials
Result
1. Application UI is loaded
Peculiarities
1. Example of credentials: username = <username>, password = <password>
2. <peculiarity 2>
3. <peculiarity 3>
Что тут как будто сразу плохо?
У теста максимально неконкретные результаты.
И в целом как будто много вопросов:
1. Как конкретно мы понимаем, что UI загрузился?
2. Почему вообще используем UI в качестве критерия, а не сообщения в логах, например?
3. Почему мы не проверяем, что мы залогинились именно тем пользователем, которому принадлежат юзернейм и пароль?
4. Кто виноват и что делать?Теперь берем и помещаем этот тест в контекст.
В контексте этот тест дублируется end to end проверками различных вариантов логина и атомарными проверками, точечно проверяющими, что у нас происходит под капотом.
В этом контексте существуют люди. Обычно люди чисто визуально отличают ситуацию “я залогинился, работаем!” и “что-то тут не то, надо поисследовать”.
Этим людям порой нужно максимально быстро и дешево по усилиям проверить, что функциональность в целом работает.
Например:
- Smoke / build acceptance testing билдов/релизов
- Поддержка доставок на продакшен силами QA и/или саппорта, когда нужно поверхностно проверить, что система работает нормально
- Отработка failover процедур
- Работа с новичками: когда онбординг только-только начинается и есть задача дать общее (неглубокое) представление о системе (и не напугать прямо сразу)
Во всех этих случаях нет задачи провести глубокое регрессионное тестирование. Это тестирование или уже проведено, или будет проведено в будущем (с помощью других тестов).
Почему просто не написать 100500 нормальных тестов на логин и не использовать самые приоритетные для smoke тестирования или онбординга?
Да потому что нормальные тесты, скорее всего, потребуют нормального времени и ресурсов мозга. В каких-то случаях это будет работать, но только если нормальные тесты написаны так, что их можно выполнить буквально за минуту. Если же нормальный тест это (например) проверка работы токена, то, как мне кажется, лучше написать дополнительный максимально простой тест на “просто логин” и использовать его для smoke тестирования и других похожих целей.
Часто нам нужны быстрые поверхностные результаты, и еретический неидеальный тест кейс с неидеально конкретными результатами тут подойдет идеально.
BY Ужасно медленная QA с крайне неэффективными инструментами в поисках Грааля
Share with your friend now:
tgoop.com/QA_with_a_spoon/37