Тестирование нового функционала. Памятка тестировщику

в 14:46, , рубрики: selenium, баги, Веб-разработка, интернет-магазины, никто не читает теги, тестирование, метки: , , , ,

Все мы прекрасно знаем, как проводить регрисивное тестирование. У нас описаны тесткейсы, есть selenium-тесты, что-то покрыто unit-тестами. Мы почти добились счастья, но тут нам дали новую фичу.

У нас нет тесткейсов, еще нет selenium-тестов. Мы даже не до конца понимаем юзкейсы новой фичи. Как же максимально полно проверить новый функционал?

Я решил написать небольшую памятку для начинающих QA — как же проверить новую фичу.

Прелюдия

  1. Определяемся с юзкейсами: читаем ТЗ, задаем вопросы менеджеру.
  2. Составляем список сценариев для проверки. Их может быть много, в зависимости от сложности функционала (количества и сложности юзкейсов)
  3. Определяемся, какие внешние системы влияют на работу функционала. И с тем, будем ли мы при этом тестировать внешнюю систему и заводить баги или она предоставляется нам «как есть».

Акт первый

Процесс тестирования хочется сделать максимально эффективным. Время на тестирование тоже ограничено.

Решение довольно простое и эффективное. Составим три списка сценариев. Первый из них — отсортированный по критичности:

  1. Пользователь регистрируется, добавляет товар в корзину, оформляет заказ и делает платеж.
  2. Пользователь регистрируется и добавляет товары в «избранные».
  3. Пользователь задает вопрос поддержке через «чат с менеджером»
  4. Пользователь сравнивает товары с помощью инструмента сравнения.
  5. ...

Отсортированные по частоте использования пользователями. Например:

  1. Клиент сравнивает товары с помощью инструмента сравнения.
  2. Клиент регистрируется, добавляет товар в корзину и делает платеж.
  3. Клиент пишет в техподдержку.
  4. ...

Отсортированные по «непредсказуемости» внешних систем. Под непредсказуемостью я имею ввиду, их потенциальную глючность — например внешняя платежная система сложнее устроена, чем отправка писем через postfix — потенциально в ней больше ошибок. Сортируем от самых непредсказуемых, до самых надежных:

  1. Карта проезда для самовывоза на странице контактов.
  2. Оплата электронной валютой.
  3. Оплата банковской картой.
  4. Отправка письма с сайта.

Мы составили три списка и что же мы получили? Если мы будем проверять сценарии по спискам сверху вниз, один тесткейс из первого списка, один из второго, один из третьего, следующий из первого списка и так далее — мы будем идти от Важных вещей к Не важным. Естественно мы не дураки и два раза одно и тоже, но из разных списков проверять не будем.

Нам дали на тестирование день — мы проверили самое важное. Дали два дня — проверили самое важное и еще немного не такого важного. Дали неделю — проверили все сценарии.

Акт второй

Мы проверили функционал, завели баги и дали их разработчикам. Что дальше? Лично я покрываю эти баги автоматическими тестами. Зачем? Если в «снуля написанном коде» там всплыл баг — значит код этого в месте изначально написан плохо. На него обратили мало внимания, или наговнокодили, или с самого начала вкрутили костыль. Как его будут править разработчики мы не знаем. Может рядом впилят еще костыль?

Покрыв это место автоматическими тестами, например с помощью selenium мы спасамемся от регрессии в «потенциально глючном месте».

P.S. Сильно не бейте, знаю что баян. Многие не знают

Автор: piromanlynx

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js