Все мы прекрасно знаем, как проводить регрисивное тестирование. У нас описаны тесткейсы, есть selenium-тесты, что-то покрыто unit-тестами. Мы почти добились счастья, но тут нам дали новую фичу.
У нас нет тесткейсов, еще нет selenium-тестов. Мы даже не до конца понимаем юзкейсы новой фичи. Как же максимально полно проверить новый функционал?
Я решил написать небольшую памятку для начинающих QA — как же проверить новую фичу.
Прелюдия
- Определяемся с юзкейсами: читаем ТЗ, задаем вопросы менеджеру.
- Составляем список сценариев для проверки. Их может быть много, в зависимости от сложности функционала (количества и сложности юзкейсов)
- Определяемся, какие внешние системы влияют на работу функционала. И с тем, будем ли мы при этом тестировать внешнюю систему и заводить баги или она предоставляется нам «как есть».
Акт первый
Процесс тестирования хочется сделать максимально эффективным. Время на тестирование тоже ограничено.
Решение довольно простое и эффективное. Составим три списка сценариев. Первый из них — отсортированный по критичности:
- Пользователь регистрируется, добавляет товар в корзину, оформляет заказ и делает платеж.
- Пользователь регистрируется и добавляет товары в «избранные».
- Пользователь задает вопрос поддержке через «чат с менеджером»
- Пользователь сравнивает товары с помощью инструмента сравнения.
- ...
Отсортированные по частоте использования пользователями. Например:
- Клиент сравнивает товары с помощью инструмента сравнения.
- Клиент регистрируется, добавляет товар в корзину и делает платеж.
- Клиент пишет в техподдержку.
- ...
Отсортированные по «непредсказуемости» внешних систем. Под непредсказуемостью я имею ввиду, их потенциальную глючность — например внешняя платежная система сложнее устроена, чем отправка писем через postfix — потенциально в ней больше ошибок. Сортируем от самых непредсказуемых, до самых надежных:
- Карта проезда для самовывоза на странице контактов.
- Оплата электронной валютой.
- Оплата банковской картой.
- Отправка письма с сайта.
Мы составили три списка и что же мы получили? Если мы будем проверять сценарии по спискам сверху вниз, один тесткейс из первого списка, один из второго, один из третьего, следующий из первого списка и так далее — мы будем идти от Важных вещей к Не важным. Естественно мы не дураки и два раза одно и тоже, но из разных списков проверять не будем.
Нам дали на тестирование день — мы проверили самое важное. Дали два дня — проверили самое важное и еще немного не такого важного. Дали неделю — проверили все сценарии.
Акт второй
Мы проверили функционал, завели баги и дали их разработчикам. Что дальше? Лично я покрываю эти баги автоматическими тестами. Зачем? Если в «снуля написанном коде» там всплыл баг — значит код этого в месте изначально написан плохо. На него обратили мало внимания, или наговнокодили, или с самого начала вкрутили костыль. Как его будут править разработчики мы не знаем. Может рядом впилят еще костыль?
Покрыв это место автоматическими тестами, например с помощью selenium мы спасамемся от регрессии в «потенциально глючном месте».
P.S. Сильно не бейте, знаю что баян. Многие не знают
Автор: piromanlynx
