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