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

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

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

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

Прелюдия

1. Определяемся с юзкейсами: читаем ТЗ, задаем вопросы менеджеру.


2. Составляем список сценариев для проверки. Их может быть много, в зависимости от сложности функционала (количества и сложности юзкейсов)


3. Определяемся, какие внешние системы влияют на работу функционала. И с тем, будем ли мы при этом тестировать внешнюю систему и заводить баги или она предоставляется нам «как есть».

Акт первый

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

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

1. Пользователь регистрируется, добавляет товар в корзину, оформляет заказ и делает платеж.


2. Пользователь регистрируется и добавляет товары в «избранные».


3. Пользователь задает вопрос поддержке через «чат с менеджером»


4. Пользователь сравнивает товары с помощью инструмента сравнения.


5. ...

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

1. Клиент сравнивает товары с помощью инструмента сравнения.


2. Клиент регистрируется, добавляет товар в корзину и делает платеж.


3. Клиент пишет в техподдержку.


4. ...

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

1. Карта проезда для самовывоза на странице контактов.


2. Оплата электронной валютой.


3. Оплата банковской картой.


4. Отправка письма с сайта.

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

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

Акт второй

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

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

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.