7 острых болей в QA – и как с ними справляться

Два готовых решения, один самописный продукт и пара лайфхаков — и у вас в компании будет QA мечты.

Если вы технологическая компания, вам очень нужен грамотный QA. Пока у вас небольшой продукт и мало задач по тестировке, можно не задумываться об организации QA-процессов, работать интуитивно и вручную.

Но по мере расширения продукта перед вами встает выбор: идти по пути машинной тестировки или совершенствовать QA-менеджмент.

Маркетплейс локальных брендов Flowwow выбрал второй путь. Рассказываем, что из этого вышло.

Тест-менеджмент нужен, чтобы все планы держать в одном месте, не терять важные таски и информацию от разрабов. К счастью, эту задачу хорошо решают готовые инструменты, в нашем случае — Qase. Здесь мы храним все тест-кейсы и тест-планы. Больше нигде: никаких сообщений в личку, списков в блокноте и другой самодеятельности.

Часто бывает так: разработчик выкатывает новую фичу и передает ее тестировщику с осознанием выполненного долга. Как Миша Козырев: “Я выкрутился, теперь ваша очередь”.

Мы настояли на том, чтобы все тест-процессы проводились у нас в тесном контакте с разработчиками. Но и контакт должен быть формализован: если разработчик передает продукт в QA со словами “А сюда можно не смотреть, это микроправка, она ни на что не повлияет” — знайте: быть беде. Поэтому мы работаем по принципу “Доверяй, но проверяй” (мы ж тестировщики!).

Завели специальный канал в Slack, куда падают из Qase репорты о тест-ранах. Наши разработчики подписаны на этот канал и выступают в роли наблюдателей: они узнают о том, что прямо сейчас тестируется их код, одновременно с тестировщиками получают информацию о багах — и, следовательно, готовятся их исправлять.

Кроме того, мы организовали внутренний хелпдеск для разработчиков: когда нам надо в экстренном формате что-то посмотреть, разработчик создает тикет, и мы оперативно его подхватываем.

Задача команды QA – точно и объективно определить сроки окончания проверки продукта. Если этого не сделать, то продакт-менеджеры тут же начнут ходить вокруг вас, как итальянские коты, и мурлыкать: quando, quando, то есть — ну когда же будет выполнена задача и мы выставим фичу в бой?

Хорошая новость: если вы имеете дело с одним и тем же продуктом более полугода, то в вашей работе становится меньше неожиданностей. Информация о повторяющихся задачах хранится в Qase, время их выполнения тоже отражено в системе, значит — мы можем с высокой точностью оценить, сколько времени займет похожий тест-ран.

Например, недавно мы тестировали такую опцию, как доставка товаров через СДЭК. Начали с мобильного приложения на iOS, победили, передаем дела на Android с готовой формулой: на тест-ран закладывайте 1,5 часа, плюс по 10 минут на каждый баг. Итого максимум 2,5 часа. Если проверка идет дольше — что-то не так.

Бонус: накопленная в системе статистика позволяет также проанализировать, какие процессы в тестировке занимают больше времени, чем хотелось бы: на чем мы проседаем и как спланировать следующий тест-ран, чтобы не ждать дольше.

У нас очень динамичный продукт: новые версии мобильных приложений выпускаем чуть ли не каждые 2-3 недели. Поэтому часто бывает, что фронт еще не отрисован, а на бэке уже что-то реализовано. Ждать, пока подтянутся все стороны, неэффективно.

В последнее время мы тестируем бэкендные задачи, не дожидаясь фронта, с помощью сервиса Postman. Нам не нужен интерфейс, чтобы отловить базовые баги на бэке. Именно так мы тестируем сейчас нашу новую главную страницу в приложении:

Тестировщику очень важно, чтобы ему быстро сообщали о багах. И не менее важно, чтобы не сообщали об одном и том же баге семь раз подряд с интервалом в 15 минут разными словами.

Чтобы решить проблему дублей, нам потребовалось ввести самописную QA-тикетницу HALP, в которой:

а) указывается автор запроса;

б) прописывается структура бага (то есть не “А-а-а, ничего не работает”, а “Не работает кнопка подтверждения заказа на такой-то странице”);

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

Тикеты видны всем последующим корреспондентам, поэтому они, прежде чем пожаловаться на проблему, внимательно изучают список свежих запросов и проверяют, не написал ли уже кто-то о той же проблеме.

До внедрения системы мы находили среди репортов об ошибке около 35% дубликатов. После внедрения этот показатель не достигает 5%. Дышать тестировщикам стало намного легче.

В любой продуктовой разработке рано или поздно появляются баги, которые никто не драйвит. Они как бы ничьи — а мешают всем. До них всегда не доходят руки, они могут висеть годами.

Нам это надоело, и мы внедрили правило Топ-3. В начале каждой недели определяем три самых неприятных и горячих бага, отдаем их QA-лиду — и он начинает драйвить их в командах разработки и следить за тем, чтобы все было исправлено к концу недели.

За месяц мы основательно подчистили список “висящих” багов. Сейчас в Топ-3 может войти и один, и два бага, а может быть и пять — если были большие изменения в коде.

Самый сильный тестировщик — это активный пользователь продукта. Мы воспользовались этой истиной и стали обучать сотрудников нашей команды саппорта на тестировщиков. 50% нашей команды сегодня — это сотрудники саппорта, получившие повышение и перешедшие на сторону QA.

Это решение позволяет нам:

• Получить уже погруженных в продукт “джунов”,
• Увидеть продукт глазами реальных пользователей, с которыми наши тестировщики общались в течение последних месяцев,
• Повысить в должности и мотивировать классных ответственных сотрудников.

Автотестирование — не единственный способ хорошо наладить QA. Можно действовать более человечным способом, но для этого потребуется использовать комбо из удобных инструментов.

Если ваша QA-команда никогда не называет точные сроки проверок, если разработчики постоянно ссорятся с тестировщиками, если сообщений о багах в три раза больше, чем самих багов — значит, пора что-то менять. Уверены, у вас все получится.