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

В этом посте узнаешь про распространённые ошибки, какие повстречал, как их увидеть, как с ними бороться и к чему приводит их допущение.

Кто-нибудь заведёт

Что значит: заметить баг и не завести на него тикет или не убедиться, что он заведён. Чаще всего думают так: «явный баг, кто-нибудь заведёт» или «100% на это есть тикет».

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

Как увидеть: это как раз баги лежащие на поверхности и чаще всего это баги графического интерфейса. Съехавшие кнопки, опечатки в тексте, битые ссылки - это все и есть баги «кто-нибудь заведёт».

Как бороться: ключевая причина проблемы - лень. Все ленятся, и тестировщик не исключение.

Чтобы не стать жертвой этой ошибки нужно:

• Если лень искать баг, написать в чат команды. Так обозначишь проблему и возможно тебе скинут ссылку на заведённый баг. Возьмёшь обязательство перед коллегами, завести баг, и лень уже не победит.

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

N-багов в одном тикете

Что значит: несколько багов объединяют в один при условии схожести, общности шагов и прочим «справедливым условиям». Иногда даже менеджеры, лиды разработки просят завести один на все.

К чему приводит: чинят один, другие остаются. Тратится время на сборку, тест, возврат на починку и нормальное переоформление. Это приводит к сдвигу релиза, переработкам, ухудшению качества тестирования.

Как увидеть: множество несоответствий в фактическом результате, например: «фактический результат: съехала кнопка, текст не соответствует действию, возвращается 500-код по клику».

Как бороться:

• Перечитывать фактический результат. Если несколько дефектов - разбить баг на несколько.

• Мелкие баги графического интерфейса или функциональные можно объединить в одном баге. Например, «цвет кнопки серый и текст съехал» или «в json нет timestamp и date приходит пустой». Но лучше так не делать. Особенно когда ты новичок или проект только начался (можешь не все понимать, лучше завести и закрыть после).

• Если просит менеджер или лид завести в один - заводи. Но обязательно прописывай каждую ошибку и выделяй, подсвечивай, обводи и т.п. Главное, чтобы невооруженным глазом было видно - в баге несколько проблем! Но the best практика - отстоять свою позицию и завести несколько багов.

Артефакты в публичном доступе

Что значит: сохранять скриншоты, скринкасты с незарелизенным функционалом в открытом доступе, не ограничивать доступ к ТЗ в гугл-доках.

К чему приводит: в СМИ появляется инсайдерская информация, убытки компании, сорванный проект, обида команды.

Как увидеть: к сожалению такие вещи сложно отследить. Для этого существуют сисадмины, которые должны контролировать ПО и действия с помощью групповых политик в домене.

Как бороться:

• В настройках любого ПО проверять не сливаются ли файлы в общий доступ

• Проставить в гугл-доках, любых других аналогах - доступ по умолчанию закрыт

• Не рассказывать, не делиться ссылками по секрету с друзьями, бывшими коллегами и т.п.

Искусственное тестирование

Что значит: тестировать на искусственных данных позабыв про использование реальных или похожих на реальные.

Также сюда входит очень тонкий момент - тестирование на проде. Нужно тестировать на проде, но очень аккуратно, и главное помнить, что нельзя ничего трогать глобального (только в рамках тестового пользователя) и без 100% уверенности, что это ничего не сломает.

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

Запуск проекта или релиз новой версии без тестирования на проде это очень редкий кейс, но если имеет место, то часто функционал не запускается (не те пути к базам, нет доступов у пользователей и т.п.)

Как увидеть: чаще всего при тестировании функционала реальными данными или похожими на них появляется больше багов. Если у тебя подозрительно мало багов, то стоит подумать, а используешь ли правильные данные (реальные, похожие).

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

Тестировать в проде

Что значит: значит проходить тестовые кейсы в продовом окружении и оставлять после себя артефакты, который могут увидеть пользователи. Например, тестируешь интернет-магазин и оставляешь после себя товары с названием "Тестовое тесто".

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

К чему приводит: в лучшем случае никто не увидет или увидит забавную карточку товара, а в худшем засветишь тестовые данные учеток или испортишь внешний вид сайта.

Про тот случай, когда есть доступ к CRM и базам, не буду описывать последствия - они понятны.

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

Как бороться: есть много способов:

• создавать виртуальные машины с соответствующим окружением,

• создание профилей для продовой и тестовой среды,

• давать права тестированию только на чтение в проде,

• разворачивать тестовую среду на отдельных URL, серверах и т.п.

Боятся задать вопрос

Что значит: не спросить побоявшись выглядить глупым.

К чему приводит: функционал не протестирован полностью, пропущены критичные баги.

Как увидеть: считаю что есть 2 основные причины

1. Коллеги считают что ты должен все знать

2. Нет 100% уверенности в правильности понимания задачи

Как бороться:

• В случае с коллегами стоит запомнить "спрашивать - твоя работа, не важно , сколько раз, и не важно кажется ли тебе вопрос глупым".

• В случае с неуверенностью перечитай ТЗ, тикеты, переписки и задай вопрос коллегам если потребуется.

Бояться задать вопрос еще раз

Смотри пункт выше.

Слепо верить ТЗ

Что значит: баги документации (логические несоответствия, противоречия, недоработки и т.п.).

К чему приводит: откладывается релиз, блокеры и криты в проде и т.п.

Как увидеть и бороться: про то, как тестировать ТЗ поговорим в следующих постах, поэтому подписывайся и обсудим.

Тестировать в перчатках

Что значит: не оставлять комментариев, артефактов после закрытия тикетов.

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

Как увидеть: после закрытия тикета или перевода в протестирован пробежаться по своим комментариям. Если их нет, то нужно оставить.

Как бороться: если есть возможность в баг-трекинговой системе настроить запрос обязательного комментария при закрытии тикета.

Использовать только исследовательское тестирование

Что значит: не применять другие техники тестирования.

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

Как увидеть: при тестировании изучаешь продукт, т.е. нет четких кейсов с ожидаемым результатом.

Как бороться: использовать подходящие техники, о которых поговорим в других постах (подписывайся и не пропустишь).

Поддержите развитие блога подпиской, лайком, комментарием на Дзене или если удобней в телеграме.