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

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

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

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

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

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

Боль 1: управление процессами

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

Боль 2: оторванность разработки от QA

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

Кадр из фильма "День радио", 2008
Кадр из фильма "День радио", 2008

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

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

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

Боль 3: сроки

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

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

Список тестранов в приложении iOS на этапе подключения доставки через СДЭК. Зеленым цветом выделены успешно пройденные тестраны.
Список тестранов в приложении iOS на этапе подключения доставки через СДЭК. Зеленым цветом выделены успешно пройденные тестраны.

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

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

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

Боль 4: рассогласование фронта и бэка

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

Так все выглядит, когда тестится на бэке без привязки к фронту.
Так все выглядит, когда тестится на бэке без привязки к фронту.

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

Боль 5: повторные сообщения о багах

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

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

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

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

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

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

Так выглядит наша внутренняя тикетница — с указанием авторов запроса, исполнителей и актуального этапа работы.
Так выглядит наша внутренняя тикетница — с указанием авторов запроса, исполнителей и актуального этапа работы.

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

Боль 6: ничейные задачи

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

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

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

Боль 7: дефицит вовлеченных кадров

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

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

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

Что в итоге?

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

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

1313
5 комментариев

Чувствуется, что у вас первый-второй небольшой проект, требующий внутренного тестирования. Все как-то поверхностно и спустя рукава.
Боль 1: управление процессами
Где храните все таски на будущее: фичи, доработки, переработки продукта? Часто они тоже лежат в системе управления проектом, чтобы и активность отслеживать и время затраченное видеть. И знать в каком релизе ожидать.
Боль 2: оторванность разработки от QA
Чат спорное решение, если проект большой и разрабы работают над разными частями. Обычно разрабы знают, что они передали релиз на тестирование. Видят задачу на тестирование. А баги на них распределяет их лид. Но для маленького проекта в самый раз.
Боль 3: сроки
Метрики. У вас ни слова о них. Да, если тестите одно и то же давно, то сроки уже опытным путем установлены. А вообще от сложности тест-кейса и считается от 10 до 30 минут на его тестирование, плюс процент на форс-мажоры.
Боль 4: рассогласование фронта и бэка
Тестирование api. Обычная работа для тестеров. Когда релизят новую версию api часто чисто ее и тестят.
Боль 5: повторные сообщения о багах.
У вас "странные" тестировщики, потому что их одна из первых обязанностей при заведении бага поискать не заведен ли уже такой. И про про структуру бага (название, приоритет, тело и т.д.) - это базовые знания, которые развиваются уже в первую неделю. Кажется, вам стоит провести обучение по этому вопросу.
Боль 6: ничейные задачи
Почему вы отдаете задачи QA-лиду. Это не особо его обязанность тыкать разраба в починку бага. Этим должен заниматься лид-разработки или ответсвенный за тот или иной блок по. Создать список и напомнить про них разработке можно, но висеть коршуном над ними - странно.

1
Ответить

Спасибо за статью! Интересно почитать, как строится работа в других командах! ✌

1
Ответить

Красиво выстроили работу, спасибо что делитесь 👍

Ответить

спасибо за отзыв!

Ответить

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

Ответить