Ошибки допускают все, это нормально. Но их нужно разбирать и принимать решения по их недопущению. Это и называется учится на ошибках. А обеспечение качества - это учиться на чужих ошибках. В этом посте узнаешь про распространённые ошибки, какие повстречал, как их увидеть, как с ними бороться и к чему приводит их допущение. Что значит: заметить баг и не завести на него тикет или не убедиться, что он заведён. Чаще всего думают так: «явный баг, кто-нибудь заведёт» или «100% на это есть тикет». К чему приводят: баг незначительный, но так как явно виден большой аудитории, то это причина перенести релиз, завернуть сборку и прочие нехорошие последствия. Как увидеть: это как раз баги лежащие на поверхности и чаще всего это баги графического интерфейса. Съехавшие кнопки, опечатки в тексте, битые ссылки - это все и есть баги «кто-нибудь заведёт». Как бороться: ключевая причина проблемы - лень. Все ленятся, и тестировщик не исключение. Чтобы не стать жертвой этой ошибки нужно: Если лень искать баг, написать в чат команды. Так обозначишь проблему и возможно тебе скинут ссылку на заведённый баг. Возьмёшь обязательство перед коллегами, завести баг, и лень уже не победит. Давать четкие однозначно описывающие названия багам. Такие баги легко ищутся в багтрекерах. Если не нашел, значит нужно заводить. Что значит: несколько багов объединяют в один при условии схожести, общности шагов и прочим «справедливым условиям». Иногда даже менеджеры, лиды разработки просят завести один на все. К чему приводит: чинят один, другие остаются. Тратится время на сборку, тест, возврат на починку и нормальное переоформление. Это приводит к сдвигу релиза, переработкам, ухудшению качества тестирования. Как увидеть: множество несоответствий в фактическом результате, например: «фактический результат: съехала кнопка, текст не соответствует действию, возвращается 500-код по клику». Как бороться: Перечитывать фактический результат. Если несколько дефектов - разбить баг на несколько. Мелкие баги графического интерфейса или функциональные можно объединить в одном баге. Например, «цвет кнопки серый и текст съехал» или «в json нет timestamp и date приходит пустой». Но лучше так не делать. Особенно когда ты новичок или проект только начался (можешь не все понимать, лучше завести и закрыть после). Если просит менеджер или лид завести в один - заводи. Но обязательно прописывай каждую ошибку и выделяй, подсвечивай, обводи и т.п. Главное, чтобы невооруженным глазом было видно - в баге несколько проблем! Но the best практика - отстоять свою позицию и завести несколько багов. Что значит: сохранять скриншоты, скринкасты с незарелизенным функционалом в открытом доступе, не ограничивать доступ к ТЗ в гугл-доках. К чему приводит: в СМИ появляется инсайдерская информация, убытки компании, сорванный проект, обида команды. Как увидеть: к сожалению такие вещи сложно отследить. Для этого существуют сисадмины, которые должны контролировать ПО и действия с помощью групповых политик в домене. Как бороться: В настройках любого ПО проверять не сливаются ли файлы в общий доступ Проставить в гугл-доках, любых других аналогах - доступ по умолчанию закрыт Не рассказывать, не делиться ссылками по секрету с друзьями, бывшими коллегами и т.п. Что значит: тестировать на искусственных данных позабыв про использование реальных или похожих на реальные. Также сюда входит очень тонкий момент - тестирование на проде. Нужно тестировать на проде, но очень аккуратно, и главное помнить, что нельзя ничего трогать глобального (только в рамках тестового пользователя) и без 100% уверенности, что это ничего не сломает. К чему приводит: пользователь получает продукт, который не будет работать в реальных условиях, а значит бесполезен. Запуск проекта или релиз новой версии без тестирования на проде это очень редкий кейс, но если имеет место, то часто функционал не запускается (не те пути к базам, нет доступов у пользователей и т.п.) Как увидеть: чаще всего при тестировании функционала реальными данными или похожими на них появляется больше багов. Если у тебя подозрительно мало багов, то стоит подумать, а используешь ли правильные данные (реальные, похожие). Как бороться: при выборе техники тест-дизайна закладывать в кейсы реальные данные. Обязательно разработать или указать в существующем регламенте выкатки в прод, тестирование на проде. Что значит: значит проходить тестовые кейсы в продовом окружении и оставлять после себя артефакты, который могут увидеть пользователи. Например, тестируешь интернет-магазин и оставляешь после себя товары с названием "Тестовое тесто". Но самое ужасное, если у тебя есть доступ к CRM, базам данных и т.п. и ты ненамеренно удалил что-то важное, например базу с пользователями. К чему приводит: в лучшем случае никто не увидет или увидит забавную карточку товара, а в худшем засветишь тестовые данные учеток или испортишь внешний вид сайта. Про тот случай, когда есть доступ к CRM и базам, не буду описывать последствия - они понятны. Как увидеть: обращай внимание на URL-сайта, какая используется база, какой серверный конфиг и прочие атрибуты окружения. Как бороться: есть много способов: создавать виртуальные машины с соответствующим окружением, создание профилей для продовой и тестовой среды, давать права тестированию только на чтение в проде, разворачивать тестовую среду на отдельных URL, серверах и т.п. Что значит: не спросить побоявшись выглядить глупым. К чему приводит: функционал не протестирован полностью, пропущены критичные баги. Как увидеть: считаю что есть 2 основные причины Коллеги считают что ты должен все знать Нет 100% уверенности в правильности понимания задачи Как бороться: В случае с коллегами стоит запомнить "спрашивать - твоя работа, не важно , сколько раз, и не важно кажется ли тебе вопрос глупым". В случае с неуверенностью перечитай ТЗ, тикеты, переписки и задай вопрос коллегам если потребуется. Смотри пункт выше. Что значит: баги документации (логические несоответствия, противоречия, недоработки и т.п.). К чему приводит: откладывается релиз, блокеры и криты в проде и т.п. Как увидеть и бороться: про то, как тестировать ТЗ поговорим в следующих постах, поэтому подписывайся и обсудим. Что значит: не оставлять комментариев, артефактов после закрытия тикетов. К чему приводит: когда будет разбор почему баг попал в прод, то будет тяжело понять, ты пропустил баг, или повлияло что-то другое. Но если ты не оставил комментария после проверки - ответственность на тебе. Как увидеть: после закрытия тикета или перевода в протестирован пробежаться по своим комментариям. Если их нет, то нужно оставить. Как бороться: если есть возможность в баг-трекинговой системе настроить запрос обязательного комментария при закрытии тикета. Что значит: не применять другие техники тестирования. К чему приводит: пропуск багов, которые быстро и просто находятся другими техниками, например, с помощью таблицы принятия решения. Как увидеть: при тестировании изучаешь продукт, т.е. нет четких кейсов с ожидаемым результатом. Как бороться: использовать подходящие техники, о которых поговорим в других постах (подписывайся и не пропустишь). Поддержите развитие блога подпиской, лайком, комментарием на Дзене или если удобней в телеграме. Инженер по тестированию